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]

The device is self-powered so it does not use the USB+5V other than current sensing it.

I will try introducing a 250ms delay before and after USB initialization tomorrow.  It also happens when the device is powered up and connected successufully to USB, but I disconnect and reconnect the USB cable.  I use EXTI interrupt to detect the USB+5V to enable the pull-up on DP

[LMorr.3]

I think my issue is related to my clock settings.  I have USB set to 48Mhz but can someone take a look an let me know if the 24Mhz are potentially causing a USB CDC timing issue?

This config does causes the USB descriptor string to sometime be corrupted:

This config causes USB descriptor to be sometimes corrupted.

This config seems to work, but my code has references to 24Mhz so I would need to update my code if I change all APB clocks to 48Mhz.  ( I would prefer to keep my clock settings as-is with 24Mhz APB clocks )  

My code uses a 24Mhz clock with SysTick dividing by 1000 to produce a systick at 24Khz.  I don't want to change that part of my code so I hope I can also get USB CDC's clock set correctly at 48MHz.

This config works

[TDK]

I wonder if it's a layout issue and you're getting noise on the USB lines due to switching noise or other digital signals. Are the usb traces short and routed differentially? Sufficient 0.1 uF decoupling caps on all pins?

[LMorr.3]

This sounds like something I should investigate.  I can trace the DM/DP to ensure differentially since I just eye-balled it. ( I did not use the differential routing feature in Kicad ).   I ignored this since the USB comm worked well once connected. ( only seemed flaky when first connecting the cable )

I did NOT include 0.1uF decoupling caps on all pins.  Which pins should I add them to?  ( all used input GPIO pins on the uC? )  Do I add 0.1uF to DM and DP?

[TDK]

I meant to say 0.1uF decoupling caps on all power (VDD) pins. GPIOs don't need them.

It is odd that it works well once connected. Never experienced that behavior myself.

[LMorr.3]

Ok thanks.  It is a bit odd... It consistently works flawless with the alternate clock settings.  I don't know enough about USB protocol but perhaps the corruption issue is being hidden by error correction at higher 48MHz clock settings.  

I need to spin up new boards to test if differential routing for DM/DP will fix it unless I find another potential cause to investigate.  I'll report back when I get it working.