RE: Drift between HFCLK TIMERs over time

Dave_couling — Fri, 15 Mar 2019 17:34:36 GMT

Thanks for the info Edvin, this helps clear up this issue

RE: Drift between HFCLK TIMERs over time

Edvin — Fri, 15 Mar 2019 13:15:57 GMT

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

RE: Drift between HFCLK TIMERs over time

Dave_couling — Thu, 14 Mar 2019 16:46:05 GMT

I solved the issue by running everything off of the same TIMER instance. However I'm still concerned seeing drifts between TIMER instances