ESP8266 Community Forum

- Sun Feb 16, 2020 5:08 pm #85695

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.

- Mon Feb 17, 2020 4:21 am #85698 problem is that the whole deep-sleep-wake_via_reset is bad work-around for a broken design.
actually the deep-sleep-wake works without the gpio16-rst connection and shows correct wake-up-reason but the internal boot-loader does not know how to handle the situation and does not start user code.

- Mon Feb 17, 2020 7:49 pm #85708

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.

Nope, that is not the problem. The problem is actually in the behavior. I don't care what they call it, I understood the behavior by reading the documentation and that behavior is wrong because it could have been better at no cost.

There is enough hardware to potentially allow you to do something, yet you cannot do it because they decided to write the software in a way that prevents you from doing it, and you have to add extra circuitry to regain what was already there in the first place. If that is not bad software design I don't know what is.

I don't know whether the RTC counts forward or backwards; either way, being able to read its value at the beginning of user code would be useful. Having it reset doesn't gain you anything in exchange for what you lose.
Actually, reading the RTC at any other time later in user code, is of no use: for that you can already read the system clock. So in that respect it makes no difference whether it's reset at boot or not: it's equally useless. The one time where it is useful to know its value is at startup. So, if there is a good reason why it needs to be reset, they could have copied the value before resetting and stored it somewhere where user code can read it later.

It was just plain stupid, mindless design. And what is worse is that years later, when forums all over the internet are full of questions like "how to tell the difference between wake up and reset" and all the variants, they still haven't fixed it.

- Tue Feb 18, 2020 4:03 pm #85733

I don't know whether the RTC counts forward or backwards; either way, being able to read its value at the beginning of user code would be useful. Having it reset doesn't gain you anything in exchange for what you lose.

So given the way and speed the counter works, its 64 bit register is going to wrap around roughly every 3.5 hours. When the chip is awake you can easily deal with the wrap around, which is what the clock code does.

But if you're woken from deep sleep and the RTC says you've been asleep an hour, how do you know it hasn't been 4.5, or 8, or 11.5 hours? The only way you're going to know that is if you have an actual battery backed RTC off chip.