RTC0 IRQ/event on overflow?

[Gordon]

In my project I need to be able to get time from a continuously running RTC. The softdevice uses RTC0, and app_timer uses RTC1 (and starts and stops it).

(annoyingly I have to support nRF51 and nRF52 so I can't just use RTC2)

I've been using RTC0, but of course it rolls over every 512 seconds.

Presumably I can't set up an IRQ because the softdevice does that, but is there some event or callback that I can use to get notified when the RTC has rolled over? Or do I just have to make sure I always wake up after less than 512 seconds so I can check for overflows?

thanks!

[Susheel Nuguru]

You are right that the softdevice is using RTC0 and you are not allowed to use it in anyways unless you use TImeslot API. How are you using RTC0?

[Gordon]

ok, so what's the suggested solution for getting a usable RTC for getting the time on an nRF51? It seems like a common thing to want to do.

[butch]

I have the same need. I think this is a request for an enhancement to app_timer: even if the app does not have any timers running, app_timer should generate an event/callback when the RTC rolls over so that the app can keep a long-running (64-bit) clock. Lacking that enhancement, as Gordon says, the app needs to always have a timer running with timeout less than 512 seconds. The handler for that timer checks the counter of the RTC to determine whether it has rolled over, and makes appropriate "ticks" on the high order bits of the long running clock. The timer must be for less than 512 seconds else the RTC rolls over twice, missing a tick on MSB of the long running clock. Maybe the request is for a long running clock library that wraps or cooperates with app_timer library. Or the request is for a reference to example code for a long-running clock that uses app_timer.

[Gordon]

Yes - enhancing app_timer would be really good. I guess simply queuing a <512 second repeating task would probably be fine, but some kind of example of doing this would be really helpful (especially to give me a bit more reassurance that the RTC would never stop).

[butch]

Queueing a <512 second repeating timer is a simpler solution than I had in mind. The handler would tick the long-running clock MSB. But wouldn't you need to start it so that it expired exactly when the RTC rolls over? I don't understand why the RTC would stop (if the app_timer library is bulletproof)? But it would be nice to have an existing implementation of a long-running clock (using app_timer) that is provably correct. In my case I am not using SoftDevice, so I can use the RTC that app_timer is not using, at the expense of more current.