GRTC Periodic interval + nrfx

RE: GRTC Periodic interval + nrfx

sasodoma — Mon, 06 Oct 2025 20:31:27 GMT

Thanks for the detailed explanation. In retrospect, it makes sense for the GRTC to be synchronized to the LFCLK since that is the one which is always running, the HFCLK isn't even synchronized to itself since it is stopped and started. Since asking this question I have kind of figured this out myself, though I was never quite sure if that's how it actually works so this was helpful.

RE: GRTC Periodic interval + nrfx

Mark Rages — Mon, 06 Oct 2025 19:44:25 GMT

Priyanka do you have any information about the use of CC[0] by the Bluetooth stack?

RE: GRTC Periodic interval + nrfx

Emil Lenngren — Mon, 06 Oct 2025 09:13:15 GMT

[quote userid="144819" url="~/f/nordic-q-a/122953/grtc-periodic-interval-nrfx/542624"]I noticed that the SYSCOUNTER will drift with respect to a timer that runs from the HFCLK. Is there any way I can prevent this drift?[/quote]

This is correct. The GRTC is synchronised towards the low frequency clock. When not active, the time is based solely on the low frequency clock. When active, it will use the HFCLK to be able to generate one tick approximately every microsecond, but the GRTC is in that case calibrated towards the low frequency clock at every low frequency clock tick. In practice, since the HFCLK is 16 MHz but the GRTC generates ticks with a 1 MHz resolution, the GRTC will in practice generate one tick with an interval between 14 and 18 HFCLK ticks, depending on the low frequency clock. This is to stay synchronised with the low frequency clock.

That said, if you have HFXO started and let the GRTC be in active mode for a long time, the timing from GRTC will still follow the low frequency clock and not HFXO.

RE: GRTC Periodic interval + nrfx

Priyanka — Mon, 06 Oct 2025 08:52:27 GMT

We suppose this is because GRTC internally runs off the LFCLK, preferably LFXO, which allows it to keep precise timing even through systemoff. When CPU is active, this LFCLK time is synched to the HFCLK to allow events/interrupt on 1 us granularity. So the drift seen is probably the LFXO vs HFXO.

-Priyanka

RE: GRTC Periodic interval + nrfx

sasodoma — Fri, 03 Oct 2025 15:10:46 GMT

I am also interested if there was any clarification of the behaviour, but for what it's worth, I have since implemented the periodic interrupt in another channel, using the grtc_handler to perform the modification of the CC value right after the compare match.

RE: GRTC Periodic interval + nrfx

Mark Rages — Thu, 02 Oct 2025 15:10:50 GMT

Did you ever get an answer for this? I am also interested in using a periodic interrupt from LFCLK and CC[0] seems to be the only way to accomplish it.

RE: GRTC Periodic interval + nrfx

Priyanka — Thu, 17 Jul 2025 08:02:01 GMT

[quote user="sasodoma"]After further testing it seems to me that the GRTC CC[0] is used by the BLE drivers and I can't use it for my application if I also want BLE. Is this correct?[/quote]

This looks right to me.

I will nevertheless check all your queries internally with the team and get back to you.

Regards,

Priyanka

RE: GRTC Periodic interval + nrfx

sasodoma — Wed, 16 Jul 2025 10:09:51 GMT

After further testing it seems to me that the GRTC CC[0] is used by the BLE drivers and I can't use it for my application if I also want BLE. Is this correct?

Additionally I would like to know, how I can ensure that the GRTC SYSCOUNTER always runs from the 16 MHz clock. The product specification states "It uses the 16 MHz clock when the high-speed clock is active". In my application I have the HFXO always enabled because I need precise timing. I noticed that the SYSCOUNTER will drift with respect to a timer that runs from the HFCLK. Is there any way I can prevent this drift?

Best regards,
Sašo Domadenik