This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TUSB2077A: /BusPwr signal causes three highest-numbered ports to disable when low!

Part Number: TUSB2077A
Other Parts Discussed in Thread: TUSB2046B

Transitioned a design from the TUSB2046B 4-port hub to the TUSB2077A 7-port hub. I could only get four of the seven ports to initialize. With the help of TI engineering (Thanks, Julie!) I learned that the TUSB2077A has an undocumented "feature". It's not mentioned in the manual, although it may once have been.

When /BusPwr is set low, it means that the device and downstream ports are powered from the upstream USB. Since there's a 500ma current limit, and 100ma is allocated for the hub chip, that leaves only 400ma (100ma per port) available. The part disables the highest three ports to comply with the standard. In bus powered mode, it's a four-port hub. It's only a 7-port hub in self-powered mode with /BusPwr set high.

The TUSB2046B has nearly the same control pins, but critically, the logical state of the BusPwr pin is HIGH for a bus-powered device, not low. When I substituted the 2077A, I missed the fact that the state of the /BusPwr pin had been flipped. I had it set low previously, as it was self-powered. 

In other news, there is no harm in using a long reset time, so long as the reset completes before the upstream device comes on line and starts looking for the USB hub. In my case, the 3.3V supply has a fairly slow ramp-up time, and I'm using a simple R/C time delay. Reset must not release until after power has stabilized AND the crystal oscillator is stable. Wtih a slow ramp time and a couple of milliseconds for the crystal to come up, it's difficult to have a simple RC far enough behind the power rail to provide enough delay, using the book value of no more than 1ms. That limit is driven by the requirement of responding to a USB connection from a live device already booted up. In my embedded system case, the PC side is still booting up and doing power-on testing long after the embedded board has powered up and become ready. I'm using 4.7K and 10uf, which gives me more like 40ms of delay.

Problem solved thanks to Julie's advice. I wanted to write it up here so that some future engineer tearing their hair out over this weird problem might find it before they're completely bald.