Access to the 32 kHz clock on nRF54L15

Question

Hello! 
 I want to make a self-test that verifies the speeds of the 32.768 kHz clock and the 32 MHz clock. 
 The idea is that if the ratio (976.56 to 1) is correct, then the speeds are probably correct. 
 However, all timers from TIMER00 to TIMER24 seem to be based on the 32 MHz clock. 
 The watchdog uses the LF clock but the driver returns -ENOTSUP unless using WDT_FLAGS_RESET_SOC, so apparently it can only reset the system and not call a custom callback. 
 The GRTC uses the LF clock in low power mode when the HF clock is not available, but I want both running at the same time. 
 Is there any other way to expose both the HF and LF clocks simultaneously as counters or timers? 
 It seems the GRTC can expose them on GPIOs, but for simplicity I want to do this purely in software. 
 Regards, Tom

Emil Lenngren · Answer

You can use the GRTC for this as it is always synchronised to the low frequency clock, regardless if it is "active" or not. Even though it uses the 16 MHz clock when it is active, it calibrates itself towards the low frequency clock at every low frequency clock tick (or often enough at least). That said, every 1 &micro;s GRTC "tick" can typically last 14-18 ticks of the 16 MHz clock. The extreme conditions happen when you run the HF clock from HFINT in extreme temperatures and the MPSL isn't running (when MPSL is running it synchronises the HFINT against HFXO every 4th second). 
 Note that the GRTC uses the LF clock whenever it is not active, regardless if the 16 MHz clock is running or not. The conditions for being in the active state are listed in the GRTC documentation. Typically it gets briefly set to active if you touch its registers, or when a scheduled COMPARE event is about to be triggered soon. 
 My suggestion is that you use DPPI to connect a COMPARE event of GRTC to trigger a CAPTURE task of a TIMER some time in the future. Then connect another such trigger exactly 1 second later in the future (according to GRTC's time base). Then take the difference between the TIMER's two CC values. It is probably only meaningful to do this while the HFXO is running.