How to Clear Core Dump Partition in ESP32: Fix Panic Loops & Free Flash

The Direct Answer: Surgical vs. Nuclear Erase

If your ESP32 is trapped in a bootloop or you need to reclaim flash space, you need to clear the core dump partition. The fastest, safest way to clear just the core dump partition without wiping your main firmware is to call the esp_core_dump_image_erase() function from within your Arduino/ESP-IDF sketch. If the board is completely bricked and won't boot far enough to run your code, the fallback is using esptool.py erase_region via the command line to surgically wipe the partition offset, or the "nuclear" erase_flash command to wipe the entire chip.

Core dumps are invaluable for debugging fatal crashes, but when the dedicated flash partition fills up or gets corrupted, the ESP32 can hang during the panic handler, causing an endless reboot cycle. Below is the exact bench-tested procedure to clear it, recover your board, and prevent it from happening again.

The Exact Errors: Why Your Core Dump Fails or Loops

Before clearing the partition, it helps to recognize the exact serial monitor strings that indicate a core dump failure. When debugging embedded systems, guessing is wasted time. Look for these exact error strings in your serial output:

Hardware Spec Sheet & Pin Mapping

The procedures and code below target the ESP32-WROOM-32 DevKit V1 (30-pin variant) with a 4MB flash module. If you are using an ESP32-S3 or ESP32-C3, the API remains identical, but your strapping pin offsets and default partition tables will differ.

Table 1: Debug & Flash Pin Mapping (ESP32-WROOM-32 DevKit V1)

Function	GPIO Pin	Notes for Flashing / Debugging
UART0 TX	GPIO 1	Connects to USB-UART bridge RX. Used for serial monitor output.
UART0 RX	GPIO 3	Connects to USB-UART bridge TX.
Chip Enable (EN)	EN	Pulled HIGH via 10kΩ resistor. Auto-reset circuit caps this for flashing.
Boot Mode Select	GPIO 0	Must be pulled LOW during reset to enter UART bootloader for esptool.py.
Status LED	GPIO 2	Built-in blue LED on most DevKit V1 boards. Used in code to verify boot.

Method 1: Programmatic Erase (Arduino/ESP-IDF Code)

This is the surgical approach. By including the ESP-IDF core dump headers in your Arduino sketch, you can check for a corrupted dump on boot and erase it before it causes a secondary panic. This code targets the ESP32-WROOM-32 and includes explicit pin definitions and error handling.

#include <Arduino.h>
#include "esp_core_dump.h"
#include "esp_partition.h"

// Explicit pin definitions for the DevKit V1
#define STATUS_LED_PIN 2
#define SERIAL_BAUD 115200

void setup() {
  Serial.begin(SERIAL_BAUD);
  pinMode(STATUS_LED_PIN, OUTPUT);
  
  // Brief delay to allow serial monitor to attach
  delay(1000);
  Serial.println("\n--- ESP32 Core Dump Management ---");

  // Step 1: Check if a core dump image exists in the flash partition
  if (esp_core_dump_image_check()) {
    Serial.println("[INFO] Core dump image found in flash partition.");
    
    // Optional: You could extract or send it to a server here before erasing.
    
    // Step 2: Erase the core dump partition
    Serial.println("[ACTION] Erasing core dump partition...");
    esp_err_t err = esp_core_dump_image_erase();
    
    if (err == ESP_OK) {
      Serial.println("[SUCCESS] Core dump partition cleared successfully.");
      // Blink LED rapidly to indicate success
      for(int i=0; i<5; i++) {
        digitalWrite(STATUS_LED_PIN, HIGH);
        delay(100);
        digitalWrite(STATUS_LED_PIN, LOW);
        delay(100);
      }
    } else {
      Serial.printf("[ERROR] Failed to erase core dump. ESP_ERR code: %d\n", err);
      // Solid LED on to indicate error state
      digitalWrite(STATUS_LED_PIN, HIGH);
    }
  } else {
    Serial.println("[INFO] No core dump image found. Partition is clean.");
  }

  Serial.println("[BOOT] Proceeding to main application loop.");
}

