Why does get_rtc_time_us() truncate the result to uint32_t?

[WiFive]

Maybe wakeup, read old cal value, do new cal, set rtc counter to

rtc_counter = ((rtc_counter_before_sleep * old_cal) + (sleep_count * (old_cal +new_cal)/2)) / new_cal

??

If we are worried about drift shouldn't we recal more often (not just at boot) and continue to rebase rtc_counter on latest cal value?

[ESP_igrr]

I was thinking along the similar lines, the only remaining question is how to do this without introducing RTC_DATA variables. Currently if the application doesn't use RTC_DATA, we can power it down.
Another option is to store these values in RTC_FAST_MEM, if it is kept enabled.

Probably will go for "rebasing" of the counter value after wakeup, assuming that calibration value was constant in deep sleep, and storing the calibration value in one of the remaining RTC__CNTL_STORE registers.

[WiFive]

Sounds good. So is it more accurate to take the constant new cal value on wake rather than some average since the die temp is going to be the major factor and is more representative of the die temp during deepsleep (assuming no large changes in ambient)? Should we do periodic cal as the die temp changes during runtime since temp at boot is not representative of temp at steady state full power?

[ESP_igrr]

Re. doing calibration at runtime — this can be exposed as a API to applications, so that they can do it once in a while if needed. Or just use 32k xtal if time precision matters.

[WiFive]

Got it. Will it be possible to call from a wake stub?

Now if we are using FRC1 for timekeeping during runtime we probably don't need to be doing calibrations but should we sync RTC counter to FRC1 before deepsleep?

[WiFive]

RTC seems to gain 0.8-1.1sec/min on FRC1 in normal runtime mode.

[ESP_igrr]

Calibration might still be messed up? Okay, will debug that as well.

[WiFive]

Also s_microseconds rolls over at 32-bit.

Code: Select all

RTC Time: 4330469173
FRC1 Time: 4260909211
RTC Time: 4391418173
FRC1 Time: 25941852 

[ESP_igrr]

I'm not getting the 1sec/min difference here, but will try a bunch of other boards, might be chip dependent?

timelog.png (57.61 KiB) Viewed 10571 times

[ESP_igrr]

Also s_microseconds rolls over at 32-bit.

Can't reproduce this here, can you hint at how you got these results?

Attached are graphs of RTC/FRC timers offset w.r.t. the timer on a PC.

RTC time was obtained from system_get_rtc_time, FRC time — from get_time_since_boot

timelog_rtc_frc.png (63.13 KiB) Viewed 10568 times

timelog_frc.png (86.08 KiB) Viewed 10568 times