USB CDC device not being recognised by windows. (STM32WB5M, Bluetooth low energy)

Javier1 · ‎2021-12-17

Context:

I have succesfully implemented a CDC device in a stm32f205 board 6 months ago.

Now im trying to implement the exact same thing in my STM32WB5M discovery board.

BLE is already activated and working P2P custom server

Using CUBEMX 6.3.0
FW package STM32Cube_FW_WB_V1.13.0

______________________________________________________________________

Problem:

Windows doesnt recognise the USB device.

________________________________________________________________

How did i got here:

I enabled the USB device mode in cubeMX

I enabled the middleware

I autogenerate the code....

Inside usb_cdc_if.c i add this code

everything compiles and runs but windows doesnt recognice the USB device

Find attached my cubeMX file.

The Windows doesnt recognice error appears when the usb is enabled (i dont know if this means anything )The usb handle struc doesnt show any errors after init

Available for consulting/freelancing , hit me up in https://github.com/javiBajoCero

Adrian Adamson · ‎2022-12-15

I'm having the same symptom.

I am using a board where the USB hardware interface works fine when I run other firmware.

I started with the .ioc file from the P2PServer and used CubeMX to generate my own project. With the help of some code from the p2pserver project, the project works fine without USB enabled, and I was able to modify it to enable it to work with FUOTA. I used CubeMX to enable the USB full-speed device, set the heap size to 0x2000, changed the GPIO speed to very fast, changed app_conf.h to the following:

#define CFG_USB_INTERFACE_ENABLE    1

and still I get the same problem where computer I plug the USB into says there's a problem with the device. I have tried disabling low power mode with no success, and I also updated the clock configuration to better match my working USB example:

@Khouloud OTHMAN @Remi QUINTIN Are there any known examples of USB working alongside USB? I just received the first small production run of a new product I'm making where I was counting on using the USB device along with BLE.

Javier1 · ‎2022-12-16

As i said 1yr ago:

My design allowed me to replace USB for UART communications.>I dont think im comming back to face this USB+BLE issue anytime soon.

And i very didnt, i still suspect the "Sequencer" used with the BLE API is the reason USB doesnt work.

Maybe they changed something since STM32Cube_FW_WB_V1.13.0 ? maybe not

Good luck @Adrian Adamson

Available for consulting/freelancing , hit me up in https://github.com/javiBajoCero

ICMosquera · ‎2023-07-17

Im still waiting for the developers to address this problem. I hope this get fixed soon.

KlemenPfce · ‎2023-11-08

Hello, I had same problem with STM32WB5M module on our custom project and also gave up on fixing USB sequencer bug, due to limited time resources and just switched to USART1 and added an ftdi serial to usb converter.

jrm · ‎2024-12-04

Has anyone found a fix for this issue. I have a project that requires both USB and BLE to be supported at the same time. I have noticed the same behavior, once the BLE sequencer is enabled, the USB function dies.

Adrian Adamson · ‎2025-02-01

I put in a support ticket in 2022 when this came up for me, and STM engineers gave me a project framework that worked. Now I'm starting on a new project from scratch that also uses BLE FUOTA and USB, and I think I'm running into either the same problem or one that's related. I'm searching for the original support ticket and came here. So the good news is, it's possible to use the BLE sequencer and USB, but the bad news is that I have forgotten what the fix is. I may end up starting over starting with cloning my previous project.

Adrian Adamson · ‎2025-02-01

I found my support ticket and here's what they said:

"Thank you for your patience. Please see the attached example code. We were able to determine the root cause of the issue. One of the semaphores of the BLE sequencer (specifically semaphore 5) is causing CPU2 to switch off the USB clock. Semaphore 5 is responsible for controlling the USB CLK48. During CPU2 startup, the CPU2 needs semaphore 5, but it is busy. Thus the HSI48 oscillator is switched off by CPU2 when a wireless stack is started. Therefore, the issue is in how the BLE stack is functioning, but not necessarily a bug. We were able to create a workaround and you can find it in the example code."

I think this led to the code that's available here: https://community.st.com/t5/stm32-mcus-wireless/usb-device-does-not-work-when-starting-ble-stack-on-stm32wb55/td-p/176360