nRF52832 System ON Run modes of consumption

RE: nRF52832 System ON Run modes of consumption

jinvers — Tue, 13 Dec 2022 07:59:44 GMT

Ok. Thank you. I'll look for them.

Regards,

Joel

RE: nRF52832 System ON Run modes of consumption

Einar Thorsrud — Tue, 13 Dec 2022 07:57:32 GMT

In the nRF5 SDK there is no automatic disabling of peripherals like you have in the nRF Connect SDK, so you will have to manage that yourself. This is not complicated though, it basically involves stopping UART, SAADC, SPIM or any other peripherals you may be using when they are not needed, and then starting them again. Most of the drivers will have API functions for that. Exactly what they are called differs from different drivers, but you should see terms like "stop", "uninit" or "disable". See for instance this old post with regard to UART.

RE: nRF52832 System ON Run modes of consumption

jinvers — Tue, 13 Dec 2022 07:49:42 GMT

Thanks for your explanation.

So, please may you share some link where I could see the function calls to disable and reenable the peripherals when needed? I am using nRF5_SDK_17.1.0 ans SES IDE.

RE: nRF52832 System ON Run modes of consumption

Einar Thorsrud — Tue, 13 Dec 2022 07:44:13 GMT

Hi Joel,

The PMU block essentially just enables clocks and regulators when some peripherals need the HFCLK or some specific voltages. It does not switch between HFXO and HFINT (the internal high frequency RC), and it does not control the LFCLK (which is normally started at startup and runs continiously. Essentially you don't have to think about it, just remember that if you have any peripherals that need the HFCLK running, it will run.

This brings us to the next point about peripherals. These are not automatically controlled, so to achieve low power, you must disable peripherals that is not currently needed. (For a HW perspective at least, if using the nRF Connect SDK there is a power management system I mentioned in my initial reply which assists with this in som cases). But generally, it is up to your application to stop everything that is not needed. If for instance UART is active, the HF clock will be running, and the device will be consuming a significant amount of power even if the CPU is sleeping.

PS: Regarding system off mode, that is useful in some special cases, but in this case the LFCLK is also stopped and you only have a few selected wakeup sources. Also, wakeup is also in form of a reset. The "normal" sleep mode which is often the only sleep mode used, and in virtually all products the main sleep mode, is system ON sleep mode. Here you can have more wakeup sources and the LFCLK is typically running.

For a Bluetooth application where the SoftDevice keeps the LFCLK and RTC0 running in system ON mode, you can get a sleep current of a few micro amps (see Current consumption scenarios).

RE: nRF52832 System ON Run modes of consumption

jinvers — Tue, 13 Dec 2022 07:29:55 GMT

Ok Einar. I understand that all this control then is automaticaly made by the PMU block inside the nRF52832 and little things can be done except using SoftDevice as calling to sd_app_evt_main() for System ON Wait or sd_power_system_off().

Or is it any specific order or function call to disable and renable a peripheral in runtime?

Regards,

Joel

RE: nRF52832 System ON Run modes of consumption

Einar Thorsrud — Tue, 13 Dec 2022 06:34:56 GMT

[quote user="jinvers"]Excuse me if I have not explained well. The board has not an onboard 32.768KHz crystal.[/quote]

I understand, that is why I explained how to configure an LFRC. And the mentionning of no need to dynamically switch was as a comment to why this is done build time as you did not like that (I don't see any reason this should be runtime).

[quote user="jinvers"]The question, then, is how (in execution time) is it possible to disable the HFCLK to use the LFRC and just th other way round.[/quote]

As mentioned, the CPU always needs the HFCLK while running. When the CPU is sleeping (which is after a __WFE() or __WFI() instruction, typically after calling sd_app_evt_wait() when using a SoftDevice), and no other peripherals are requesting the HFCLK, this is disabled. The SoftDevice always keeps the LFCLK and RTC0 running for time keeping. RTC1 is also typically used by the app_timer library. You can see how this is done in any Bluetooth example in the SDK.

RE: nRF52832 System ON Run modes of consumption

jinvers — Mon, 12 Dec 2022 15:45:16 GMT

Hi Einar,

Excuse me if I have not explained well. The board has not an onboard 32.768KHz crystal. The question, then, is how (in execution time) is it possible to disable the HFCLK to use the LFRC and just th other way round.

Regards,

Joel

RE: nRF52832 System ON Run modes of consumption

Einar Thorsrud — Mon, 12 Dec 2022 15:18:46 GMT

[quote user="jinvers"]So definitely I cannot stop the main HFCLK using external 32MHz crystal. Is this correct?[/quote]

No. The CPU will always need a 64 kHz clock while running (meaning when not in sleep), but that can be generated from either HFINT (RC) or HFXO (the latter is needed when an accurate clock is needed, like when using the radio). Switching between the two oscillators is seemless. And when the clock is not needed (like when the CPU and other peripherals that runs of the HF clock is sleeping or disabled), the HFCLK (regardless of source) can be disabled.

[quote user="jinvers"]Using the sdk_config.h implies make the selection in the design phase and not in the execution phase.[/quote]

Yes. I cannot think of any real world use cases where you would want to ever use LFRC if your board has an onboard 32.768 kHz crystal.

RE: nRF52832 System ON Run modes of consumption

jinvers — Mon, 12 Dec 2022 14:58:02 GMT

Hi Einar,

[quote userid="7377" url="~/f/nordic-q-a/94784/nrf52832-system-on-run-modes-of-consumption/400189"]That is not supported on the nRF5 devices. On the nRF52 series the high frequency clock is always 64 MHz. However, this clock only runs when needed. The only clock that always runs is the 32.768 kHz clock. The paradigm used for power optimization in the nRF devices is "race to idle".[/quote]

So definitely I cannot stop the main HFCLK using external 32MHz crystal. Is this correct?

[quote userid="7377" url="~/f/nordic-q-a/94784/nrf52832-system-on-run-modes-of-consumption/400189"]You don't normally switch. If you have a 32.768 kHz crystal you always use that. If not, you use the RC. As you use the SoftDevice this is part of the SoftDevice configuration, and you adjust sdk_config.h as explained in this post.[/quote]

Using the sdk_config.h implies make the selection in the design phase and not in the execution phase.

[quote userid="7377" url="~/f/nordic-q-a/94784/nrf52832-system-on-run-modes-of-consumption/400189"]I think you misunderstood how this works. sd_app_evt_wait waits indefinitel[/quote]

I have understood it well. Considering your other answers, I see that the options are very limited.

Regards,

Joel

RE: nRF52832 System ON Run modes of consumption

Einar Thorsrud — Mon, 12 Dec 2022 14:42:05 GMT

[quote user="jinvers"]- Usually in other microcontrollers the total consumption may be reduced by dividing the clock that use the CPU and the peripherals, although the main crystal oscillator could be running. Are there no instructions for this, then?[/quote]

That is not supported on the nRF5 devices. On the nRF52 series the high frequency clock is always 64 MHz. However, this clock only runs when needed. The only clock that always runs is the 32.768 kHz clock. The paradigm used for power optimization in the nRF devices is "race to idle".

[quote user="jinvers"]- What are the function calls or instructions to switch between the internal 32.768KHz LFRC oscillator and the HFCLK?[/quote]

You don't normally switch. If you have a 32.768 kHz crystal you always use that. If not, you use the RC. As you use the SoftDevice this is part of the SoftDevice configuration, and you adjust sdk_config.h as explained in this post.

[quote user="jinvers"]I have seen this functions in other cases and I will be able to use it probably in a part of the code. But there will be other cases in the machine state of the application wher I cannot enter into a wait state. In these last cases (in fact, the more usual) where I would try to reduce the consumption by reducing the oscillator frequency or switching to tha LFRC oscillator.[/quote]

I think you misunderstood how this works. sd_app_evt_wait waits indefinitely, and most applications only include this in a single place, which is in your application main loop. The way this then works is that whenever the device wakes up on an interrupt, the main loop runs after the interrupts are processed, and then all other calls in the main loop is run once until calling sd_app_evt_wait(). This way the CPU sleeps when not in use instead of spending CPU cycles doing nothing. You can see this being used in virtually all SDK examples.

Also, the CPU can never run of the LFRC. Only a few selected low power peripherals use the LFRC, most notably the RTC, which is used to keep basic track of time for when to wake up. For instance, when in a BLE connection, the RTC is used to wake up the device before every advertising event, connection event, and so on.

RE: nRF52832 System ON Run modes of consumption

jinvers — Mon, 12 Dec 2022 14:27:16 GMT

Hi Einar,

Thank you for your answer.

I'm using the nRF52832 SoC over nRF5_SDK_17.1.0 and the SES IDE.

[quote user="eith"]No, that is not possible. However, the nRF will normally use the HFINT which is an high frequency RC oscillator when there is no need for a highly accurate clock.[/quote]

- Usually in other microcontrollers the total consumption may be reduced by dividing the clock that use the CPU and the peripherals, although the main crystal oscillator could be running. Are there no instructions for this, then?

- What are the function calls or instructions to switch between the internal 32.768KHz LFRC oscillator and the HFCLK?

[quote user="eith"]If using the nRF5 SDK, the main thread of the examples will typicall enter system ON low power mode in the main loop by calling sd_app_evt_wait(), via the power management library[/quote]

I have seen this functions in other cases and I will be able to use it probably in a part of the code. But there will be other cases in the machine state of the application wher I cannot enter into a wait state. In these last cases (in fact, the more usual) where I would try to reduce the consumption by reducing the oscillator frequency or switching to tha LFRC oscillator.

Regards,

Joel

RE: nRF52832 System ON Run modes of consumption

Einar Thorsrud — Mon, 12 Dec 2022 13:10:59 GMT

Hi Joel,

[quote user=""]Run mode using the external 32MHz crystal (I have no one external 32KHz crystal).[/quote]

You can never achieve low power if the 32 MHz clock is running all the time. However, that is no concern, as the nRF has an internal 32.768 kHz low frequency RC (LFRC) oscillator that will be used when there is no 32.768 kHz crystal.

[quote user=""]- Modifying the HFCLK clock frequency dinamically while the BLE module would not be needed.[/quote]

No, that is not possible. However, the nRF will normally use the HFINT which is an high frequency RC oscillator when there is no need for a highly accurate clock. Whenever an accurate HF clock is needed, the HFXO will be started (this is for instance always when using the radio).

[quote user=""]- Deactivating and reenabling dinamically internal peripherals.[/quote]

This is a key point. The details are different depending on which SDK you are using, but in any case the CPU will normally enter a low power system ON sleep mode whenever there is nothing to do. In this case, the RTC0 is running and will wake the CPU when it is time. However, other peripherals and resources must be disabled so that they do not consume power (for instance, if the UART is kept active, it will request the HF clock, causing a high current consumption even if the CPU is sleeping).

If you use the nRF Connect SDK you may find Power optimization and Power Management relevant. If using the nRF5 SDK, the main thread of the examples will typicall enter system ON low power mode in the main loop by calling sd_app_evt_wait(), via the power management library. This will wait for event, typically from RTC0, or any other application interrupt.

Einar