Absent tests for machine.lightsleep/deep sleep

[Josverl]

I was working in a small project over the weekend where power consumption mattered.
Using an ESP32-C3 , with a custom fw.built I was having problems with waking on an interrupt.
To try to dissect the problem, I went looking for a MicroPython /test that validated the correct working of either method.

To my surprise I found none. That seems to be an omission that should be addressed, also given the substantial number of questions and issues raised on these topics.

Is there a rationale for this?
Is it too complex to handle the usb events in bash ? Or that special wiring may be needed to test this?

[jonnor]

Hardware tests are always a bit more complicated than pure software ones. And the test coverage is generally worse in hardware-related areas of MicroPython. Some basic tests around this would probably be very welcomed :) With the octoprobe stuffs we should have a decent way to run it?

[jonnor]

A typical thing that might be testable without much external hardware is sleep/deepsleep -> timer wakeup. Other things like wakeup on external GPIO would naturally require some external IO capabilities, so more complicated. We do have some tests that use two targets, notably Bluetooth I think - that could be a way to do those kind of tests.

[Josverl]

I've not looked in detail into the "wiring" options, but that should allow at least some test.
Hopefully that should help prevent regressions

[shariltumin]

I don't know if these are useful to you. If you're interested, take a look at https://github.com/shariltumin/wake_on_pin-esp32_sleep-micropython

[Josverl]

Thanks for sharing @shariltumin , definitely useful.

Both your tests require a person to press a wake-up button, correct?

[shariltumin]

Yes, we need a way to trigger the wake-on pin by pulling it low. Any kind of switch, whether mechanical or electric, that pulls Pin4 low, will trigger the wake-on-pin interrupt.

While a person could press a switch, I have in mind an automatic, event-based switch system.

[KnorkFox]

Does soft touch-pins work after deep sleep? I wish, i could wake up the computer with my finger on a certain pin.

[shariltumin]

The ESP32-C3 does not have a touch sensor on its pins, so the esp32.wake_on_touch() function is not supported. However, the ESP32 does support esp32.wake_on_touch(). I have not tested the ESP32-S3 or ESP32-S2, but I think the touch sensor is supported on those as well.

The test scripts "deepsleep_wakeontouch.py" and "lightsleep_wakeontouch.py" can be found at https://github.com/shariltumin/wake_on_pin-esp32_sleep-micropython/tree/main/tests

[Josverl]

we need a way to trigger the wake-on pin by pulling it low. Any kind of switch, whether mechanical or electric, that pulls Pin4 low, will trigger the wake-on-pin interrupt.
While a person could press a switch, I have in mind an automatic, event-based switch system.

Lacking a stackable HHIL Hardware+Human in the loop solution

Im working on a test that tries to do this with a simple wire from pin-X to Pin-wake (work in progress)
next step up would be Octoprobe.

@hmaerki I assume Octoprobe could do this with the proper wiring ?

[Josverl]

With the octoprobe stuff we should have a decent way to run it?

I'd start by just being able to run it with a device attached, then octoprobe could bring that to CI level.

[hmaerki]

I created a issue in octoprobe: octoprobe/testbed_micropython#77.

@shariltumin: You provided C code https://github.com/shariltumin/wake_on_pin-esp32_sleep-micropython/blob/main/esp32/modmachine.c which I preferably not use for my proposal (just to make things simpler). Which of the machine.lightsleep/deep sleep functionality may be tested with micropython 1.26.1?

[Josverl]

@hmaerki

Also have a look at : Josverl#26

Caution

I have not yet validated these on hardware

[shariltumin]

It is for "deep_sleep_wakeon.py" only. It is important for S2 and S3 to have hold set to True:

wake_pin = Pin(4, mode=Pin.IN, pull=Pin.PULL_UP, hold=True)

The /dev/ttyUSBx devices behave differently than the /dev/ttyACMx. The /dev/ttyUSBx do not disconnect the REPL serial connection. The /dev/ttyACMx do disconnect, but need to be awokean; otherwise "no device found" error will occur.

The C patches are for "light_sleep_wakeon.py". These patches introduce 'IRQ_LOW_LEVEL' Pin attribute so that I can have wake-on-pin interrupt for lightsleep too. I have not tried this on S2 and S3 yet.

The "deepsleep_wakeontouch.py" and "lightsleep_wakeontouch.py" only work on ESP32.

[shariltumin]

The REPL disconnects at deepsleep or lightsleep because the chip resets or powers down parts of the USB peripheral. This makes debugging and viewing output difficult.

It's not perfect, but using mpremote run produces a reasonable run log before crashing.

$ mpr a0 run deep_sleep_wakeon.py
Woke up from deep sleep
Going to deep sleep. Press button on GPIO4 to wake.
Traceback (most recent call last):
...

and

$ mpr a0 run light_sleep_wakeon.py
Going to light sleep
Woke up
Going to light sleep
Woke up
Going to light sleep
Traceback (most recent call last):
...

[Josverl]

the chip resets or powers down parts of the USB peripheral. This makes debugging and viewing output difficult

I think the only portable approach is to save state on the device - either in NVRAM, or better yet in a state file on the vfs.
I am using that approach as wel in micropython-stubber , where some of the low-memory devices need to reboot multiple times in order to finish a run.
It is a bit finnicky - but not rocket science.
measuring timing will be difficult using just mpremote - but using octoprobe it should be possible to create a scope trace of an GPIO output of the DUT for that reason. Or even add an INA3221 or similar to measure current. ( but lets start simple )