TUSB4041I: HUB disconnects from uplink host when a device is removed and connected back on downlink port.

Hello,

I have not heard of an issue like this before with the TUSB4020/4041.  Let me attempt to reproduce the issue in our lab and get back to you within 3-4 days.

Regards,

Nicholaus

Hello,

I was able to create a bench setup with the TUSB4020BI and a connection exerciser.  I performed 300 cycles of an 80ms attach/detach with 50% duty cycle.  I did not see an issue during initial testing.

Can you please provide your schematic so I can see the configuration of the hub?  Pekka should be able to open a confidential E2E issue to share your schematic.  He can also set up a meeting so we can go over the settings for the hub and share any more relevant information to help reproduce the issue.  I have added him to this E2E ticket for visibility.

Thanks,

Nicholaus

In addition to our own HW, we are able to reproducer the issue with TUSB4041PAP Evaluation Module connected to Linux Fedora laptop.

So, could it be that the 2-port TUSB4020BI works in a different way than the 4-port TUSB4041B ?

The TUSB4041I hub in our application has be configured as follows:

SMB is in use.
After power-up and releasing the GRSTz (18), the hub is started by writing the cfgActive bit in register F8h.
No other configurations in the registers are changed.
SDA/SMBDAT (5), pull up 1k to 3.3V
SCL/SMBCLK (6), pull up 1k to 3.3V
SMBUSz (7), pull down 4k7

Full power managemnt is enabled and polatiry is active high.
FULLPWRMGMTz/SMBA1 (8), floating / NC
PWRCTL_POL (9), floating / NC
GANGED/SMBA2/HS_UP

Automatic charge mode is disabled.
AUTOENz/HS_SUSPEND (13), floating / NC

Forgot to describe the pin 10 connection...

The TUSB4041I hub in our application has be configured as follows:

SMB is in use.
After power-up and releasing the GRSTz (18), the hub is started by writing the cfgActive bit in register F8h.
No other configurations in the registers are changed.
SDA/SMBDAT (5), pull up 1k to 3.3V
SCL/SMBCLK (6), pull up 1k to 3.3V
SMBUSz (7), pull down 4k7

Full power managemnt is enabled and polatiry is active high.
FULLPWRMGMTz/SMBA1 (8), floating / NC
PWRCTL_POL (9), floating / NC
GANGED/SMBA2/HS_UP (10), floating / NC

Automatic charge mode is disabled.
AUTOENz/HS_SUSPEND (13), floating / NC

Hi Antti,

I may need to order a TUSB4041PAPEVM to test.  In the meantime, I'm doing a schematic review for both hubs and testing the TUSB4020BI with matching settings.

Regards,

Nicholaus

Hi Antti,

Do you see this same issue with Windows OS?  How are you controlling the attach/detach cycles of the downstream device? 

Regards,

Nicholaus

Can you disable SMBus mode and try the same test?  I'm wondering if there is a timing issue causing cfgActive bit to not be set.  

Regards,

Nicholaus

I think it is not due to the SMB activated, as we can reproduce the issue with TUSB4041I evaluation board, which is operating as stand alone and SMB disabled.

We tried to isolate the issue further by testing with different host devices.

Same hub disappearing and re-enumerating issue is observed with four different system and hosts:
1. Intel Core i7 laptop running Linux and TUSB4041PAPEVM
2. Intel Core i7 laptop running Windows 10 TUSB4041PAPEVM
3. i.MX8MP running custom Linux and TUSB4041PAPEVM connected directly to i.MX8MP USB host controller
4. i.MXRT106x running RTOS and TUSB4041I connected through TUSB4020BI to i.MXRT106x USB host controller

Looks like the error happens only once after USB hub reset is released or it is powered up.
Example sequence 1:
1. Connect TUSB4041PAPEVM to host and power-up (turn SW3 from "off" to "Bus Power")
2. Observe the TUSB4041I is enumerated to host
3. Connect USB FS or LS device to hub downstream port
4. Start disconnecting and reconnecting the device on downstream port
5. Observe the TUSB4041I disappear and re-enumerate back
6. Continue disconnecting and reconnecting the device on downstream port
-> TUSB4041I stays enumerated after the first re-enumeration (step 5).

