Lightsleep failing on some boards and a question about the WIFI firmware.

[anglerfish27]

Hello brilliant minds,
I have been experimenting with some different variants of the ESP32 which I'm new too. I mostly have used RP2040s in the past.
I purchased a book for Micropython on the ESP32. The book describes the MCU to purchase which appears to be a very old or as some have called it the "original" ESP32. The MCU first up is the Adafruit HUZZAH 32 feather with 4MB Flash (per the bottom of the board).
The silver top of the chip says: ESP32-WROOM-32E.

Of the boards tested, this was the only one the lightsleep example worked as expected. I could re-run it over and over in Thonny (and other IDEs) and there were no issues.

I decided I wanted to learn on a more "modern" board that I could use later for projects.
I picked up an Espressif ESP32-S3 DevKitC-1 N8R8 from an official vendor. This MCU of course looked nothing like the other one I had it was way bigger in size with 22 pins on each side. Silver chip says ESP32-S3-WROOM-1

On this board the light sleep example would work the first time. If you tried to re-run it again it would crash the IDE forcing you to have to pull the plug and plugging in back in. Sometimes it would start to work on the 2nd run but it would die at any given point and also run really slow.

I then tested the Arduino ESP32NANO. This one completely crashed even on the first run, it got partially through and then crashed.

I tried with an Unexpected Maker ProS3 and it would only run once, if I tried to rerun it it would crash. Everytime.

All chips were tested with the stable release of MP and also with the latest build available at the time (a few days ago). Results were the same.

Is there a different way to implement this code on newer ESP32s? Since it only seemed to work on the really old board.

from machine import lightsleep
from time import sleep
for i in range(10):
    print("starting sleep",i)
    lightsleep(1000)
    print("back from sleep",i)

interestingly. a deep sleep version that saves the value of 'i' to the RTC memory worked on all the versions. The code is a bit different and I'm more interested in lightsleep.

Thoughts?? I was going to reach out on Discord and see if the Unexpected Maker can chime in on his boards.

Lastly, is there a way for me to check what the Wifi Firmware version is and how to upgrade it? I found an a step by step from Adafruit for circuitpython but I dont want to load CP just for that purpose. Surely it can be done in MP. Or is the latest and greatest firmware part of the Micropython build you install? Sorry I'm new :(

Thanks in advance.

[davefes]

On this board the light sleep example would work the first time. If you tried to re-run it again it would crash the IDE forcing you to have to pull the plug and plugging in back in. Sometimes it would start to work on the 2nd run but it would die at any given point and also run really slow.

A long-shot ... similar to the issues I was having on a PICO W until the latest nightly build sorted it. I have been using light and deepsleep on the ESP32-WROOM-32U for a couple of years now without any issues.

One test that seems to provide insight is to use a simple program:

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)

and either monitor the supply current or flash an "off-board" LED when it is NOT connected to rshell or Thonny.

Your test program should work as well, but I find that when you call deepsleep and maybe lightsleep the print statement does not get executed. So, I use a short sleep() after print statements.

[shariltumin]

I assumed you were using a Windows PC. Can you try running your test script directly from a terminal program such as PuTTY?

I think the problem is with Thonny, the connection got disconnected while the board went to lightsleep().

This is what I got when I tried to run the test script from Thonny on my Linux PC:

>>> %Run -c $EDITOR_CONTENT
waiting 2 seconds for a CTRL-C
going to lightsleep for 2 seconds
waiting 2 seconds for a CTRL-C
going to lightsleep for 2 seconds

waiting 2 seconds for a CTRL-C
going to lightsleep for 2 seconds
PROBLEM IN THONNY'S BACK-END: Exception while handling 'Run' (ConnectionError: device reports readiness to read but returned no data (device disconnected or multiple access on port?)).
See Thonny's backend.log for more info.
You may need to press "Stop/Restart" or hard-reset your MicroPython device and try again.


Process ended with exit code 1.

Unable to connect to /dev/ttyACM0: [Errno 2] could not open port /dev/ttyACM0: [Errno 2] No such file or directory: '/dev/ttyACM0'

Process ended with exit code 1.

I have no problem while running your test program using a terminal program, for example:

$ tio /dev/ttyACM0
>>> 
paste mode; Ctrl-C to cancel, Ctrl-D to finish
=== from machine import lightsleep
=== from time import sleep
=== for i in range(10):
===     print("starting sleep",i)
===     lightsleep(1000)
===     print("back from sleep",i)
=== 
starting sleep 0
back from sleep 6
starting sleep 7
back from sleep 7
starting sleep 8
>>> 

However, some of the output lines were missing.

[anglerfish27]

No I am using a Macbook pro laptop. I will try running it from a terminal session and on a local Raspberry Pi 4b I have as well as multiple IDEs again. Like on some chips such as the Unexpected Maker it run fine once, but the second time to you try to run it that's when it bombs out. Keep in mind though that this crashes VSCODE for me, Mu, and Arduino's cheapo IDE as well. Its not tied to "just Thonny".

