Microseconds since start

RE: Microseconds since start

Nick Ewalt — Thu, 24 Apr 2025 18:22:21 GMT

CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC should be 1000000, so rather than calling nrfx_grtc_syscounter_get you can just call k_cycle_get_64.

RE: Microseconds since start

Tony — Mon, 07 Apr 2025 15:59:34 GMT

Thank you for the suggestions. I will try them out.

RE: Microseconds since start

Emil Lenngren — Mon, 07 Apr 2025 15:56:58 GMT

I guess you can just try it out? Otherwise you can probably use the nrfx_grtc_syscounter_get method also which returns microseconds.

CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC is the parameter that controls the actual hardware clock frequency.

RE: Microseconds since start

Tony — Mon, 07 Apr 2025 15:25:21 GMT

So I can just change the clock ticks per second and it will work? For some reason I thought that define value would be specific to the crystal and clock, board and processor and not something I could just change. I thought it would have to match....

RE: Microseconds since start

Emil Lenngren — Mon, 07 Apr 2025 15:18:31 GMT

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.

RE: Microseconds since start

Tony — Mon, 07 Apr 2025 15:06:12 GMT

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.

RE: Microseconds since start

Emil Lenngren — Mon, 07 Apr 2025 11:09:48 GMT

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.

RE: Microseconds since start

Susheel Nuguru — Mon, 07 Apr 2025 10:51:36 GMT

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.

RE: Microseconds since start

Turbo J — Sat, 05 Apr 2025 15:53:54 GMT

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).