gettimeofday returns incorrect timestamp after ~7 days

RE: gettimeofday returns incorrect timestamp after ~7 days

esscriber — Fri, 28 Jan 2022 11:17:15 GMT

The problem that I was running into was caused by k_ticks_to_ns_floor64, but the overflow in z_imp_clock_gettime that you pointed out would have been an issue at an later stage.

After searching through code on Zephyr's github, I found that this issue was reported on github (https://github.com/zephyrproject-rtos/zephyr/issues/41111). A solution was pushed to github on the day that I created this Q&A (https://github.com/zephyrproject-rtos/zephyr/pull/41602).

The overflow that you pointed out has also been fixed (https://github.com/zephyrproject-rtos/zephyr/pull/41814).

RE: gettimeofday returns incorrect timestamp after ~7 days

Einarh — Fri, 21 Jan 2022 15:07:17 GMT

Right, most Zephyr applications don't keep track of real time, only the local system ticks, and these posix libraries are there mostly to make it easier porting linux applications as far as I've understood, which is probably why this isn't a more wide spread issue.

I do agree it seems like it is this part of the gettime code that is causing the unfortunate quick overflow:

elapsed_nsecs = k_ticks_to_ns_floor64(k_uptime_ticks());
ts->tv_sec = (int32_t) (elapsed_nsecs / NSEC_PER_SEC);

But I believe it might be the part where nsecs is divided by a billion and typecasted from uint64 to int32, and possibly not the k_ticks_to_ns_floor64 function itself.

You might want to look into whether it could suit your application to use one of Zephyr's APIs, for example Counter which can give you an interrupt when it overflows.

You could also report this as an issue on Zephyr's github if you believe it is not the intended behavior.

Best regards,

Einar

RE: gettimeofday returns incorrect timestamp after ~7 days

esscriber — Thu, 20 Jan 2022 09:32:16 GMT

It is indeed the k_ticks_to_ns_floor64 function that overflows every ~6.51 days. Looking at the code in zephyr/lib/posix/clock.c, the only way to counteract the overflow is to resync with the NTP server after a rollover, with the possibility of having gaps where the time is in the past. Syncing before the rollover will have little to no effect.

This will happen to every board where Z_HZ_ticks=32768. So I would assume that this would be a more wide spread issue, but I couldn't find anything related to this.

RE: gettimeofday returns incorrect timestamp after ~7 days

Einarh — Tue, 18 Jan 2022 15:54:25 GMT

You might be right, it could just be the k_ticks_to_ns_floor64 function overflowing.

One way to interface with the RTC is through Zephyr's Counter API:

http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/reference/peripherals/counter.html#counter-api

-Einar

RE: gettimeofday returns incorrect timestamp after ~7 days

esscriber — Tue, 18 Jan 2022 15:42:52 GMT

Hi Einarh,

I don't know what the prescaler setting is. Do you know where I can find it in the sdk?
If it is the RTC that overflows, shouldn't the uptime also be affected (decrease)?

Best regards,

esscriber

RE: gettimeofday returns incorrect timestamp after ~7 days

Einarh — Tue, 18 Jan 2022 15:37:19 GMT

Hello!

Sounds like this could be the RTC overflowing, which happens regularly at an interval determined by the RTC prescaler:

https://infocenter.nordicsemi.com/topic/ps_nrf9160/rtc.html

Do you know what the prescaler is set to in your application? Does it match the interval you've observed?

Best regards,

Einar

RE: gettimeofday returns incorrect timestamp after ~7 days

esscriber — Tue, 18 Jan 2022 15:37:08 GMT

I have been looking into the differences between the gettimeofday and k_uptime_get_32 and I have found the following call sequences:

gettimeofday() => clock_gettime () => k_ticks_to_ns_floor64(k_uptime_ticks())

k_uptime_get_32 () => (uint32_t)k_uptime_get() => k_ticks_to_ms_floor64(k_uptime_ticks())

So it could be an overflow in the k_ticks_to_ns_floor64 call (from clock_gettime)?