Failed to re-enumerate USB3.0 plug

[Mark_Huang]

Hi

We are running a restart test. The periodic procedure is as below.
1. boot into Windows OS
2. auto-run BurnInTest for 5 minutes, then stop and exit.
3. shutdown the system and then boot up

= Test environment =
OS: Win Server 2019 64bit
Test Program: BurnInTest 10.2 1010 (64-bit)
USB Plug: Firmware 2.7, Driver 1.2.3
Duty Cycle: 50%
Test items: CPU, RAM, USB

After running hours(could be 1 hour or 8 hours), it shows the error message (Failed to re-enumerate USB3.0 plug) for a few times.
I can't find the description for this error in the manual.

Would you advise what does this error mean?
Thanks a lot.

[David (PassMark)]

USB 3.0 enumeration is the process where a host discovers and configures a newly connected USB device. The key steps include:

1. Device connection detection via VBUS power and differential pair connection
2. Reset and speed negotiation (SuperSpeed uses separate differential pairs). Part of this step is link training sequences.
3. Device descriptor request to identify basic information
4. Address assignment to uniquely identify the device
5. Configuration descriptor request to understand device capabilities
6. Configuration selection by the host
7. Interface and endpoint setup for data transfer

So a failure of any of these steps can result in the device failing to re-enumerate. Several of these steps also have tight timing constraints. So the device or host failing to response quickly enough can also cause a failure. Software issues (like missing device drivers) can also cause problems, but that is less likely here as it works most of the time.

The really get to the bottom of it a protocol trace on the USB bus would normally be required.

What USB host controller are you using?

[Mark_Huang]

We are using this CPU Intel® Xeon® D-1746TER Processor as the USB3.0 host.

Unfortunately we don't have an USB protocol analyzer to debug.
Does the loopback driver support Win Server 2019? (I can't see it in the supported list.)

[David (PassMark)]

The CPU doesn't contain the USB host controller. It is part of the motherboard chipset, or when a lot of ports are required, or higher speed ports, a separate controller chip on the motherboard is used. (For Intel this is sometimes called the PCH, Platform Controller Hub chipset)

We are not aware of any problems with Windows Server 2019.

Update: Xeon D are system on a chip CPUs, so they do contain some of the PCH functionality. So might be worth checking if there is a device driver update available.

Update 2: We had a report last week of a host controller that was very sensitive to the link training sequence start delay and duration. (i.e. didn't enumerate due to the timings being wrong by a number of milliseconds). We are still looking into this.

[Mark_Huang]

Hi David,

We have used the latest driver from intel.

Thanks for your update.
1. Have you seen this kind of error on any USB hub design?
2. Is there a workaround (i.e. some settings in the burn in program) to avoid this error?
3. Is it possible that we can get an older FW or driver of USB3.0 plugs to try if it can have a different result?

Thanks a lot.

[Mark_Huang]

Hi David (PassMark),

Thanks for your support.

We found below history in the readme file of USB3.0 loopback FW.
Actually our platform does have TI TUSB8041 on board.
After doing some cross checks, the error of "Failed to re-enumerate USB3.0 plug" can only happen when the loopback is on the downstream ports of TUSB8041.
If we plug loopback on other ports only, it can run over 24 hours without errors.

Is it possible that this bug occurred before could reappear in Burn in v10.2 1010 (64-bit) with loopback FW 2.7?

v2.1 31/August/2016
- Fixed a re-enumeration issue with Cypress CY4609, Texas Instruments TUSB8041 and Microchip USB5534B hubs

[David (PassMark)]

Seems unlikely that the same problem fixed in 2016 would be back.

We have made a new firmware update, to fix an issues from another customer (to do with the precise timings of training sequences).

It should be released next Monday 14th on this page.
https://www.passmark.com/products/us...k/download.php

So try that next week. There is some chance it might also fix your issue, but can't be sure.

[David (PassMark)]

New firmware is up on the site, if you would like to give it a try.

[Mark_Huang]

Hi David (PassMark),
Thanks for your support.

We have tried the new firmware v2.8 today.
Unfortunately it didn't fix our issue. The situation is still the same.

- Would you think it is worth to try the FW v2.1? (But there is no download link for it)

- Below information for your reference.
During the restart test, it detects all USB loopback plugs at the first step in Windows OS, and then running Burn In test.
All loopback plugs were found at the detection step.
However when Burn In test starts running, it could happen "Failed to re-enumerate" error. And the loopback on downstream ports of hub is missing in Burn In test.
(P.S. If the system doesn't restart, there is no error at all for 24h running.)

[David (PassMark)]

If this doesn't happen with any other hubs / port, it might be an issue with the hub.

Also are any other devices connected to the hub (e.g. keyboard / mouse)? Years ago there were sometimes issues if a mix of USB2 and USB3 devices were connected to the same hub.

Is the hub you are using available as a commercial standalone product we can buy?

[Mark_Huang]

David (PassMark),

Thanks for your information.
We do have an USB2.0 device on the other downstream port.
However after disconnecting that USB2.0 device, the issue is still existed.

I found another post which discussed a similar issue.
It mentioned a timeout setting of USB test which could avoid this re-enumerate error.
I can only find below similar setting.
Is it the same setting for USB3.0 loopback plugs?

[David (PassMark)]

Enumeration is a low level process, that occurs without any interaction at the application level. (i.e. it is at the level of electrical signalling and integrated circuits).

That timeout you mentioned was not for enumeration step, it was for how long the application level waits for data to be fully transmitted.

If you really want to get to the bottom of it you are probably going to need a protocol analyzer.