STM32F405 CDC USB isn't enumerated by the host

[Jcoll.1]

I have a new STM32F405 based board design. It is USB powered. In cube IDE I have the STM USB section configured as 'device only', 'no vbus sensing', and I have the middleware set to CDC and 'USBD_SELF_POWERED' is disabled (although I have tried both settings).

When I plug the board in to a host the host wont even attempt to enumerate it. I have also checked this with wireshark. I have tried several known-good cables and USB ports. The fact that the host won't try to enumerate makes me think that the STM is not pulling the D+ pin high.

As a test I powered the board from a bench supply, with no USB cable attached, and measured the D+ and D- pins. I expected to see 3.3V on D+ but instead I see about 500mV on each pin. This is suspiciously close to a diode breakdown voltage, so I double checked the orientation of my USB ESD package and it appears to be correct.

Before I remove this package, does anyone have any suggestions for things I can test in hardware or software?

EDIT #1 - I removed the ESD chip and D+ and D- continue to float around 500mV (when not attached to a host) and the host does not attempt to enumerate.

EDIT #2 - The chip is STM32F405VGT6. I believe this chip has integrated USB pull-up resistors.

[waclawek.jan]

IF OTG_FS, DFU bootloader enumerates?

JW

[Jcoll.1]

Thanks for your reply, JW.

I don't know what "IF OTG_FS" means.

I've never used the USB bootloader, but my understanding is that if I pull BOOT0 high that it should allow programming via USB. I just tried this and it clearly does not load my default program, however I also don't see any USB activity.

[Jcoll.1]

I went ahead and removed the ESD protection chip and confirmed the pinout from the end of a USB cable to the chip.

I still do not see an enumeration attempt from the PC, even when pulling BOOT0 high. And more importantly, when running my application, D+ and D- continue to float around 500mV (when not attached to host).

Is VUSB required for the bootloader to work?

[waclawek.jan]

I meant, you can test the hardware through bootloader, if the USB you are using is OTG_FS, as bootloader uses only that (and if you use a crystal with integer values as outlined by AN2606).

In other words, which pins are you using?

If DP is not pulled up, check if DP/DM are properly set in GPIO by reading out and checking the respective GPIO registers; then check if the USB module has clock set in the respective enable register in RCC, then check the OTG registers - you should have GCCFG.NOVBUSSENS = 1, GCCFG.PWRDWN = 1, DCTL.SDIS = 0.

I don't use Cube so can't help with that.

JW

[Jcoll.1]

Ah, I understand now. Looking at AN2606 my setup should support USB DFU (16MHz clock; PA11 and PA12, the OTG_FS pins). BUT, since I wasn't planning to use this feature I didn't route the BOOT1 pin, which is required to get into the bootloader (BOOT1=0, BOOT0=1). I ran out of fine gauge wire to manually jumper that, so I won't be able to try the USB DFU until Saturday.

I ended up finding the problem. My clock configuration had the system clock being sourced from HSI while USB (the 48MHz clock?) was being sourced through the PLL by the HSE. I found that if I sourced the entire design from HSE that the system would fail. On closer inspection the HSE is never going ready. Specifically this line is never passed: `while(__HAL_RCC_GET_FLAG(RCC_FLAG_HSERDY) == RESET)`. I can get around this problem by sourcing the PLL from the HSI.

I suppose I should start a new thread to troubleshoot the HSE issue. The parts and design come from a known working project, so I'm thinking maybe an assembly error.

[waclawek.jan]

HSI is not precise enough to run USB. There is also some minimum system clock frequency requirement for USB to work (14MHz IIRC).

JW