void loop() {
  // Main application logic goes here
  // Intentionally left clean to prevent further panics during recovery
  delay(1000);
}

Method 2: CLI Region Erase (esptool.py)

If your ESP32 is hard-faulting before setup() can execute, you must clear the partition from your PC. While esptool.py erase_flash wipes everything (firmware, SPIFFS, NVS, and coredump), you can surgically erase just the coredump region if you know the offset.

On a standard 4MB ESP32 using the default_4MB.csv partition table, the coredump partition is typically 64KB (0x10000) located at offset 0x3F0000.

Troubleshooting: First 3 Things to Check When It Fails

If the partition refuses to clear or immediately corrupts again, check these three bench-level culprits:

1. Partition Table CSV Mismatch: The Arduino IDE or PlatformIO might be compiling against a custom partition table, but the physical flash still holds the default one. If your code thinks the coredump is at 0x3F0000 but the flash has it at 0x3E0000, your erase commands will hit empty space or NVS. Always verify by running esptool.py read_flash 0x8000 0xC00 partition_table.bin and parsing it.
2. Flash Encryption is Enabled: If you have enabled hardware flash encryption in menuconfig (or via the Arduino IDE Tools menu), raw esptool.py writes to specific regions will fail or result in garbage data because the bootloader expects encrypted payloads. You must disable encryption or use the espsecure.py tool to encrypt the dummy payload before writing.
3. Secondary Brownout During Dump: Writing to flash spikes the current draw. If your USB cable is low-quality or your PC's USB port is current-limited, the voltage drops below 2.7V during the core dump write. This causes a secondary brownout reset, corrupting the partition header mid-write. Use a high-quality, short USB-C data cable and a powered USB hub.

How to Extend or Simplify the Build

To Simplify: If you are shipping a product and flash space is at a premium, disable core dumps entirely. In the ESP-IDF menuconfig, navigate to Component config → Core dump and set Data destination to CONFIG_ESP_COREDUMP_ENABLE_TO_NONE. In Arduino IDE, this requires modifying the esp32 core's sdkconfig or using a custom partition table that omits the coredump row entirely.

To Extend: Route the dump to UART instead of flash by setting CONFIG_ESP_COREDUMP_ENABLE_TO_UART. This prevents flash wear, avoids partition-full bootloops, and allows you to capture the base64-encoded dump directly from your serial terminal into a file for offline analysis with espcoredump.py.

FAQ: Clearing ESP32 Core Dumps

How do I know if my ESP32 partition table actually has a core dump section?

Open the partitions.csv file in your project directory (or the default one located in the ESP32 hardware package folder). Look for a row where the Type is data and the SubType is coredump. A standard entry looks like this: coredump, data, coredump, 0x3F0000, 64K,. If this row is missing, the ESP-IDF panic handler has nowhere to write the data, and it will default to dropping it or failing silently depending on your configuration.

Can I clear the core dump partition over-the-air (OTA) without a USB connection?

Yes, but with a caveat. If the device is still running its main loop and hasn't crashed, you can deploy the programmatic erase code (Method 1) via an OTA update. Once the new firmware boots, it will clear the partition. However, if the device is already stuck in a panic bootloop, the WiFi stack never initializes, making OTA impossible. You must break the bootloop physically via UART (Method 2) before OTA can resume.

Why does my ESP32 keep rebooting before the core dump finishes writing?

This is almost always caused by the Task Watchdog Timer (TWDT) or a power brownout. Writing 64KB to SPI flash takes time. If the panic occurred in an ISR (Interrupt Service Routine) or a high-priority task that starved the IDLE task, the watchdog might trigger a secondary reset while the flash write is still in progress. To fix this, ensure your coredump partition is large enough to write quickly, and verify your power supply can handle the 350mA+ peak current spikes required during SPI flash write operations.