ESP32-C3 crashes/doesn't wake from lightsleep timeout with wifi involved

[kmm]

I'm trying to add light sleep to a polling loop for a wifi sensor but there appears to be some issue with the device either crashing or just not waking up from sleep after a seemingly random number of packets.

A stripped down version of my loop that I've been using as a test case is just this:

while True:
    wlan.send_udp({"time":tw.gmt_unix()}) # just send a UNIX timestamp
    utime.sleep(1) # this seems to make it take longer to crash (10s of packets get sent rather than 3 or 4), but it still does eventually
    machine.lightsleep(9000) # light sleep 9 sec

wlan.send_udp just wraps sock.sendto, encoding the object passed to it in JSON and then sending out the message over UDP. The socket options are (socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP).

Aside from the device stopping sending packets and apparently crashing, the interval itself is not that consistent - sometimes it will send two packets in quick sequence, with an interval much shorter than the lightsleep timeout (looks like the previous one has been buffered).

My suspicion is that there's an underlying RTOS background task involving the wifi send that's not completed before it goes to sleep, and this is causing it to sometimes buffer packets until next wake, and sometimes just crash due to an inconsistent wifi state. The board I'm using has 2 USB serial, micropython REPL is using the built in USB serial endpoint on the C3 and the other is connected to the C3 UART; I've looked at what's coming off the secondary (UART) one during the crash since it does print boot messages to this port, and I don't see any messages indicating a failure/exception at a level below python. I've also instrumented this loop with a LED blink, and the LED stops blinking with the packets ending, indicating that the device is either crashing or never waking up.

The micropython version string is:
MicroPython v1.19.1 on 2022-06-18; ESP32C3 module with ESP32C3

So with that context I have a few questions:

• Anyone seen this before? I've searched around and not found really anything applicable. C3 is more or less an entirely different platform from mainline ESP32, being RISCV and single core.
• Anyone have a workaround? Adding a utime.sleep does seem to affect the problem but not solve it.
• Is there a way to poll the wifi to determine if it's actually done doing stuff and safe to go into sleep mode? Looking at the API docs this level of introspection doesn't seem to be available from python (not sure if this is even available from native code since wifi is pretty abstracted on these devices, but I haven't dug into the C API).
• Is this is a known issue that reflashing to a specific version may solve?

Addendum:
I've had a dev board sitting on my desk running the test code for the last day or so and while working on my event collector noticed that it is actually coming back occasionally and sending some telemetry packets before going dormant again for up to several hours. Perhaps a timer overflow kicks it? I'm not currently logging these messages to my database and they just appear as rejects in my console log so I can't easily query them to see if there's a pattern to the gaps, but it's a bit more information.

Anyway, it appears this is more of a "not coming out of sleep on time" issue rather than a crash, which at least explains why I didn't see any exception or reboot messages.

[karfas]

I suspect the forced lightsleep() might do something to your WLAN connection. The ESP WIFI will most likely need to do something to maintain the connection to your AP. WIFI disconnects might be hidden by the automatic reconnect built into micropython (which I consider as a bug on it's own).

Maybe you will get better results when you allow the RTOS/WIFI to control lightsleep using the WIFI power save options (see e.g. PR #8993 or #6774 - you will need to merge them yourself + build micropython, as these patches aren't merged yet).

[kmm]

Pretty much the sort of thing I was thinking. I don't really want to be dependent on a custom build so I've set a watch on #8993 and for now worked around it by manually tearing down the wifi connection before calling lightsleep and then restarting it on wakeup. If/when 8993 is merged into mainline I'll revisit this.

I had seen mentioned on a random blog that lightsleep used a background "DTIM beacon" mechanism (presumably with periodic implicit wakes) to keep the connection alive, but this appears to not be the case. Just noting that for anyone that might find this in the future and have gotten that impression. Might be true on the dual core ESP32 but evidently not on the single core ESP32-C3.