STM32 as USB COM Device fails when debugging but works when running.

[NoobWhoIsGettingBetter]

Hello dear supporters,

I had some issues setting up my STM32G0B1CET6N as USB Communication Device Class (Virtual Port COM). 

Clock Source for the USB is the internal "HSI48 RC" oscillator, designed for USB application.  

What happened? 
I used the default USB Settings (default USB STMCube MX generated).

I started debugging (step by step) and came to the 

MX_USB_Device_Init();

function inside the main.c 

Then I open the Windows11 "Gerätemanager (Device Manger)" and the USB device always failed to get recognized. 

--------------------------------------------------------------------------------------------------------------------------------------------------

I relaunched the debugger and this time I just klicked on the "Run" button. No step by step debugging this time. The STM32 gets recognized as a COM device without any problem. 

And the communication (sending data to the putty terminal) works without any problem. 

-------------------------------------------------------------------------------------------------------------------------------------------

However when adding a debug breakpoint (for example in the while(1) loop) the STM32 gets no longer recognized as a COM device anymore. 

Same problem as before:

---------------------------------------------------------------------------------------------------------------------------

So is this a bug? Or is it simply not possible to have a working STM32 COM-device when working with the debugger? Is this problem caused by the fact, that the USB works via Interrupt and interrupts fail in the debugger?

-------------------------------------------------------------------------------------------------------------------------------------------

Thanks for tipps and explanations 

[Andrew Neil · Accepted solution]

---

@NoobWhoIsGettingBetter wrote:

However when adding a debug breakpoint (for example in the while(1) loop) the STM32 gets no longer recognized as a COM device anymore. 

---

I don't think that's altogether unexpected?

By putting a breakpoint, you will disrupt the comms between the USB Host (your PC) - which could well cause the failure.

---

@NoobWhoIsGettingBetter wrote:

So is this a bug? Or is it simply not possible to have a working STM32 COM-device when working with the debugger?

---

You have to be very careful about breakpoints withing timing-critical code!

---

@NoobWhoIsGettingBetter wrote:

Is this problem caused by the fact, that the USB works via Interrupt and interrupts fail in the debugger?

---

It's not that they fail as such - but halting the core may cause deadlines to be missed.

This isn't specific to STM32 - it's an inherent limitation of halting debug.

Segger have a clever trick to help in these situations but, IIRC, not on Cortex-M0:

https://www.segger.com/products/debug-probes/j-link/technology/monitor-mode-debugging/