STM32WLE restarts after exiting Standby instead of continuing the execution

[frnt]

Hello,

I'm porting the code developed for the STM32WL55 development board to a STM32WLE5.

Using the STM32WL55 I had no issue in putting the board into STOP2 and STANDBY, restoring the execution of the program after wakeup from RTC interrupt.

However, I'm having trouble with the STM32WLE. Here, I can successfully put the microcontroller into STOP2 and wakeup it to continue the execution, but unfortunately, I'm not able to restore the execution after entering STANDBY.

Where is the difference? From the reference manual, they appear to behave similarly. However, the only thing I see is that the STM32WLE reset the MCU after exiting STANDBY instead of continuing the execution as happened for the WL55.

After the execution of the WFI, the WL55 continues the execution after receiving the RTC interrupt. On the contrary, the WLE restart from the main after exiting the deep sleep state.

According to both reference manuals, section "Exit low-power mode" they report:

From Standby and Shutdown modes, the CPU exits low-power mode through an external reset (NRST pin), an IWDG reset, a sub-GHz radio IRQ, a PVD event, an edge on the sub- GHz radio busy signal, a edge on one of the enabled WKUPx pins, an RTC and TAMP event, or a radio event (for Standby only).

After waking up from Standby or Shutdown mode, the program execution restarts in the same way as after a reset (boot pin sampling, option bytes loading, reset vector is fetched).

The system mode when it wakes up from low-power mode can be determined from the C1STOPF, C1STOP2F and C1SBF bits in the PWR extended status and status clear register (PWR_EXTSCR). 

According to the last paragraph, I would expect a reset also in the WL55 but it does not happend.

I’m interested in restoring the execution when exiting STANDBY, instead of a complete reset of the MUC

Does someone have suggestions?

Thanks a lot.

[Louis AUDOLY]

Hello @frnt​,

Could you compare the startup files of the two projects to ensure you store and restore the context correctly when you exit from Standby mode.

Otherwise if you don't store your context, you should have the same behavior between those two boards.

Regards

Louis

[frnt]

Dear @Louis AUDOLY​ ,

thanks for your reply. I have checked both startup files and they seem identical except for a few lines in the vector table (see them attached).

I never modified the startup files of the two projects.

Do you have some suggestions?

Best,

[frnt]

I'm uploading the section file in a new reply because only one was allowed in my previous answer.

[Louis AUDOLY]

Hello,

Could you give more information about the code you are running ?

If you try with the example code from STM32Cube_FW_WL_V1.2.0, under "Projects\NUCLEO-WL55JC\Examples\PWR\PWR_STANDBY", you should have the same behavior for the both target.

Regards

[Piranha]

https://community.st.com/s/question/0D53W00001bnh8dSAA/how-to-enter-standby-or-shutdown-mode-on-stm32

[frnt]

Thanks for the clarification. Because with the WL55, the program can restart right after the WFI call instead of restarting from main. That seems not to be possible with other single core microntrollers.

[Piranha]

RM0453 Rev 3 section "6.5.4 Exit low-power mode":

After waking up from Standby or Shutdown mode, the program execution restarts in the same way as after a reset (boot pin sampling, option bytes loading, reset vector is fetched).

Which part of that sentence is not clear? Your actual issue could be that the MCU does not enter the Standby mode at all. That's why I gave the link to my article and for multicore parts there is also an important note in section "6.5 Low-power modes":

The system operation mode depends on the CPU1 and the CPU2 sub-system operating mode. The system only enters a low-power mode when both sub-systems allow it to do so.

[MAult.1]

Hi, did you ever resolve this? I see you got little help here. I have the same issue. Once LORA is initalised with LmHandlerInit(), standby just fails (and resets like you said). I have tried all sorts to de-init/shutdown the Lora stuff, but no joy.  Please tell me you resolved this. (Note I did remove the standby disable in the lora code).
Cheers, Matt

[MAult.1]

Finally found  my wake-up cause. Radio was poking me in the ribs. This stopped it though:

/* Disable EXTI 44 : Radio IRQ ITs for CPU1 */
LL_EXTI_DisableIT_32_63(LL_EXTI_LINE_44);

/* Disable wakeup signal of the Radio peripheral */
LL_PWR_SetRadioBusyTrigger(LL_PWR_RADIO_BUSY_TRIGGER_NONE);