• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 3 answers
  • Subscribers 33 subscribers
  • Views 1006 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TUSB8041: Enumeration Issues

Darren (FAE)
Expert 5483 points
Part Number: TUSB8041
Other Parts Discussed in Thread: TUSB542

Customer is experiencing some issues with the TUSB8041.

1. During power-cycle test, the USB3.0 HUB is not properly recognized
2. During low-temperature startup test, there is leakage to 1.1V

Internal TI Drive Link to Detailed Issue Description

SBD of use-case is on p5, schematics on p6,7
The setup is Host - TUSB8041 #1 - TUSB8041 #2 - USB3 connectors
Abnormalities / summary of tests shown on p3
Waveforms on p4

Problem 1:
- During OFF/ON power-cycle test, about once every few-hundred times, the 2nd TUSB8041 hub doesn't get recognized
- 1st NG Issue:  2nd TUSB8041 HUB is not recognized by Host PC
- 2nd NG Issue: The 2nd TUSB8041 HUB identification fails, and the Host PC shows the Δ! mark
- 3rd NG Issues: Both the 1st/2nd TUSB8041 HUBs are not recognized by Host PC
For 1st / 3rd above, even when GRSTz was pulled to GND, the HUBs did not recover.

Are there any thoughts on to what could be causing this?

Problem 2:
- Under low-temperature power-on testing, before 1.1V rail is powered up, there seems to be 200mV of leakage on the line
- Due to the following, we believe this is leakage due to TUSB8041 HUB:
1) By removing the TUSB8041 HUB the condition resolves itself
2) Using a cooling-setup to specifically target only the TUSB8041 and cool it, causes the condition to occur

Are there any thoughts on to what could be causing this?

Other:
The setup doesn't use an EEPROM, and OTP is Default settings.
Reset is an Active Reset. Power is supplied 3.3V then 1.1V.
10ms after the 1.1V rises, Reset is released.

