QUERY · ISSUE

esp32.wake_on_ext0 not workingon esp32s2

openby kjm1102opened 2024-06-12updated 2024-09-01

bugdocs

Port, board and/or hardware

esp32 port, waveshare ESP32-S2-Pico

MicroPython version

MicroPython v1.23.0 on 2024-06-02; Generic ESP32S2 module with ESP32S2

Reproduction

import os,time,esp32
from machine import Pin,deepsleep

time.sleep(5)
pb=Pin(0, Pin.IN); esp32.wake_on_ext0(pb,0)
deepsleep(10*1000)

Expected behaviour

Loaded the file as main.py then reset the board. Expected s2 to either deepsleep for 10s or exit deepsleep when I press the button connected to gpio0.

Observed behaviour

The s2 exits deepsleep immediately after entering it. This can be verified with a usb ammeter in series with the usb powering the board. I did not include print commands because having a usb repl active often plays badly with deepsleep.

Additional Information

esp32.wake_on_ext0 works OK with deepsleep on an esp32 v1.23.0 so I figure the instant wakeup on the s2 is down to it being an s2.

Code of Conduct

Yes, I agree

CANDIDATE · ISSUE

S2/S3 RTC_VALID_EXT_PINS definitions

closedby stephanelsmithopened 2022-04-04updated 2022-04-14

port-esp32

Coming around back to this one https://github.com/micropython/micropython/issues/7607

On S2/S3 variants, GPIO0 through GPIO21 are valid RTC pins. In this example, asserting pin 5 should wake.


import esp32
import machine
from machine import Pin
o = Pin(5, Pin.IN, pull=Pin.PULL_DOWN)
esp32.wake_on_ext1(pins = (o,), level = esp32.WAKEUP_ANY_HIGH) #multi-pin

machine.deepsleep(10000)

I have a local fix, working on a pull request...

Assessment

S Sonnet · medium

Both issues concern external wake pin handling on ESP32-S2/S3 variants during deep sleep. Candidate 8489 identifies that RTC_VALID_EXT_PINS definitions for S2/S3 incorrectly exclude GPIO0–GPIO21, which is the likely root cause of the query's symptom. However, the candidate focuses on wake_on_ext1 while the query is about wake_on_ext0, and the symptoms differ: the query sees immediate wakeup (suggesting the pin condition fires immediately or ext0 is misconfigured), while the candidate describes pin validation failures for ext1. The shared root cause (wrong RTC pin definitions for S2/S3) means fixing 8489's underlying issue would likely also fix 15260, but the two issues are not describing the same bug instance — they involve different wake functions and different failure modes.

Suggested action

Link issue 15260 to issue 8489 as related context. If a PR was opened to fix RTC_VALID_EXT_PINS for S2/S3, verify whether it also corrects `wake_on_ext0` behaviour on S2, and close 15260 as resolved if so. Otherwise, keep both open and investigate whether the immediate-wakeup behaviour in 15260 is caused by the same incorrect pin definitions or a separate ext0-specific bug on S2.