• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 352 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.

TUSB9261: Intermittently not detected as boot device

Peter Bouvy
Prodigy 140 points
Part Number: TUSB9261
Other Parts Discussed in Thread: HD3SS3220,

In the design under test the TUSB9261 is connected to a laptops USB Type-C port via the HD3SS3220 type-c multiplexer chip.

The design has been working flawlessly for the last few months. However testing the design with a new laptop has encountered a strange bug.

When the design is connected to an HP ProBook 450G8, the TUSB9261 is intermittently not detected as a boot device.

When the laptop is off the Type-C port still provides 5V power. This is pretty typical for laptop Type-C ports. When the TUSB9261 is plugged in to the powered down laptop it enters the USB2.0 SUSPEND state. This is what we would expect given that the USB controller of the laptop will be disabled. I have seen this in the debug port output of the TUSB9261. 

Turning the laptop on generates a USB reset event, but the 5V rail remains high (the TUSB9261 is not power cycled). From this point on there the behavior of the TUSB9261 is inconsistent. The output of the TUSB9261 debug port is below. 

In all cases we see "connected at superspeed" initially. But there are multiple reset events that occur in succession. I have observed these multiple reset events result in the final state being:

  • Connected at SuperSpeed (Device is detected by the bios as a potential boot device)
  • USB2.0 Suspend- BIOS does not detect the device at all in this case
  • The debug port shows the TUSB9261 in POLLING forever (The device is also not detected in this case) (USB2 or USB3). 

Do you know why this one laptop may fail to see the TUSB9261 at boot time? The multiple USB reset events in a row is particularly weird. I should also say that when the device is connected the device runs well, and we see no evidence of link errors, or retraining, to suggest that the signal integrity is poor. 

TUSB9261 debug logs. Start of the log is when the laptop is switched on. 

Device detected as boot device, and shows up in boot menu:

[0000064988] USB Reset event occurred.
[0000064988] -> ahci_reset_lun(0)
[0000064989] Connected at SUPER speed.
[0000064989] USB Reset event occurred.
[0000064989] -> ahci_reset_lun(0)
[0000064989] LTSSM state = (0x7) POLLING.
[0000064989] LTSSM state = (0x7) POLLING.
[0000065089] Connected at SUPER speed.
[0000065712] USB Reset event occurred.
[0000065712] -> ahci_reset_lun(0)
[0000065712] Connected at SUPER speed.
[0000066032] -> usb_hal_set_address() - addr: 0x1.
[0000066035] -> handle_usb_set_configuration() - val = 1.

Device not detected by BIOS as boot device:

[0000023064] USB Reset event occurred.
[0000023064] -> ahci_reset_lun(0)
[0000023065] Connected at SUPER speed.
[0000023065] USB Reset event occurred.
[0000023065] -> ahci_reset_lun(0)
[0000023065] LTSSM state = (0x7) POLLING.
[0000023178] HS/FS/LS state = (0x0) ON.
[0000023181] HS/FS/LS state = (0x5) EARLY SUSPEND.
[0000023184] HS/FS/LS state = (0x3) SUSPEND.

Thanks in advance for your help.

  • 0
    TI__Guru 64326 points

    Hi Peter,

    We have not seen this issue reported before with TUSB261. Would you be able to provide a USB packet trace when the issues is seen? Just to clarify at boot you multiple reset then one of the three states occur:

    • Connected at SuperSpeed (Device is detected by the bios as a potential boot device) - OK?
    • USB2.0 Suspend- BIOS does not detect the device at all in this case - NG
    • The debug port shows the TUSB9261 in POLLING forever (The device is also not detected in this case) (USB2 or USB3). - NG

    I agree that multiple resets are odd in this case. We should confirm if Host is sending the TS2 ordered sets as expected for Hot Reset or understand if there is a LFPS timeout that could send the USB 3 link to SS.Inactive then down to USB 2.0 Suspend. Not sure if this involves Warm Reset as I would expect to see link reenter RX.Detect when Warm reset is initiated. 

  • 0 in reply to Malik Barton57
    Prodigy 140 points

    Hi Malik,

    Yes that is correct. I have attached 4 csv files that re the output from my USB protocol analyser. There are 2 cases which result in successful detection of the device, and 2 cases wheere the device is not connected (USB2 or USB3).

    Three captures are on the HP laptop which works intermittently, and one is one is on a Dell Laptop which always works. 

    I hope these results shed some light on the issue.

    Thanks for your help,

    PeterHP_DetectOk.csvHP_DetectFail_2.csvHP_DetectFail_1.csvDell_DetectOk.csv

  • 0 in reply to Peter Bouvy
    TI__Guru 64326 points

    Hi Peter,

    I will review these files and get back to you by Wednesday afternoon. Is that okay? 

  • 0 in reply to Malik Barton57
    TI__Guru 64326 points

    Hi Peter,

    Sorry for the delay had to dig a bit deeper on this one. It seems that we have a couple of situations going on revolving around the inability to complete link training successfully. I will give a detailed post tomorrow with some potential debug steps. Do you have the ability to capture some waveforms on the SS lines?

  • 0 in reply to Malik Barton57
    Prodigy 140 points

    Hi Malik,

    The fastest oscilloscope I have is 2GHz. Which is probably not fast enough to read and decode USB3 Superspeed packets. Does link training happen at the full 5Gbps speed? Or something slower?

    Any debug advice you can provide is greatly appreciated.

    Thanks,

    Peter

  • 0 in reply to Peter Bouvy
    TI__Guru 64326 points

    Hi Peter,

    I agree signal integrity does not seem to be the issue here as the Polling.RXEQ sate where Gen 1 RX training to TSEQ packets complete regularly. It seems the link with this HP laptop is having issues:

    • Completing Polling.Idle. To complete and enter U0, a Idle Symbol Handshake the link must transmit however it seems the link continues to transmit TS2 and state times out. Link is direct back to RX.Detect.
      • We can try to probe on the SSRX of TUSB9261 in order to understand what is actually happening in between Polling and U0. However 2GHz scope wont have enough bandwidth here and may cause more errors in the link. 
    • Completing Polling.Configuration, This can be caused by a 12ms timeout if the correct TS2 packets are not received. There are multiple errors during this phase which my contribute to the 12ms timeout. 
      • This would seem to point back to SI issues but I am unsure without being able to probe the TS2 packets directly. 2GHz scope wont have enough bandwidth here and may cause more errors in the link 
    Repeated failing of Polling.LFPS. Seems to be a symptom of the repeated packet errors or even lack of packets in the protocol log (Fail2). Is this repeatable?
    • We can try to see with your scope if the LFPS packet are coming in and out as expected. 2GHz scope if fine for this debug.  

    With the repeated errors in the link training process it does make sense that the link falls back to USB 2 but device should still enumerate here. is it expected that the BIOS does not detect USB 2 only devices?