print doesn't come back after light sleep on rpi pico

[kjm1102]

print seems problematic on the rpi pico (upython v 1.22.2)

from machine import lightsleep,Pin; from time import sleep
led = Pin(25, Pin.OUT)
for i in range(3):
  print('cycle', i); sleep(.1)
  led(1)
  lightsleep(1000)
  led(0)
  lightsleep(1000)
print ('end') 
>>> 
cycle 0

The led flashes 3 times which means the loop runs as expected but I get only one of the 4 prints I expected. Is there a work around for this behaviour?

[davefes]

Try adding:
time.sleep_ms(5)
after and before light and deepsleep and machine.reset() and

[kjm1102]

No joy Dave. What a bummer, feeling handicapped here with my fav diagnostic (the strategically placed print stmt) rendered inoperative.

[davefes]

Hmmm, been doing that for the last year or so on ESP32s.

[robert-hh]

This blocking of print is caused by lightsleep(). lightsleep turns of the USB clock and slows down other clocks. It seems that USB needs input from the PC to get working again. The same would happen if you use sys.stdout.write() instead of print(). Using sleep_ms() instead of lightsleep() works.

[kjm1102]

So what's the best way forward when I see a problem I think needs fixing but I don't have the smarts to offer the code to fix it Angus? https://github.com/orgs/micropython/discussions/14539

[projectgus]

@kjm1102 In the case of that discussion then I'd suggest adding more detail: exactly what hardware (development board, etc.) that you have, the exact code you're running that you expect to work, exactly what is connected to which pins on the board, etc etc.

It's almost impossible to provide too much detail, as long as the information is specific.

That will let someone try to reproduce the behaviour, or maybe even tell you why it doesn't work, without having to guess.

[kjm1102]

And I do that in a PR rather than here in the forum?

[projectgus]

I suggest adding that information in the Discussion you already created. A PR is for when you have code changes that you wish to contribute.

[kjm1102]

OK I expanded on my problem @ https://github.com/orgs/micropython/discussions/14539 but I'm not hopeful. It's not every day that an Angus comes along, sees a problem in a discussion, knows how to fix it then does a PR. Many thnx for that BTW.

[projectgus]

I've submitted a pull request that keeps the USB peripheral clocks enabled during lightsleep on rp2, if a USB host is connected and active: #15111

[dpgeorge]

This PR was merged in a84c7a0 (not part of the v1.23.0 release, will be in the next release).

[GitHubsSilverBullet]

Ahem, has this been tested?

#!micropython
from machine import lightsleep, Pin
led = Pin(25, Pin.OUT)
for i in range(10):
    led.toggle()
    lightsleep(100)
for i in range(6):
    print(f'cycle {i}')
    led.toggle()
    lightsleep(500)

Hangs. Sometimes during the first run, sometimes during the second.
But it will hang. Not only the communication, the µC itself.
MicroPython v1.23.0 on 2024-06-02; Raspberry Pi Pico with RP2040

EDIT:
Interesting. Tried it on a different system (Notebook) using Debian 12 instead of Debian 11.
Was a bit more stable, took four runs until it crashed and hung. (USB2)
On the USB3 port it crashed almost always instantaneous.

[scruss]

can confirm intermittent lock-ups of a Pico W when run from mpremote. Curiously, indication that a crash is imminent seems to be that cycle 0 is not echoed to the terminal, but 1–5 are.

Running it in Thonny is not recommended at all.

[projectgus]

The PR was merged after v1.23.0, it won't be in a release until v1.24. I'll update the other reply to make that clear.

If it's still not working on the latest v1.24 preview build then that's concerning, though. I wasn't able to reproduce the exact behaviour @GitHubsSilverBullet saw before the change, so it's possible there are host controllers that still don't like the way the RP2040 behaves after the change.

[projectgus]

Also, I appreciate that it's frustrating when things don't work as expected however I don't appreciate the tone of comments such as "Ahem, has this been tested?". The PR description has a specific list of tests that were run, and explains in detail how there is some reported behaviour that I was unable to reproduce on my own hardware.

I'm happy to work with folks to debug this kind of stuff, but only if it's going to be in a mutually respectful way.