RTC1 behavior in low power mode

[psavoy]

I intend to keep a long running clock in the system and use the app_timers(hence RTC1) in a soft device enabled nrf51822 firmware. I basically have a minute tick and update local time every minute, However, I've observed that once I call the sd_power_mode_set(NRF_POWER_MODE_LOWPWR), I see the RTC not being updated regularly and begin to see a drift in the local clock because of this. The code would then mainly be at WFE() - is this correct ? Is this a possibility, what is the accuracy of RTC1 when in low power mode? I am using a 32Khz NRF_CLOCK_LFCLKSRC_XTAL_20_PPM and internal RTC1 via app_timer approach to keep track of time.

[psavoy]

Thanks Stefan, Yes, the logic doesn't necessarily uses a app_timer, the ticks are extracted out of RTC1 counter and added to my local time. So, even if the app_timer interrupts are delayed the RTC1 counter should reflect that shouldn't they ? i.e. my logic is not say add "60" seconds to my local time every minute started with app_timer called minute_timer, However, whenever requested (by BLE application), convert_to_seconds(RTC1 counter) + "previously set time from phone". This RTC1 counter can go wrong only on reboot, or roll-over, with my logic making sure I don't roll over.

So, there is a high chance that no timers, BLE events, system events are called in my system for huge time (with prescaler set to 0xFFF, roll over happens after 590~ hours). Could this be a concern ?

Unlikely with the crystal accuracy - it is said to be 20ppm.

[psavoy]

Update: 3/12/2015

Stefan, Can you explain this a bit more ? We (I and manjunatha) do that configuration where we have reduced RTC_COMPARE_OFFSET_MIN to 1 since our prescaler was the largest that we could set (0xFFF), would this actually cause the drift ? Can this happen in System ON mode when CPU is not sleeping as well ?

Also, the large prescaler we set was due to the power considerations, setting RTC_COMPARE_OFFSET_MIN to default value and reducing the prescaler to 0x1FFF (15.625) would then affect my power numbers wouldn't they ?

[Stefan Birnir Sverrisson]

I do not realize what tick frequency you actually need, but you should keep the RTC_COMPARE_OFFSET_MIN to 3 in order to ensure normal operation, regardless if you are in low power mode or constant latency mode. Did you try already to set RTC_COMPARE_OFFSET_MIN as 3? Does the problem persist? As I understand your problem, you are missing some RTC interrupts and that is what is expected if you have RTC_COMPARE_OFFSET_MIN as 1.

Changing the prescaler should not have any effect on the power consumption of the device. The RTC consumes ~0.1uA regardless of prescaler settings. It is the actual interrupt frequency that will effect the power consumption as higher interrupt frequency would require higher CPU activity.

[psavoy]

At RTC_COMPARE_OFFSET_MIN = 3, our APP_TIMER_PRESCALER set to 0xFFF, A "tick_timer" is started with 125ms as timeout. In this situation our ticks are delayed and hence the unit is not-operational from a functional perspective (this is solely our product requirement issue...)

Issue: We set RTC_COMPARE_OFFSET_MIN = 1, APP_TIMER_PRESCALER=0XFFF and the tick_timer at 125ms timeout, then we never see any ticks that happen at 125ms getting skipped, However, on entering a product defined low power mode, I perform a sd_power_mode_set(NRF_POWER_MODE_LOWPWR), turn off several other components and wait at sd_app_event_wait() - long hours of wait in this certainly causes the drift.

drift definition: when a current time is requested, we add a phone's set time to rtc1_counter_get() to get the time, this time is different from time on phone. phone sets the time once say on boot.