ESP-WROOM-32, v1.19.1, ^C doesn't break lightsleep

[kebwi]

I'm not sure if this is board-specific or OS-specific, but I just installed 1.19.1 on an ESP-WROOM-32 and from the REPL, I can't break out of lightsleep with a ^C, which has always worked on D1 Minis (and I think ESP01s and PyBoards except that I can't recall from so long ago).

Should lightsleep be breakable in my desired fashion, something akin to a ^C from the keyboard? It always worked before. If not, what is the recommended way to get out of lightsleep without hard-reseting from the on-device hardware button? Even ^D doesn't work. It takes a physical button press to recover control of the device. Surely there is a way to do this, right? It's only "light" sleep after all.

Thanks!

[karfas]

The ESP-IDF defines the wakeup sources (see https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html).
There is a method to wakeup the device with UART activity - from the link above:

The UART peripheral contains a feature which allows waking up the chip from Light-sleep when a certain number of positive edges on RX pin are seen. This number of positive edges can be set using uart_set_wakeup_threshold()

A quick grep over the micropython sources does not find uart_set_wakeup_threshold(); this would also not immediate send the ^C to the python interpreter (as noted in the ESP-IDF documentation). The ESP8266 port might behave otherwise (I have no experience with it and I don't care about it).

I seriously doubt this ever worked on ESP32.

[kebwi]

Thank you very much. I read the same section about UART-waking you indicated, but it isn't clear how to use it from Micropython. I also see a reference to "esp_sleep_enable_wifi_wakeup" on that same webpage, but there is no indication of how to use it, much less from Micropython.

[karfas]

I'm pretty sure that there doesn't exist a way (from micropthon) to configure the ESP32 so UART or WIFI activity cause a wakeup from light sleep. Regarding WIFI, the open PR #8993 reduces power when WIFI is active (at cost of latency, I think). #6774 contains a similar function.

I really have no idea why it requires years for some ESP32 related PRs to merge (even when there are only minor changes in interface and behavior).