This looks like a very useful addition to the Zephyr port. Thanks!

I think, instead of grabbing the console device and putting it to sleep, it should either rely on zephyr's power policy management or implement pm_policy_next_state, or provide a API to chose what devices to turn on and off.

Otherwise this looks good.

I think, instead of grabbing the console device and putting it to sleep, it should either rely on zephyr's power policy management or implement pm_policy_next_state, or provide a API to chose what devices to turn on and off.

Otherwise this looks good.

Thanks @VynDragon

I think the uart/console has to be manually shutdown on the nrf chips regardless of PM policy.

My understanding is that when CONFIG_SERIAL=y then serial logging is enabled for debugging which uses power, even in low power modes. We can't turn off CONFIG_SERIAL because it's needed for micropython repl.

There is some info on it here.

Power Optimisation

You can see also in the power management examples they shut down the console device manually before power off.

System off sample

I'm very new to zephyr so I could be wrong, what do you think?

Also looking at the example if might be worthwhile also implementing deepsleep with sys_poweroff();?

I have added machine.deepsleep() to this PR which completely powers down the system using sys_poweroff();

I am trying to write PM for the chips I want to support but I am nowhere near a expert on this subsystem, so take what I say with a grain of salt.

I think the uart/console has to be manually shutdown on the nrf chips regardless of PM policy.

Dont take the NRF sdk docs as exclusive reference, there are a lot of other chips :)
In theory, Power policy via residency (the default when the application doesnt implement one), guides device power via power states: https://docs.zephyrproject.org/latest/services/pm/device.html, put differently, this is a zephyr setting rather than something the application should manage in the first place, unless power management is left unconfigured. This then follows the system power management states in https://docs.zephyrproject.org/latest/services/pm/system.html.
When calling sleep, the susbsytem calculates how much time it has to shut down and come back up, and switches to the lowest possible power state listed in the DTS, the code for this is there: https://github.com/zephyrproject-rtos/zephyr/tree/main/subsys/pm/policy

You can see also in the power management examples they shut down the console device manually before power off.
System off sample

That is indeed a example of manual control of the power saving, but not of managing power states via policies. See https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/pm/latency for the default latency policy.

I am also not sure if poweroff should be deep sleep of if that should be PM_STATE_SOFT_OFF. I have implemented power off on my platform, and it conserves some ways to be powered back on, but in comparison to ESP32 deepsleep, it would match a higher power state with more ways to wake up.

I tested this on nucleo_wb55rg, and it breaks the UART REPL on that board: the UART responds only occasionally to input (output is fine though). I'm guessing it's because power management is now enabled and the UART is mostly asleep?

I also tested it on frdm_k64f and rpi_pico. machine.lightsleep(2000) waits 2 seconds but doesn't seem to change the power consumption at all on those boards, maybe they don't implement low power?

If we want to move forward with this, I suggest only enabling CONFIG_PM/CONFIG_PM_DEVICE on devices where it's known to work.

I tested this on nucleo_wb55rg, and it breaks the UART REPL on that board: the UART responds only occasionally to input (output is fine though). I'm guessing it's because power management is now enabled and the UART is mostly asleep?

I also tested it on frdm_k64f and rpi_pico. machine.lightsleep(2000) waits 2 seconds but doesn't seem to change the power consumption at all on those boards, maybe they don't implement low power?

If we want to move forward with this, I suggest only enabling CONFIG_PM/CONFIG_PM_DEVICE on devices where it's known to work.

Hi Damien,

Apologies for the late reply.

I did some more research into this and it turns out that this high power usage on the UART is only related to nordic chips, something to do with the HFCLK being required when the uart is enabled.

Did enabling CONFIG_PM break the repl or was it calling lightsleep()?

Is there a mechanism where we could include the feature on just the nrf family? Or would if be better to add an nrf module with uart_sleep function?

Is there a mechanism where we could include the feature on just the nrf family? Or would if be better to add an nrf module with uart_sleep function?

if you make the config proper on zephyr side, UART will go to sleep automaticlaly when calling k_sleep or power off

if you make the config proper on zephyr side, UART will go to sleep automaticlaly when calling k_sleep or power off

Not for the nordic chips unfortunately, it's a know limitation that requires the uart to be powered down manually at the discretion of the application.

https://devzone.nordicsemi.com/f/nordic-q-a/101872/how-to-make-zephyr-power-management-unit-work-with-nrf52

If it is not standard within zephyr even, why add it to micropython code?

Sounds like that's true for all UART on all platforms though, so I'd be wrong. Regardless there should be some way to disable that right? It seems @dpgeorge 's issue is exactly what's described as happeneing when you turn off uart :)

Seems this machine.lightsleep() accessible in Micropython 1.26 beta?. On a pico 2 at least I get a response from the function. However the time delay seems a bit random as / and seems to turn off the internal RTC. Cannot be totally sure as testing with Thonny so UART kicked into action by interaction. But when I set up some delays and print(time.time()) I get no change in the time. And I cannot set up predictable delay loops. I would just like to be able to sleep the machine and reboot it reliably after a relatively accurate time delay... Still a bridge too far it seems..

I just created PR #18197 that allows Pin IRQs to interrupt machine.lightsleep()

Did enabling CONFIG_PM break the repl or was it calling lightsleep()?

CONFIG_PM_DEVICE breaks the REPL. I have a different board (an Apollo3 from Ambiq), and tried to investigate this stuff directly at Zephyr level, starting with the shell sample and adding PM configuration. On my board, the working config is the following:

CONFIG_PM=y
CONFIG_PM_DEVICE=y
CONFIG_PM_DEVICE_RUNTIME=y

Skipping the last line makes the UART unresponsive to user input (it does print messages, though). It seems that there is nothing that marks the REPL (or the Zephyr shell) as making use of the console. Adding the following to main is enough to make the shell usable even without CONFIG_PM_DEVICE_RUNTIME:

    const struct device *dev;
    dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));
    pm_device_busy_set(dev);

I think this line would solve the REPL issue also for MicroPython; but then, before going to sleep you would need to relinquish the console with a corresponding pm_device_busy_clear().

I can confirm that the solution above works also for MicroPython on the board I have. Here is my patch:

diff --git a/ports/zephyr/main.c b/ports/zephyr/main.c
index 8d39935884..ef1c7590ae 100644
--- a/ports/zephyr/main.c
+++ b/ports/zephyr/main.c
@@ -89,6 +89,10 @@ static __noinit char heap[MICROPY_HEAP_SIZE];
 extern int mp_usbd_init(void);
 #endif // defined(CONFIG_USB_DEVICE_STACK_NEXT)
 
+#if CONFIG_PM_DEVICE
+#include <zephyr/pm/device.h>
+#endif
+
 void init_zephyr(void) {
     // We now rely on CONFIG_NET_APP_SETTINGS to set up bootstrap
     // network addresses.
@@ -163,6 +167,14 @@ soft_reset:
     }
     #endif
 
+#if CONFIG_PM_DEVICE
+    const struct device *dev;
+    dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_console));
+    if (dev != NULL) {
+        pm_device_busy_set(dev);
+    }
+#endif
+
     for (;;) {
         if (pyexec_mode_kind == PYEXEC_MODE_RAW_REPL) {
             if (pyexec_raw_repl() != 0) {