NCS Power Management

RE: NCS Power Management

Ryjan — Mon, 06 Nov 2023 22:22:16 GMT

Just in case someone is looking for information on the follow-up subject, like I was, it can be found here.

RE: NCS Power Management

Susheel Nuguru — Mon, 05 Dec 2022 09:21:01 GMT

Please create a separate ticket for this. This thread has already been with multiple different info which would be hard to search for other forum members.

We try to keep one thread to one context/querry.

RE: NCS Power Management

David Ormand — Sat, 03 Dec 2022 01:12:56 GMT

Thanks, this helps a lot.

Now I've got more of a QUESTION about NCS Power Management:

I'm guessing (and was not informed otherwise by any response to my clarification point #8 (the first #8, oops)) that Device PM puts a peripheral into low-power by setting the ENABLE register of the peripheral to disable it, and then the PMU on the chip automatically shuts down the power and/or clock to the peripheral.

The Runtime Device PM uses a pm_device_runtime_enable(dev) call, where "dev" is a pointer to a struct device pointer, same as used in the device_is_ready() call.

Our project uses GPIO for LEDs, the ADC to monitor the supply bus, and I2C for a sensing peripheral. In main(), I call device_is_ready() for everything, and that works. At the end of main(), I call pm_device_runtime_enable() for all those struct device pointer things for which device_is_ready() was called.

I2C works. I guess Device PM for I2C is implemented.

GPIO ("led.port") does not work. -134, ENOTSUP. I see in other DevZone queries that the GPIO subsystem is not subject to power shutdown, and it does not have an ENABLE register. So I'm not surprised.

ADC ("adc_channels[i].dev") does not work. -134, ENOTSUP. This is surprising that the SAADC cannot be controlled by Device PM under NCS. It has an ENABLE register. I see in other posts that the ADC could be shut down in older contexts (HAL/nrf?). Am I missing something? Or do I need to use the nrf libraries to shut down the SAADC between readings?

RE: NCS Power Management

Susheel Nuguru — Thu, 01 Dec 2022 19:05:03 GMT

[quote user=""]6. I've seen external sample code (from a DevZone query) in which all the
unused peripherals are "disabled" in a DeviceTree overlay. Since none of
the Zephyr samples do this, I'm guessing that unless a peripheral is
activated (via is_device_ready()), it never gets powered, or Device PM
makes sure it never gets powered.[/quote]

ANot sure if you are asking any question but all points above and including this seems correct.

[quote user=""] I'm guessing the RTC wakes up the CPU to run any timers that
are configured, and to perform the Bluetooth radio activities on schedule.
So one of the three RTCs never gets shut down (which one?).[/quote]

It is NRF_RTC1, please look into \ncs\v2.x\zephyr\drivers\timer\nrf_rtc_timer.c

[quote user=""]I'm guessing a timer interrupt will wake up
the system just like a "tick", and there will be a system wake-up latency.[/quote]

Yes,rtc timer interrupt is enabled to wakeup and handle its current_tick count updates.

[quote user=""]8. There are a CONFIG_PM_CPU_OPS and a CONFIG_PM_DEVICE_POWER_DOMAIN and a
CONFIG_PM_DEVICE_RUNTIME_EXCLUSIVE and a series of CONFIG_PM_MCUX_ config
options, but none of the nrf or Zephyr samples use them, so they must not
be critical. Or maybe not even wired up in NCS.[/quote]

I am not sure.

[quote user=""]9. I see some main() functions in the samples end in a busy loop and some
that do not. I've got (pre-PM) code now that after setting up the
Bluetooth structure and start a timer just ends and lets everything
just work. I'm guessing that the main() function exits to the idle
thread. Or would it be better to end in a forever-sleep?[/quote]

Main can exit when it is not doing kernel initialization. This is clearly defined in the documentation for system threads.Not using main in application is still ok if the application does not need one.