ESP32 deep sleep does not wake up: timer, GPIO and RTC fixes

The timer wake-up value is in microseconds, and GPIO wake-up works only on RTC-capable pins. A wrong unit or a wrong pin is the usual cause.

What the message means

In deep sleep the main CPU is off and only the RTC part runs. Wake sources must be set before esp_deep_sleep_start(), and the chip restarts from the beginning of setup() when it wakes.

Fix it in this order

Set the timer with esp_sleep_enable_timer_wakeup(seconds * 1000000ULL). Use 64-bit math; a plain int overflows.
For a pin wake-up use an RTC GPIO such as GPIO 0, 2, 4, 12 to 15, 25 to 27 or 32 to 39 on the classic ESP32, with ext0 or ext1.
Give the wake pin a defined level with an external pull resistor, because internal pulls may be off in sleep.
Do not use GPIO 6 to 11. They are tied to the flash.
Put all code in setup(). The program restarts after waking, so loop() state is lost unless stored in RTC memory.
Measure the board current. A dev board with a USB chip and LED still draws a lot in sleep.

Why it happens

The ESP32 wakes from deep sleep only through the sources you enabled before sleeping, such as a timer, an RTC-capable GPIO or a touch pad. Only RTC GPIOs can be used for external wake-up, and the pin state must be held correctly.

Enable the source before calling esp_deep_sleep_start(), use an RTC-capable pin for ext0 or ext1, and make sure the pin is not left floating. After wake-up the sketch restarts from setup().

If you see this, do this

You see	Do this
Never wakes	Check units and the wake pin type.
Wakes at once	Floating wake pin. Add a pull resistor.

ESP32 brownout, ESP32 pinout.

Last reviewed: November 2026. These are the usual causes and the order that finds them fastest. Test on your own board; clones and cables differ.

Why this happens

In deep sleep the main CPU, most RAM and the Wi-Fi radio are off. Only the low-power RTC domain keeps running, and the chip leaves sleep only through a wake-up source that was enabled before sleeping. After wake-up the program starts again from the beginning, as after a reset, so setup() runs and ordinary variables are lost.

The timer takes a value in microseconds. A plain 32-bit number overflows quickly: one hour is 3,600,000,000 microseconds, which is more than a signed 32-bit integer can hold (2,147,483,647). The result is a short or odd sleep time. Pin wake-up is limited to RTC-capable pins, and a floating pin can wake the chip immediately or never.

How to confirm the cause

Print the wake-up cause at the start of setup(). It tells you whether the chip woke from the timer, a pin or a reset.
Print the sleep time as a 64-bit number before sleeping and compare it with your expectation.
Check the pin number against the RTC pin list of your chip. Other pins cannot wake it.
Measure the wake pin with a meter during sleep; it should sit at a defined level.
Measure the board current in sleep. A development board with a USB chip and LED draws much more than the chip alone.

Worked example

Waking every 10 seconds and counting the boots in RTC memory:

RTC_DATA_ATTR int bootCount = 0;

void setup() {
  Serial.begin(115200);
  bootCount++;
  Serial.printf("Boot %d, cause %d\n", bootCount,
                (int)esp_sleep_get_wakeup_cause());
  esp_sleep_enable_timer_wakeup(10ULL * 1000000ULL);
  esp_deep_sleep_start();
}

void loop() {}

Common mistakes

Using int arithmetic for the sleep time instead of 64-bit values.
Putting code in loop() and expecting it to run after wake-up.
Using a pin that has no RTC function, or one of the flash pins.
Using wake-up calls that belong to another chip type; the ESP32-C3 and the S3 have different wake-up APIs.
Holding a pin that is also needed at boot in the wrong state.

If this did not fix it

A brownout on wake-up, when the radio starts; the board resets repeatedly.
A sleep time that is set correctly but a peripheral that keeps the board powered from the USB adapter.
Code that never reaches the sleep call because an earlier step blocks.