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.

TUSB8044A: No data on Downstream Ports

Part Number: TUSB8044A

Hello,

I have designed an USB Hub wit 4 outputs.

The issue i see is on the downstream ports where there are camera modules connected. Upstream port seems to work, HUB is visible on the PC side,

The issue is located to the Crystal side , the chip comes out of reset and sees no Clock. Please check the pictures attached.

One picture present the behavior of the Crystal on EVM and rest of them are on the custom hub.

Downstream port is connected to a camera module and Upstream to the PC, same setup used on the EVM.

Crystal on custom board is trying to wake before the chip comes out from reset but something stop him , there are multiple tries before the CLOCK is actually  present, so the chip comes out of reset and doesn’t see the CLOCK, so this result in an undefined behavior. We don’t know what can cause this.

Could you please help us with some hints?

Desktop.rar

  • Hi,

    Would you be able to share your schematic so that I may get more similar with your custom board? Does you 3.3V rail have any issues at power-up? A wave form with 3.3, 1.1, GRST and XI would be helpful? Is it possible there may be some soldering issue with the TUSB8044A IC? In some cases when the GND pad does not have ample solder or bad connection it can cause issue. Can you see this issue on multiple platforms across multiple parts? 

  • Hi,

    The clock behavior looks ok. Here’s a scope plot of the clock on our EVM if you power on the EVM with a host connected and a downstream device attached without an EEPROM and not in SMBUS mode (attached). The clock will stay on longer if the hub has a valid EEPROM installed or if it is in SMBUS mode.

    I would recommend removing the EEPROM attached to see if that is causing any issues. If a blank EEPROM is attached to the hub, the hub will default to configuring itself as a programming endpoint.

    Also, as a debug step once the clock is running you can try force resetting the hub (just short GRSTz to ground briefly) to see if that impacts behavior.

    If you continue to have issues can you send scope shots of the upstream DP / DM lines?

  • Also, this ticket is being handled internally via TI rep.  I will close the E2E thread and we will continue to address on internal thread.