USBH_Get_DevDesc fails to return unless extended wait before reset

[ZThat]

Hello All,

I am using the usbh_core module to enumerate mass storage devices as a host. I have had it work for plenty of USB 2.0 sticks (not for 3.0), but suddenly, a large batch of USB 2.0 sticks fail to work. After extending all of my delays, this seems to work more consistently, but I am still having issues, especially when inserting an extension cord.

I understand that this may be electrical, but if anyone has any good resources that outline exactly what sequence of events occur in the enumeration sequence, that would be very helpful. I have already started looking through the USB 2.0 specification, and I can see some of the critical timing requirements, but it doesn't then actually provide a complete example of exactly what needs to happen in order in terms of control requests to get from the default state to the configured state.

To me it seems like the first interrupt happens when DP goes high, then the BSP for the host waits 200ms. Then it pulls the DP line low for 100ms. Then brings it back up and waits 10ms, then it tries to communicate with the get device descriptor. Am I missing any part of this? Also, is there any issue with asking for the device descriptor repeatedly without performing a device reset in between?

Any suggestions are appreciated.

Thanks!

[Pavel A.]

USB analyzer can be very helpful to understand what's going. Especially, confirm the timing.

Check that your host provides enough power to the sticks, there are no glitches etc.

Reading the device descriptor repeatedly should not cause any issue by itself.

-- pa

[ZThat]

​Thanks Pavel. I will insert an analyzer and get back to you with what I discover. Thus far, analyzing with an oscilloscope, it seems like the extension chord that I am using is introducing noise. It also seems like this batch of USB sticks is more prone to this noise. This batch also seems to take longer to communicate and pull the Dp line up after being supplied power.

I am unsure as to why blowing out the initial time delay is helping me connect (I have checked and it actually significantly improves when I make it longer than 300mS, even though the USB specification only asks for 100mS), but I would certainly recommend this to someone having connection issues.

[ZThat]

Pavel,

See the attached image for the crux of the issue. I analyzed a working USB and a non-working USB. This is a screenshot of the non-working USB. Not shown here is the fact that the get descriptor message was sent, and it was followed by packets containing "address 0, endpoint 0". The last two of these "address 0, endpoint 0" messages are shown here. In a healthy connection, each of these messages is followed by a nack until the device responds with the device descriptor. In this communication, only the last message was nacked, and then the messages end abruptly. I am looking further into packets and what they typically contain, but I am on the right track.

-Zach

[waclawek.jan]

How do you supply VBUS? Can you observe it, on the device end (against ground at the same end)?

JW

[ZThat]

Jan,

I have been monitoring VBUS on the STM board's side. I supply VBUS from the host. Is there any benefit to monitoring on the device side? My probes are at the connector.

Here are the LL driver parameters for clarification.

 /* Set the LL driver parameters */

 hhcd.Instance = USB_OTG_HS;

 hhcd.Init.Host_channels = 11;

 hhcd.Init.dma_enable = 0;

 hhcd.Init.low_power_enable = 0;

 hhcd.Init.phy_itface = HCD_PHY_EMBEDDED;

 hhcd.Init.Sof_enable = 0;

 hhcd.Init.speed = HCD_SPEED_HIGH;

 hhcd.Init.vbus_sensing_enable = 0;

 hhcd.Init.use_external_vbus = 1;

 hhcd.Init.lpm_enable = 0;

-Zach

[waclawek.jan]

I mean, observe using oscilloscope. Can't your connectors/extension cord be crappy and drop too much voltage until the device/can't the device draw excessive current?

History of USB is the history of violations of a badly defined standard.

JW

[ZThat]

The root of all of this intermittency was that the 48MHz clock used for USB was actually running at 50MHz. Be careful when using the CubeMX example code as a starting point for an application that uses the 48 MHz clock for multiple purposes that the 48MHz clock isn't being set to 50MHz. 48 should work for both the SD card and the USB. 50 only works for the SD card.