Debug in STOP mode, how it should work?

[Gordon01]

If STM32L0 spends most of the time in STOP mode and I haven’t set any breakpoints, it seems impossible to break-in.

VisualGDB shows window “The GDM break-in request is taking too long to complete”.

I’ve googled this problem and for everybody adding a line with

HAL_DBGMCU_EnableDBGStopMode();

but not for me.

Adding this line doesn’t change the behaviour of VisualGDB at all.

And also “Live Variables” breaks and shows garbage if the CPU spends most of the time in STOP.

[Gordon01]

OK, I’ve googled more thoroughly and discovered that I missed enabling DBGMCU interface with

__HAL_RCC_DBGMCU_CLK_ENABLE();

Looks like it’s now working as intended (except for increased power consumption).

But “Live Variables” still not work properly: it shows 0 most of the time and the real value for just a fraction of second.

[support]

Hi,

The Live variables function relies on the CPU’s ability to read the memory contents without completely stopping. The exact details of this mechanism are target-specific and it is completely plausible that entering the STOP mode would power down either the memory itself, or the logic responsible for reading the memory through SWD/JTAG.

Our best advice is to check the STM32 documentation for the description of the STOP mode logic. There might be a configuration register that allows specifying which clocks actually get stopped during the STOP mode and you might be able to prevent the memory from being powered down (checking what exactly __HAL_RCC_DBGMCU_CLK_ENABLE(); does can provide some clues as well).

Please also feel free to ask on the ST forums, or contact ST support, as they have a better insight into the STM32 tutorials.

[Author]

Posts