time.sleep() runs indefinitely after calling displayio.release_displays()

[mcauser]

Found an issue with time.sleep() when testing the latest CircuitPython on Wio Terminal.
After calling displayio.release_displays() all calls to time.sleep() run indefinitely until you trigger a KeyboardInterrupt.
A soft reset isn't enough to fix it, but a hard reset is.

Board:
Adafruit CircuitPython 6.0.0 on 2020-11-16; Seeeduino Wio Terminal with samd51p19

Steps to replicate:

>>> import time
>>> time.sleep(0.1)   # works as expected
>>> time.sleep(0.5)   # works as expected
>>> time.sleep(1)     # works as expected

>>> import displayio
>>> displayio.release_displays()
>>> time.sleep(0.1)   # fail: keeps sleeping until KeyboardInterrupt
>>> time.sleep(0.5)   # fail: keeps sleeping until KeyboardInterrupt

soft reboot
>>> import time
>>> time.sleep(0.5)   # fail: keeps sleeping until KeyboardInterrupt
>>> time.localtime()  # shows an incrementing time

hard reboot (unplug it)
>>> import time
>>> time.sleep(0.1)   # works as expected

[skerr92]

I checked on the Feather M4 Express to see if maybe it was affected too running the same code you did, I don't have anything else to check on but at least it isn't affecting it on the latest CP build for it.

[mcauser]

Retested with 6.1.0 beta 2. Same lockup on the Wio Terminal.

Adafruit CircuitPython 6.1.0-beta.2 on 2020-12-03; Seeeduino Wio Terminal with samd51p19

[DavePutz]

I followed the steps above with a 'fresh-out-of-the-box' Wio Terminal. I loaded CP 6.1.0-beta.2 and did not see any hangups using time.sleep(). I re-tested using CP 6.0.0 and still do not see the reported behavior. Do you possibly have any libraries installed that might be interfering here?

[mcauser]

I did have around 10x files from adafruit-circuitpython-bundle-6.x-mpy-20201208 in /lib
Deleted them, rebooted, seeing the same issue.

I noticed when I upgraded from 6.0.0 to 6.1.0, it kept my files in the filesystem.
Is there a command I can run to wipe it back to factory defaults?

>>> import storage
>>> storage.erase_filesystem()

This one reset the board fs, but didn't fix the issue.

[mcauser]

It's actually sleeping for the correct duration, but after it finishes, it's not displaying a new line + >>> on the REPL.

I noticed this by pressing the down arrow on my keyboard after the sleep duration finished, while it looked like it was locked up ... but it wasn't locked up at all!
It just didn't move down to the next line, ready for the next command.

After releasing the display, if I paste the following into the REPL:

time.sleep(2)
time.sleep(3)
print('done')

Instead of printing 'done' after 5 seconds...
It pauses after the 2 seconds waiting for me to interact (press the down arrow)
Then it locks for another 3 seconds and only prints after I interact again.

eg.

1. Paste above snippet. REPL looks like this:

>>> time.sleep(2)

2. Wait 6 seconds (longer than both sleeps combined), then press down arrow on keyboard. REPL:

>>> time.sleep(2)
>>> time.sleep(3)

