Thanks for doing this!

So this will disable some peripherals during light sleep now?

Is the RP2350 sleep current high because it doesn't use POWMAN to shutdown ram?

So this will disable some peripherals during light sleep now?

To be tested, but probably yes, due to the switch to dormant-state. For light-sleep with serial-connection, there should be no change.

Is the RP2350 sleep current high because it doesn't use POWMAN to shutdown ram?

I think so, dormant does nothing with other units than the cores.

Please mark this as a draft PR. The Pico-W (and probably the Pico2-W) need some more investigation. In my tests, the CYW43 did complain with messages like:

[CYW43] cyw43_kso_set(1): failedF2 not readyF2 not ready[CYW43] STALL(0;129-129): timeout

There is acyw43_enter_deep_sleep() function called fromcommon_hal_alarm_enter_deep_sleep(), but I am missing the counterpart. Since this only setsWL_REG_ON to false, it might be simple.

Pinging@eightycc: any ideas?

@bablokb The[CYW43] cyw43_kso_set(1): failed message may be occurring because simply turning off power to the WIFI radio as is done incyw43_enter_deep_sleep() does not put the driver into a quiescent state. Similarly, properly powering the WIFI radio back up requires a sequence of operations involving an interrupt from the CYW43 that appears to be entirely missing.

I'll reproduce the failure here and get back with a more detailed analysis.

The best source of technical specs for the CYW43439 that I've been able to find is the source code for Infineon's WHD driver:https://github.com/Infineon/wifi-host-driver.

The KSO (Keep SDIO On) bit managed bycyw43_kso_set() appears to affect operation only when the CYW43's interface is in SDIO mode. Why it's getting touched when the interface is in gSPI mode is a bit of a puzzler.

Incommon_hal_alarm_set_deep_sleep_alarms() we're missing code for putting the CYW43439 into a quiescent state before pulling the plug on the WIFI radio by callingcyw43_enter_deep_sleep(). We're also missing code for bringing the CYW43439 back up after exiting deep sleep. That requires pretty much a complete re-initialization of the chip. There's no similar code in Micropython (i.e., powering down/up the WIFI radio), so we're on our own for an implementation.

The CYW43439 does expose power management controls, but the best I say for the documentation is that it's murky. There might be an alternative to pulling the plug there?

@eightycc thanks for your input. I will do some more analyses and tests next week. Maybe it makes more sense to put the driver into a quiescent state and leave the chip as is. Or I will try to reinitialize the chip. Although I don't really like the idea, because currently this is a lengthy process with a hard-coded delay of one whole second.

Becausecommon_hal_alarm_set_deep_sleep_alarms() with its call tocyw43_enter_deep_sleep() leaves the CYW43439 in an unrecoverable state (at least with the code as it is), I'd suggest removing the call tocyw43_enter_deep_sleep() and seeing what the power consumption hit is. Just a nit to pick, but the function as is includes a hard-coded pin number.

It may be worthwhile to look into the power management features of the chip exposed bycyw43_wifi_pm() incyw43-driver. Presentlybindings_cyw43_wifi_enforce_pm() inports/raspberrypi/bindings/cyw43/__init__.c disables all power management features by default.

I added two small changes:

• keep WLAN alive for light-sleep/deep-sleep when connected via USB
• fix AON-wakeup for RP2350

The code from the PR is now also working for Pico-W and Pico2-W, butit is necessary that the user disables WLAN (wifi.radio.enabled = False) before switching to light-sleep (and "slow-sleep" also btw, since the CYW does not like changing clocks).

Looking at the measurements, the W variants draw a lot of current, probably more than what can be attributed to the CYW-chip. Light-sleep currently does not touch the CYW, so here is still some room for improvement. The goal would be to bring current draw down to deep-sleep level at least for the RP2350 (which would imply turning of the chip and reinitializing after wakeup).

Disabling the radio is currently a task for the user-code. This could be integrated into the firmware. Re-enabling could probably also be done, but re-connecting to the AP will always have to be done by the user (especially if turning off the chip during light-sleep works). This must be cleanly documented.

The measurements show considerable improvements for light-sleep and time-alarms (RP2040). The figures for the RP2350 are similar.

Pico-W (RP2040)

Test-Setups:

• (a):import wifi and connected as documented
• (b): wifi not imported
• (A):import wifi, CYW43 shutdown, manual reconnect
• (B): wifi not imported, CYW43 shutdown

¹ connected
²wifi.radio.enabled=False
³ reconnect from user-code necessary

(Pico2-W) RP2350A

Test-Setups:

• (a):import wifi and connected as documented
• (b): wifi not imported
• (A):import wifi, CYW43 shutdown, manual reconnect
• (B): wifi not imported, CYW43 shutdown

¹ connected
²wifi.radio.enabled=False
³ reconnect from user-code necessary

@dhalbert: I am still working on this, trying to fix a pin-alarm related problem. I found this piece of code while searching for a solution (see:https://github.com/adafruit/circuitpython/blame/d965980a986c44c3048fd744e7112c5dda782288/ports/raspberrypi/common-hal/alarm/pin/PinAlarm.c#L31):

    if (_not_yet_deep_sleeping) {        // Event went off prematurely, before we went to sleep, so set it again.        gpio_set_irq_enabled(gpio, events, false);    } else {        // Went off during sleep.        // Disable IRQ automatically.        gpio_set_irq_enabled(gpio, events, false);        gpio_set_dormant_irq_enabled(gpio, events, false);    }

I don't understand the "if"-part of this. I think to "set it again" I would need both function-calls from the else-part but withtrue as last argument?!

Otherwise, I am making good progress. I managed to shutdown (and restart) the CYW-chip, so current in light-sleep is down to deep-sleep levels. I will update the PR as soon as I sorted out the last few problems.

This is now ready for review (and merging IMHO). I don't know why there is a complaint about a conflict incommon-hal/alarm/__init__.c. Github marks a handful of lines as having a conflict although I change almost everything in the given file.

I also updated the measurements in the comments above. For the Pico-W for example a light-sleep time-alarm is now down from 60mA to below 2mA.

I don't know why there is a complaint about a conflict incommon-hal/alarm/__init__.c.

I changed that file in#10018, which was recently merged. Your PR is against an older commit of that file. So could you rebase or merge from upstream? That should clear the conflict, but check the changes. I think your rework will make that change moot, but try the test program in#10018. Thanks.

I actually integrated your recent change already. I will try a rebase and see if this resolves the issues.

Ok, seems I need a new PR since I could not push the rebased branch without deleting my upstream branch.

@bablokb FYI, agit push --force will replace a branch on github and will automatically update any pending pull requests.

git push --force-with-lease will force but only if your local copy of the branch matches the remote one.