USB non recognizable (Code 43) for STM32WB55 microcontroller

[JGoh.1]

Hi

I have a custom made PCB with a STM32WB55CGU6. It is normally programmed via USB DFU mode using the USB_DP and USB_DM of the microcontroller. I dont know why but it is unable to be detected by my computer as it is unrecognizable with an error of code 43 as shoiwn in the diagram below.

Here is also my Schematic & PCB layout for the programming part.

Here is also a link to the datasheet of the STM32: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ed=2ahUKEwjbxrremrjqAhXCoXEKHdKkBmQQFjAAegQIBhAB&url=https%3A%2F%2Fwww.st.com%2Fresource%2Fen%2Fdatasheet%2Fstm32wb55cc.pdf&usg=AOvVaw1alFzy0x1GLOyfV8ewuUlj

Do you guys have any suggestions on why it doesnt detect the microcontroller correctly?

[XPonc.1]

Hey,

I have a similar yet different problem.

You haven't stated that you programmed the microcontroller.... Your hardware seems to be just fine , but the problem seems to be the program.

If you go under CubeMX, create a new project for STM32WB55, activate "USB" under "connectivity" and "USB_Device" under "Middleware", then generate project and program your stm32 with the compiled code, this should work.

However my problem is that when I activate the RF stack and STM32_WPAN, it doesn't work anymore...

[KPenn.1]

Yeah, I had the same problem. I cleared it up by adjusting the relative interrupt priorities. Specifically, you have IPCC RX/TX interrupts, USB FS interrupts, and any others used in the app (e.g. EXTI, USART). It looks like the IPCC interrupts have to be the lowest priority or they block pretty much everything else. Haven't rigorously debugged the app to see if it still meets timing requirements of both USB and BLE protocols, but it'll at least get you un-stuck.

[XPonc.1]

I forgot to add that I got the problem:

https://community.st.com/s/question/0D50X0000C7cRcvSQE/problems-using-usb-mass-storage-middleware-with-ble-stack-on-stm32wb55

Apparently, the USB clock is used for the RNG module in the RF stack. You need a workaround (the code in the link works), with harware semaphores that allow/disallow the 48MHz clock ressource to be shared.

I'd like to have an official statement / document from ST to confirm everything...

cheers