GPIO wakeup from light sleep

[jeffmer]

In doing an all micropython implementation for the esp32 based T-watch 2020 - see #10741 (comment), I hit a problem with lightsleep. Essentially, ideally, the watch should be woken up from light sleep by either a real-time clock, accelerometer or power management interrupt. However, since the real-time clock is active low and is not configurable neither of the EXT1 wakeup modes - ALL LOW or ANY HIGH works.

The esp32 does have a GPIO wakeup facility that only applies to light sleep not deep sleep but this is not available in the current ESP32 port. There is a pull request for GPIO wakeup for the ESP32 C3 - see Issue #9583 (comment)
but this does not apply to other ESP32 types since it replaces the EXT1 wakeup.

Has anyone had the same problem?
Are there ways other than GPIO wakeup of dealing with it?
Lastly, is there any intention to include GPIO wakeup in a future release of the ESP32 port

[davefes]

Yes, it would have saved me putting transistor inverters in several projects to use WAKEUP_ANY_HIGH.

Could the constant not be changed?

[jeffmer]

Actually, having looked at this further and done some more testing, it seems that setting wake_on_gpio modifies how the ISR is called in some way. In fact, I think it would be better to set the wakeup property when setting up the interrupt usingPin.irq. In the current implementation, the Pin.irq implementation supports only IRQ_FALLING and IRQ_RISING and not IRQ_LOW_LEVEL and IRQ_HIGH_LEVEL for some reason. The latter two trigger types are the only two allowed with gpio wakeup which may be where the problem is......

[jeffmer]

The problem with GPIO wakeup is that it only applies to LOW and HIGH LEVEL interrupt triggers and these cause problems with ESP32 micropython in that you get continuous interrupts which do not give the ISR a chance to run and cancel the interrupt. To overcome this, I have implemented a solution which disables interrupts on a Pin immediately the LEVEL interrupt occurs. This leads to the light sleep solution example below:

from machine import Pin,lightsleep,SLEEP
from time import sleep_ms

def isr(p):
    print("Interrupt ",p)

pa = Pin(32, Pin.IN)
pb = Pin(34, Pin.IN)                                                                                                                                                                                                             

pa.irq(isr,Pin.IRQ_LOW_LEVEL,wake=SLEEP)
pb.irq(isr,Pin.IRQ_LOW_LEVEL,wake=SLEEP)

while True:
    print('sleep')
    sleep_ms(500)  # allow print to complete
    lightsleep()
    print('wake')
    sleep_ms(1000) # time to set pins back to high_level 
    pa.enable()
    pb.enable()

Sample trace:

  sleep
  wake
  Interrupt  Pin(32)
  sleep
  wake
  Interrupt  Pin(34)
  sleep
  wake
  Interrupt  Pin(34)
  sleep

This implementation is consistent with the current micropython documentation for machine.irq. It implements IRQ_LOW_LEVEL and IRQ_HIGH_LEVEL which are currently not available in the ESP32 port. However, it does require the new methods Pin.enable() and Pin.disable() which enable and disable interrupts on a GPIO pin. As mentioned above, after a LEVEL interrupt the pin is immediately disabled to prevent continuous interrupts so it must be enabled after the interrupt is serviced to permit the next interrrupt. The behaviour of edge triggered interrupts is as before - with no automatic disable - although the enable and disable methods apply to all interrupts. In addition, the modifications to not affect the ESP32 ext0 and ext1 methods of waking from light and deep sleep.

I would be interested on whether others view this as a sensible solution.

[karfas]

