TUSB2036: Data lines on DP1 to DP1 remain low and oscillator swing up takes very long

1. The devices connected to the downstream ports should enable their DP pullup when they are connected, does that happen?

2. Clock timing may vary based on power ramp and reset timing, what is the yellow signal in the trace?

Also, ports 1 and 2 are marked as non-removable, is that expected?

Regards,

JMMN

Thanks for your answer.

1. No, the DP pullups remain on low state.

2. The yellow trace is a signal on the upstream port of the hub. Note that there is a small spike at cursor 1. This is the sent signal.

Well, all three ports are non-removable. So I tied both, NPINT0 and NPINT1, to Vcc.

Regards

1. The DP pullups should be turned on by the downstream devices when they see power (VBUS) go high.  The hub cannot access the devices until that happens.

2. What is the yellow trace?  DP or DM?  And what signaling is the host sending?  It doesn't look long enough to be a reset?

Regards,

JMMN

1. Ok, so I have to check the downstream devices.

2. Ah, sorry, it's DP. I just didn't know about the bus reset before. I will check it out tomorrow when I'm back at work.

Thank you.

Regards

Ok, so far I checked it out and with your hints I now understand some more points of the USB bus.

2. I didn't switch on the frame markers on the host. That's why the oscillator stopped working after a few milliseconds. Also in this way it doesn't matter, that the clock takes 3ms to swing up since it's just one time at the beginning.

Thank you very much for your help!

Regards,

No Body

Ok, let us know if you have more questions!

Well, one more questions I have:

Unfortunately the DP lines of all three downstream ports still remain low. I checked the downstream devices; they work properly because when I disconnect them from the hub, the DP line is properly pulled to high state.

Could it be, that the hub pulls the DP lines low as long as the hub isn't initialized (enumerated) correctly?

What does the signaling on the upstream port look like?  Can you give me a scope plot of DP and DM?

Here's the signaling on DP and DM when I send the Get_Descriptor command from the host to the hub.

C3 is DM, C4 is DP.

Ok, that signaling looks ok.  For the downstream devices, can you confirm that they are powered (VBUS is on)?  The pulldowns are 15K, and the pullup on the device's DP is 1.5K so the hub will not hold the line low.

The downstream devices are powered. Since the devices (mPCIe data cards) have no VBUS-pin, the VBUS must be connected internally to the main power Vcc. This is also confirmed when I unsolder the 33R resistors on the DP and DM line (so there's no connection to the hub anymore) since then the DP line is pulled high.

My devices at the downstream ports are self-powered. Could it be, that I made a mistake with the PWRON or OVRCUR pins?

The hub will not drive the downstream DP/DM lines until it sees a connect event from the DP pullup.  Can you ohm out the lines and see that the resistance is?

Well, since the pull-up probably isn't connected directly to Vcc, but only to a switch which connects to Vcc (like the pullup of the upstream port of the hub isn't connected directly to Vcc but to DP0PUR), that won't be possible. But I ohmed it out and measured several hundred kilo-ohms.

Sorry, I wasn't clear.  I meant to ohm out the DP/DM lines from the hub.  They should only be 15K to ground.

Thank you for your reply.
I measured the DP and DM line from the hub to GND. One port showed only 3K, the others where ok. And between DP and DM line of the same port I measured only 2.8ohms.

I changed the hub. Now the DM and DP lines of all ports have 15K (and 29K between DP and DM). But the DP line still remains low.

If the DP lines only have 15K pulldowns, and the devices are enabling a 1.5K pullup, you should be able to see DP go high.  The hub won't drive those pins low until after a device has been detected and the host sends a USB reset.

Regards,

JMMN

Unfortunately I still couldn't find the error. I'm not sure, if I understand the function of the OCPROT/PWRSW correctly. In the datasheet it's explained on page 5. Could you shortly explain its function regarding a self-powered hub?

The OCPROT/PWRSW setting just changes what the hub reports to the host in its descriptors.  For a self powered hub if it is low, that indicates that port power switching is enabled.  This isn't true for your system but functionally it should not have an impact.

What does the host report with the hub is connected?

Regards,

JMMN

Sorry for the late reply.

JMMN said:

The OCPROT/PWRSW setting just changes what the hub reports to the host in its descriptors.  For a self powered hub if it is low, that indicates that port power switching is enabled.  This isn't true for your system but functionally it should not have an impact.

Ok, thank you.

JMMN said:

What does the host report with the hub is connected?

The first eight bytes of the device descriptor are as follows:

- bLength: 0x12 (18 bytes)
- bDescriptorType: 0x01 (DEVICE)
- bcdUSB: 0x0110 (USB1.1)
- bDeviceClass: 0x09 (hub)
- bDeviceSubClass: 0x00
- bDeviceProtocol: 0x00
- bMaxPacketSize0: 0x08 (8 bytes)

I do not know, why bcdUSB reports USB1.1 since the TUSB2036 is a USB2.0 hub.  Is there any reason for that?

Thank you for your response.

Regards,

No Body

The TUSB2036 is a USB Full Speed hub (12 Mbps).  What downstream port status is reported?