Why can ST-Link debugger reconnect after STOP2 but not SHUTDOWN mode?

[LWChris]

I am using STM32WB55, and try to implement power saving functionality.

I am using FreeRTOS and have a task that checks for the sleep conditions, and if they are met, it shall put the device in the lowest power mode possible. Wake-up is then triggered by an interrupt on PA0 (falling edge). After wake-up, the code will do a NVIC_SystemReset, so there's not a lot to worry about regarding SRAM data retention, restarting RTOS etc.

I have been able to utilize the STOP2 mode like so:

vTaskSuspendAll();
uint32_t dbgMcuCr = DBGMCU->CR;
DBGMCU->CR = 0;
PWR_EnterStopMode();
DBGMCU->CR = dbgMcuCr;
NVIC_SystemReset();

If I place breakpoints on lines 4 and 6 and run the code in debug mode, it hits the breakpoint on line 4 just before the MCU enters STOP2 mode. During STOP2, STM32CubeIDE keeps printing "Target is not responding, retrying..." which is understandable. When I trigger the IRQ on PA0 fast enough before it stops retrying, the debugger just reconnects and the breakpoint on line 6 is hit.

Now I am trying to achieve the same behavior using the SHUTDOWN mode. I am using this code:

vTaskSuspendAll();
DBGMCU->CR = 0;
if ((LL_PWR_IsActiveFlag_C1SB() == 0) || (LL_PWR_IsActiveFlag_C2SB() == 0)) {
  LL_C2_PWR_SetPowerMode(LL_PWR_MODE_SHUTDOWN);
}
HAL_PWREx_ClearWakeupFlag(PWR_FLAG_WU);
HAL_PWR_EnableWakeUpPin(PWR_WAKEUP_PIN1_LOW);
HAL_SuspendTick();
HAL_PWREx_EnterSHUTDOWNMode();
DBGMCU->CR = 7;
NVIC_SystemReset();

I am resetting DBGMCU->CR to 7, because that is the value I know CR had before I clear it in the STOP2 example.

If I add breakpoints in lines 9 and 11, line 9 is hit before entering SHUTDOWN mode. Again, STM32CubeIDE will print "Target is not responding, retrying...". I then trigger the IRQ on PA0. From the rest of the system, I see that the NVIC_SystemReset() has been executed, because I see all functionality come back to life. Meanwhile however the IDE keeps printing "Target is not responding, retrying...", until it finally gives up, which is several seconds after the system is already running normally again.

What am I missing in the SHUTDOWN variant that prevents the debugger from reconnecting, either before the NVIC_SystemReset to catch that breakpoint, or at least after the reset when everything should be initialized from the main() again?

[Bruno_ST]

Hello @LWChris​ 

Just to be clear, HAL_PWREx_EnterSHUTDOWNMode() is similar to a reset. The code behind is never executed if you enter in shutdown mode !

As soon as there is a reset occured (wakeup button pressed), the connection to target should possible again (feature attached to running target) and it is not the case ? Is it you issue ?

Are you using STM32CubeIDE ?

BR,

Bruno

[LWChris]

Hello @Bruno_ST​ 

oh, when I inspected the source code of HAL_PWREx_EnterSHUTDOWNMode() I saw the final line of code is __WFI(), as is the final line of code in PWR_EnterStopMode(). Since the latter method just exits after interrupt is received, I assumed so would the prior. But now that I think about it, it makes sense that wouldn't happen. Since SRAM is not retained, program counter, stack, etc. will all be gone after wake-up.

But the remaining "issue" is that in SHUTDOWN the STM32CubeIDE won't automatically re-attach vial ST-Link to the device, even if that is running again already and the IDE is still retrying.

With STOP2, the debugger automatically re-attaches after the device wakes up from STOP2. I don't need to press any button in STM32CubeIDE.

With SHUTDOWN, STM32CubeIDE will continue to print "Target is not responding, retrying..." for a few seconds, and then give up with "Shutting down..." and "Exit.", even if the device is awake for several seconds already.

[mattias norlander]

Hi,

Did you ever solve this?

The JTAG/SWD function is probably lost when entering the shutdown mode. In order to keep debug alive in the low power modes the DGBMCU->CR should be kept at 0x7. The IDE will configure this during connection if "Debug in low power modes" are set in the debug configuration settings.

Could you validate these settings? Maybe upload a screenshot of the Debugger tab of the Debug config GUI if you are uncertain?