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.