However, even with version 0.0.29 the following program will only loop a few times before stopping.

from time import sleep
from machine import Pin, lightsleep
import network

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

while True:
    print ('going to lightsleep for 2 seconds')
    sleep(0.1)
    lightsleep(2000)

Thonny behaves the same when there is a lighsleep in the program.

No, it just stops running. However, now I can't even access the PICO W, so I think have another problem. I will get a PICO (no WiFi) tomorrow and continue my efforts.

Thanks for the response.

@cpottle9 sorted this issue in discussion
https://github.com/orgs/micropython/discussions/10889

Be aware, that lightsleep messes up the USB link to thonny (and probably rshell as well)

Is this a problem that needs fixing?

I commented in the other discussion.

I suspect this is a thonny issue, not a micropython or RP2040 issue.

@cpottle9, Thanks for the offer. Yes, I have been building lots of ESP32 devices that use light and deepsleep and LoRa. There is a hardware hack called pico_en_control.py, which uses a SN74HC74 to toggle the 3V3_EN line. The current with a DS3231 should be low enough for me.

I will keep your offer in mind if I need to start changing registers.

I stopped using Pico W over a year ago.
BTW, I have found that before same statements like machine.reset(), deepsleep() and maybe even lightsleep()and after a print statement that a short delay needs to be placed between them. Say, time.sleep_ms(10).

The are currently (1.24.1 at least) several things making lightsleep complicated.
If you try to use print, it will be messed up by lightsleep, But if you use, for example, time.sleep_ms(10) before the lightsleep, that will help with print BUT the lightsleep will no longer sleep and return almost immediately.
Also time.time() pauses during lightsleep meaning you can't keep track of time

I will test the zipped.uf2 from https://github.com/orgs/micropython/discussions/16314 tomorrow. It appears to be:
v1.25.0-preview.88..g2d4b02b4d on 2024-12-08

I should have said that the comment was based on my ESP32 experience.

Ran some simple tests, as agreed. Sorry but with v1.25.0-preview.88.g2d4b02b4d it appears things are now much simplified - lightsleep(2500) or (5000) don't ever seem to sleep.

On the other hand 1.25.0-preview81 on a Pico2 (not a W) does sleep mostly ok but interferes with time.time and usb print, in turn it is interfered with by adjacent previous time.sleep

Well, I did not find anything wrong in the internals of lightsleep().

But, I did see that timer 2 is active (the interrupt for it is enabled).
This is true in the latest version of micropython but not in 1.23.0.
Note that lightsleep uses timer 3.
I do not know what timer 2 is being used for.

In the micropython documentation https://docs.micropython.org/en/latest/library/machine.html
for lightsleep it says:

If time_ms is specified then this will be the maximum time in milliseconds that the sleep will last for. 
...
With or without a timeout, execution may resume at any time if there are events that require processing. 

Timer 2 expiring would be such an event.

As a result it necessary to call lightsleep from a loop.
Here is a function I wrote.

When I tested this code I saw lightsleep called 80 times for 5 seconds.
On average each call to lightsleep actually slept for about 60 milliseconds.

from time import sleep_ms, ticks_ms, ticks_diff
from machine import lightsleep

def my_lightsleep(time_ms) :
    before_tick = ticks_ms()
    after_tick = before_tick
    sleep_ms = time_ms
    while sleep_ms > 0 :
        sleep_ms = time_ms - ticks_diff(after_tick, before_tick)
        if sleep_ms > 0 :
            lightsleep(sleep_ms)
            after_tick = ticks_ms()

I see this commit added use of timer 2.
74fb42a

I don't understand why those changes were necessary.
I trust the author and Damien George.

you might want to comment on the open issue - #16181 - as it's more likely to have maintainers look at it than discussions

@scruss good point! I just updated the issue.

Sorry but the issue you seem to have updated was the related: #16180 I replied with some questions there.