PICO W - lightsleep not working after cyw43_deinit

[cpottle9]

I'm trying to build a small app to run from battery with minimum power.
I want to power down the cyw43 wifi module when I don't need it.

I found a recipe to do that as follows.
In a loop I:

• initialize wifi using:

import rp2
import network
rp2.country('CA')
wlan = network.WLAN(STA_IF)
wlan.config(pm = 0xa11140)
wlan.active(True)
wlan.connect('secretSSID','secretPW')

• do my networking (MQTT). No issues here.

• shutdown the wifi connection using:

wlan = network.WLAN()
wlan.disconnect()
time.sleep_ms(1000)
wlan.active(False)
time.sleep_ms(1000)
wlan.deinit()

I have a USB power meter and I see a significant drop in power when wlan.deinit() happens.
It seems the cyw43 is powered down.
Also, if I turn the LED on, when I call wlan.deinit() the LED is turned off.

BTW, whoever implemented deinit() did a good job.
After calling deinit() if I turn on the PICO_W LED or access any other GPIO connected to the cyw43 it just works.
Restarting wifi works top.
The cyw43 is powered up.

After shutting down the wifi connection I call time.sleep_ms(60000) to sleep for a minute.
When it returns the loop starts again and wifi is re-initialized.

On the other hand, using machine.lightsleep(60000) instead of time.sleep_ms() I have a problem.
lightsleep() returns immediately.

I looked at the micropython source code. In the implementation for lightsleep (modmachine.c):

    if (cyw43_has_pending) {
        restore_interrupts(my_interrupts);
        return mp_const_none;
    }

I added an mp_printf to the body of the if statement and confirmed cyw43_has_pending is set.
I think the solution is that either wlan.active(False) or wlan.deinit() should clear cyw43_has_pending.

As an experiment, I modified network_cyw43_deinit() in network_cyw43.c to clear cyw43_has_pending.

STATIC mp_obj_t network_cyw43_deinit(mp_obj_t self_in) {
    network_cyw43_obj_t *self = MP_OBJ_TO_PTR(self_in);
    cyw43_deinit(self->cyw);
>   extern volatile int cyw43_has_pending;
>   cyw43_has_pending = 0;
    return mp_const_none;
}

This fixed my problem with lightsleep().

IMO, this is not a good fix. The variable cyw43_has_pending is defined in ports/rp2 and only used there.
network_cyw43.c is used for both ports/rp2 and ports/esp32.

I'm new to micropython and github (but not git).
I am willing to prepare a proper fix and submit a pull request.
But I would like some advice from and expert before I proceed.

[cpottle9]

OK, I continued to poke around in the micropython source code.

I have a better fix (I think).
In modmachine.c I am using cyw43_poll being NULL to indicate the cyw43 is not initialized.