While I am sure your modification does work (I'm using it with the watch currently on my wrist), I am not happy with the concept of using Pin.irq() to configure sleep wakeup sources.

At least on micropython level, a wakeup from light sleep or deep sleep has nothing to do with an IRQ. It has been a bad decision to mix wakeup sources (ext0) in the Pin.irq() call at the first place, I think.

We can't do much regarding the ext0 configuration in Pin.irq() on backward compatibility reasons, but we might discuss the interface to the ESP-IDF function esp_sleep_enable_gpio_wakeup().

In the moment...

We have two different possibilities to configure ext0 wakeup sources:

• Pin.irq()
• esp32.wake_on_ext0()

We have an error in the documentation:

• esp32.wake_on_ext0(pin, level) calls esp_sleep_enable_ext0_wakeup(). Both functions get a boolean for the desired wakeup level, not WAKEUP_ALL_LOW, WAKEUP_ANY_HIGH as in the latest documentation.
  WAKEUP_ALL_LOW, WAKEUP_ANY_HIGH is only relevant for ext1.

I could not find any call to esp_sleep_enable_gpio_wakeup().

To discuss

The ESP-IDF functions for power save are complex and include e.g. functions like esp_sleep_enable_wifi_beacon_wakeup(), different power domains and WIFI power save mode.

Doing some of these things implicit from functions in the Pin class increases complexity.

For esp_sleep_enable_gpio_wakeup(), I would prefer a function similar to the already-existing calls for the deep sleep wakeup sources like

esp32.wake_on_touch(wake)
esp32.wake_on_ulp(wake)
esp32.wake_on_ext0(pin, level)  # only RTC pins. Level is boolean (true=>high, false=>low)
esp32.wake_on_ext1(pins, level) # only RTC pins, WAKEUP_ALL_LOW, WAKEUP_ANY_HIGH 

Further calls to power save related functions should also live in esp32 and should be as low-level as possible, so the user has to fight only the ESP-IDF complexity, not complexity introduced by an additional micropython layer.

Common power-save configurations (e.g. lightsleep while modem-sleep is in effect) can be handled in micropython itself.

[jeffmer]

Thanks for the feedback. In general, the Micropython approach seems to be to, as much as possible, abstract the details of specific architectures in the machine module to enable code portability and where something is specific to a single architecture put it in an architecture module e.g. esp32

I have tried to follow this approach in implementing support for GPIO wakeup and have followed the existing documentation for Pin.irq() which has a wake parameter. The only difference from the documentation was the need to introduce the Pin.enable() and Pin.disable() as described in a previous post. Arguably, these routines would be useful in many architectures.

In my view, GPIO wakeup is the most useful and general of the many esp32 wakeup mechanisms and it is a pity it did not also apply to deepsleep - although, I think it does in some more recent processors?

I don't think there is any issue with backward compatibility as the existing implementation involving ext0 is completely undocumented and you need to look at the code to discover it.

[karfas]

@jeffmer: My comment wasn't exactly about your changes . I just got curious regarding gpio_wakeup and wakeup using ext0 and wanted to write down the results of what I found.

[brianwyld]

I have the same problem : device with multiple buttons (pulled low when pressed) and need to use lightsleep(). My dive into the problem found:

On ESP32, esp32.wake_on_ext1() wakes from lightsleep(), but the fact that only a 'ALL_LOW' option is possible means it doesn't work (have to press all the buttons simultaneously to trigger!). On ESP32S3, I can't get wake_on_ext1() to exit lightsleep() at all...

I added a esp32.wake_on_gpio() method, which uses the gpio_wakeup_enable() and esp_sleep_enable_gpio_wakeup() functions. This works to exit lightsleep() as you say on both esp32 and esp32S3.

[btw putting this function in esp32 module seems like the 'good' place for it to me as its specific to the esp32.]

However, when the IRQ callback (set by Pin.irq()) gets called at the exit of the sleep the pin value is always 1 - and in fact the execution post-sleep blocks until the buttons is released. Reading this thread lets me see this is probably because triggering on level=0 means that the MCU is blocked looping on the IRQ until the button is released - and then the callback is run but the button is now released ie value()=1!

@jeffmer : where did you add the interupt disabling to avoid this problem? Is there a patch available?

I also wonder if the trigger for the irq gets changed by gpio_wakeup_enable() permanently to level detect (from the edge detect trigger I set when configuring the Pin to start with)?

Then, having an 'enable()' and 'disable()' method on Pin seems generic enough to me to be ok (although I would call them enable_irq()/disable_irq() to make the purpose clear)

[jeffmer]

Hi,

Apologies for not replying earlier - I have been travelling. My code to deal with GPIO wakeup can be found at https://github.com/jeffmer/micropython/blob/GPIO_WAKEUP/ports/esp32/machine_pin.c.

I have outlined my rationale for implementing it in machine_pin.c in the above posts - also, it mean't all the changes are in one file.

[xyzzy42]

Also trying to get lightsleep wake on GPIO working.

Here's what I see with current 1.22 preview.

Pin.irq() has a wake argument, but it will be silently ignored unless the trigger of the irq is set to the undocumented values Pin.WAKE_HIGH or Pin.WAKE_LOW. So you can make a call set to set a wake from sleep rising edge irq, and it will produce no error, but it won't work to wake.

If an allowed trigger is used, then an ext0 deep sleep wakeup is configured. The interrupt handler supplied is silently ignored and will not be used. The value used for wake can be either machine.SLEEP or machine.DEEPSLEEP, it makes no difference, you get an ext0 deepsleep wakeup either way.

I tried adding the code to enable lightsleep GPIO wake up for wake=machine.SLEEP. It's necessary to patch machine_sleep_helper() because it disables all wakeup sources. It needs to then enable GPIO wakeups.

Since the handler is ignored when Pin(wake=) is supplied there's no callback. But it does work to wake from lightsleep. It is possible to set an edge-triggered interrupt afterward with another Pin.irq() call, and that handler will work. It will be edge triggered and not go into an IRQ loop. I think there reason this can work, is that if the pin is an RTC pin, then the RTC config register will be set to wake on level while the interrupt, set in the GPIO registers, can be set to edge.

However it doesn't work to call Pin.irq() twice in the opposite order. E.g.

p = machine.Pin(8, machine.Pin.IN)
p.irq(lambda p: print("IRQ"), trigger=machine.Pin.IRQ_RISING, wake=machine.SLEEP)
p.irq(trigger=machine.Pin.WAKE_HIGH, wake=machine.SLEEP)

That will IRQ loop! The problem is that gpio_wakeup_enable(irq, trigger) will internally effectively call gpio_set_intr_type(irq, trigger), making the interrupt level triggered. And level triggered interrupts will loop.

[kjm1102]

When I couldn't get my head around the GPIO wakeup minefield earlier this year I had no choice but to find a way to detect edges using esp32.wake_on_ext0. I ended up setting the level in esp32.wake_on_ext0(pin, level) to not pin() which wakes the esp32 whenever the pin level changes. Since my post wakeup tasks took longer than typical switch contact chatter I didn't even need a debouncer. Apologies if I'm too off topic but the technique seemed vaguely relevant.

[davefes]

What is the current lightsleep situation on ESP32 Generic? Is it edge-triggered or level triggered for WAKEUP_ANY_HIGH? If level triggered how long does it have to stay high?

I am using this firmware:
https://github.com/shariltumin/esp32-cam-micropython-2022/tree/main/X23/esp32-aiThinker
in an ESP32-CAM, which is solar-powered and I want it to lightsleep until triggered. The camera takes too long to init if using deepsleep. Using lightsleep(), ie forever doesn't not work consistently. My hardware/software seem to work for a few hours then intermittently fails days later.

Appreciate any insights.