Timer drifting in nRF52810 based custom board

Question

Hi, 
 We are currently developing an application that makes use of soft device(s112). We tried using timer(Timer 1) for a timed wake up and sleep but found that the actual timeout is different than the configured timeout. We tried using different frequencies and timeout values for timer but the results were the same. 
 Timer Drift Observations

Frequency 
 Configured Timeout 
 Actual Timeout

125 kHz 
 1 s 
 0.977 s

250 kHz 
 1 s 
 0.974 s

250 kHz 
 60 s 
 58.388 s

250 kHz 
 300 s 
 291.873

2 MHz 
 1 s 
 0.975 s

2 MHz 
 60 s 
 58.391 s

16 MHz 
 1 s 
 0.974 s

We are using "nRF SDK version 14.2". 
 Also we tried using the app timer instead of Timer module and the timings from app timer was correct (configured for 60s and it timed out after 60s perfectly). We didn't populate the external low frequency crystal. 
 We could use app timer for this application(need to do further testing) but would like to know about the cause of this issue so that this can be taken in to consideration while designing our future products. 
 Thanking you in advance Hari

AmbystomaLabs · Accepted Answer

I covered the main timer issues earlier. However, I will cover them again for you. 
 The main timer, runs off of whatever 32MHz source is currently running. The HF_EXT clock(ie, crystal based 32MHz) is never run for your app by default. The nRF will always run client code on HF_INT which is RC based. This is done to reduce power consumption. An RC oscillator has terrible accuracy (it is about +/- 20000ppm) so you have to actually request HF_EXT the crystal based oscillator (+/-10ppm depending on your crystal choice) if you require it's accuracy. 
 The above is one huge source of problems with using timer that people fail to address. 
 The second thing most people do wrong is they try to clear and restart the timer in an ISR. You can't do this on any computer and expect it to work out. An ISR always has a random latency depending on what the cpu is doing and what was queued ahead of you by the NVIC. On the nRF it is doubly worse since the processor is off doing BLE half the time and will always be serviced ahead of your app. 
 For this reason if you use the main timer, you must use the shorts to clear and restart the timer if you expect any accuracy. 
 If you do everything correctly then the timer will operate at 10ppm (or whatever your crystal is) if you do it wrong as you did in your code, then the timer will have random latency on its operation and will not timer correctly. 
 As for power, running on the internal HF(32MHz) RC oscillator is 60uA, running on the HF EXT (ie, crystal 32MHz) is 250uA , running on the LF RC is 2.5uA (average due to cal cycle), and running on the RTC external crystal is 0.6uA.

AmbystomaLabs · Answer

You should make it a point to familiarize yourself with the product spec. Timer1 makes use of HF clock. Thus after coming out of power manage the device is running on HF int to save power. HF int has an accuracy of +/- many percent. You have to actually request HF ext to get its accuracy. 
 Regardless of the above, timer1 would be a terrible thing to use for 60second timing since it consumers so much power. You should be using the RTC timers. The RTC uses very little power and is very accurate. 
 app_timer uses the RTC thus that is why you see it to be more accurate. Since your board doesn't have an external RTC crystal it is actually using the internal RTC RC oscillator. The RC is calibrated periodically against the HF EXT based on the crystal info you passed to the SD when you initialized it. Using calibration the RC RTC is kept to +/- 250ppm.

Timer drifting in nRF52810 based custom board

Top Replies

core_v2_widget.Hide()