Reset-surviving system clock on nrf54

RE: Reset-surviving system clock on nrf54

Hieu — Thu, 05 Dec 2024 22:53:54 GMT

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.

[quote user="McRancor"]Is there a way to run zephyr, with BLE advertising, without GRTC enabled?[/quote]

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.

RE: Reset-surviving system clock on nrf54

McRancor — Wed, 04 Dec 2024 20:21:39 GMT

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?

RE: Reset-surviving system clock on nrf54

Hieu — Wed, 04 Dec 2024 14:01:36 GMT

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.

RE: Reset-surviving system clock on nrf54

McRancor — Wed, 04 Dec 2024 13:45:24 GMT

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?

RE: Reset-surviving system clock on nrf54

Emil Lenngren — Tue, 03 Dec 2024 22:07:43 GMT

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.