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.

[projectgus]

No worries at all, I appreciate the explanation. If it's not working on v1.24-preview then please do let us know.

Are you both using Thonny? I don't know what happens if the host (i.e. Thonny) tries to send some data over USB while the RP2040 is in light sleep. It will be NAKed at the USB layer, and the host will retry, but maybe after a while the host still gives up and sends a write error back to Thonny.

[GitHubsSilverBullet]

That's good to hear.
No, I have never used Thonny, I feel that it introduces far more problems than it promises to solve.
Vi, a slightly modified version of pyboard and miniterm is all I need.
Will get the newest preview, give it a try and post what transpires.

EDIT:
OK, tested with:

MPY: soft reboot
MicroPython v1.24.0-preview.23.g8809ae716 on 2024-06-05; Raspberry Pi Pico with RP2040

Here's a slightly modified python code to test:

#!micropython
from machine import lightsleep, Pin
from time import sleep_ms

def flicker(delay=50,num=10):
    for _ in range(num):
        led.toggle()
        sleep_ms(delay)

led = Pin(25, Pin.OUT)
for i in range(10):
    flicker()
    print(f'cycle {i}')
    sleep_ms(50) # needed to print anything at all
    lightsleep(500)
flicker(25,50)
led.on()

dmesg showed neither errors nor anomalies.

[ 7526.144550] usb 1-1.3.4: new full-speed USB device number 23 using ehci-pci
[ 7526.255349] usb 1-1.3.4: New USB device found, idVendor=2e8a, idProduct=0005, bcdDevice= 1.00
[ 7526.255354] usb 1-1.3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 7526.255365] usb 1-1.3.4: Product: Board in FS mode
[ 7526.255366] usb 1-1.3.4: Manufacturer: MicroPython
[ 7526.255368] usb 1-1.3.4: SerialNumber: ba4d9216214d8a53
[ 7526.257126] cdc_acm 1-1.3.4:1.0: ttyACM0: USB ACM device

On the µC the code always ran through to the end. (verified by observing the flicker patterns)
But only the first 2,3,4, sometimes 5 cycles were printed and it was not possible to get the REPL prompt afterwards.
While I was able to connect to the µC, I did not get a response. All the Ctrl-C…D…E inputs didn't bring it back to life. Needed a hard reset.

[projectgus]

Thanks @GitHubsSilverBullet for the clear explanation and test case.

I can reproduce this intermittently here. Most of the time it completes, but sometimes it gets stuck as described. Will investigate more.

[GitHubsSilverBullet]

@projectgus It's been quite a while but I seem to remember that there are a couple of timeouts which have to be observed.
Had a look at the USB Spec Rev2.0 April 27, 2000 to verify.
Table 7-14. Device Event Timings (Continued) on page 189 shows a number of different 50ms timeouts as well as one 500ms timeout. I wonder whether that might be a potential source for complications.

[projectgus]

I think this is solved, fix and a new test case here: #15301

Table 7-14. Device Event Timings (Continued) on page 189 shows a number of different 50ms timeouts as well as one 500ms timeout. I wonder whether that might be a potential source for complications.

Hmm, yeah, probably at the minimum there are device control transfers where NAKing them continually isn't allowed. I think this should be safe from the device's perspective though, either the USB host stack should return an error or it will keep trying.

It wasn't exactly what happened here though, it seems like reconfiguring the PLL on wake would sometimes introduce a clock glitch that broke USB entirely (no more responses at all, NAK or otherwise.)