(The 2nd sleep hadn't started yet)

3. Wait 6 seconds, then press down arrow on keyboard. REPL:

>>> time.sleep(2)
>>> time.sleep(3)
>>> print('done')
done
>>>

(Note the print() call printed it string then put >>> below - sleep() doesn't)

4. Paste print('cool'), enter. REPL:

>>> time.sleep(2)
>>> time.sleep(3)
>>> print('done')
done
>>> print('cool')
cool
>>>

(Only time.sleep() is affected. The print() prints immediately)

[tannewt]

This seems very niche because it depends on pasting multiple lines into the REPL. Does it work as expected when you do each line individually?

[dhalbert]

I replicated this, but it seems to depend on the host computer!
On Linux using picocom: this works:

Adafruit CircuitPython 6.1.0-beta.2-125-g3b4c14f3e on 2020-12-21; Adafruit QT Py M0 Haxpress with samd21e18
>>> import time
>>> time.sleep(2)
>>> 

On MacOS 11.0.1, using screen, I have to type return to get the prompt to appear:

Adafruit CircuitPython 6.1.0-beta.2-125-g3b4c14f3e on 2020-12-21; Adafruit QT Py M0 Haxpress with samd21e18
>>> import time
>>> time.sleep(2)
[must type return here]
>>> 

I will note that MacOS is anxious to identify the HID keyboard type and that the "Keyboard Setup Assistant" dialog is up, but it may have nothing to do with this. I was trying to get past that window doing like time.sleep(2); kbd.send(Keycode.Z).

[dkirkby]

I just followed the Welcome to CircuitPython instructions for writing your first program on a Metro M4, using the recommended stable 6.0.1 and Mu editor, and it is now broken because time.sleep hangs.

Having a working new user tutorial is important, but that could mean simply downgrading the recommended stable release if there isn't a simple fix to the sleep issue.

[dkirkby]

The most recent working M4 Express download that I could find is 3.1.2 from S3 (since the 5.x series .uf2 files are not available on either github or S3).

[dhalbert]

The earlier builds were not grouped by language. Look under the en_US (or other directory) to find newer builds on S3.

[dhalbert]

@dkirkby Are you trying this in the REPL or in a code.py? In the REPL, it seems to mess up, but try it in a program file. As I noted above, the time.sleep() does seem to finish, but the >>> fails to print.

[dhalbert]

@hathach Could you take a look at #3829 (comment) above? This seems very odd, and seems to depend on the host driver, or maybe the terminal program. We may not be servicing USB properly on the CircuitPython side. #3912 is similar, on Windows 7. I haven't yet tried to replicate on Windows 10.

[dkirkby]

Thanks @dhalbert, I found 5.3.0 on S3 here.

I am following these welcome instructions which have you enter the code in the Mu editor then save.

In my debugging, I later opened the serial connection but that did not change the problem (but did enable me to isolate time.sleep as the problem).

I am using the latest v.3.10.0 bootloader on a Mac, in case that's relevant.

[dhalbert]

@dkirkby Are you trying the blink example, saved as code.py? Does on-board LED blink?

[dkirkby]

I will be walking 25 students through their first CircuitPython program via zoom on Monday, so just looking for a working recipe now :-)

3.1.2 (which is what the board shipped with) seems to work fine.

6.0.1 (the current recommend stable version) hangs in time.sleep.

5.3.0 (mentioned in #3912 as working) hangs (with the RGB led solid blue) when I drag the .uf2 file to the USB drive, and never remounts as CIRCUITPY.

[dkirkby]

Yes, the blink example, saved as code.py. The code hangs at the first time.sleep, so with the D13 LED on:

import board
import digitalio
import time
 
led = digitalio.DigitalInOut(board.D13)
led.direction = digitalio.Direction.OUTPUT
 
while True:
    led.value = True
    time.sleep(0.5) #### CODE HANGS HERE WITH 6.0.1
    led.value = False
    time.sleep(0.5)

If I replace time.sleep with a busy loop (for i in range(20000): y = math.sin(0.1)) it works as expected.

[dhalbert]

What version of MacOS are you using, and are all the students using the same?

[dkirkby]

I am using OS X 10.15.6 and the students are likely using 25 different platforms :-)

Thank you for following up on this @dhalbert!

(after manually unplugging and inserting the USB cable, my 5.3.0 install seems ok)

[dhalbert]

I will try to replicate this. Here is 5.3.1 (note it appears above the earliest 6.0.0 releases, due to chronology): https://adafruit-circuit-python.s3.amazonaws.com/bin/metro_m4_express/en_US/adafruit-circuitpython-metro_m4_express-en_US-5.3.1.uf2

[dkirkby]

Dropping 5.3.1 onto the bootloader works as expected (i.e. with CIRCUITPY automounted after a short delay), thanks! Was that a known issue with 5.3.0?

[dhalbert]

Dropping 5.3.1 onto the bootloader works as expected (i.e. with CIRCUITPY automounted after a short delay), thanks! Was that a known issue with 5.3.0?

I did see that once, but power-cycling the board made it possible to load 5.3.0. There is no change between 5.3.0 and 5.3.1 that would have fixed that. It may be some MacOS idiosyncrasy. I am testing on a Big Sur machine (that's all I've got).

[dhalbert]

Closing in favor of #3918 and #3919.