Racing RTC - days pass in a minute

[Trikkitt]

I've had this happen a few times and just can't figure out why. The RTC races ahead for no apparent reason at boot time. This is across multiple modules, but I can't find out how to recreate it. It just happens totally randomly.

Calls to the normal time related functions return figures as normal, but as an example 5 seconds in the real world passes but the clock goes forward by much more. The following were taken 5 seconds apart:

>>> rtc.datetime()
(2022, 6, 26, 6, 12, 12, 0, 477)
>>> rtc.datetime()
(2022, 6, 26, 6, 14, 29, 36, 179)

There is absolutely no reason why this should happen. But it will continue even with resetting the module. It seems to need a total power down to fix the issue. This breaks so much stuff as a lot of what I'm doing is time critical. I could create a check to validate the issue, but then I still can't see how to fix it without yanking all the power, which my circuit just isn't designed to do. Any suggestions?

[scruss]

The internal RTC of the ESP8266 can be charitably called not fit for purpose, and has been called far worse. An external I2C RTC such as the DS3231 will be far more reliable

[Trikkitt]

Indeed - I know it can drift a bit at times. But you're talking a few minutes over a 24 hour period. This was drifting by days every hour. Seems like some kind of weird condition that causes the RTC to go totally haywire during initial bootup and only a full genuine powerdown (the machine.reset() command isn't enough). Once fully powered down and back up the problem goes away and normal time is followed. So clearly something in bootup is having issues, but it must be some kind of very precise timing issue, because the problem doesn't exist very often and isn't specific to one module type (I've had this on ESP8285 and ESP8266 if memory serves.

[scruss]

The ESP8266 that taught me about this lost 11 minutes per hour: more that two months per year. They don't have useful RTCs

[Shards]

A while back I tested a range of microcontroller RTCs and the ESP8266 was easily the worst. If you must use an ESP8266 and require decent timekeeping either an external clock chip or frequent resetting using ntptime is essential.

It's not that Expressif can't do decent RTCs, timekeeping on the ESP32 is excellent.

[pythoncoder]

The issue isn't the RTC logic on the chip, it's the type of oscillator that drives it. ESP8266 board use an RC oscillator which has poor accuracy owing to component tolerances. Good quality boards use a 32KHz crystal which will give excellent accuracy. STM goes further by enabling the crystal oscillator to be calibrated: this can yield stability within about 1 minute per year.

I tested a UM Feather S2 (ESP32-S2) board. Its accuracy is about 0.9% or 30 seconds per hour. Looking at the schematic the chip seems to have provision for a 32KHz crystal but one isn't fitted. I'm unclear what the timing source is - as far as I can see the pins are unconnected. Accuracy is too good for an RC oscillator and too bad for a crystal.

[Roberthh]

I‘m coding for the SAMD chips at the moment. These have 2 built-in clocks, at 32kHz and 48 MHz. At room temperature they are like 0.2 % off. But they have a large temperature drift. Good enough for the CPU clock, but not for RTC.