• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 273 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.

Original question:

TUSB8041: Using available 8041 instead of unavailable 8042 part. Are they swappable?

TUSB8041: Accidentally entering compliance mode

WST
Intellectual 935 points
Part Number: TUSB8041
Other Parts Discussed in Thread: TUSB8042, ,

We aren't able to currently get the TUSB8042 part for our board in the future, but we can get the TUSB8041 (non-A) version.
I have asked in an earlier thread and found out that it is pinout compatible and so that isn't a problem.
We don't currently have the I2C bus connected to our part, but can do that if necessary. We also don't have an external EPROM connected and have no plans to do so.

What I'm wondering is the following:
1) I heard that a USB3.0 device (the 8041) could accidentally enter COMPLIANCE TEST mode and then have to be powered off or reset to get out of this mode.
Is this a big problem? How can I test for this?

2) If so, then I saw in an earlier discussion that I could write the 'dsportEcr_en' bit in Register A high to prevent compliance mode entry:
QUOTED FROM 2 year old thread:
--------------------------------------------------------
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.
---------------------------------------------

3) If I connect the I2C bus to write this bit high to prevent problems, then it seems like we HAVE to write to the part to activate it after power-on, it won't load the defaults and appear on the upstream bus unless CFG_ACTIVE is cleared. Is this true? We did find in our first prototypes that have the TUSB8042 loaded, that if I have SMBUSZ/SS_SUSPEND tied low to allow the I2C bus to be used, that the HUB didn't appear on the upstream port. I had to float this pin to activate it.

If the 8041 won't easily go into compliance mode accidentally, then I see no reason to go through the trouble of activating the I2C interface and writing CFG_ACTIVE and the DSPORT_ECR bit after every power up; but if this is a real problem, then I suppose we will have to activate and test the interface if necessary for operation after power-up.
Again, we want to continue to use the 8042 part, we just can get it right now.

Thanks for any insight,
Warren

P.S. I was able to complete compliance testing on the TUSB8042 downstream ports on our currentboard by cutting the upstream connections on our board to our LINUX controller and wiring in a cable from a Windows10 host on which I could use the HSETT tool to activate compliance. Not the easiest way, but it worked.

  • 0
    TI__Guru 60865 points

    Hi Warren,

    I actually just wrote a FAQ about this today: https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1080227/faq-tusb8041-how-do-i-test-usb-3-0-usb-3-1-usb-3-2-electrical-compliance-on-usb-hubs

    1. How common of a problem is this?  It depends on the application, if it is a more traditional hub application where the downstream ports are exposed and power controlled by the hub PWRCTL pins, then we don't see it.  Most of the times the issue has been reported, it is in an embedded system with permanently connected downstream devices where the devices power on in a way where the downstream devices enable the rx terminations before they are ready to actually do polling.  I would recommend doing power cycle or reboot testing and see if the downstream devices ever fail to connect.  Or switch the upstream connection of the hub back and forth from USB 2.0 to USB 3.0 and make sure any USB 3.0 downstream devices follow.

    2 / 3 Yes, the TUSB8041 would require an EEPROM to be connected or the I2C/SMBUS host connected to write the register bit DSPORTECN_en after every power on / reset event.  Also, yes, if SMBUSz is low, the hub won't connect on the upstream port until the cfgactive bit is set.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Intellectual 935 points

    Thank you for the information. Three of the four downstream hubs are exposed to external 3.0 type A connectors. The 4th is connected to a touchscreen that is 2.0, and isn't a 3.0 device and only the D+/- are connected, and the TX/RX lines for that port are NCs. Therefore it doesn't look like we would have an issue. I guess if there was a USB3.0 device attached to one of the external ports during power-up there could be one, but likely the only thing that would be there is a flash drive and so I don't think that would cause the compliance mode to activate. Overall, it looks like we would never see this problem.
    But we may do some SMB R/W communication to see if we can power-up and write the registers to prevent the issue from happening. If the problem happens at power-up, is it true that writing the DSPORTECN bit to 1 and then writing CFG_ACTIVE bit high will not allow compliance mode even with a 'bad' device attached to a port? Also, I'm assuming that if we put a 8042 part on the board, Register 0A could be written and that the DSPORTECN bit position would just be ignored, correct?
    Maybe I'm being paranoid about this issue and it won't occur with our design, but I'm just checking.
    Thanks!

  • +1 in reply to WST
    TI__Guru 60865 points

    Hi Warren,

    It looks like your system would not see the issue based on the implementation.

    So if you want to write the dsportecr_en bit to prevent a compliance mode entry at power on, you would need to set SMBUSz low on the board to keep the hub from connecting until it has been configured, then set dsportecr_en and then the cfg_active bit - then the hub would connect with compliance mode on the downstream ports disabled.  If the hub is already enumerated, setting dsportecr_en at that won't change the device behavior.  

    Setting the bit on the TUSB8042 won't impact anything since it is hard coded.

    Regards,

    JMMN