Microseconds since start

[Tony]

I am using the nRF54L15 and SDK 2.9.1 in VSCode.

I need to know the microseconds since start throughout my code.

I created this function:

inline unsigned long micros(void)
{
    double value = k_uptime_ticks();
    value /= ((double)CONFIG_SYS_CLOCK_TICKS_PER_SEC / (double)1000000);
    return (unsigned long)(value);
}

The problem is that CONFIG_SYS_CLOCK_TICKS_PER_SEC is defined as 31250. That means there are fewer ticks per second than a microsecond. I understand why this is, but how can I get microseconds on nRF54L15?

[Turbo J]

What do you need this time for?

You can keep the HFXO running and use a TIMER peripherial, but that would require significantly more power than usual (in idle).

[Susheel Nuguru]

The system timer uses RTC which is low precision timer by design for lower power.

If you want higher precision timer than like Fischer suggested, you need HFCLK based TIMER and you can then get a better accuracy on tick.

[Emil Lenngren]

I'm a bit surprised since the nRF54L platform only has GRTC, which is backed by a 32768 Hz clock, but that one cannot be queried directly as opposed to the RTC peripheral that is present in other nRF series. Instead, there is a 1 MHz clock waked up on demand, so the resolution is 1 tick per microsecond. If the high frequency clock that the GRTC uses when querying the current time is off, the solution implemented in nRF Connect is to trigger GRTC to start the high frequency clock, busy-loop the CPU up to 31 µs so that the high frequency clock can synchronise with the low frequency clock, and then return the current µs at that point.

[Tony]

 Emil Lenngren  Could you give more details about this please? Maybe a code example on how to implement it in my code? Power will be important, but I might be able to handle then while sleeping. While processing the RF signals I need good accuracy and it might be worth the power draw.

[Emil Lenngren]

What I wrote was regarding the hardware GRTC peripheral itself. And regarding the software, this is was the nRF Connect SDK already does when you query the current time, at least the last time I examined the code. It could be that the k_uptime_ticks() converts the 1 MHz resolution timestamp from the GRTC to that defined "ticks per sec" divider though.

This commit https://github.com/nrfconnect/sdk-zephyr-testing/commit/175855e0d8032400d5544d47971dc654e1717ec4 sets the CONFIG_SYS_CLOCK_TICKS_PER_SEC to the completely arbitrary value 31250 with the motivation that it divides 1 million. I guess it should be possible to set it simply to 1000000 instead if you want better resolution. Not sure if there is a valid range on this configuration variable.

If you want more details on the GRTC perihperal itself, you can see my findings here:  GRTC peripheral not always emitting scheduled events . You can also read the GRTC docs in the data sheet.