Waking from SLEEP_MODE_DEEP ? status flag


Does anyone know if there is a status flag that will indicate when the Photon has wakened from SLEEP_MODE_DEEP via the WKP pin rather than a sleep timer expired wake up?

1 Like

I checked back at :spark: Particle and the answer was: “No, there is no way to know, after application code has started running again.”

At least for the time being :wink:

A possible hazy workaround would be to store the RTC time (e.g. FlashEE) before sleep and estimate if current time after wake does not fit the sleep timeout.

1 Like

Thanks @ScruffR Yeah, That’s an idea not sure if I am taken by it though. With my Core based product I had an RC to save a pin state (external reset switch) at least long enough that my user code was able to catch that a switch had been pressed, but now that the system code takes longer to hand over control to the user code on the photon my RC does not work. I have some ideas on how to make my RC hold its state longer and am going to play with that,

@mdma, @satishgn Having a flag available to the user code to distinguish between the 2 forms of wake up I am sure would be useful to many OP

1 Like

Another method to solve my problem would be if there was a way to have the system code save a snapshot of the io pins on wake up so that it could be checked by user code later. Is there any such ability?

You can use SEMI_AUTOMATIC mode to get faster handover to user code.
Also useful for cutting down on the led usage before the user code can use RGB to take control over it.

Thanks @MORA. I am already using Manual mode so that is probably the fastest. I am looking at the state of the pin at the very top of my setup() loop so not much more I can do in SW if there is not something in the system code to help me.

Quite honestly my further testing with the RC is not working out so I might have to go with @ScruffR’s idea on how to use the RTC. I might also take a look at the system code to see where or if this is detected by the system

have you thought about an SCR?

thinking if you could somehow latch the signal sent to the WKP pin, you can come back and check it and reset it…

just a thought

Hi @BulldogLowell I was looking for a solution to use my existing pcb as is. I ended up implementing @ScruffR’s idea on how to use the RTC expected wake up time compared to actual. It works very well.

I was hoping for a more elegant solution though and had spent a lot of time on this trying to figure out which system flag or combination of flags would help differentiate between the 2 wake up events. I have come to the conclusion reading the STM32 docs and doing many tests that the 2 alarm events are combined and there is not proper way to differentiate them with system flags.

1 Like

Doesn’t the millis() function reset after waking from SLEEP_MODE_DEEP?

@kropbj Yes when you wake up from Deep Sleep the counter will again restart at zero. My experience has been the it must be being reset by the system firmware because once user code runs the value is already at 1000+ or something like that

I thought there was a flag that was set in a status register. I don’t recall off the top of my head.


“4.4.2 PWR power control/status register (PWR_CSR)”


This has various flags related to power management that are only cleared on a full reset and not cleared on wakeup from sleep. E.g.

This bit is set by hardware and cleared only by a POR/PDR (power-on reset/power-down reset) or by setting the CSBF bit in the PWR power control register (PWR_CR).
0: Device has not been in Standby mode 1: Device has been in Standby mode

1 Like

@mdma are you sure that the status registers that would differentiate the 2 modes of wakeup are still holding their wakeup values once user code runs?

From all the testing and research I did I thought that this should have been possible to differentiate, but in practice I was never able to make it work therefore assumed that system code was resetting the registers before user code could read them.

I searched the firmware repo and the PWR_CSR register isn’t referenced anywhere other than STM32 header files. So this should still be intact.

@mdma I know I played with it specifically. At some point I will circle back around and give it another try.

Just to follow up, the firmware is clearing the flag in rtc_hal.c. I am going to remove this (and also provide a HAL interface function so application code can determine in a cross platform way if the device woke up from sleep mode.)


Is there any update to this thread?

Has anyone found a way to determine how the device woke up from sleep mode (timer or interrupt?)


Anyone know if this modification to the firmware clearing the flag in the rtc_hal.c and HAL interface function update was ever done, and if so, where the HAL interface function is documented?

I know there is a lot of “discussion” about this topic on the community (and users pointing other users to other threads, or suggesting they search on their own as this has been asked many times), but from hours of searching, and since this “suggestion” was a couple of years ago, I can find no clear answer that supports this Particle’s senior engineer’s inference that he (or anyone else for that matter) actually did provide this solution.

As a workaround, you could just check for Time.now() before it goes to sleep, and after it woke up from sleep. Then derive the number of seconds it was sleeping for, and check this against the sleep timer that you initially set. Match = woke up from the timer, Mismatch = woke up from the WKP pin.

Not the fanciest way of doing things perhaps, but it works great for me.