Why do we have to clear Deep Sleep bit after wake up?

[jfcote]

Hi everyone,

Is anyone can explain the SLEEPDEEP bit from SCB->SCR with more information than the pm0214 stm32 cortex-m4 reference manual?

Controls whether the processor uses sleep or deep sleep as its low power mode: 0=Sleep, 1=Deep Sleep

What i want to know exactly is why do we need to reset this bit when waking up?

If you refer to the image attached, taken from HAL_PWREx_EnterSTOP2Mode, first line after __WFE(),is to clear back the deep sleep bit.

What is the effect to clear that bit?

For your information. it seems to be very important on STM32WLE4CB because it fixed a mcu deadlock/crash issue i had recently.  I had a __NOP() following the __WFE() instead of the deepsleep bit clearing.

Any information you got regarding this will be very helpful to understand.

Best Regards

[Issamos]

Hello @jfcote 

I suggest you to take a look at the pwr chapter in the reference manual of your MCU. That should explain this.

Best regards.

II 

[jfcote]

I have an update regarding my original post.

I still have the deadlock issue while in stop mode 2 on stm32wle4cb.  It seems the mcu does not wake up from stop mode 2.  When the issue occur, I stop IAR st-link debugger and my disassembly code is pointing outside internal flash memory address like the stack is corrupted.

1) If i put a line in comment to NOT enter stop mode 2, the crash never occur.  Everything work fine.

2) If i do not use the deep sleep bit in SCB->SCR register to use regular sleep mode, the crash never occur as well.

3) As a test, i set a gpio pin just before executing the __SEV(); __WFE(); __WFE(); and clear the gpio pin on wake up.  I can confirm that the pin is set when the crash occurs. So it means entering deep sleep is causing something internally to the mcu.

Am i missing something regarding deep sleep and __WFE?

Regards,

[Billy OWEN]

Hi @jfcote 

The forum moderator had marked your post as needing a little more investigation and direct support. An online support case has been created on your behalf, please stand by for just a moment and you will hear from us.

Regards,

Billy

[jfcote · Accepted solution]

Hi @Billy OWEN 

I successfully been able to pinpoint the issue.
There was a corner case where the unit was not going through the expected sequence when waking up for periodic tx. Because of that, the SysTick was configured on that wakeup, but not disabled before entering deep sleep and that seems to be the cause of the crash/freeze.

We tried replicating the issue and even on first start-up when everything is configured properly, if we leave the SysTick running before entering deep sleep it completely crashes the MCU.

So finding the SysTick was the cause, i double-check in the errata sheet to find this:

2.2.9 SysTick trigger in debug emulation generates HardFault

Description
When the CPU enters its deepsleep state and debug emulation is active, the CPU SysTick is still running and
able to trigger interrupts. The CPU is woken up and fetches code from the system Flash memory. As the Flash
memory is not active, the CPU starts fetching code from a resource that is not available, and receives random
data from the bus, causing HardFault.
When the debug emulation is active and the CPU enters its deepsleep state, the system exhibits unpredictable
behavior due to the SysTick activity.

Workaround
Always disable SysTick before the CPU enters its deepsleep state. This consistently prevents any interrupt
triggering and any possibility of HardFault.

So the issue is now resolved.  Thank you very much.