GRTC resets after sys_poweroff when using MCUboot (ncs 3.1.0)

[ddiassword]

Hello Nordic team,

We are using the GRTC on the nRF54L15, and we are observing the following behavior:

• When MCUboot is enabled, the GRTC (likely backed by SYSCOUNTER) is reset after waking up from sys_poweroff().

• When MCUboot is not used, the GRTC behaves as expected and is not reset after wake-up.

We have already found a related DevZone ticket that appears to describe the same root cause:

GRTC resets after sys_reboot() when using MCUboot (NCS v3.1.0)

The workaround proposed there involves changes to MCUboot.
However, in our case, the devices are already deployed in the field and do not support OTA updates for MCUboot, so modifying the bootloader is not an option.

Is there any alternative way to prevent the GRTC reset (or restore its state) without modifying MCUboot?
For example, a configuration option, application-level workaround, or recommended handling in Zephyr/NCS for this scenario.

Thank you in advance for your support.

[Vidar Berg]

Hello,

Unfortunately, I do not see any way to work around this in your case since the bootloader is immutable and not updatable. The bootloader will clear the counter register before the main app is allowed to run.

Best regards,

Vidar

[ddiassword]

Hello Vidar,

Thank you for the clarification.

Given this constraint, our team has been exploring a possible workaround and we would like your feedback on whether this approach is technically sound or if there are any pitfalls we are missing.

Our board includes an nPM1300 PMIC, which provides timer functionality and wake-up sources. The idea would be to avoid relying on GRTC altogether and instead use the PMIC as a coarse RTC while the SoC is fully powered down.

Proposed approach:

• Before entering low power, the application stores the current timestamp in non-volatile memory.

• Instead of calling sys_poweroff(), we configure the nPM1300 to:

  • Enter hibernate mode (or something similar, we haven't fully investigated yet)

  • Wake the SoC periodically using its internal timer (e.g. every X seconds)

• On each wake-up, the application adds X seconds to the stored timestamp.

  • We accept that there will be drift and limited resolution.

• Additionally, we would configure the PMIC to wake the SoC not only on the timer, but also on charger detection.

One open point we would like your input on:

• If the device wakes due to a charger interrupt (rather than the periodic timer),

  • Is it feasible to read the PMIC timer registers to determine how much time has elapsed since entering hibernate?

  • In other words, can the PMIC timer state be used as a reliable indication of elapsed time across hibernate until a wake event occurs?

Does this approach seem viable from your perspective?
Are there any limitations with the nPM1300 timer, wake sources, or register retention that would prevent this from working as described?

Any guidance or confirmation would be greatly appreciated.

Best regards

[Vidar Berg]

Hello 

I have forwarded these questions to our PMIC team to see if they foresee any problems with this approach but their response may be a bit delayed due to the holidays.

Best regards,

Vidar

[Vidar Berg]

Update:

Unfortunately, as discussed in this thread: https://devzone.nordicsemi.com/f/nordic-q-a/115521/possibility-to-read-the-current-timer-value, the npm1300 does not expose a counter register for the host to read the current counter value from the TIMER. Because of this it will not be possible to keep track of time when wakeup is triggered by the VBUS.