ESP32C6 using MicroPython will not WAKE_UP from external signal

I using firmware supplied in XIAO ESP32C6 with MicroPython | Seeed Studio Wiki
The MicroPython website does not have an alternative image.
Could there be additional setup required to get this work or a code change?
Thanks for any suggestions.
SailorMorris


 # MicroPython v1.24.0-preview.407.g197becbdc on 2024-10-09;
"""
Deepsleep is NOT waking up from an external signal.

Function			Purpose
--------			-------
__main__ 			Setup
main				Verify the door_sw is working, init and enter deepsleep
new_mail_notice		Report reset_cause worked in main
"""
from micropython import const
import os
import sys
import time
import machine
from time import sleep, ticks_ms, ticks_diff
from machine import Pin, UART, ADC
from esp32 import wake_on_ext1, WAKEUP_ALL_LOW


LED_PIN = const(15)
WAKE_UP_PIN = const(2)                                             # **********
WAKE_UP_PIN_MASK = const(1 << WAKE_UP_PIN)                         # **********


def new_mail_notice(door_sw):
    vsys = ADC(Pin(0))
    vsys.atten(ADC.ATTN_11DB)                 # 0-3.6volt range
    print(f'VSYS = {vsys.read_uv() * 2 / 1000000:02f} volts')
    print(f'{door_sw.value()=}')


def main():
    global WAKE_UP_PIN, WAKE_UP_PIN_MASK
    door_sw = Pin(WAKE_UP_PIN, Pin.IN, Pin.PULL_UP)               # ***********
    print("OK, operate the switch verify the value changes.")
    for _ in range(20):
        print(f'Mailbox door_sw is {"Closed" if door_sw.value() else "Open"}.')
        sleep(0.5)     
    if machine.reset_cause() == machine.DEEPSLEEP_RESET:
        new_mail_notice(door_sw)   
    # wake_on_ext1([WAKE_UP_PIN_MASK], (WAKEUP_ALL_LOW, ))        # ***********
    # wake_on_ext0(door_sw, WAKEUP_ALL_LOW)                       # ***********
    wake_on_ext1((door_sw,), WAKEUP_ALL_LOW)                      # ***********
    # I've tried all versions of WAKEUP_ALL_x & WAKEUP_ANY_x x=HIGH or LOW
    #    only the WAKEUP_ALL_LOW is accepted by the interperter.
    if door_sw.value():    # default (door_sw=closed=1) to DeepSleep
        print('Going into DeepSleep for maximum of 30 seconds.')
        sleep(1)
        machine.deepsleep(29 * 1000)                              # ***********
    print('Past deepsleep()')
 
    
if __name__ == '__main__':
    print("Entry to __main__")
    led = Pin(LED_PIN, Pin.OUT, value=0)      # light the LED
    start = ticks_ms()
    excpt_log = open('exception.txt', 'w')
    try:
        uart = UART(1, baudrate=115200, tx=Pin(6), rx=Pin(7))
        uart.init(115200, bits=8, parity=None, stop=1)
        os.dupterm(uart, 0)
        main()
        print(f'Runtime = {ticks_diff(ticks_ms(), start)} millisecs.')
    except Exception as e:
        sys.print_exception(e)   # , excpt_log)
    excpt_log.close()
    led.value(1)        # turn the LED OFF (program end)
1 Like

Hi there,

So , AFAIK the GPIO2 is RTC capable and should support deep sleep wake-up. You’re using wake_on_ext1() on on the XIAO ESP32C6 it’s relatively new to python, but it’s not waking from deep sleep via external pin, Hmmm even though your logic seem correct. :+1:

it’s likely the MicroPython BSP doesn’t fully support GPIO wake from deep sleep yet on the ESP32-C6.

If using wake_on_ext1() or wake_on_ext0() does not work despite correct wiring and logic, and only timeout wake works, it confirms the issue is firmware-level.

can you test if ?
If EXT1 doesn’t behave, try wake_on_ext0() instead, which supports a single pin but might be better supported:

from esp32 import wake_on_ext0
wake_on_ext0(pin=door_sw, level=esp32.WAKEUP_ANY_HIGH)  # or WAKEUP_ALL_LOW

you’ll get Warning: If esp32.WAKEUP_ANY_HIGH or constants aren’t defined on the C6 port, that confirms the MicroPython port is incomplete.

try using an external pull-down or pull-up** if needed. Don’t rely solely on internal Pin.PULL_UP during deep sleep — some pins lose their pull config during deepsleep.

