cancel
Showing results for 
Search instead for 
Did you mean: 

DBGMCU_CR_DBG_STOP setting ignored

Andrew Neil
Evangelist III

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.

AndrewNeil_0-1701710496575.png

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

Is this the intended behaviour?

 

 

8 REPLIES 8

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.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Andrew Neil
Evangelist III

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
Chief II

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

"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
Chief II

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.

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
Chief II

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.