Questions about low-power deep sleep

RE: Questions about low-power deep sleep

Susheel Nuguru — Fri, 19 Nov 2021 08:21:09 GMT

[quote user="Libertas"]1. So if I keep the radio on and execute __WFI/__WFE to wait for incoming RF packet, your chip is smart enough to keep the HFXO on for quick wakeup, which according to some users' post is around 10us[/quote]

HFXO must be (there is no smartness in this as this is a must condition) ON for radio to work to wait for incoming packets and according to this data, the standby current can be anywhere between 80-900uA depending on the vendor of the XO you are using.

[quote user="Libertas"]2. On the another hand, if my device is a battery powered sensor and I turn off the radio and other peripherals, while only keep the RTC interrupt enabled, then execute __WFI/__WFE, the chip is smart enough to turn off HFXO to conserve the battery with uA level of current draw.[/quote]

Yes, turning of the peripherals will trigger the internal clock/regulator logic to be able smartly turn ON only those regulators that are needed for the enabled peripherals. In your use case, having only RTC enabled and calling __WFI/__WFE with other peripheral that use HFCLK disabled will disable the HFCLK in idle sleep (WFE/WFI)

[quote user="Libertas"]I believe I also need to use CONSTLAT for above case 1 and LOWPWR for case 2.[/quote]

Yes, that fits fine for the given cases.

RE: Questions about low-power deep sleep

Libertas — Fri, 12 Nov 2021 16:04:44 GMT

[quote userid="6207" url="~/f/nordic-q-a/81569/questions-about-low-power-deep-sleep/338734#338734"]Some of the base resources are kept active in sleep when CONSTLAT is enabled. HFCLK might still be off but the regulator for that might be kept active. [/quote]

Thanks again. One more question:

On page 87 of the specs of NRF52840, it states that "The HFXO must be running to use the RADIO...".

1. So if I keep the radio on and execute __WFI/__WFE to wait for incoming RF packet, your chip is smart enough to keep the HFXO on for quick wakeup, which according to some users' post is around 10us.

2. On the another hand, if my device is a battery powered sensor and I turn off the radio and other peripherals, while only keep the RTC interrupt enabled, then execute __WFI/__WFE, the chip is smart enough to turn off HFXO to conserve the battery with uA level of current draw.

I believe I also need to use CONSTLAT for above case 1 and LOWPWR for case 2.

Please confirm that it is the case.

RE: Questions about low-power deep sleep

Susheel Nuguru — Fri, 12 Nov 2021 09:56:49 GMT

[quote user="Libertas"]1. About idle sleep, my understanding is that "sub-power modes" will affect the HFCLK on __WFI/__WFE. If TASKS_CONSTLAT is set, __WFI/__WFE won't turn off HFCLK. Please confirm.[/quote]

Some of the base resources are kept active in sleep when CONSTLAT is enabled. HFCLK might still be off but the regulator for that might be kept active.

[quote user="Libertas"]2. If I am build my own wireless mesh protocol, there is only RADIO HAL API in nRF SDK. I will need to manage HFCLK by myself. Please confirm. [/quote]

If you are writing a low level proprietary stack and you are using XTAL HFCLK then you need to have control on starting and turning it off.

RE: Questions about low-power deep sleep

Libertas — Thu, 11 Nov 2021 15:49:02 GMT

Hello Susheet,

Thanks for clarification. Coming from CM3 world, this kind of sleep is already pretty deep 😀.

Just two quick questions:

1. About idle sleep, my understanding is that "sub-power modes" will affect the HFCLK on __WFI/__WFE. If TASKS_CONSTLAT is set, __WFI/__WFE won't turn off HFCLK. Please confirm.

2. If I am build my own wireless mesh protocol, there is only RADIO HAL API in nRF SDK. I will need to manage HFCLK by myself. Please confirm.

RE: Questions about low-power deep sleep

Susheel Nuguru — Thu, 11 Nov 2021 12:08:58 GMT

