DBGMCU_CR_DBG_STOP setting ignored

[Andrew Neil]

Setting DBGMCU->CR.DBGMCU_CR_DBG_STOP should allow debugging in STOP mode; eg, from ST examples:

  /* Allow debugging in Stop Mode */
  DBGMCU->CR |= DBGMCU_CR_DBG_STOP;

  /* Enter Stop Mode */
  HAL_PWR_EnterSTOPMode( PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI );

But, if 'Debug in low power modes' is set to anything other than 'Enable', that statement has no effect - the bit is not set, and the debugger loses connection.

When 'Enable' is selected, the bits are already set - so the code is pointless.

Is this the intended behaviour?

[Tesla DeLorean]

Which part?

It's not uncommon for the debugger implementation to push in settings that suit it's operation, irrespective of whether you can do some manually from MCU side application code.

ST, Segger and Keil pods may have assortedly different behaviours and expectations.

Might be relevant if the pod is attached subsequently, the bits purpose in the general sense is to keep portions of the logic powered which might otherwise be turned off. ST doesn't share a lot of internal operational details, so exact operation over different models and families may be subtly different.

You should probably chat with your FAE, or other internal contacts, to determine expected behaviours in different circumstances.

[Andrew Neil]

Oops - omitted to mention:

STM32CubeIDE Version: 1.13.0 Build: 17399_20230707_0829 (UTC);

STM32F030.

"if 'Debug in low power modes' is set to anything other than 'Enable'"

On further investigation, that's not quite right:

• If 'Enable' had previously been set, then 'No configuration' acts as 'Enable';
• If 'Disable' had previously been set, then 'No configuration' acts as 'Disable'.

[Piranha]

From the DBGMCU_CR register documentation:

It is asynchronously reset by the PORESET (and not the system reset).

Therefore it just keeps the previous value until one disconnects the power supply and waits until the capacitors discharge.

In addition I will remind that all of ST's HAL/Cube and example code for low-power modes is broken. To implement correct code, read these topics:

https://community.st.com/t5/stm32-mcus-motor-control/mc-sdk-not-work-with-mcu-stop-mode/m-p/94522

https://community.st.com/t5/stm32-mcus-embedded-software/how-to-enter-standby-or-shutdown-mode-on-stm32/m-p/145849

[Andrew Neil]

"Therefore it just keeps the previous value until one disconnects the power"

OK, but shouldn't the line

DBGMCU->CR |= DBGMCU_CR_DBG_STOP;

be able to override that value?

EDIT

Or is this just a debugger limitation - it can't/doesn't see/display changes to these bits?

[Piranha]

That line should enable the respective bit and the debugger can read it as a normal register. Maybe try if setting that bit once and early in the project makes some difference. Also try setting an SWD frequency to some safe value, for example 4 MHz. On L4 series I have debugged going into and out of Standby and even Shutdown modes, not loosing the debugger connection, so Stop modes should definitely work.

[Andrew Neil]

With the IDE setting, it is working to be able to step "over" the STOP mode.

But overriding the IDE's "no debug" by runtime code doesn't seem to work.

And harder to be sure that the bits are not set when I want them not set!

[Piranha]

For me disabling the standby bit on L4 in code definitely works and the debugger looses connection. Though I'm using EmBitz IDE and J-Link, which sets these bits at connection. Are you sure that, when you are testing it, the device actually enters the Stop mode? The WFI instruction doesn't guarantee it... Maybe CubeIDE and/or ST-LINK is doing something that it shouldn't. For example, re-configuring those bits on every breakpoint or step.

[Andrew Neil]

Looks like someone else having the same issue:

https://community.st.com/t5/stm32-mcus-boards-and-hardware/stm32f030-disable-debug-in-stopmode-from-firmware-registers-edit/td-p/696293