GRTC Periodic interval + nrfx

[sasodoma]

Hi,

I recently found out about the Periodic interval feature on GRTC CC[0] and it seems like it would be quite useful for my application. Most of my code so far uses the nrfx drivers. Looking at the nrfx: GRTC driver page it seems that there are no functions available for that feature, but I do see some in the HAL section. What would be the best way to use the CC[0] channel in my code? Also how can I make sure that the channel is free to use and do I need to somehow reserve it so it doesn't accidentally get used elsewhere?

Regarding my application, I would use the INTERVAL register to auto increment the CC[0] register, but also sometimes increment it manually using CCADD. Is there also a safe way to decrement it while ensuring that I don't get an auto increment in between my read, subtract and write?

Best regards,
Sašo Domadenik

[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?

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

[Priyanka]

sasodoma said:

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?

This looks right to me.

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

Regards,

Priyanka

[Mark Rages]

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.

[sasodoma]

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.

[Priyanka]

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

[Emil Lenngren]

sasodoma said:

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?

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.