• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 33 subscribers
  • Views 847 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: silicon bug in TUSB8041?

Guo Tschi
Prodigy 30 points
Part Number: TUSB8041

Dear sir,

We recently discovered a strange issue with the TUSB8041 USB 3.0 hub controller. We have designed a USB 3.0 hub PCB based on TUSB8041 controller. There are 2 USB 3.0 cameras connected to this USB hub PCB. The up stream port is connected to the PC. In normal mode of operation the data from the 2 USB camera's are streamed to the PC (we use USB 3.0 port on PC). In the normal model of operation everything works as expected.

Recently we however discovered that connectivity with the USB camera's  is lost under the following conditions:

  • Both camera's stream the image data to the PC through the USB hub. The hub is connected to a USB 3.0 port of the PC.
  • Unplug USB cable while both camera's stream data to the USB. In device manager you will see that USB hub and camera's disappear.
  • Restore USB cable connection. The USB hub drivers pop up in device manager, however this time the drivers of both camera's are not loaded. Or if it is loaded then windows report unknown device.
  • If you unplug all down stream USB devices (i.e. both camera's) and restore connection again, windows 10 keep reporting that devices are unknown or that there is a problem with device.
  • If you then connect another USB 3.0 device, we notice the same problem. We have attached a USB 3.0 harddisk. 
  • Note that if you connect a USB 2.0 device, then it operates OK. So it looks like that the USB 3.0 port on the TUSB8041 is disrupted and that all USB 2.0 downstream ports work fine.
  • Unplugging all USB cables (up stream and down stream) and reconnecting will not solve the issue. We have also rebooted PC but this also doesn't help. Only way to recover is power cycle the USB hub.

We have repeated above experiments by connecting the USB hub to an upstream USB 2.0 port on the PC. Then we noticed that the above-mentioned problem does not occur.

Lastly I can provide following details:

  • USB hub is self powered. 
  • The upstream VBUS line  is connected to VBUS pin of TUSB8041 by a resistor divider (design is identical as reference design of TI).
  • The downstream ports are powered from the local 5V board power supply. This power supply is independent of VBUS. So if upstream VBUS disappear (by disconnecting USB cable) then downstream ports VBUS are still powered with 5V.
  • From the USB 3.2 protocol standard I understand that if VBUS is low then all state machines of down stream and upstream ports should reset to a default state. This apparently does not happen.

I have following questions:

  1. Can you explain why the TUSB8041 controller behaves as described above?
  2. Is this a silicon bug? Are there errata of the TUSB8041?
  3. Is there a work around for this problem?

Best regards,

Guo

  • 0
    TI__Guru 60870 points

    Hi Guo,

    What operating system is being used?

    From the problem description it sounds like the downstream ports of the TUB8041 hub are entering USB 3.0 compliance mode or an error state.  Is the application using SMBUS or EEPROM?  If so please set the the DSPORT_ECR bit in Register 0Ah.  Also can you confim that fullpwrmgmtz is set to 1 in the application?

    Thanks,

    JMMN

  • 0 in reply to JMMN
    Prodigy 30 points

    Dear JMMN,

    Thanks for your reply.

    The systems runs on Windows 10 operating system.

    Our USB hub PCA (based on TUSB8041) contains no EEPROM, neither can it be configured through SMBbus  by use of a microcontroller (because the PCB contains no microcontroller only the TUSB8041 hub controller). So for configuration we are dependent on the default pullup and pull down's on the PCB and in TUSB8041. In the pictures below you can find the downstream port connections, upstream port connections and TUSB8041 controller. From this picture you can see that there is no EEPROM neither is SMBBUS configured.

    Because there is no EEPROM or SMBBUS we can not configure DSPORT_ECRT bit as requested in your reply. So according to the datasheet the value of DSPORT_ECR will be the default value at power up which is 0. What does this bit do and what happens if bit is 0 in stead of 1 (as requested in your reply)?

    Fullpwrmgmtz is configured during reset and since pin 40 of TUSB8041 is unconnected in schematics fullpwrmgmtz will be set to 0 during power up (because according to the datasheet pin 40 has a internal pull down). Note also that datasheets state that pin FULLPWRMGMTZ can be left unconnected if full power management and SMBUS are not implemented. For this reason we have left pin 40 unconnected.

    You wrote that the downstream ports are probably in error state state or compliance mode. Is there a way to leave this state without power cycling? 

    Thanks for your help.

    Best regards,

    Guo

  • 0 in reply to Guo Tschi
    TI__Guru 60870 points

    Hi Guo,

    Per the datasheet if power switching and over current inputs are not supported then FULLPWRMGMTz should be set to "1".

    Can you try pulling the pin to test if this addresses the issue?  Also can you download usbview.exe or usb device tree viewer and report what the hub is reporting when the issue occurs?

    The DSPORT ECR bit, if enabled, changes the hub downstream port behavior so that it is only able to enter compliance mode when directed to do so by the host controller.   The TUSB8041A has this enabled be default:  https://www.ti.com/lit/an/slla377/slla377.pdf?&ts=1589219767223  and is pin for pin compatible with the TUSB8041.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Prodigy 30 points

    Hi JMMN,

    I have been able to reproduce the issues also under Ubuntu 20  operating system. Fortunately with Linux it is easier to collect kernel logging. I have attached a file where you see typical error messages when we disconnect and reconnect USB cable to host computer.  Unfortunately we could not try your suggestion trying to pull pin 40 (fullpwrmgmtz) high, because we did not succeed attaching a wire to pin 40. So we need to change the board layout and replace TTUSB8041 with TUSB8041A.  Before we do this I need confirmation from you that following your suggestions will solve the issues we have observed.

    So my question to you is:

    1. Do you think that when we migrate to TUSB8041A and pull pin FULLPWRMGMTZ high will resolve the issues when we disconnect and reconnec the USB cable? 
    2. Our USB hub is self powered. We currently have powered the downstream ports from the local 5V power supply (i.e. downstream VBUS connection is connected to local 5V power supply). Can this also cause problems? If it causes problems, do we need to interrupt the downstream VBUS connection if the upstream VBUS connection is lost (i.e. if upstream VBUS=0 then disconnect local 5V power supply from all downstream VBUS connections).
    3. Do you have other recommendations we should incorporate in next board design/layout in order to fix the observed issues?

    Best regards,

    Guo

    7343.log.txt

  • 0 in reply to Guo Tschi
    TI__Guru 60870 points

    Hi Guo,

    How many USB disconnect / reconnect cycles are occurring during the debug log you sent?  What other devices are connected to the hub other than the two USB 3.0 cameras and which ports are these devices on?

    The results in the Linux debug log show that one of the cameras connects and the other does not, which doesn't match the results from the Windows setup.

    Thanks,

    JMMN