Example sequence 2:
1. Connect TUSB4041PAPEVM to host and power-up (turn SW3 from "off" to "Bus Power")
2. Observe the TUSB4041I is enumerated to host
3. Connect USB FS or LS device to hub downstream port
4. Start disconnecting and reconnecting the device on downstream port
5. Observe the TUSB4041I disappear and re-enumerate back
6. Continue disconnecting and reconnecting the device on downstream port
-> TUSB4041I stays enumerated after the first re-enumeration (step 5).
7. Reset the TUSB4041I by pulling pin 18 GRST_N low for a while
8. Observe the TUSB4041I disappear and re-enumerate back
9. Continue disconnecting and reconnecting the device on downstream port
10. Observe the TUSB4041I disappear and re-enumerate back
11. Continue disconnecting and reconnecting the device on downstream port
-> TUSB4041I stays enumerated after the first re-enumeration (step 11).

So, After the issue has occurred once, the hub works normally until next reset or power cycle.

We were able to reproduce the issue with TUSB4020BPHPEVM as well on Windows laptop.
TUSB4020BI wasn't tested in other systems.

Yes, issue was reproduced with Windows machine as well.

In automated test we use a device with TS3USB221 to disconnect the DP/DM pair. TS3USB221 pins 3/4 are NC and differential pair is routed through pins 7/8 and 2/1. The device VBUS is disconnected at the same time with P-channel FET (SI3483DV).
So, this emulates a full disconnection of the device cable as both the VBUS and DP/DM are disconnected.

You ca reproduce the issue also manually by for example connecting and disconnecting e.g. a USB mouse.

Understood.  Thank you for the detailed test procedure.  We placed the TUSB4041 EVM on Monday and as soon as it arrives I will reproduce the issue and find root cause.

Thanks,

Nicholaus

Hi Antti,

The EVM has arrived, and I will get results ASAP.

Regards,

Nicholaus

Hi Antti,

I used the same test with the MCCI USB 3.0 connection exerciser, and I tried manually connecting and disconnecting a mouse as well.  I was able to see a driver instance of a hub "disconnect" as shown below, but this seemed to be related to the software and didn't affect the functionality of the hub.

In your EVM test procedure the SW2 and SW1 settings are all default?  

Could you let me know the Windows software you are using for your testing and seeing the hub disconnect?

Regards,

Nicholaus

Hi,

On Windows machine we did the test manually and observed the device connection state with USB Device Tree Viewer V3.8.1.
Looks like you have used the same software.

Manually plugging and unplugging a mouse was able to cause the TUS4041I to disconnect. At the same time you lose all USB devices connected to the TUSB4041I. In our case there was a USB keyboard connected as well.
This happens only once - the TUSB4041I disconnect and re-enumerate right back and the connected USB devices re-enumerate as well.

The TUSB4041I evaluation board switch settings are:
SW1: 1=OFF, 2=ON, 3 to 7=OFF
SW2: 1=ON, 2 to 7=OFF

You have to power cycle the TUSB4041I pull reset low to get the TUSB4041I to a state where it makes the same disconnection again.

On host running Linux or RTOS machine we can observe the TUSB4041I disappearing and re-enumerating directly from the USB host driver.

So, what could cause the TUSB4041I to disconnect like this ?
Look like it is some kind of internal soft reset as the SMB register values are not reset to default values and TUSB4041I re-enumerates back after the disconnection.

Thanks Antti,

I'm not sure why the hub would disconnect.  It shouldn't be, and I'll need to do a hands-on debug.  I don't have a Linux system to test with.  Is there any dependency on USB host/device?  In other words, is this passing on any systems?  Can you post your USB Tree view results so I can see the conditions for failure?

I'm going to continue to try and reproduce this failure with the SW1/SW2 settings today.  I have been power cycling between each test.  I'll update you before EOD.

Regards,

Nicholaus

Hi Antti,

I saw the problem!  I'll be using a USB protocol analyzer to see what may be happening.

