php fan wrote:davydnorris wrote:Yes this is documented behaviour - both system clock and RTC clock are reset after deep sleep,
Documented but nevertheless a plain wrong design.
There's an RTC that keeps track of time during deep sleep, and yet the software destroys that valuable information for no good reason.but the RTC memory is retained.
Unfortunately that's of no help in order to know how long the deep sleep has been, nor does it provide a way to even distinguish whether we woke up automatically or by external reset during deep sleep.The built in RTC is actually not very accurate
I know, it's terribly inaccurate, but even so it's accurate enough for my application, so it enrages me that I have to add extra hardware to obtain information that was already there in the first place but someone decided it was a good idea to erase.
It's not actually a wrong design - it's a wrong description. The problem is that they call it a Real Time Clock. It isn't, it's a counter.
It doesn't keep track of time during deep sleep - it is set to the number of ticks you want to sleep for and it's used as a countdown timer for wake up, which is why it is 'reset' when it's woken up - it's counted down to zero.
It also wraps roughly every 3.5 hours so it's useless for keeping time.
It also is HIGHLY inaccurate if the ambient temperature changes more than a few degrees while it's sleeping, because it bases its tick value on the calibration factor at the point you went into deep sleep. I have seen it vary up to 15-20%.
So my advice is to be enraged at the documentation, not the hardware, and find a better approach than the deep sleep clock.
If you need to distinguish between a deep sleep reset and a hardware reset, you have two options:
- since the deep sleep reset is exactly the same as a hardware reset except for the real time memory, you can use the CH_PD instead of RST and that will generate a different restart code
- if you need the real time memory, then you will need to add a bit of external logic that sets one of the GPIO pins high for a second or so if an external wake up caused the restart. You can then read the pin to see if your chip was woken externally
I figure if you're going to add the external logic to work out if there was an external reset, you may as well add a proper RTC chip instead and then you can tell explicitly exactly how long you've been asleep regardless of the way the chip's woken up.
The other approach is what I have done - I connect to an SNTP clock and set the time. I need to send regular heartbeats anyway so I have to connect to a wifi AP, and an SSL connection needs the time to be set because it's used during the connection.