Hi Qingjun,

[quote user="Libertas"]1. Before entering the deep sleep (calling __WFI), I need to call nrfx_clock_hfclk_stop(). This will stop HFXO and HFINT will be used to keep the code running.[/quote]

Just a clarification, __WFE/__WFI are called "idle sleep" (not deep sleep) which will make the CPU go to sleep. All peripherals that are not active/enabled will have their clocks released and if all the peripherals that use HFCLK are disabled then the HFCLK will be stopped when CPU goes to sleep.

Normally, calling __WFI/__WFE will turn of HFCLK if you have no peripherals like TIMERS/UART etc that depend on HFCLK are running.

[quote user="Libertas"]2. calling __WFI in "low-power" mode will put the system in deep sleep with HFCLK turned off.[/quote]

Not guaranteed, but yes if all other peripherals that use HFCLK are disabled. Then the only peripheral that uses HFCLK will be CPU calling WFE/WFI will make the CPU go to low power and release the HFCLK and if no other peripherals use the HFCLK at that time, then the HFCLK is stopped automatically.

[quote user="Libertas"]3. RTC or external pin interrupt will wake up from deep sleep.[/quote]

only four things mentioned here (deep sleep = System off mode) can wake the chip with a reset. I think you mean to ask this for idle sleep. In that case yes, RTC or external pin interrupts can wake the chip. FreeRTOS port works with SEVONPEND bit set in ARM core registers. That means that the interrupt does not need to be even enabled in the NVIC, if the peripheral generates interrupt, and the correct INTENSET bit is set in that peripheral, then that interrupt will wake the system from idle sleep.

[quote user="Libertas"]4. I need to call nrfx_clock_hfclk_start() to start HFXO and wait for HFXO debounce time for HFXO to stabilize. Because I need the radio I will need the HFXO.[/quote]

Normally all the device drivers and libraries in our SDK handle the clocks they use properly. I strongly recommend you to use the drivers and libraries for peripheral so that their clocks can be automatically requested/released when needed. You can ofcourse request the hfclk in your application but your application will then bear the responsibility to release this clock before going to sleep.

RE: Questions about low-power deep sleep

Libertas — Wed, 10 Nov 2021 16:28:08 GMT

Hello Simon,

Thanks for your response. I am using nRF5 SDK and FreeRTOS. I am building a novel OS layer on top of FreeRTOS.

I think I've found the code in nrfx_clock.c. Here is my understanding:

Assuming I take care of all other peripherals, let's concentrate on the clocks here.

1. Before entering the deep sleep (calling __WFI), I need to call nrfx_clock_hfclk_stop(). This will stop HFXO and HFINT will be used to keep the code running.

2. calling __WFI in "low-power" mode will put the system in deep sleep with HFCLK turned off.

3. RTC or external pin interrupt will wake up from deep sleep.

4. I need to call nrfx_clock_hfclk_start() to start HFXO and wait for HFXO debounce time for HFXO to stabilize. Because I need the radio I will need the HFXO.

I will appreciate if you can confirm my understanding is correct or wrong.

Thanks

Qingjun

RE: Questions about low-power deep sleep

Simonr — Wed, 10 Nov 2021 14:13:58 GMT

Are you going to work on the nRF5 SDK or the nRFConnect SDK based on the Zephyr stack?

1. If you just call __WFI this will not automatically turn off all peripherals and HF sources, as these must be disabled somehow first. In our SDK we do have various wrapper functions regarding sleep/sub power modes that will prepare the device for sleep before calling __WFI/__WFE so that all high current consuming sources are disabled first. An example is the idle_state_handle() function in the nRF5 SDK.

2. Ramp-up times and behavior for the internal oscillators are stated in the nRF52840 product specification. If you are interested in current consumption in general, please check out our Online Power profiler which can give you an idea of what current consumption you can expect in various situations.

Best regards,

Simon