• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 653 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TUSB8040 link issue

Gary Teng
Genius 5310 points
Other Parts Discussed in Thread: TUSB8040, TUSB8040A1, TUSB8040A

Hi all,

 My customer use TUSB8040 as Hub product for their customer. Please see the question below and see if you have any idea about that. Thank you very much.

The issue description is shown below. Please help to ask help from TI and see if it can be fixed by software level.

Platform: HP EliteBook Folio 9470m looks like an old Intel 3rd Gen platform.  

USB docking station: TI USB hub TUSB8040. Under the hub, there is DisplayLink USB to HDMI chipset.

 

Step to reproduce:

-  Connect a folio 9470m to a 3005pr USB3.0 Port Replicator and connect a screen in Port replicator.

-  When you can see the display on the screen laptop and on external screen  , RESTART the computer

-  If the display is still on both screen ( laptop + external) RESTART the computer again

-  Repeat these steps until the display appears only on the laptop screen

-  when the problem appears if you click on RESTART , all comes back normally with a display on both screen but if you click on SHUTDOWN you may have a problem on USB3 eXtensible host driver in device manager.

 

The USB traffic captured when reproduced:

https://1drv.ms/u/s!AmBiJ6rWJ1B0hgEWDxJN2-Y1o4N0

DisplayLink’s analysis:

What should happen:

The dock's USB hub will perform an LFPS handshake with the notebook USB host controller and then will continue with USB link training (TS1, TS2 etc.). 

What is happening in the failure case:

The dock's USB hub doesn’t respond to the notebook USB host controller’s LFPS during the handshake phase and instead starts sending TS1 directly.

The notebook USB host controller then ignores the TS1 as it is still expecting an LFPS response.

As such we believe this is an issue with the USB hub inside the HP 3005pr dock and we suggest passing this information to Texas Instruments for further investigation.

 

Comments from Intel:

Yes, I expected the issue is related to USB3 hub. We didn’t observe this issue on other hub and request HP to check with their hub vendor. When issue happen, the USB3 port will stop to detect RX termination. We didn’t reproduce this issue with other USB3 device, it seems your docking may have some abnormal behavior during reboot and cause our USB3 port lose function.

  • 0
    TI__Expert 7395 points

    Hello Gary,

    First I would like to mention that the TUSB8040 was the first generation of our SuperSpeed USB Hub controllers and it is no longer recommended for new designs.

    The TUSB8040 has some known issues that are properly documented on the errata document published in the device's product folder (http://www.ti.com/lit/pdf/sllz064).

    By taking a look at the traces you provided, I think the issue might be specifically related to errata number 2.1

    "2.1 Problem

    The TUSB8040 may fail to recognize a device initiated U1 exit. Problem only occurs with SS devices that

    have short LFPS signals.

    Work Around

    Disable U1/U2 support via the SDA_SMBAT input."

    Can you please try the suggested work around and provide your results?

    Thanks,

  • 0 in reply to Jorge Llamas (SWAT)
    Genius 5310 points

    Hi Jorge,

    Thanks for your response. Due to 8040 is the first generation U3 hub IC, do you think later version device like... 8040A1 can solve customer's issue? BTW, please help to check the customer's response. Thank you very much.

    ************************************

    At Oct. 18:

    1. The latest dock driver already disabled USB 3.0 U1/U2, and still can reproduce this issue. We captured the USB traffic and confirmed the USB bus did not enter U1/U2. Thus, the issue seems not related to U1/U2. Please ask TI to investigate again.

    2. The laptop is running Windows 7. Do you think we still have U1/U2 problem?

    3. Does this workaround “Disable U1/U2 support via the SDA_SMBAT input" mean we need to add flash to run external firmware or configuration? If yes, please provide the firmware for experiment. However, the dock product does not have flash inside such it is not feasible solution. Can TI check if there is any workaround in driver level?

    *********************************************************************************************************************

    At Oct. 21:

    The following is the comments from Intel.

    On this protocol trace, we found some abnormal behavior on device side.

    1. Device will send TS1 before it send LFPS.polling during power on. It conflict spec.

    2. Device send out a LFPS which is not defined in spec, there is no LFPS tBurst should be 1sec.

    The following information is the experiment result we have in 2013. HP has reported the same issue at 2013. The following is the report :

    1. This issue only happen with TI hub with HP system, we have reproduce this issue on 3 different types of TI hub

    Report in 2013 :

    Issue observed on following 3.0 hubs:

    Rev1:

    Chip: 18ADDZW TUSB8040 G4

    Evaluation Board: TUSB8040 EVM EDGE # 6519967

    idVendor:           0x0451 (Texas Instruments)

    idProduct:          0x8040

    bcdDevice:          0x0100

    Rev5:

    Chip: PUSB 8040A1 RKM TI 2CI ALZ0 G4

    Evaluation Board: TUSB8040A1 EVM

    idVendor:           0x0451 (Texas Instruments)

    idProduct:          0x8046

    bcdDevice:          0x0100

    Rev6:

    Chip: TUSB8040A RKM TI 27I AZ5Y G4

    Evaluation Board: TUSB8040A EVM

    idVendor:           0x0451 (Texas Instruments)

    idProduct:          0x8041

    bcdDevice:          0x0100

    2. The issue also reproduced on Win8.

    It prove the issue is not driver issue, Win8 XHCI driver is implemented by MFST. It means both MFST and intel driver can reproduce the issue. The following is the detail debug result :

    During driver initialization HCRST is issued. It should trigger Port Reset on all ports and swith connected ports to enabled state and others to disconnetced state.

    However the SS port where hub is connected is blocked in reset state for very long time (PORTSC=0x2b0) and finally it goes to disconnected state with PRC bit set. Driver clears PRC, but afterwards port is not functional - even driver disable/enable could not recover this particular port.

    Issue reproducible only on client platform with all avialable in ITP versions of TI HUB.

    The failure won’t be recovery by USB port reset even HC reset, there is nothing driver can workaround in this case.