Restore date and time after reboot

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?

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related