USB Device sometimes not recognized

[LMorr.3]

Using an STM32F373, I setup a USB DEVICE virtual port class.  The connection does work but it takes disconnecting/reconnecting the USB cable once or twice before it gets detected successfully as a serial port/usb device on my linux box.  I use lsusb to see which USB devices are found, and when the connection intialy fails, I get the following message in 'dmesg':

"new full-speed USB device number 48 using xhci_hcd
usb 3-1: config index 0 descriptor too short (expected 67, got 9)
usb 3-1: config 1 has 0 interfaces, different from the descriptor's value: 2
usb 3-1: New USB device found, idVendor=0000, idProduct=0001, bcdDevice= 2.00
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1: Product: my Module
usb 3-1: Manufacturer: STMicroelectronics
usb 3-1: SerialNumber: 2077345D5646

 

If I disconnect the USB cable and reconnect it it usually works.

Any ideas on what I should look at to fix this issue?

Thank you,

[Pavel A.]

It fails to return the configuration descriptor for some reason. Debug. Likely the host reads the device descriptor and strings first, but does not print that before parsing config descriptors.

 

[LMorr.3]

What's odd is the descriptor Product, Manufacturer and Serial gets corrupted with 'pi' character or sometimes repeats the Product string for Manufacturer and Serial Number when it fails.  ( maybe USB uses those as defaults before they are read in ).  But the connection seems to work well when it does connect... 

Also, it always shows 'expected 67, got 9' so if it was receiving 'garbage' it would not always be '9' I would assume.  I'll keep looking...

[TDK]

Seems very unlikely that the descriptor, which is largely a static array with a constant size, is actually changing size. What would the mechanism even be? Not questioning your results, just thinking the problem may lie elsewhere.

Do you have a Windows machine you could try it on?

You could try inserting a delay (250ms or so) before initializing USB, and after initializing it before using it. This is a USB-powered device, yes?

[LMorr.3]

My DM trace length is 206.67mm and the DP is 166.06mm.

Could the 40.61mm length delta potentially cause the corrupted USB descriptor data I'm seeing?

[TDK]

No, 40mm shouldn't matter on a 12 MHz signal. (You should probably get those a bit closer on the next revision though, if it happens, and route them side by side.)

USB is error-detecting/correcting so it's a bit weird that it gets through at all. Really feel like it could be a Linux driver thing, especially since it's consistent. But since it works if you change clocks that doesn't quite fit either. Can you try on a Windows machine? I assume the delays didn't help at all.

 

[LMorr.3]

Ok thanks.  I will try on a Windows and a MAC.  You may be right about the Linux driver... considering the Vendor and Manufacturer are sometimes filled with 'default' data when the connection fails.  ( either a pi character or copying the value from Product to Serial Number and Manufacturer ) I don't think the USB protocol or uC is adding these default values so it must be the Linux driver.  I'll also try upgrading my Linux kernel.

I also had a logic analyzer connected to the DM/DP pins but could not decode to usable values.  ( lots of 'reset' and 'error' fragments )

[LMorr.3]

I found the problem.  I tried on a MAC and Windows and it worked.  I then tried again on my Linux box, but using a USB port on my keyboard instead of using the USB ports on the front of my PC.  ( keyboard uses a different USB controller )  It worked flawlessly so it must be a bad USB port on the front of my PC.  It must have been damaged by all the abuse it has gone through with all my custom prototype boards.  Thanks for the heads-up, good call!