Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@meirarmon
Copy link
Contributor

@meirarmon meirarmon commented Jun 17, 2025

Summary

Some boards support waking up from deepsleep via GPIO pins (for instance ESP32C3, ESP32C6), but this is not currently supported by MicroPython. This commit adds support for waking with GPIO in a similar interface to waking with ext0, ext1, touch and ulp. This commit adds documentation for this new function as well.

This is a long standing request, with a lot of chatter online. Over the years there have been several attempts to add this (#15498, #13333 and #9583), but with no success. I also explain below why my approach is better (it is based on the existing PRs, so thanks to @m-cas, @puppet13th and @ondiiik).

Testing

Tested ESP32_GENERIC_C3with:

import machine
import esp32
esp32.wake_on_gpio((machine.Pin(5),machine.Pin(2)), esp32.WAKEUP_ANY_HIGH)
machine.deepsleep()

and checked that the relevant pins wake up from deepsleep.

Trade-offs and Alternatives

The existing PRs mentioned above modify wake_on_ex1, testing if the port is specifically ESP32C3. My solution adds a wake_on_gpio which is a similar interface, and tests for the SOC capabilities.

@meirarmon meirarmon force-pushed the esp32-wake-on-gpio branch 5 times, most recently from c9561f2 to a12c15c Compare June 20, 2025 10:56
@meirarmon meirarmon marked this pull request as ready for review June 20, 2025 11:43
@meirarmon
Copy link
Contributor Author

@dpgeorge as specified in the description, this is a feature request that is very long standing (several years at least). I think that my implementation should satisify your standards, and if it does, I would appreciate serious consideration and merging this for the next release. Thank you for maintaining MicroPython and all of your hard work :-)

@meirarmon
Copy link
Contributor Author

@dpgeorge @jimmo — any blockers left? Happy to iterate or split this into smaller PRs if the size is an issue. Thanks for reviewing!

@meirarmon
Copy link
Contributor Author

@dpgeorge is there any way to oush this? Is there anything that I can do?

@VikingMultimedia
Copy link

Would love to see this merged! I'm stuck with a bunch of C3 and C6 boards laying around that would be significantly more useful with this implemented.

@Zil0
Copy link

Zil0 commented Sep 9, 2025

Same here, been running this PR on some C3 for a while, and it works very well.

@meirarmon
Copy link
Contributor Author

@jimmo maybe you can help push this? As you can see, many people will benefit by merging this

@kastaneda
Copy link

kastaneda commented Oct 18, 2025

Just tested the patch on my ESP32-C3. Works as expected! Many thanks!

My board is small, labelled "ESP32-C3 Super Mini" on back side, no vendor information, and those boards are sold widely on marketplaces. There are 16 legs, and no one of them are connected to the RST, so that feature is really, really needful.

Hopefully this PR will be in the next release!

@Josverl
Copy link
Contributor

Josverl commented Nov 8, 2025

Needed to rebase on top of master in order to build with a recent IDF, but indeed allows to wakeup from multiple Pins fine.

Testing :

  • Used deepsleep() and deepsleep(20_000) + Manual wakeup tests on multiple GPIOs
  • Ran full tests suite using both UART and USB-CDC interfaces.
    • tests/extmod/machine_i2s_rate.py needed adjusting the pin numbers used as the C3 exposes less pins.
      I have opened a separate PR for that.

Note

AFAIKT None of the existing /tests actually test machine.deepsleep() or machine.lightsleep()
It would be a good addition to the PR to at least add a test for machine.lightsleep(10) or similar

@jkorte-dev
Copy link

jkorte-dev commented Nov 10, 2025

Rebase with master needed otherwise it will compile but linking fails.

I did manual testing with esp32c3 and wake up pin 2

esp32.wake_on_gpio((Pin(2),), esp32.WAKEUP_ALL_LOW)
and
esp32.wake_on_gpio((Pin(2),), esp32.WAKEUP_ANY_HIGH)

Is works fine. Thanks a lot!!! You made me happy.

Some remarks:

  • It should be documented, that it works only with gpio pins of the VDD3P3_RTC domain (GPIO 0-5).
  • If you choose a pin outside the range (0-5) it fails where entering deepsleep (machine.deepsleep()). I would expect that the exception occurs when setting wake_on_gpio(), but the exception message is clear: "E (66622) sleep: gpio 8 is an invalid deep sleep wakeup IO"
  • You always need to specify a tuple even with only one pin. It's ok, but maybe there is a better way to allow setting only one pin.

I did the same tests with esp32c6 and it also works. Valid wake up pins are: GPIO 0-7

Copy link
Member

@dpgeorge dpgeorge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for adding this feature, and sorry it took a while to get to.

It's a very straightforward extension of the existing wake_on_XXX functions, so it fits in nicely with them (from an API point of view).

Some boards support waking up via GPIO pins, but this is not currently
supported by MicroPython.  This commit adds support for waking with GPIO in
a similar interface to waking with ext0, ext1, touch and ulp.  This commit
adds documentation for this new function as well.

Signed-off-by: Meir Armon <[email protected]>
@dpgeorge
Copy link
Member

If you choose a pin outside the range (0-5) it fails where entering deepsleep (machine.deepsleep()). I would expect that the exception occurs when setting wake_on_gpio()

I don't think it's possible to validate the pins in wake_on_gpio() because the validation criteria is different depending on whether deepsleep() or lightsleep() is used.

You always need to specify a tuple even with only one pin. It's ok, but maybe there is a better way to allow setting only one pin.

That's also how the existing wake_on_ext1() works, you must specify a tuple. That could probably be improved to allow a single pin, or a tuple of pins. But let's leave that for a follow up PR, to improve both those methods (if someone wants to do it).

@dpgeorge dpgeorge merged commit b4ab3a8 into micropython:master Nov 13, 2025
10 checks passed
@meirarmon
Copy link
Contributor Author

meirarmon commented Nov 15, 2025

Thank you!
I will be happy to get to the enhancements that you mention, as soon as I get a chance.
Maybe this enhancement could get merged as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants