Restore date and time after reboot

[Roman Veselskyi]

Hello Nordic Support,

I have a question regarding the real-time clock (RTC) functionality on the nRF9160.

1. RTC availability

   • Does the nRF9160 have an internal real-time clock that can preserve time across reboots?

2. Behavior on reboot

   • We observe that after a device reboot (without loss of power or battery), the time is reset.

   • I can understand losing time when the device is fully powered off or the battery is disconnected, but why is this happening during a reboot?

3. Use case

   • Our firmware collects events and stores them in flash. Each event requires a timestamp.

   • Additionally, we generate JWT tokens, which also depend on accurate time.

   • In some scenarios, the device may reboot while in an area without network coverage. After the reboot, we need to continue collecting events with valid timestamps, but without network access we cannot re-sync the time.

Question:
Is there an option or recommended method to prevent the time from resetting during a reboot (e.g., preserving RTC state across soft resets), so that the device can continue operating without immediate network connectivity?

[Håkon Alseth]

Hi,

 

Does the nRF9160 have an internal real-time clock that can preserve time across reboots?

nRF devices has a real time counter, not real time clock, unfortunately.

I can understand losing time when the device is fully powered off or the battery is disconnected, but why is this happening during a reboot?

All peripherals are reset on reboot, except certain functions as listed here:

https://docs.nordicsemi.com/bundle/ps_nrf9160/page/pmureset.html#ariaid-title9

After the reboot, we need to continue collecting events with valid timestamps, but without network access we cannot re-sync the time.

The nRF91-device needs to fetch time from somewhere. LTE network, NTP, and/or GNSS are all options in this case.

You mention that you store entries with timestamps:

Our firmware collects events and stores them in flash

You can restore the timestamp, based on the last stored entry, to get a approximation relative to the last stored timestamp. When you update the timestamp, you can compare and store the diff. This is a hack, but can give you an anchor.

Example, use clock_settime() to restore after boot:

 Setting and Updating Absolute Time in Zephyr Application Using time_t Epoch 

 

Kind regards,

Håkon

[Roman Veselskyi]

HelloHåkon Alseth,

Thanks for the information.

[Paul012]

There is another way.  I have used a combination of the reset reason register and scratch space in RAM to store the current time at some frequency (say 30s) to be able to restore the time, with accuracy directly related to scratach space update frequency.

It requires the following:

• define/reserve a scratch space in RAM
• modify cinit() to not erase the scratch space upon reset
• at some frequency, save the current RTC value to the scratch space and calculate a CRC on it (CRC-8 or 16 should do)
• at boot time, after cinit(), during system init, check the reset reason and calculate the CRC on the scratch space
• if the reset reason was not power related and the CRC is good, then set the RTC to the stored value
• continue system init....

Note that reset reason is really optional.  If the power glitches so fast that the RAM isn't corrupted then you're probably OK.  But if the time values is very critical (safety related) then the reset reason is another check to ensure the value is good to go.