Reset-surviving system clock on nrf54

[McRancor]

Hi!

I'm writing new firmware for the nrf54 family, and I want to have a system timer with 1s resolution (clock). This clock will be occasionally synchronized with epoch, so it will provide the date source. 

I would like to ensure that this clock is not erased during reset.

I had this functionality working on nrf52, using RTC and generating an event every second. The event increased an system variable which was kept in uninitialized memory region. This ensured that after reset the clock can continue.

Since the rtc was powered by LFCLK it was trivial to get super low power consumption.

How to achieve something similar on nrf54? Is there any other option than using GRTC and SYSCOUNTER?

[Emil Lenngren]

Yes you can use GRTC. It consists of an "internal" low power clock using the 32 kHz LFXO source but will be woken up to high accuracy mode (16 MHz) when necessary. A wake up from system off will reset the system (and reset all visible registers of GRTC) but keep the internal low power clock running and maintain its counter, so if you then enable the SYSCOUNTER you can then read the current time. If instead keeping the system on but issuing a (soft) system reset, it appears also the rest of the GRTC retains the registers, like the CC values and the last known SYSCOUNTER.

[McRancor]

Is the GRTC used by zephyr for delayed queues etc? I don't see any difference in power consumption once started using GRTC, so I assume it was already running. Currently seeing power consumption on the levels of 10uA, with advertising every 10s (max time), uart disabled. Is this expected on 54L15DK?

[Hieu]

Whether GRTC or RTC is used for System clock is controlled by CONFIG_NRF_GRTC_TIMER and CONFIG_NRF_RTC_TIMER.

By default, GRTC is used. Therefore, it is indeed used under the hood for delayed queue.

If you are sure that all threads have gone idle then 10uA System ON Idle is a little high.
I recommend using Hello World sample and just let main returns as a baseline.

But diving into current consumption analysis might sidetrack the topic of GRTC here, so unless you think this is related to the GRTC configuration somehow, I would like to recommend diving into it in a different dedicated case.

[McRancor]

I tested the system_off example, without retention (the basic case) and I'm getting current consumption at the level of almost 4uA. This is the current chart:

I see it has GRTC enabled, and I suspect this is it.

The power consumption is actually part of the topic because I'm a bit concerned that the GRTC running is consuming more current than the whole nrf52 project with advertising running. And I'm aiming for the lowest consumption possible.

Is there a way to run zephyr, with BLE advertising, without GRTC enabled?

[Hieu]

What you were seeing when you have BLE activity is most likely the device in System ON Idle between the radio events. The expected current of System ON Idle with full RAM retention is 3uA. In this state, as you are running a RTOS, you need the RTOS system clock, and thus either GRTC or RTC has to be on. GRTC is good for this purpose.

The System OFF sample demonstrate the System OFF state. That is a deeper state of sleep. 4uA is quite high for this. If you want to explore this mode further, make sure you have turned off all peripherals, and turn off RAM retention. Also, your application restart when it wakes up from this state.

McRancor said:

Is there a way to run zephyr, with BLE advertising, without GRTC enabled?

In most common use cases of BLE advertising, you will be in System ON Idle, so you will have GRTC (or RTC, which isn't superior power-consumption wise).

You can theoretically put the device in System OFF, but that is pretty niche. A common pattern to connectable devices is to have the device advertise for a while, and if no connection happened, put the device into System OFF sleep.