STM32L476VG USB CDC Not Recognized

[jacob2]

Posted on October 12, 2016 at 19:56

I'm working on a USB CDC project to get a virtual com port using an STM32L476VG processor, I have it configured to be a device only in hopes to simply pass information over the com port between my board and PC. I am able to trigger the interrupt when the USB connection is made, but I am not able to have the computer identify the USB. I set everything up in the STM32Cube application and have the latest virtual com port drivers installed from ST. I was able to run essentially the same USB style on an STM32L476G-EVAL board, both projects configured the exact same in everything with regards to the USB. Are there any suggestions on how to handle the Unrecognized USB for my main board I plan to be using? I've already confirmed the interrupt occurs and that I have the correct drivers installed, I'm just not seeing it be recognized correctly.

#!usb #stm32l4 #cdc #!vcp

[Tesla DeLorean]

Posted on October 12, 2016 at 20:41

And how does your board design differ from that of the EVAL one? Clock sources?

[jacob2]

Posted on October 12, 2016 at 21:55

The rest of the pinout is different from the EVAL board, however I still have a 48MHz clock set for USB as configured by STM32Cube utility on my custom board.

[stm322399]

Posted on October 13, 2016 at 10:00

Is the source of 48MHz clock stable enough (e.g. derived from a quartz) ?

[jacob2]

Posted on October 13, 2016 at 15:52

I'm using the multi-speed internal (MSI) oscillator for the STM32L4 family of processors which ST states to have an accuracy of Â±0.6%. I guess I may need to look more closely at the clock to ensure it actually runs at the specified speed.

[stm322399]

Posted on October 13, 2016 at 17:33

Did you run on EVAL board deriving USB clock from MSI as well ?

Crystal-less USB systems are not very common, and L476 reference manual clearly states that USB clock is derived from a quartz (see 43.4.2 OTG core), to get higher precision than MSI capability.

[jacob2]

Posted on October 13, 2016 at 17:57

Here is the configuration for the EVAL-Board, as you can see it still bases off of the MSI clock. In my board configuration, it is slightly different where instead the MSI is configured for 48 MHz and passed directly to the clock for USB.

[stm322399]

Posted on October 13, 2016 at 18:29

The pro of the EVAL board config is that the last divider might deliver a cleaner duty cycle than feeding directly from MSI.

I already worked with an USB IP requiring 96MHz (that will be internally divided to 48MHz). The documentation saying that it has been done so to get a very clean 50/50 duty cycle. Can you try to use the PLL (x2 then /2) on your board ? That would be interesting to see if it works better that bare MSI. Anyway, even when this setting works, I won't bet that this is a safe choice for a product on the field.

[jacob2]

Posted on October 13, 2016 at 20:15

I can check for another available clock to work off of with the settings, but I was able to verify with a frequency counter that my MSI clock is operating at the specified 48 MHz, there is a minor offset of about 8800 Hz but that wouldn't be enough to cause problems, would it?

[jacob2]

Posted on October 18, 2016 at 23:37

FIXED:

The HCLK ended up being the problem where ST auto-generates code in the HAL_PCD_IRQHandler() for uint32_t hclk to be at 80000000 which isn't a problem if your HCLK is configured for 48 MHz or higher, but ours was at 24 MHz. Still running into an issue with running at the 24 MHz but am working around it!