PICO W lightsleep doesn't work when using rshell

[davefes]

I can get lightsleep to work as a stand-alone device as per:
https://github.com/orgs/micropython/discussions/10889
but it appears that trying to use rshell stops lightsleep from working.

Could anyone tell me how to use rshell to monitor program execution that has a lightsleep in it?

[davefes]

https://blog.martinfitzpatrick.com/using-micropython-raspberry-pico/

tells me to download:

python -m pip install https://github.com/dhylands/rshell/archive/pico.zip

[davefes]

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.

[FilipSLO]

Is there any output on stop?
From your description it seems to me that running repl is causing this. At least that make more sense then both rshell and Thonny cause the same error. But this is just a wild guess.

[davefes]

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.

[davefes]

As a stand-alone unit powered by Vsys the program is still running, I can see the supply current changing. However, plugging it into the USB port, pulling the RUN port low briefly and then hitting enter on rshell --buffer-size=512 -p /dev/ttyACM0 gives:

Using buffer-size of 512 Connecting to /dev/ttyACM0 (buffer-size 512)... failed to access /dev/ttyACM0
When I was able to get into the device on rshell or Thonny access would often terminate after a period of time, but I could always hit run and start over again. I thought access via USB seemed a bit flaky.

Off to buy a PICO.

[davefes]

Fired-up up a PICO with V1.20 and the latest nightly release. The following script runs OK until lighsleep is introduced to either firmware version.

from time import sleep
from machine import lightsleep

while True:
    print ('waiting 2 seconds for a CTRL-C')
    sleep(2)
    print ('going to lightsleep for 2 seconds')
    sleep(0.1)
    lightsleep(2000)
    print ('woke-up again')
    sleep(0.1)

It will not run for more than30-60 seconds before locking-up. If someone could run this script that would be helpful.

Thank you.

[davefes]

@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?

[cpottle9]

I commented in the other discussion.

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

[davefes]

@cpottle9 tried your suggestion of reducing the lightsleep period to 500ms. It still acts-up. There was a suggestion by @robert-hh that modemmanager has been implicated in this type of behaviour. Removed modemmanager and no improvement, when using rshell or Thonny.

I can tell that the program is still running on the device but comms is lost out the USB port.

[cpottle9]

@davefes, I assume you are building an app that will run from batteries.

I have some micropython code I use to reduce power consumed for my app by manipulating some RP2040 hardware registers.

I can share that code with you.
But, I don't want to do that here.
Github does not provide private messaging.
We could exchange email addresses if you like.

[davefes]

@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.

[CrabbyPete]

What version are you using? I had it working perfectly in 1.23, and now in 1.24 I am having that issue.

`from time import sleep,gmtime
from machine import lightsleep

while True:
lightsleep(3600)
print (f'woke-up again {gmtime()}')`

[davefes]

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).

[ssotheremail]

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

[davefes]

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

[ssotheremail]

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

[CrabbyPete]

What happened? v1.23 worked perfectly.

[cpottle9]

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()

[cpottle9]

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.

[scruss]

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

[cpottle9]

@scruss good point! I just updated the issue.

[ssotheremail]

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