Partition table failure on ESP32

ESPHome
1

My ESP32 device running ESPHome is failing with a “Partition table failure” after flashing, entering into an infinite loop of boot failures.

My device is an ESP-WROOM-32 development board (https://www.aliexpress.com/item/1005005704190069.html#nav-specification).

I’m using esphome 2025.12.1 on macOS (though I’ve tried with multiple different esphome versions, on macOS and Linux).

I’ve tried to simplify to using a basic ESPHome configuration:

esphome:
  name: sample
  friendly_name: Sample

esp32:
  variant: esp32

logger:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

Here is the output of esphome run:

INFO Successfully compiled program.
esptool v5.1.0
Connected to ESP32 on /dev/cu.usbserial-110:
Chip type:          ESP32-D0WD-V3 (revision v3.1)
Features:           Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency:  40MHz
MAC:                d8:13:2a:43:08:e4

Stub flasher running.
Changing baud rate to 460800...
Changed.

Configuring flash size...
Auto-detected flash size: 4MB
Flash will be erased from 0x00010000 to 0x000d1fff...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Wrote 793648 bytes (524825 compressed) at 0x00010000 in 14.1 seconds (451.4 kbit/s).
Hash of data verified.
SHA digest in image updated.
Wrote 26240 bytes (16491 compressed) at 0x00001000 in 0.8 seconds (262.1 kbit/s).
Hash of data verified.
Wrote 3072 bytes (144 compressed) at 0x00008000 in 0.1 seconds (367.0 kbit/s).
Hash of data verified.
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (612.4 kbit/s).
Hash of data verified.

Hard resetting via RTS pin...
INFO Successfully uploaded program.
INFO Starting log output from /dev/cu.usbserial-110 with baud rate 115200
[11:24:32.624]32: SPI Flash Size : 4MB
[11:24:32.630]I (72) boot: Enabling RNG early entropy source...
[11:24:32.635]E (76) flash_parts: partition 0 invalid magic number 0x200
[11:24:32.638]E (82) boot: Failed to verify partition table
[11:24:32.645]E (86) boot: load partition table error!
[11:24:32.645]ets Jul 29 2019 12:21:46

[11:24:32.651]rst:0x3 (SW_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
[11:24:32.653]configsip: 0, SPIWP:0xee
[11:24:32.659]clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
[11:24:32.662]mode:DIO, clock div:2
[11:24:32.664]load:0x3fff0030,len:6 380
[11:24:32.664]ho 0 tail 12 room 4
[11:24:32.667]load:0x40078000,len:15916
[11:24:32.670]load:0x40080400,len:3860
[11:24:32.672]entry 0x40080630
[11:24:32.678]I (56) boot: ESP-IDF 5.5.1 2nd stage bootloader
[11:24:32.684]I (56) boot: compile time Dec 21 2025 11:20:15
[11:24:32.686]I (56) boot: Multicore bootloader
[11:24:32.689]I (58) boot: chip revision: v3.1
[11:24:32.692]I (61) boot.esp32: SPI Speed      : 40MHz
[11:24:32.695]I (65) boot.esp32: SPI Mode       : DIO
[11:24:32.700]I (68) boot.esp32: SPI Flash Size : 4MB
[11:24:32.703]I (72) boot: Enabling RNG early entropy source...
[11:24:32.709]E (76) flash_parts: partition 0 invalid magic number 0x200
[11:24:32.714]E (82) boot: Failed to verify partition table
[11:24:32.718]E (86) boot: load partition table error!
[11:24:32.721]ets Jul 29 2019 12:21:46

and then it just keeps looping with the same output over and over.

2

I know what docs say, but try with this:

esp32:
  board: esp32dev
3

Thanks for the suggestion. I tried your suggestion but unfortunately no improvement: still an infinite loop of the same output.

4

I expected you tried with usb ,not ota…
Try with

  framework:
    type: esp-idf
5

The log clearly states that the partition table is bad, so I suspect that is the real problem.

Normally the partition table just works. The flashing log also clearly shows that the partition table was washed and the hash matches so it was flashed correctly.

That likely means the partition table it is flashing got corrupted somehow. This big report is a different issue but provides some insight on the likely location of the file.

It appears to be in the space that is typically managed by platformio. This likely means there has been some corruption on your install/machine.

If it were my machine, I would uninstall esphome and platformio and then reinstall esphome (which will reinstall platformio). Make sure you backup your system before doing this if you try it.

1 Like
6

Thanks. I uninstalled esphome and platformio, reinstalled esphome (brew install esphome), and also wiped out what I think are the cache folders for esphome (./.esphome) and platformio (~/.platformio).

When I re-ran esphome run basic.yaml it downloaded a bunch of dependencies and recompiled the project. Still no luck.

I’m including the end of the build log below. I notice there are a few lines such as Info: partition-table.bin not found - skipping – I don’t know if that’s relevant at all.

Building .pioenvs/sample/bootloader.bin
Creating ESP32 image...
Successfully created ESP32 image.
Linking .pioenvs/sample/firmware.elf
                            Memory Type Usage Summary                             
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Memory Type/Section ┃ Used [bytes] ┃ Used [%] ┃ Remain [bytes] ┃ Total [bytes] ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ Flash Code          │       593740 │          │                │               │
│    .text            │       593740 │          │                │               │
│ Flash Data          │       100728 │          │                │               │
│    .rodata          │       100472 │          │                │               │
│    .appdesc         │          256 │          │                │               │
│ IRAM                │        83127 │    63.42 │          47945 │        131072 │
│    .text            │        82099 │    62.64 │                │               │
│    .vectors         │         1028 │     0.78 │                │               │
│ DRAM                │        36816 │    20.37 │         143920 │        180736 │
│    .bss             │        20904 │    11.57 │                │               │
│    .data            │        15912 │      8.8 │                │               │
└─────────────────────┴──────────────┴──────────┴────────────────┴───────────────┘
Total image size: 793507 bytes (.bin may be padded larger)
Note: The reported total sizes may be smaller than those in the technical reference manual due to reserved memory and application configuration. The total flash size available for the application is not included by default, as it cannot be reliably determined due to the presence of other data like the bootloader, partition table, and application partition size.
RAM:   [=         ]  11.2% (used 36816 bytes from 327680 bytes)
Flash: [====      ]  43.2% (used 793251 bytes from 1835008 bytes)
Building .pioenvs/sample/firmware.bin
Creating ESP32 image...
Successfully created ESP32 image.
merge_factory_bin([".pioenvs/sample/firmware.bin"], [".pioenvs/sample/firmware.elf"])
Info: bootloader.bin not found - skipping
Info: partition-table.bin not found - skipping
Info: ota_data_initial.bin not found - skipping
Info: sample.bin not found - skipping
Using FLASH_EXTRA_IMAGES from PlatformIO environment
Merging binaries into /Users/dstebila/Downloads/esphome/.esphome/build/sample/.pioenvs/sample/firmware.factory.bin
Merging binaries with esptool
SHA digest in image updated.
Wrote 0xd1c30 bytes to file '/Users/dstebila/Downloads/esphome/.esphome/build/sample/.pioenvs/sample/firmware.factory.bin', ready to flash to offset 0x0.
Successfully created /Users/dstebila/Downloads/esphome/.esphome/build/sample/.pioenvs/sample/firmware.factory.bin
esp32_copy_ota_bin([".pioenvs/sample/firmware.bin"], [".pioenvs/sample/firmware.elf"])
Copied firmware to /Users/dstebila/Downloads/esphome/.esphome/build/sample/.pioenvs/sample/firmware.ota.bin
=============================================================== [SUCCESS] Took 147.91 seconds ===============================================================
INFO Successfully compiled program.
esptool v5.1.0
Connected to ESP32 on /dev/cu.usbserial-21330:
Chip type:          ESP32-D0WD-V3 (revision v3.1)
Features:           Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency:  40MHz
MAC:                d8:13:2a:43:08:e4

Stub flasher running.
Changing baud rate to 460800...
Changed.

Configuring flash size...
Auto-detected flash size: 4MB
Flash will be erased from 0x00010000 to 0x000d1fff...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Wrote 793648 bytes (524824 compressed) at 0x00010000 in 14.1 seconds (449.4 kbit/s).
Hash of data verified.
SHA digest in image updated.
Wrote 26240 bytes (16487 compressed) at 0x00001000 in 0.8 seconds (256.6 kbit/s).
Hash of data verified.
Wrote 3072 bytes (144 compressed) at 0x00008000 in 0.1 seconds (367.0 kbit/s).
Hash of data verified.
Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (612.1 kbit/s).
Hash of data verified.

Hard resetting via RTS pin...
INFO Successfully uploaded program.
INFO Starting log output from /dev/cu.usbserial-21330 with baud rate 115200
[21:21:19.757]200
[21:21:19.760]E (82) boot: Failed to verify partition table
[21:21:19.764]E (86) boot: load partition table error!
[21:21:19.766]ets Jul 29 2019 12:21:46
7

Erase flash and try again.

8

Can you tell me how to do that or point me to a tutorial for it?

9

Esptool Documentation - ESP32 - — esptool latest documentation

I use pipx to install it, which puts it into its own environment:
pipx install esptool
You can then just run it:
esptool
from the command line

The warning about skipping the partition-table.bin appears to be fine, mine does that too.

10

Or when flashing your device, just pick manual download, save the file as modern or whatever it says for the top option when it completed. Then go here and flash it, it will erase first. You need chrome browser.

https://web.esphome.io/?dashboard_wizard

11

I’ve used esptool erase-flash to erase the flash (see output below). After that I tried esphome run basic.yaml again. It yielded the same partition table errors as before.

> esptool erase-flash
esptool v5.1.0
Connected to ESP32 on /dev/cu.usbserial-213430:
Chip type:          ESP32-D0WD-V3 (revision v3.1)
Features:           Wi-Fi, BT, Dual Core + LP Core, 240MHz, Vref calibration in eFuse, Coding Scheme None
Crystal frequency:  40MHz
MAC:                d8:13:2a:43:08:e4

Stub flasher running.

Flash memory erased successfully in 3.1 seconds.

Hard resetting via RTS pin...
12

What do the following commands show?

esptool flash-id

and

esptool read-flash 0x0000 0x2000 /dev/cu.usbserial-213430
13

Not any difference?

14

Do you have more than one esp32 device?

The logs show the tools flashing the bootloader and the partition table and verifying the hash of the data that was flashed, which seems to indicate it was flashed as expected.

The logs also show that when the bootloader starts up and reads the partition table it is corrupt.

Those two things don’t add up.

Perhaps your esp32 device is defective in some way. I would try a different one to rule that out. I have flashed many different esp devices and I have seen one or two defective ones. So it is possible for them to fail.

Perhaps your system is creating a bad partition table. That doesn’t seem likely, but it is possible. You said you removed all esphome and platformio content, which is the standard way of fixing a corrupt install.

Perhaps the content is getting corrupted after it was flashed. This is the reason to read back the flash after flashing and check the partition table to see if it really is corrupt.

This post has some good information:

Note that some chips/bootloaders expect it to be at 0x8000 while others expect it to be at 0x9000. This might be a clue (if it is flashed at 0x8000 and it is expected at 0x9000, it wouldn’t have the right magic number).

Normally this stuff just works when people are using the normal configs. It frequently fails when people modify the configuration without understanding all the things they need to change.

Perhaps your board isn’t what you think it is.

15

I have a few esp32 devices, all of the same model. I tried with a different device, and it was able to flash successfully. So your theory that the first esp32 device is defective seems plausible. I tried all 4 of my esp32 devices, and of them, 2 were able to be flashed, 1 was the device that spawned this thread (still not flashable), and the 4th wouldn’t even show up in my computer’s list of USB devices. So perhaps my batch is pretty flaky.

Thanks all for the help.

2 Likes
16

If you are happy with the result that 2 out of 4 are working, fine.
But are those 2 failed? You could do some testing out of Esphome, like uploading arduino “hello world” sketch or running
esptool flash-id
multiple times in a row…