TUSB4041I: TUSB4041I Intermittent Failed Enumeration Windows 11 USB2.0

Hi,

Do you have a protocol analyzer to analyze the USB enumeration process?

This will help us identify where in the enumeration process we see issues. 

Is there a specific downstream port that has issues or is it intermittent across all 4?

Are yo able to share a PDF schematic?

I do not currently have an analyzer with a high enough bandwidth to measure the data lines, however, I plan on having a capable piece of equipment in this week.

The error appears across all ports and is intermittent. Lately, I've been testing with only 2 devices on the downstream ports for ease. I've tried different combinations of ports that are used but I still get the same error. Sometimes only 1 port fails, sometimes both.

I will have to sanitize the schematic in order to provide a pdf. The only thing I didn't include in the original post are the regulators and accessories that do not interact with the hub design.

Hi,

What is the driver used on the Windows11 machine?
Are there any low power states enabled? Can you try disabling low power states in Windows 11?

Driver:

I've disabled the power management turning off the device as well as disabled the selective suspend setting. Are there any other setting to disable?

There are other threads that I've looked at that have had different enumeration problems which required using OTP to reprogram registers on the hub to support legacy USB devices. The register in particular is the "bcdUSB" changing from 0x0210 to 0x0200. Do you think this could potentially resolve my issue? I do not have access to the OTP ROM software.

Hi Eric,

Yes this may be the issue. The bsdUSB device descriptor defines what USB specification version the device is compliant to. It could be that Win11 has requirements for this field that Win10 does not. This will not effect the function of the TUSB4041I, just what is advertised to the driver. 

Please accept my friend request, I will share the tool over private message.

You can use the instruction in the thread for reference:

e2e.ti.com/.../tusb4041i-tusb4041i-temporarily-disconnects-when-downstream-device-is-quickly-unplugged-and-replugged

Vishesh,

I think I accepted your friend request but I'm not sure if it went through. Let me know!

Hi,

I'm still unable to message you, are you able to send me a message?

I was able to successfully change bcdUSB from 0x0210 to 0x0200, however, I still see enumeration failures on Windows 11.

Hi Eric,

Got it, we are checking internally to try and isolate the issue.

Were you able to get access to a protocol analyzer?

Hi Eric,

Are you able to use an oscilloscope to capture the HS enumeration waveform?

I've got my hands on a logic analyzer that I'm still in the process of setting up. 

Here is an example of when the hub enumerates all 4 ports successfully:

And here is an example where all 4 ports fail:

On the Windows 11 system I'm working with now, it either fails all 4 ports or is only successful on the 4th port.

Here is also an example on Windows 10:

If you have any suggestions on what I should look closer at, please let me know.

Hi Eric,

The USB HS looks like slide 4 of the linked PPT: https://www.ti.com/content/dam/videos/external-videos/ko-kr/9/3816841626001/6305893689112.mp4/subassets/what-is-usb-2-0-high-speed-detection-handshake-presentation-quiz.pdf

Can you zoom in to see this waveform on the Downstream ports?

Just to confirm we only see the enumeration on the downstream ports of the hub correct? Do we see the hub fail enumeration?

Yes, this is only the downstream ports. I have not seen the hub fail enumeration.

Each little spike shown is the chirp detection. Whenever enumeration fails, the time between each detection attempt is ~615ms. 

Whenever, enumeration passes, the time between each detection attempt is ~115ms.

The logic analyzer I'm using isn't able to set the threshold voltage low enough to detect the high-speed chirps but I'm able to see it on an oscilloscope.

Am I not supposed to see what looks like data during the DP pull-up section?

I do not see this whenever I connected a single device directly into the host PC bypassing the hub. However, there is a delay in the device chirp K.

Looking at the broader spectrum, it appears that the DP Pull-up, SE0 and Device Chirp K occur prior to going into this unknown section. Then the Device Chirp K is repeated which leads into the Host Chirp KJ.

Here's a closer look at the first Device Chirp K on a scope:

Also, here's a closer look at the unknown section. Notice that all 3 of the ports have the same response. This response isn't the same from point to point.

Hi Eric,

Can you share the full enumeration waveform on Windows10 and Windows11 so I can do a side by side comparison?

What is the USB device used that is having issues with the descriptors. 