--- a/ports/rp2/modmachine.c
+++ b/ports/rp2/modmachine.c
@@ -146,7 +146,7 @@ STATIC mp_obj_t machine_lightsleep(size_t n_args, const mp_obj_t *args) {
 
     uint32_t my_interrupts = save_and_disable_interrupts();
     #if MICROPY_PY_NETWORK_CYW43
-    if (cyw43_has_pending) {
+    if (cyw43_has_pending && (cyw43_poll != NULL)) {
         restore_interrupts(my_interrupts);
         return mp_const_none;
     }

I would still like to have an expert comment before I create a pull request.

[aleppax]

I'm not an expert but am trying to build a similar project to yours, here: ghubcoder#8 (comment) Jmodrako found a solution in micropython, the difference being that after wlan.deinit() he adds wlan = None
and switching the pin 23:
wlanSw = machine.Pin(23, Pin.OUT) wlanSw.low()

[cpottle9]

Alessandro, thanks for the pointer.

I tried the code provided by jmodrako. It doesn't work for my with a recent version of the micropython interpreter.
Looking at the source code of the interpreter I see a change made late september that is likely the problem.

Also, as I mentioned in my original post wlan.deinit() will power down the cyw43 wifi module.
And it will get powered backup automattically on the reconnect.

You don't need to mess with pin 23 yourself.

I am going to submit a pull request with my change to modmachine.c.
It will take me a little while.

[aleppax]

Thank you for the explanation of the inner functioning of the source, indeed even if more than 20 years ago I used to code in C++ and OpenGL now it is very hard for me to dive into it.
I've too encountered the problem with lightsleep exiting immediately but only occasionally and I am not able to reproduce it: i'm using MicroPython v1.19.1-896-g2e4dda3c2 on 2023-02-25; and 99.9% of times it works properly. Don't know whether this binary is based on different code.

[danjperron]

if (cyw43_has_pending && (cyw43_poll != NULL))
This work very well!

Last summer I made a garden Pico Solar and everything was working but with the last release it wasn't!
https://github.com/danjperron/PicoWSolar

I did recompile the most recent github code and change the line 148 with this modification and then it works!

daniel@linuxserver:~$ mosquitto_sub -t "#" -v | xargs -d$'\n' -L1 bash -c 'date "+%Y-%m-%d %T $0"'
2023-03-03 10:05:15 PicoW2/TempCPU 27.981
2023-03-03 10:05:15 PicoW2/Vsys 4.796
2023-03-03 10:05:45 PicoW2/TempCPU 27.044
2023-03-03 10:05:45 PicoW2/Vsys 4.801
2023-03-03 10:06:15 PicoW2/TempCPU 27.044
2023-03-03 10:06:15 PicoW2/Vsys 4.801
2023-03-03 10:06:45 PicoW2/TempCPU 27.044
2023-03-03 10:06:45 PicoW2/Vsys 4.796

[cpottle9]

I created a pull request with the change to modmachine.c.

But, it turns out some else already had a pull request in the queue with the same fix.
#10803

I learned a lesson, next time I find a bug I need to look for an existing pull request.

[robert-hh]

That PR exists already #10803 .

[dpgeorge]

This PR has been merged.

[davefes]

Tried many different scripts on V1.20 and the latest nightly build, but can not get the Pico W to go into lightsleep.
Does the script at the top of this post now run properly and on what firmware version?

Thanks

[FilipSLO]

It seems already fixed/committed 3 days ago.

[davefes]

With nightly build:
RPI_PICO_W-20231002-unstable-v1.20.0-544-g977dc9a36.uf2
and the following code running on a bare PICO W:

from time import sleep
from machine import Pin, lightsleep


print ('waiting 2 seconds for a CTRL-C')
sleep(2)

led = Pin('LED', Pin.OUT)
led.off()

while True:

    led.on()
    sleep(.1)
    led.off()

    lightsleep(10000)

I get an unchanging 17mA. I must be doing something wrong.

[cpottle9]

I was super busy today. I will test the latest nightly tomorrow.

@davefes note the problem I reported that is fixed by #10803 was lightsleep() would return immediately after disabling wifi using wlan.deinit().

In your code, the wifi chip remains powered up all the time.
It is the biggest power consumer on the PicoW.
Note that 'LED' is connected to the wifi chip so anytime you are accessing 'LED' the wifi chip has to be powered up.

[davefes]

So, you need to do a wlan.deinit() even when you do not want the WiFi chip. Will try that again as I had tried it on previous nightly builds.. Thank you.

[davefes]

Wahoo! 1.4mA. As well doing a wlan.deinit() one also has to remove:
led = Pin('LED', Pin.OUT)
or the WiFi seems to be re-enabled.

Test script now:

from time import sleep
from machine import lightsleep
import network


wlan = network.WLAN(network.STA_IF)
wlan.active(False)
wlan.deinit()

print ('waiting 2 seconds for a CTRL-C')
sleep(2)

lightsleep(10000)

@cpottle9 Thanks again. This means the last few weeks of getting to know the RP2 devices and wanting to use them as LoRa sensors has not been wasted.

[cpottle9]

I did test to confirm that lightsleep does work correctly while wifi chip is disabled.

import time
from network import WLAN, STA_IF

wlan = WLAN(STA_IF)
wlan.active(False)
wlan.deinit()

print('Light sleep')
machine.lightsleep(2000)

led = machine.Pin("LED", machine.Pin.OUT)
led.low()
time.sleep(0.5)
led.high()
time.sleep(0.5)
led.low()
time.sleep(0.5)
led.high()
time.sleep(0.5)
led.low()

print('Done')```

I have cheap USB power monitor. I see power usage drop while the lightsleep is running.
Then I see the led flash and power consumption goes back up.

Be aware, that lightsleep messes up the USB link to thonny so you won't see 'Done' get printed.

[davefes]

@cpottle9 thanks for the added information. I had figured that USB was being messed about with. I started another thread:
https://github.com/orgs/micropython/discussions/12573
as the PICO W seems to have died so got a standard PICO, it is the one likely to be used as a remote sensor and the one that I would normally put lightsleep on.

I did notice, when the PICO W was alive that stand-alone was OK. So, can I assume that lightsleep on the standard PICO will mess with the USB as well?

[cpottle9]

I guessing, but I think the USB issue is with thonny.
I think thonny is polling the PICO for status and the PICO is not responding during the lightsleep.
In my code sample above if I replace the single call machine.lightsleep(2000) with four machine.lightsleep(500)
the print('Done') works.

My use of Pico_W is for home automation.
I currently I am monitoring temperature and posting to an MQTT server over wifi.
In the future, I will monitor humidity and other environmental data.
In some cases the Pico_W is powered from battery and others it is powered over USB.

When running from battery I use a private micropython load that allows me to turn off RP_2040 blocks I don't need.

My only use of USB is for developing and debugging.

[davefes]

rshell seems to behave the same way, is this respect. Same here, w.r.t. USB but it is sure nice to be able to develop and debug using it!