Try external 10k pull-up resistor on GPIO2. :v:

Does the Basic Sleep work ?
Test basic deep sleep without any wake source

Just test whether the system goes to deep sleep and reboots normally after timeout:

import machine
machine.deepsleep(5000)

If this works, but GPIO wake doesn’t — then it’s 100% a MicroPython firmware issue, not hardware.

Alternative: Use Arduino firmware instead

The Arduino BSP 3.2.0 for Xiao ESP32C6 has full deep sleep + GPIO wakeup working. I’ve personally tested it (PJ can confirm too :grinning_face_with_smiling_eyes:). :backhand_index_pointing_right: If your project isn’t tied to Python, use Arduino for stable GPIO wake from sleep.

HTH
GL :slight_smile: PJ :v:

Our AI , said this… too

  • The Seeed-provided MicroPython firmware may not fully support all light/deep sleep wake sources yet on the ESP32-C6 — this is likely tied to IDF support for deep sleep IO muxing not being complete in MicroPython for the C6 chip.
  • The C6 port is still in preview/unstable phase, even in v1.24.x-preview.

I think the last version that worked was 1.21…
It looks like 1.25 and 1.26 still don’t work.

I’d suggest using CircuitPython, Arduino (or ESP-IDF) for now.

Hello PJ,

Tried wake_on_ext0 and it didn’t wake on signal.
External pull-up didn’t resolve the issue.
Basic deepsleep with timeout did wake after timeout.
OK, no fix without a firmware update.
I’ll try to port my test to circuit python… then regrettably C++
Thanks for the reply,
SailorMorris

1 Like

Hi there,

Well then , there you have it. :+1: Good work walking it down.

Definitely send an email also to support at seeed to alert them with your findings and tah it’s still needs addressed and when you can expect some update.
They are a lot of staff back from Summer vacation so things should pick up.

HTH
GL :slight_smile: PJ :v:

I saw this morning a preview version of micropython v1.28 is available. Thought I’ve give it a try and see how deepsleep is working.

UART output following deepsleep:
ESP-ROM:esp32c6-20220919
Build:Sep 19 2022
rst:0x5 (SLEEP_WAKEUP),boot:0x1f (SPI_FAST_FLASH_BOOT)
SPIWP:0xee
mode:DIO, clock div:2
load:0x40875730,len:0xdbc
load:0x4086b910,len:0xc34
load:0x4086e610,len:0x2e3c
entry 0x4086b910

I know the C lib API’s work OK but my upython test program doesn’t seem to work.

Would someone please explain what the output above is telling or how I can find a explanation of the output.

Thanks, Morris

Hi there,

So a couple things here,
SO you say its a preview , :face_with_peeking_eye:

ESP32/MicroPython, deep sleep behaves like a reset on wake, so your code needs to expect a fresh boot and check machine.reset_cause() for DEEPSLEEP_RESET. If the C API works but your MicroPython test does not, I would suspect either the preview MicroPython build or the test script logic

What it is saying:

  • rst:0x5 (SLEEP_WAKEUP) means the chip reset because it woke from sleep.
  • boot:0x1f (SPI_FAST_FLASH_BOOT) means it then booted normally from SPI flash. That is expected because on ESP32-class chips, deep sleep is effectively a reset-like wake and the normal boot path runs again unless you use a special wake stub. Espressif’s deep-sleep docs say waking from deep sleep requires ROM/bootloader/app startup again, and MicroPython’s ESP32 docs say after deep sleep execution starts again from the main script, similar to a hard reset.

So the banner itself is not the problem. It is actually evidence that:

  1. the chip did enter deep sleep, and
  2. it did wake up.

The likely issue is higher up, for example:

  • the MicroPython preview build has a deep-sleep regression on ESP32-C6,
  • the test script expects wake behavior that does not match how MicroPython handles deep sleep,
  • or the script is not checking machine.reset_cause() and re-running its init logic correctly after wake. MicroPython documents that wake from deep sleep resumes by restarting the normal boot sequence, and you should detect it with machine.reset_cause() == machine.DEEPSLEEP_RESET

HTH
GL :slight_smile: PJ :v:

As mentioned in the lengthy AI reply above the initial information is flash boot information.

I checked the latest preview and the deep sleep with wake from GPIO (High) or Timer works fine. GPIO (Low) wake seems to (still) suffer from “stuck pin” syndrome :thinking:

Perhaps post your code to determine if there are any potential “issues”?

1 Like