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]

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.