Using two TUSB2077A chips, one downstream from the other

Yes, it is possible.

The 2nd Hub should have the same sort of configuration as the one connected directly to the host.

You probably have a timing issue, you have to wait until the first hub is enumerated by the host to release the reset signal from the second hub.

The enumeration of the first hub is complete aprox 300ms after power-up.

Also, the second hub must be configured as a self-powered hub.

You can send your schematic for review.

Regards.

Thanks for the reply. The 2nd hub is configured as self-powered, and in general is configured in the same way as the first. Could you explain a bit about possible timing issues? Other than sitting and waiting, I'm not sure what I can do to address that issue.

I don't think I can release the schematic but it is as simple as could be--one USB input to the first hub IC, which is connected to five output ports and a second downstream hub IC, which likewise fans out to five output ports. The physical board is quite long, though--could this be a layout/signal integrity issue? The first chip is right next to the USB connector but the second is about six inches away. Any other ideas for what might be preventing the second chip from being configured would be very much appreciated.

Hello, the length of the traces are definitely something to take care of, you can see the document at the following link http://www.usb.org/developers/docs/hs_usb_pdg_r1_0.pdf

1) How long do you hold low the RESET signal for the 1st and 2nd hub after the power rails reach its 90%?

2) Is the same power rail/source for both hubs?

3) Is the SUSPEND output active on the 2nd hub?

4) Is the input clock running on the 2nd hub?

5) Check the power rails meet the specification.

6) Do you have a 1.5k pull-up installed on DP0 of the 2nd hub?

If you don't want to post your schematics you can email direct to elias.villegas@ti.com

Regards.

That document was my go-to guide during this design, but it's still possible my layout was not quite adequate.

In reference to the other items, please see the schematic I've sent you via e-mail:

1.) Both reset lines are tied to the power rail. I suspect this may be the timing culprit--should the second hub have a delay that holds its reset line low for a few hundred milliseconds?

2.) Each hub is on its own power rail, but each rail comes from the same overall supply (common battery -> separate DC/DC converters -> separate LDOs).

3.) I will check this when I have access to the hardware tomorrow--I assume that if the hub is not functioning, suspend will be high. Would that give me any new information? Is there any reason to expect it to be low?

4.) Each chip runs on its own 6 MHz oscillator. I suspected this might be the issue, but shouldn't it be possible to do this anyway? Is there any reason having independent oscillators could cause problems?

5.) The 3.3V power rails do not deviate from the specified 3.0-3.6V range and can source adequate current.

6.) There is indeed a 1.5k pull-up from DP0 to DP0PUR at the second hub.

Thank you.

Hello Jeff,

I've reviewed your schematics and have the following comments:

a) You are using the TPS3825-33 for generating a power-up reset signal, this IC has a watchdog timer fixed to 200ms, per USB specification a USB device must be able to communicate with the host within the 100ms after power-up. You need to ensure the reset signal for the first hub is low from 1ms to 3 ms after power rails reach its 90%. You can do this by just adding a RC circuit at the RESET# input to generate the delay (a 20K resistor along with a 0.1uF cap will do the job). With the same method you can add a longer delay to the second hub(60ms).

b) The schematic does not show the 33ohm series resistors, 22pF edge control capacitors and 15K pull-downs on the DP0 and DM0 of the second hub, this components must be populated.

c) Tie to 3.3-V all the unused OVERCUR# terminals.

d) Terminate to ground via a 15K resistor all the unused downstream ports.

Regards.

Elias,

Thanks for looking over the schematic. Could you possibly elaborate on the timing requirements? I've modified the hardware to (1) include the necessary discrete components on the data lines at JT3 and JT4 and (2) allow the second hub to be held in reset as long as desired. Shouldn't it be possible to hold the second hub in reset, connect the first to USB, allow enough time for initialization, and then release the second hub from reset so that the first hub identifies it? I'm also unclear on whether the second hub should be held in reset for 60ms or 300ms, as you mentioned in an earlier post.

Thanks again.

Hello Jeff,

If you can hold the second hub in reset the time you want that would be great. Wait until the first hub is enumerated and then release from reset the second hub is also a good approach. The 60 and 300 ms were just proposals since we can't know how long will the enumeration be, we only know that the enumeration will start within 100ms after power-up.

Regards.

Are there any constraints on which upstream ports can be connected to downstream hubs? I've found that connecting port 5 of the first hub to the input of the second hub, as well as adding 22-ohm series resistors and 15k pull-downs in parallel with 10pF caps at JT3 and JT4, allows the second hub to communicate successfully with the first. However, mimicking this situation at port 6 (to the second hub) does not show successful results.

There are no constraints, make sure your first hub is self-powered and there is nothing "broken" between the connection.

Can you switch the downstream hubs? Is the Port 6 always the failing-one?

Regards.

Both hubs are self-powered, and the connections are solid. Port 6 is always the failing one, but it may not have anything to do with port 6 itself--I can't switch the configuration to test this. One difference is that the other data lines have ESD protection ICs on them, whereas the port 6 lines do not. I can't imagine this has any effect, but it seems to be the only difference. I also scoped the data traces between the hubs and found that absolutely no data is communicated from the first hub to the second (unless I modify the hardware to connect port 5 to the second hub, as I mentioned above). The only sort of communication is that the D+ line is asserted low for 125 ms, then returns high.

Hello Jeff,

You say that the 2nd hub works on port 5. Is the port 5 also a long distance away from the downstream device(2nd hub)?

Are you able to take some bus traffic trace captures? Also, there is the option to ship us your system for debug.

Regards.