I see that there are differenced between the enumerations, but its difficult to isolate why. Especially because we see this working with Windows 10. Are you able to test on another platform? What is the processor used?

I shared the full enumeration waveforms of Windows 10 and 11 in a previous message. It's the first reply I sent with the logic analyzer outputs. Are you looking for something in more detail? 

Windows 10 seems to not start the enumeration process on subsequent devices until the current device enumeration is fully complete. Windows 11 seems to perform steps of enumeration of the subsequent devices during the "downtime" of the current device enumeration. 

The device I'm trying to connect to the hub uses FTDI's FT2232H.

The processor on the Windows 11 machine is an i7-8700K @3.70GHz.

The processor on the Windows 10 machine is an i7-4790K @4.00GHz.

Hi Eric,

Eric Hamel said:

I shared the full enumeration waveforms of Windows 10 and 11 in a previous message. It's the first reply I sent with the logic analyzer outputs. Are you looking for something in more detail? 

Yes, I'd like a wider frame of this capture specifically:

Eric Hamel said:

Windows 10 seems to not start the enumeration process on subsequent devices until the current device enumeration is fully complete. Windows 11 seems to perform steps of enumeration of the subsequent devices during the "downtime" of the current device enumeration. 

The device I'm trying to connect to the hub uses FTDI's FT2232H.

The processor on the Windows 11 machine is an i7-8700K @3.70GHz.

The processor on the Windows 10 machine is an i7-4790K @4.00GHz.

Got it.

I've discussed this with my senior engineer and we had the following thoughts:

1) This is very unlikely to be a hardware issue as we see the system run fine on Windows10.

2) This is most likely a driver issue, or a resource allocation issue. We see that Win10 allows of enumeration to complete, while Win11 starts midway. This could lead to possible resource allocation contention within the system. 

Could you test the following:

1) Test the driver used for Win10 on the Win11 OS

2) Test the driver used for Win11 on Win 10 OS. 

3) Try rolling back the driver on Win11. This version works on our hub without issue

I haven't been able to swap out the drivers. Windows is complaining about digital signature and I'm unable to disable signature enforcement. I'll keep looking to see if I can bypass it.

Here are more images on the enumeration waveform. Unfortunately, I do not have the proper probes to analyze the HS packets at this moment.

Hi Eric,

Thanks for the waveforms. 

Looks like the SoF pulses on the Win11 looks to be different than Win10. Is this a rendering issue on the scope, or are the SoF pulse heights actually chnaging?

Any luck trying roll back the Windows 11 driver on the Windows 11 system?

I believe the SoF height variance is due to a mix of poor rendering and insufficient probes. 

I'm not sure how I can roll back the Windows 11 driver to that specific version.

Hi Eric,

Got it. 

I did some online research for potential fixes to this issue, as driver software is outside the scope of our expertise. 

I found two video links that guide you through a Windows 11 debug for the hub enumeration issue. 

Can you try following these steps of your Windows 11 PC?

1) https://www.youtube.com/watch?v=TT4gQgOcw9A

2) https://www.youtube.com/watch?v=NGLfnK_JPEA

The first video will guide you through resetting the windows 11 drivers.

the second video is a working fix for the "Device Descriptor Request Failed" error. 

I went through the 2 videos but didn't see any success.

The link you provided for the driver doesn't work for me.

Hi Eric,

The link provided is the driver itself. It should have started a download.

Here is a .zip file, see if this works.

 usbhub.zip

What are the devices that fail this enumeration? Are there any other devices outside of the FT2232H that have been tested?

I was able to complete testing USB a TUSB4041I EVM and the TUSB3410UARTPDK. I tested this on both Win11 and Win10 and was able to enumerate without issue.

Additionally try this USB hub driver as well.
USBHUB3.zip

Replacing the drivers didn't resolve the issue.

I ordered the FT2232H Mini Module from FTDI to use as an alternative device to see if it too has this issue. I should receive it tomorrow or Friday.

Hi Eric,

Ok. If possible, can you also test with the TUSB4041I EVM?

Hi Eric,

When only one device is present do we still see the issue? 2 devices, 3 devices?

Do we see this issue on the first connection or do we only see this issue when we disconnect and reconnect the upstream cable?

Is it possible to bus power the TUSB4041I?

Vishesh Pithadiya said:

What are the devices that fail this enumeration? Are there any other devices outside of the FT2232H that have been tested?

Any update here?