Spurious EXT1 wake from deep sleep after reset

[arc12_esp]

I use the RTC GPIO wake on an ESP32-C6, set up like:

Code: Select all

esp_sleep_pd_config(ESP_PD_DOMAIN_RTC_PERIPH, ESP_PD_OPTION_ON);
rtc_gpio_pullup_en(GPIO_CTRL_WAKE);
rtc_gpio_pulldown_dis(GPIO_CTRL_WAKE);
esp_sleep_enable_ext1_wakeup_io(1 << GPIO_CTRL_WAKE, ESP_EXT1_WAKEUP_ANY_LOW);

I also set esp_sleep_enable_timer_wakeup() use esp_deep_sleep_start().

On wake, I check esp_sleep_get_wakeup_cause() and act differently according to the cause.
This works perfectly most of the time, with cause ESP_SLEEP_WAKEUP_EXT1 or ESP_SLEEP_WAKEUP_TIMER being given when the GPIO event or timer occurs.

The problem occurs if a reset (or power-on) occurs. This gives a wakeup cause of 0 (as exected) but immediately after the device is put to sleep with esp_deep_sleep_start(), it wakes up again immediately, with cause = ESP_SLEEP_WAKEUP_EXT1.

It appears that the reset somehow latches an EXT1 interrupt.

I have consulted the ESP-IDF documentation and cannot see an explanation or a fix for this.

Can anyone explain?

[emp_tamarin]

I'm seeing something similar, have you resolved this?

I have an ESP32 C6 DevKitC (clone I think) and only use GPIOs to wake up from deep sleep, no timers (yet):

Code: Select all

rtc_gpio_pullup_dis(GPIO_NUM_3);
rtc_gpio_pulldown_en(GPIO_NUM_3);

rtc_gpio_pulldown_dis(GPIO_NUM_0);
rtc_gpio_pullup_en(GPIO_NUM_0);

esp_sleep_enable_ext1_wakeup_io(UINT64_C(1) << GPIO_NUM_3, ESP_EXT1_WAKEUP_ANY_HIGH);
esp_sleep_enable_ext1_wakeup_io(UINT64_C(1) << GPIO_NUM_0, ESP_EXT1_WAKEUP_ANY_LOW);

esp_deep_sleep_start();

After reset and having called esp_deep_sleep_start this immediately wakes up with esp_sleep_get_wakeup_cause returning ESP_SLEEP_WAKEUP_EXT1 and esp_sleep_get_ext1_wakeup_status returning 1, meaning GPIO_0.

Now if I leave the code as is but also add external pull up and pull down resistors to both GPIOs everything works fine. I was hoping to avoid adding external resistors since they are built in but apparently it's not working 100% as intended?

[boarchuz]

Could you try rtc_hal_ext1_clear_wakeup_status() after configuring the pin?

Or you could always do a full RTC reset (eg. using RTC WDT). That fixes everything.

[emp_tamarin]

Could you try rtc_hal_ext1_clear_wakeup_status() after configuring the pin?

Or you could always do a full RTC reset (eg. using RTC WDT). That fixes everything.

Thanks for the suggestions, unfortunately an rtc_hal_ext1_clear_wakeup_status() call after configuring the pins didn't do anything.

What do you mean by a full RTC reset? Trigger the RTC WDT once from code, set a flag or otherwise detect it happened and then run the actual app code?

[boarchuz]

What do you mean by a full RTC reset?

There are a few different types of "resets", of which only an RTC reset completely restores all registers to default values, equivalent to a power-on. A lot of state can persist over the softer resets, which can cause rare and difficult bugs like the one you see here.

AFAIK the only way to do it in software is using the RTC WDT (configure it for RTC reset on timeout, and set the timeout to 0).