Timer Drift Clarification

[jpelo]

Working with nRF52832 and SD132-v2.0.1

Using external 32.768kHz xtal in addition to 32MHz xtal.

I realize there are a lot of posts about timers, but I didn't find any posts that answered my question(s).

I'm using a timer running at 1MHz to generate interrupt every 10ms (range from ms to minutes). Using short to clear the timer on CC match. I'm ok with interrupt latency to handle/process interrupt. I am seeing a drift between the RTC and the Timer (~1ms every ~11s).

Is is accurate to assume this drift can be attribute to (1) time to clear timer per manual "After the TIMER is started, the CLEAR task, COUNT task and the STOP task will guarantee to take effect within one clock cycle of the PCLK16M." (so worse case delay of 1/16M per int?) and (2) tolerances diffs between 32k and 32M xtals? The maths indicate this is possible but unsure if I'm missing something.

Am I correct that shorts don't require CPU so there isn't additional overhead for the clear? regardless of cpu sleep state?

I'm also curious if there is a way to calibrate the 32MhHz or the 16M peripheral clock against the 32k xtal?

[jpelo]

thank you for the followup. i'm using external xtals for both. one thing i did notice when checking this is i'm setting the accuracy to NRF_CLOCK_LF_XTAL_ACCURACY_50_PPM when i init/enable softdevice which could explain the additional drift -> need to source why this was set loose (since this tolerance covers a temp range for the xtal beyond what we need/expect). the information on how this is used to calculate the timing windows is very sparse (in terms of determining how this adds) - have you seen a good explanation of how this is used? in terms of the code snippet, its not easily postable -> sampling at 100hz and adding a timestamp from rtc to sample data on sample - i get in/out of int handler in plenty of time and i could expect some jiggle of the timestamp but in trends repeatable at ~1ms/11s.