cancel
Showing results for 
Search instead for 
Did you mean: 

When I program my device in debugging via JTAG/SWD with instances of low-power STOP mode within the code and disconnect Debugger, device never goes to sleep and get Ghost wake-up INTs. However, if I power cycle not pin reset device, every thing works.

UAnya.1
Associate II

Is there registers set by JTAG/SWD preventing sleep after programming.

I also experience the same behavior after programming and reset within the STM32 ST-LINK Utility and not only within the IDE

5 REPLIES 5
S.Ma
Principal

Do you try to say that the target MCU debug IP prevents clock stop modes and these settings requires HW reset to go back to default?

Usually if not, the STLink can't entrer debug mode if user code already in sleep, and reset as bootloader mode would be the only way to recover (as STLink doesn't control the boot pin, this is a manual operation)?

I believe this what I am trying to say - target MCU debug IP prevents clock stop modes and these settings requires HW reset to go back to default. Even after enabling the setting the DBG_STOP or DBG_STANDBY bits in the DBGMCU_CR register which is not really required. Is this expected behavior? Note: I do not try to enter debug mode in sleep and I disconnect debug using only console print for debugging via serial so no connection to debugger after initial flashing.

What part specifically are we talking about here?

Several of the newer STM32 need power cycling to clear internal settings related to FLASH or Option Bytes, improves robustness against hacking exploits.

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

Okay if this is the case, the programming reference manual doesn't specifically state this in the low power mode operation. Can you point to documents that can help understand the underlying issue. Well I use RTC running on LSE to wake up device at x interval and I think when connected to the debugger/jtag, the mcu is prevented from sleep and hence require a full on power cycle before operating normal again.

KLars.3
Associate

Hi @UAnya.1​ 

Did you solve this?