Best way to implement system clock on nRF51

[Alessandro]

Hi everybody,

a while ago I used the approach proposed here devzone.nordicsemi.com/.../ to keep the date and time on a NRF51822 device while using Softdevice S110 and the Timeslot advertiser-scanner (github.com/.../nRF51-multi-role-conn-observer-advertiser).

In practice I created an app_timer timer that executes every 250 milliseconds (this is the resolution I wanted) and inside the handler I incremented some variables accordingly to keep date and time. The problem is that I noticed that the time was not accurate, it was wrong, sometimes of several seconds, already after 1 hour. Here is the first question: I think that the time was wrong mainly because the app_timer handler gets delayed by the BLE stack, am I correct?

My idea to improve this is to connect an RTC1 COMPARE event to the TIMER1 COUNT task through PPI. The RTC1 will be configured to fire the event every second. This way I could keep the time in TIMER1 as a Unix timestamp (seconds since 1970-01-01) and I could read the number of milliseconds from RTC1 (I will use the number of ticks together with the prescaler to compute the milliseconds). This way there is no software handler involved and therefore it could not get delayed, is it correct? Is this going to be more precise than the solution using the app_timer? Will this solution consume more power? Do I need to keep on the 16MHz clock?

The implication of this solution is that I cannot use the app_timer library anymore or I could modify it to connect the RTC COMPARE event with the TIMER COUNT task and this should not interfere with the normal operation of the library, right?

I could try to implement the solution but since I am not sure it will work I would like some feedback from you.

Thanks a lot. Alessandro

[Alessandro]

This is similar to what Aryan suggested but the handler could still be delayed, even if in this case it is very short, something like "overflows++;".

[Martijn]

actually, looking at that image. I see the prescaler (and with that the PCLK) getting disconnected when COUNTER mode is selected. This image shows the TIMER mode enabled (switch pointing down). I don't see how the COUNT task needs the HFCLK to run, according to this image they never can be connected.

quote from the reference manual: "In counter mode, the TIMER's internal Counter register is incremented by one each time the COUNT task is triggered, that is, the timer frequency and the prescaler are not utilized in counter mode. Similarly, the COUNT task has no effect in Timer mode."

[Susheel Nuguru]

Martijn, I was wrong, so i have converted my previous answer to comment and giving you the proper answer.

The information given in the document is not adequate, the designer of the TIMER gave me proper information. In COUNTER mode of the TIMER, the HFCLK is not requested unless there is a COUNT task. When COUNT task is triggered, the TIMER peripheral will request the hfclk to get one clock cycle so that it will be able to do the COUNTER increment logic. And after that it stops requesting the HFCLK. This means that if nothing else is using HFCLK, and when COUNT task is triggered then HFCLK is requested and is turned on for 62ns (1 cycle) and then requested to turn off again.

Alessandro, your proposed way of using RTC1 and routing it to TIMER COUNT task through PPI will give you the highest precision possible in any software mode and with no power increase. Sorry for confusing you guys initially and thank you for making me dig into it.

[Martijn]

Ah, thanks for sorting this out. Can we expect updated documentation about this?

[Susheel Nuguru]

I will create internal ticket to update this document. I am not sure when it will be done, but wont be ignored too long.