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.

TUSB8042: Compatibility with TUSB8044

Part Number: TUSB8042
Other Parts Discussed in Thread: TUSB8043, TUSB8044, TUSB8040, TUSB8041,

Because of assurance of supply (AOS) issues I am looking at loading a TUSB8044[A] or TUSB8043 in place of a TUSB8042RGCT part currently on my board.

It looks like the register defaults are all the same and I have pin 49 pulled low through an external resistor.
I am using the upstream port and 4 down stream ports.

I have the SMB bus pinned out but not connected externally so I want to make sure it will power-up and operate the same with my current bootstrapping and the default register loading will work.

Bootstrapping:
pins 49, 40, 42 and 45 - pulled low through 4.64K
pin 39 floating.
pin 50 pulled to 3.3V through 10K tied to 1uF on the pin 50 side.
The overcurrent and port pins are connected.

It LOOKS like this will all be compatible between ICs but I wanted to confirm we don't have problems loading the 8044 instead of the 8042.

Thanks!
Warren

  • Pin 41 is also floating through a 0 ohm resistor that isn't connected.

  • Hi Warren,

    This looks compatible.  Documents outlining the differences between the hubs are here:

    www.ti.com/.../slla377.pdf
    https://www.ti.com/lit/an/slla445/slla445.pdf

    Please note that when using a passive reset (external capacitor) we do not recommend external pullups on GRSTz since it already has an internal pullup.

    Regards,

    JMMN

  • Yes, thank you! I found both of those documents and they gave me some assurance that the substitution was possible.
    As to GRSTz I don't have a 10K to a controlled 3.3V that feeds the capacitor. Are you saying the 10K is unnecessary? I can just connect the capacitor to pin 50? Does it get pulled up to the VDD33 pins? If so, that is the same power supply where I am connecting the 10K.
    Timing requirement of tD2 said VDD3 had to be stable for 3ms before I let go of the GRSTz and so that is why I used that supply.
    ALSO...
    Note 2 of Table 7.6 of the datasheet says that I must have a 10us stability of VDD BEFORE VDD3 if I only have an external capacitor, and since I wasn't sure of that, I have the resistor connected.
    I will have to re-do my measurements to make sure I'm meeting the 3ms timing, but it looks like I should be fine.

  • GRSTz has an internal pullup to 3.3V, adding an external 3.3V pullup will shorten the reset timing when using a RC circuit for reset.

    As long as 3.3V and 1.1V are ramping together, there is no issue using the passive reset circuit. Since we were concerned about customer delaying the 1.1V ramp after the 3.3V ramp, the wording was added to the datasheet. The potential issue with 3.3V ramping before the 1.1V is that the passive reset circuit relies on the external capacitor and an internal pullup to 3.3V, if the 1.1V ramps well after the 3.3V ramp there is a chance the reset would end before the hub is fully powered.

    A 1uF capacitor on GRSTz is fine for most applications, but if the power supply ramp time is long, you may need to increase it to 2 uF to meet the power on reset timing conditions.

    Regards,

    JMMN

  • Hi,

    You shouldn't have any issues using TUSB8041 instead of TUSB8042/A.  They are both 5 Gbps, just compliant to different versions of the USB 3.x specification.  The TUSB8041 is not marked NRND.  The much older TUSB8040 is marked as NRND, however, but that has a different package and couldn't be used with your design.

    Please note that for best interop performance the TEST pin should be pulled low in the design.  It isn't required for all versions of the hub, but if you are changing them it is best practice to have it pulled down. Also, since the TUSB8041 is compliant to an older version of the specification, it will allow downstream ports to enter USB 3.x compliance mode if they detect the receiver terminations but polling doesn't complete - this is different from later versions of the hub that require a command for a USB host to enable entry to compliance mode. 

    Regards,

    JMMN