clock_gettime sometimes returns the wrong time (seconds in the past)

[inge2]

Hello,

I've got an issue with the clock_gettime function.

When I set the RTC time to a known hour (00h11h00s in my case), I don't read the same value immediatly after, I get 00h10m59s.

Does someone has already encounter this issue? Is there a better way to update the RTC value, avoiding this drift (in the past)?

To set the RTC value:

I'm using timeutil_timegm64() to convert POSIX date time into a timestamp and clock_settime with the CLOCK_REALTIME to set my new value.

To get the RTC value:

I'm using clock_gettime with the CLOCK_REALTIME to get the timestamp.

Then I convert it into POSIX date time with gmtime_r().

I'm using a nFR52833 devkit, with Zephyr toolchain nRF Connect SDK V1.9.1

[hmolesworth]

Outside of Zephyr, I use repeated sampling to ensure no rollover issues; one would expect Zephyr does something similar, but perhaps not.

// 64-bit unsigned RTC time: typically number of 125 millisecond ticks from Jan 1st 2024
static volatile uint64_t mRTCTimer;

uint64_t getRTCTime(void)
{
    // Ensure no rollover issues as we cannot be sure this instruction is atomic
    uint64_t timeLatch;
    do {
        timeLatch = mRTCTimer;
    } while (timeLatch != mRTCTimer);
    return timeLatch;
}

[Susheel Nuguru]

I think writing RTC here is a bit confusing because RTC is an actual hardware peripheral on our SoC. But I see that you do not mean hardware RTC but in general getting a real time clock in the operating system perspective. These two are different things. 

Assuming that you are talking about the clock in the OS. Here are my 2 cents

I think when you are setting time in other time units than ticks, then there is some loss of time accuracy due to conversion of you time into ticks or vice versa. Try to dive into your time handling API if they are using any macros to convert from one unit to the other and if there is any division involved then there is most likely some loss of accuracy there. I have not heard of such an issue about setting a time in the application and reading it immediately to get less accurate value but I am guessing this is a different issue than the accuracy issue in time that is caused from the efficiency of LFCLK being used.