Regards,

Nicholaus

One thing I noticed that was interesting on USB Tree View is that the text on the port changes from "Generic USB 2.1 Hub" to "Generic USB 2.0 Hub" after the failure.  Is it the same in your case?

Regards,

Nicholaus

We have been able to reproduce the issue in 4 different systems.

This should show that it is not dependent on the USB host controller.

Same hub disappearing and re-enumerating issue is observed with four different system and hosts:
1. Intel Core i7 laptop running Linux and TUSB4041PAPEVM
2. Intel Core i7 laptop running Windows 10 and TUSB4041PAPEVM
3. i.MX8MP running custom Linux and TUSB4041PAPEVM connected directly to i.MX8MP USB host controller
4. i.MXRT106x running RTOS and TUSB4041I connected through TUSB4020BI to i.MXRT106x USB host controller

Hi Antti,

I have a PC in the lab with two different USB controllers.  One passes and one that fails.

ASMedia USB3.1 eXtensible Host Controller: ASMedia USB Root Hub (Fail)
Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft): USB Root Hub (USB 3.0) (Pass)

In order to perform the test.  I run 10 cycles of 250ms attached and 250ms detached of a low-speed mouse connected to the TUSB4041PAPEVM.  

I have a USB protocol trace for both of these conditions, so there is a side-by-side comparison of passing and failing conditions.  We are analyzing the data now to understand what is happening.

Regards,

Nicholaus

Hi Antti,

In the failing case.  We see this full-speed J occur upstream when connecting/disconnecting the LS mouse. 

I measured this with a oscilloscope as well.  We are in the process of determining the source of this J and what is causing it to occur in the failing case and not the passing case.

Regards,

Nicholaus

Hi Antii,

Another interesting point on the protocol trace and the oscilloscope measurement.

There are no SOF packets before the full-speed J.  The hub should go into suspend when it doesn't see any traffic from the host after 3ms.  This doesn't explain why this issue only happens with the TUSB4041, but it may help explain what role the host is playing in this issue.

Are you able to confirm if your USB host controller is ASMedia?

Regards,

Nicholaus

On the Windows 10 computer, where we can reproduce the issue with TUSB4041I, there is Intel controller:
Intel(R) USB 3.1 eXtensible Host Controller - 1.10 (Microsoft)
PNP Device ID: PCI\VEN_8086&DEV_A36D&SUBSYS_09061028&REV_10\3&11583659&0&A0

On the embedded Linux and RTOS systems where we have reproduced the issue use the integrated host controller of NXP's i.MX8MP and i.MXRT106x processors. These are I believe using the USB 2.0 EHCI IP from Synopsys.

For me the easiest way to reproduce this issue is to connect a mouse to the hub, disconnect it after 400ms and then after 1 or more seconds connect it again for 400ms. The issue usually reproduces within 5-20 cycles.

I have an Intel(R) USB 3.0 eXtensible Host Controller on my Dell Precision M3800 laptop running Fedora 37 Linux.

Hi Claus,

I can reliably reproduce the issue now.  No problem there. 

Currently, I see that when the failure happens SOF packets stop transmitting to the hub and the HUB going into suspend.  I'm haven't found the reason for the behavior yet, but I'll let you know as soon as I have narrowed down the cause.  Thank you for the results.  I'll have another update soon.

Regards,

Nicholaus

Hi Claus and Antti,

After further testing I was able to reproduce this issue on both hosts and with the TUSB4020B.

I investigated the downstream port and don't see any anomalies, but the start of enumeration after attaching a device is ~190ms.  This is close to the cycle time of the attach/detach cycle.  If the hub is allowed time to enumerate the device there is no issue.

There is no way to change the TUSB4041I advertising bcdUSB=0x0210, so that is not a path for resolution.  I also attempted to plug the HUB downstream of a USB 2.0 high-speed hub and that does not change bcdUSB=0x0210, and so it does not resolve the issue.

It looks like we are limited to changing registers or pin settings to find a workaround.  I'll be doing that today to see if we can modify the reset timing or configuration to resolve the issue.

Regards,

Nicholaus