Regards,
Darren

  • 0
    TI__Guru 60870 points

    Hi Darren,

    For these issues, #2 seems like standard bad connection / protocol issue that could be linked to signal quality or an unexpected event.  Issues #1 and #3 are strange since they appear similar to an issue with a USB 3.0 port going into compliance mode, but a hub reset should have cleared the issue.  Are the resets to the hubs done simultaneously and are they done while the hubs are disconnected from the host?  Was there any error reported from the host side about disabled ports?

    I'll need to check with the internal team on possible leakage at low temp.

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 5483 points

    Hi JMMN, I have some replies from the customer.

    JMMN said:
    #2 seems like standard bad connection / protocol issue that could be linked to signal quality or an unexpected event. 

    Yeah, let's focus on #1 and #3, and these problems aren't resolved with GRSTz - so they could be hardware-related.

    JMMN said:
    Are the resets to the hubs done simultaneously

    They reset HUB #1, then HUB #2 - they haven't tried GRSTz on both HUBs at the same time.

    JMMN said:
    are they done while the hubs are disconnected from the host?

    The Host PC is connected to the HUBs for the reset

    JMMN said:
    Was there any error reported from the host side about disabled ports?

    It's not like every log was checked for errors, but what was checked didn't show any errors.
    Also, when GRSTz was issued, the Device Manager on the PC refreshes, but there was no error message.

    JMMN said:

    I'll need to check with the internal team on possible leakage at low temp.

    Thank you. There is another E2E post about the 3V3 rail leaking to 1V1 rail during power-up, but the answer wasn't public. Could you confirm?

    Regards
    Darren

  • 0 in reply to Darren (FAE)
    TI__Guru 60870 points

    HI Darren,

    The "leakage" in the other thread was measurement noise, we were not able to see any leakage during lab testing.  I'll check with the quality team on low temp leakage.

    Issue #3 could be the host port entering compliance mode - that will happen if the first LFPS polling handshake after power on fails.  And if that were the case, no amount of resetting of the hubs would impact it, the host would need to be reset or the host driver reloaded.  Does that match your understanding of the issue?

    I'm still looking at issue #1 since it appears like an unexpected compliance mode entry but it should be cleared by resets.

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 5483 points

    Hi JMMN,

    I was looking through the schematics, and there are a few points I want to mentions that stood out to me.

    1) Design uses external oscillator powered from 3.3V, with a voltage divider at the output so the TUSB8041 sees a 1.8V clock signal - this is fine?

    2) The HUB1 VBUS follows the DS recommendation for 90.0k and 10k resistor divider for USB_VBUS, but HUB2 uses the EN output of HUB1 to "detect" when VBUS is applied. They use a different resistor divider ratio to do this, as the EN output (PWCTL1/BATEN1) is 3.3V logic.

    3) The VDD33 and VDD are powered from DC/DC converters - 3.3V powers up before 1.1V. But GRSTz is held low for ~10ms after both rails are turned on, before going High. This seems fine...but any thoughts?

    4) reviewing p6/7 of the document linked in original post...I noticed the SSTX± lines for DN ports don't have AC coupling caps. I confirmed with customer, and it looks like for HUB2, the caps are by the connector (so not in the schematic) - but they might be missing SSTX caps between HUB1 and HUB2...having them check just in case.

    I understand you need the AC caps, as the devices use them and a resistance presented to the SS lines by each device, to detect the RC time constant and see if there is a device attached. Without the AC caps, could the system ever enumerate? If yes, then could this be a reason HUB1 connects, but HUB2 fails?

    5) You said for Issue#3 above, the Host Port could be entering compliance mode...Could you point me to where (page numbers) in the USB3 spec it discusses hubs and compliance mode, and what could cause this? 

  • +1 in reply to Darren (FAE)
    TI__Guru 60870 points

    Hi Darren,

    Has the customer seen the leakage on multiple units?  If it is limited to a single unit, let me know if you want to arrange for it to be returned.

    1. Voltage divider on the oscillator is fine.

    2.  USB_VBUS resistors can be adjusted based on the driving voltage, it should switch around 500 mV.

    3. Reset timing sounds valid.

    4. I have never tested the hubs without the AC caps, I'm not sure what the expected behavior would be.

    5. Section 7.5.5 / 7.5.4.3.2 in the USB 3.2 specification covers compliance mode and its entry.  Please note that the TUSB8041 was designed during the USB 3.0 / early USB 3.1 time period and its downstream ports can enter compliance mode without being specifically enabled to do so (this changed to match the spec updated in the later hubs).

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 5483 points

    Hi JMMN, 

    I clicked "this resolved my issue" instead of reply...

    Anyway, it looks like they were missing the AC caps between the two TUSB8041 upstream/downstream hubs on the SSTX lines. (The caps were there from Host to TUSB8041 #1, and TUSB8041#2 to Device, but not between the two hubs)

    1) They have re-worked the boards and are doing tests with the caps inserted.

    2) Can we provide any AC specifications / Block Diagram for the TUSB8041I hub, revolving around the need for these 100nF caps?
    - I know the USB3 specification dictates they are needed, but the strange thing is the TUSB8041 hubs were enumerating USB3 between each other without these caps. I thought for Rx.Detect, the caps were needed for the charge-time-constant, for a host/device to recognize another device plugged-in that is SS capable.

    Regards,
    Darren

  • 0 in reply to Darren (FAE)
    TI__Guru 60870 points

    Hi Darren,

    That's interesting that it worked without the AC caps, I have seen other implementations where the caps were left off and the system did not work.  Perhaps they have more parasitic capacitance on the line that is compensating for it.  I cannot share internal design information on how our devices perform rx.detect.  We definitely would not recommend using the hubs without the AC caps.

    Regards,

    JMMN

  • 0 in reply to JMMN
    TI__Expert 5483 points

    Hi JMMN, 

    Some follow-ups.

    [1]

    My understanding is for two TUSB8041 connected together (one HUB's downstream port connected to the other hubs upstream port), they are required to have AC coupling capacitance to meet the USB3 specification. 

    Without this capacitance, the device may or may not function, based on factors such as parasitic capacitance, bias voltages, etc...

    But the recommendation is to follow the USB3 specification for AC Caps (100nF or 220nF?) on the SSTX lines. Coupling caps on the SSRX lines is optional, but should be between 297 nF and 363 nF?

    [2]

    Is they any specifications you can share (offline) for AC/DC characteristics? I am not asking for proprietary information, but for similar information available in the TUSB542 DS. For example, p7 of the TUSB542 datasheet lists things like the differential receiver / transmitter impedance characteristics, etc. Are the values for the TUSB8041 similar or equivalent, if these values are based on the USB3 specification? Can we provide any kind of information like this for the TUSB8041?

    [3]

    With no AC coupling caps between TUSB8041 hubs, is there a danger of the IC being damaged?

    [4]

    Do we have any update on recreating the cold-temp 1.1V leakage issue?

  • 0 in reply to Darren (FAE)
    TI__Guru 60870 points

    Handling over direct email