k_uptime_get() drift way too much using LFXO.

RE: k_uptime_get() drift way too much using LFXO.

Anthony Yuan — Sat, 11 Jan 2025 03:07:31 GMT

Hi Håkon,

Thanks for the update.

1. I use clock_skew to test RC32k Skew and it < 50 ppm

2. I put sometime read the zephyr kernel code and figure it out what cause my issue:

My project in NCS 2.3.0, no time drift

//generated autoconf.h
#define CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC 32768
#define CONFIG_SYS_CLOCK_TICKS_PER_SEC 32768

My project in NCS 2.5.2, have time drift

//generated autoconf.h
#define CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC 32768
#define CONFIG_SYS_CLOCK_TICKS_PER_SEC 1000

cycles per tick = CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC / CONFIG_SYS_CLOCK_TICKS_PER_SEC = 32768 / 1000 = 32.768 cycles

Since the hardware cannot generate fractional cycles, this value is typically rounded up or down to the nearest integer, such as 32 cycles or 33 cycles. And Tick period of kernel is 1 ms.

There may be cumulative timing errors due to rounding, as 32.768 is not an exact match for the hardware clock cycles.

After change the CONFIG_SYS_CLOCK_TICKS_PER_SEC to 1024, Tick period change to 0.97656ms and cycles per tick is 32 and there is no need to rounding, and that eliminate the time drift.

Regards,

Anthony Yuan

RE: k_uptime_get() drift way too much using LFXO.

Håkon Alseth — Fri, 10 Jan 2025 15:26:16 GMT

Hi,

You are changing the prescaler for the NRF_RTC instance that is used by the kernel for timekeeping by changing that specific kconfig.

Could you try to run the sample in zephyr/samples/boards/nordic/clock_skew ?

Then add the 32k RC config:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

And add this to the startup sequence to use HFXO:

https://github.com/nrfconnect/sdk-nrf/blob/v2.8.0/samples/cellular/at_client/src/main.c#L18-L23

My output running on RC32k:

Ty  Latest           Base             Span             Err
HF  00:03:40.572049  00:00:00.017209  00:03:40.554840
LF  00:03:40.577789  00:00:00.033599  00:03:40.544189 -00:00:00.010651
RHF 00:03:40.572019                                   -00:00:00.000030
Skew 1.000048 ; err -48279 ppb

Ty  Latest           Base             Span             Err
HF  00:03:50.597951  00:00:00.017209  00:03:50.580741
LF  00:03:50.603271  00:00:00.033599  00:03:50.569671 -00:00:00.011070
RHF 00:03:50.597928                                   -00:00:00.000022
Skew 1.000048 ; err -48041 ppb

Ty  Latest           Base             Span             Err
HF  00:04:00.623685  00:00:00.017209  00:04:00.606475
LF  00:04:00.628753  00:00:00.033599  00:04:00.595153 -00:00:00.011322
RHF 00:04:00.623685                                    00:00:00.000000
Skew 1.000047 ; err -47087 ppb

< 50 ppm drift.

Changing to LFXO gives <2 ppm initial drift:

Ty  Latest           Base             Span             Err
HF  00:00:10.026283  00:00:00.017210  00:00:10.009073
LF  00:00:10.523406  00:00:00.514312  00:00:10.009094  00:00:00.000021
RHF 00:00:10.026273                                   -00:00:00.000009
Skew 0.999998 ; err 2086 ppb

Kind regards,

Håkon

RE: k_uptime_get() drift way too much using LFXO.

Anthony Yuan — Fri, 10 Jan 2025 02:11:10 GMT

Hi Håkon,

Just tested with CONFIG_SYS_CLOCK_TICKS_PER_SEC=1024 in .conf file

And now the k_uptime_get() matching with RTT log and matching with my stop watch.

I am not quite familiar with zephyr/kernel, I have 2 questions about CONFIG_SYS_CLOCK_TICKS_PER_SEC:

1. I can't find out why NCS 2.3.0 and NCS 2.5.2 use the same CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000 but have different result.

2. I change CONFIG_SYS_CLOCK_TICKS_PER_SEC=2048 and the k_uptime_get() works properly too, as my understanding that it will make zephyr kernel more accurate if I set CONFIG_SYS_CLOCK_TICKS_PER_SEC=32768, but is there any side effects?

Regards,

Anthony Yuan

RE: k_uptime_get() drift way too much using LFXO.

Anthony Yuan — Thu, 09 Jan 2025 14:59:24 GMT

Thanks for your reply Håkon,

I will try your suggestion tomorrow.

And I realize that there is a pattern in the data:

I use the RTT timestamp as "total" and you can see the "delta/total" is linear relative and close to 0.024

`total`	`delta`	`delta/total`

9706

233

0.02400577

17055

409

0.02398124

20708

497

0.02400039

23586

566

0.02399729

25461

611

0.02399749

27160

652

0.02400589

30735

738

0.02401171

0.024 == (1024 -1000)/1000

Maybe I should change

CONFIG_SYS_CLOCK_TICKS_PER_SEC=1000

CONFIG_SYS_CLOCK_TICKS_PER_SEC=1024

RE: k_uptime_get() drift way too much using LFXO.

Håkon Alseth — Thu, 09 Jan 2025 14:51:52 GMT

Hi,

Now you are introducing uncertainty in the RTT process itself, so this is not a very reliable way of checking the accuracy.

What I would recommend is to check the timestamp against a known stable high speed timer on the nRF itself, as this is sourced from the HFCLK.

What is important then is to first start the HFXO, either via clock_control API, or by just running this:

NRF_CLOCK->TASKS_HFCLKSTART=1;
while(NRF_CLOCK->EVENTS_HFCLKSTARTED == 0);
NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;

Kind regards,

Håkon