If I recall I did an ls /dev | grep tty after one of the failures and the device was gone. I have double check and confirm that may not be accurate.

@shariltumin I have seen that missing output as well not as bad as your case but where it starts a new line when it should not or skips a number that kind of thing.

I will work on this tomorrow and report back. Thanks again!

[shariltumin]

I've got some ESP32-S3 DevKit N16R8 (16MB Flash, 8MB PSRAM) boards. This board has 2 USB ports, one marked COM and the other marked USB.

Now that I have built my own custom firmwares for all my boards. One firmware (A) has REPL on USB-CDC. The other firmware (B) I disable USB altogether and has REPL on UART.

Running your test in a loop on firmware A, I can see that lightsleep() disconnects and reconnects the board from the terminal connection.

back from sleep 6
starting sleep 
[tio 14:40:19] Disconnected
[tio 14:40:25] Connected
starting sleep 8
 8
starting sleepback from sleep 9
starting sleepback from sleep 0
starting sleepback from sleep 1
starting sleepback from sleep 2
starting sleepback from sleep 3
starting sleepback from sleep 4
starting sleepback from sleep 5
starting sleepback from sleep 6
starting sleep 7back from sleep 7
starting sleep 8
 8
starting sleepback from sleep 9
starting sleep
[tio 14:41:49] Disconnected
[tio 14:41:55] Connected
starting sleep 1
 1
starting sleep 2

[tio 14:42:04] Disconnected
[tio 14:42:10] Connected
starting sleep 3

I have no issue with firmware-B

starting sleep 0
D (2023651) sleep: RTC_PERIPH: AUTO(OFF)
back from sleep 0
starting sleep 1
D (2025651) sleep: RTC_PERIPH: AUTO(OFF)
back from sleep 1
starting sleep 2
D (2027651) sleep: RTC_PERIPH: AUTO(OFF)
...

The debug messages are due to firmware-B being compiled with CONFIG_LOG_DEFAULT_LEVEL_DEBUG=y.

With firmware-A I connect the USB port of the board to my Linux PC. With firmware-B I have to use the COM port.

Interestingly, the dmesg reports a different USB device type for firmware-A and firmware-B.

dmesg for firmware-A:

[ 9345.766097] usb 1-7.4.4: New USB device found, idVendor=303a, idProduct=1001, bcdDevice= 1.01
[ 9345.766112] usb 1-7.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9345.766119] usb 1-7.4.4: Product: USB JTAG/serial debug unit
[ 9345.766124] usb 1-7.4.4: Manufacturer: Espressif
[ 9345.766129] usb 1-7.4.4: SerialNumber: F4:12:FA:CE:C8:F4
[ 9345.781915] cdc_acm 1-7.4.4:1.0: ttyACM0: USB ACM device
[ 9346.940128] usb 1-7.4.4: USB disconnect, device number 23
[ 9347.340322] usb 1-7.4.4: new full-speed USB device number 24 using xhci_hcd
[ 9347.543891] usb 1-7.4.4: New USB device found, idVendor=303a, idProduct=4001, bcdDevice= 1.00
[ 9347.543906] usb 1-7.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 9347.543913] usb 1-7.4.4: Product: Espressif Device
[ 9347.543918] usb 1-7.4.4: Manufacturer: Espressif Systems
[ 9347.543923] usb 1-7.4.4: SerialNumber: 123456
[ 9347.553039] cdc_acm 1-7.4.4:1.0: ttyACM0: USB ACM device

dmesg for firmware-B:

[ 9010.827425] usb 1-7.4.4: New USB device found, idVendor=1a86, idProduct=55d3, bcdDevice= 4.45
[ 9010.827440] usb 1-7.4.4: New USB device strings: Mfr=0, Product=2, SerialNumber=3
[ 9010.827446] usb 1-7.4.4: Product: USB Single Serial
[ 9010.827452] usb 1-7.4.4: SerialNumber: 56E1008631
[ 9010.836235] cdc_acm 1-7.4.4:1.0: ttyACM0: USB ACM device

For now, I am building firmware with "MICROPY_HW_ENABLE_UART_REPL" set to 1 and disabled "USB-REPL" on all boards that support "USB Single Serial".

Perhaps I will try to use the USB for other things in a future project, such as connecting it to a USB camera.

[anglerfish27]

Thanks for the info. It's an very unlikely use case so I'm not going to bugger on about it. I can use and light and deep sleep just fine within normal situations. The thing I found a bit strange is with deepsleep i'm still pulling about 7ma during sleep. I have a soil sensor that I turn on for 5 minutes every hour, the rest of that time its in deepsleep and pulling 7ma according to my power profiler kit. Not sure why but not worth fussing about 7ma on the battery packs I have will last a lifetime!

[davefes]

Has your dev board got a UART to USB converter chip on it? CP2102?