Drift between HFCLK TIMERs over time

Question

I have two TIMER instances, TIMER1 and TIMER2, both setup to Clear Mask on timeout (aka restart). I use TIMER1 and PPI to trigger ADC measurements every 5msec. In the ADC handler I add measurements to a queue of size 100. I used TIMER2 to trigger burst reading a sensor every 500msec. I added GPIO toggling once I reach 100 ADC samples (500msec) as well as on the TIMER2 handler. In theory 100 TIMER1 timeouts should align to a single TIMER2 timeout. However I see considerable drift between them over time. ~148msec after 528sec. If these timing windows get too out of synch I can no longer align my ADC data to my sensor data. This drift is ~280ppm which seems way out of spec of the timers. Also note this test was run without the Softdevice enabled to eliminate the Radio as a cause of jitter. I also request the hfclk at the start of the test to reduce any HFCLK start-up times. 
 Is it just CPU cycles that are causing this kind of drift? Is there a was I can buffer up to 100samples of ADC data in DMA (no CPU usage)? Otherwise I'm going to need to find an inventive way to periodically realign these timers. 
 
 Thanks for your help guys,

Edvin · Accepted Answer

Hello,

I see.

My assumption is that when you use the Timer + PPI to trigger events every 5ms, you probably reset the timer count on this event, is that correct?

The issue is that it takes a couple of ticks to actually do this. If you reset one timer every 5th ms, and the other timer every 500ms, then the 5ms timer is reset 100 times as often as the other. After a while this will lead to a large difference. I have not done the maths, but it sounds plausible that this is the cause.

From this page (sorry for old link, but it is difficult to link to the nRF52832 specification in the new DocLib libraries) :

On each PPI channel, the signals are synchronized to the 16 MHz clock, to avoid any internal violation of setup and hold timings. As a consequence, events that are synchronous to the 16 MHz clock will be delayed by one clock period, while other asynchronous events will be delayed by up to one 16 MHz clock period.

The question is how you set up the Clear mask. Do you fork it, or do you short it?

From the same page:

Note that shortcuts (as defined in the SHORTS register in each peripheral) are not affected by this 16 MHz synchronization, and are therefore not delayed.

So if you have shorted the clear mask:

TIMER1->SHORTS = TIMER_SHORTS_COMPARE0_CLEAR_Msk << TIMER_RELOAD_CC_NUM; // TIMER_RELOAD_CC_NUM is just the the CC register that you want to reset on. Typically the same as the CC you use for your 5ms delay.

this should not cause a delay.

However, if you FORK this to the TIMER1->EVENTS_COMPARE ppi channel, then it will be one clock period delay before it is cleared.

Best regards,

Edvin

Drift between HFCLK TIMERs over time

Top Replies