Task and event jitter/delay

Jitter or delay in the RTC, is due to the peripheral clock being a low frequency clock (LFCLK), which is not synchronous to the faster PCLK16M.

Registers in the peripheral interface that are part of the PCLK16M domain, have a set of mirrored registers in the LFCLK domain. For example, the COUNTER value accessible from the CPU is in the PCLK16M domain, and is latched on a read from an internal COUNTER register in the LFCLK domain. The COUNTER register is modified each time the RTC ticks. The registers are synchronised between the two clock domains (PCLK16M and LFCLK).

CLEAR and STOP (and TRIGOVRFLW, which is not shown) will be delayed as long as it takes for the peripheral to clock a falling edge and a rising edge of the LFCLK. This is between 15.2585 μs and 45.7755 μs – rounded to 15 μs and 46 μs for the remainder of the section.

When a STOP task is triggered, the PCLK16M domain will immediately prevent the generation of any EVENTS from the RTC. However, as seen in the following figure, the COUNTER value can still increment one final time.

The START task will start the RTC. Assuming that the LFCLK was previously running and stable, the first increment of COUNTER (and instance of TICK event) will be typically after 30.5 μs ±15 μs. Additional delay will occur if the RTC is started before the LFCLK is running, see CLOCK — Clock control for LFLK startup times. The software should therefore wait for the first TICK if it has to make sure that the RTC is running. Sending a TRIGOVRFLW task sets the COUNTER to a value close to overflow. However, since the update of COUNTER relies on a stable LFCLK, sending this task while LFCLK is not running will also add additional delay as previously described. The figures show the smallest and largest delays on the START task, appearing as a ±15 μs jitter on the first COUNTER increment.

The following tables summarize jitter introduced for tasks and events. Any 32.768 kHz clock jitter will come in addition to these numbers.