Hi Claus and Antti,

I have tried changing many different settings and registers yesterday in order to workaround the quick connect/disconnect issue with the hub, but I could not find one that resolves the issue.

What are the exact conditions for passing the quick attach/detach test?  How many cycles and how quickly does the attach/detach occur?

Regards,

Nicholaus

Hi Nicholaus,

What do you mean by "passing" the test?

I mentioned earlier:
"For me the easiest way to reproduce this issue is to connect a mouse to the hub, disconnect it after 400ms and then after 1 or more seconds connect it again for 400ms. The issue usually reproduces within 5-20 cycles."

I have not tried to find the minimum connect/disconnect time where the device doesn't re-enumerate into 2.00 mode. In our  use case it isn't very useful to find the minimum time but I can do some tests tomorrow.  

We have tried in many ways to reset the hub, the upstream hub and the devices. No software interaction seem to have any effect on this issue. It really seems that the only way to get the device to advertise itself as a 2.00 hub is to disconnect/connect  a  device on the down stream port and cause it to re-enumerate itself after n tries. (Usually between 5-20 tries).

Regards,

Claus

Hi Claus,

My understanding is the reason that we are considering this attach/detach scenario is because there is some proprietary test that needs to pass before production.  It is difficult to reproduce in a real-world scenario, unless you are trying to make it happen.  The end result is that the hub re-enumerates and the LS/FS device works as intended. 

So, I didn't mean that we need to find the min/max time.  I was wondering if maybe we can change the timing that the issue occurs, and so that we can pass this test.  If there is not a test defined, how is this an issue for an end user?

Regards,

Nicholaus

Hi Nicholaus,

The problem for us is that we can't control how the customer/user behaves and if the customer causes the issue to occur, then all other devices connected to the hub will re-enumerate and this is not good in our use case.

We can easily reproduce this by connecting and disconnecting a device manually by hand for a few seconds. If we can do it, then it's quite clear that the customer will do it.

Regards,

Claus 

Hi Claus,

I see.  Electrically, the enumeration begins ~200ms after attach and enumeration completes in about 200ms, per the USB 2.0 spec. The Windows hub driver must also observe a period of at least 100ms where there are no port changes, if the port has not stabilized after 200ms, the hub driver will disable the port and cancel enumeration.

Quickly removing and inserting the device at 400ms intervals causes issues with enumeration as the device is not given enough time to settle and properly enumerate. The timing interval needs to be increased to allow the device to enumerate. 

Regards,

Nicholaus

Hi Nicholaus,  The test the team is doing is a reliability test of the USB subsystem.  It is acceptable that enumeration fails during this test.  The failure of the test is not due to failure to enumerate, it is due to the hub re-enumerating and causing all other attached devices on the hub to have to re-enumerate.  Granted that 400 ms is quick, but not out of the realm of possibility of human interaction.  It is also definitely within the range of connection "chatter" or what may be experienced when a physical wire is frayed or intermittent in the attached USB cable.  Again, the failure is not one of failure to enumerate.  Our system handles that.  The failure is one of how the hub reacts to that failure to enumerate by re-enumerating the hub itself leading to the temporary disconnect of all hub attached peripherals.  Other compliant hubs the team has worked with do not behave in this manner.  If we change the test time, we may get to a point that the hub does not respond in this manner.  However, that defeats the purpose of the reliability test.

Regards,

Dave

Hi Dave,

Yes, I understand.  However, it seems this issue is part of the operation of the hub.  The hub doesn't contain firmware, and so the behavior cannot be easily changed.  This means that we won't be able to meet the required resolution time.  

We are escalating this issue internally to see what the next steps will be.

Regards,

Nicholaus

Hi Claus and Antti,

Please accept my friend request.  I have some software that will allow you to access the OTP ROM of the TUSB4041, which may allow you to force the hub to advertise bcdUSB=0x0200.

Regards,

Nicholaus

Hi Nicholaus,

I accepted your friend request. Please share the information.

Thanks,

-Claus-

Done. 

Let me know if setting the OTP bit forces the hub to USB 2.0.

Regards,

Nicholaus