XMC flash chip boot-up failure detected, claims to fix but does not do so (ESPTOOL-1393)

[snuq]

Operating System

Kubuntu 26.04

Esptool Version

5.4.0

Python Version

3.14

Chip Description

ESP32-S3 (QFN56) (revision v0.2)

Device Description

ESP32-S3-N16R8 Development Board CORE Board Type-C
Purchased from AliExpress: https://www.aliexpress.us/item/3256808865544909.html

Hardware Configuration

Nothing attached yet

How is Esptool Run

No IDE, Linux terminal

Full Esptool Command Line that Was Run

esptool --no-stub --baud 460800 write-flash --flash-mode dio 0 ESP32_GENERIC_S3-20260824-v1.29.0.bin

Esptool Output

esptool v5.4.0
Connected to ESP32-S3 on /dev/ttyACM0:
Chip type:          ESP32-S3 (QFN56) (revision v0.2)
Features:           Wi-Fi, BT 5 (LE), Dual Core + LP Core, 240MHz, Embedded PSRAM 8MB (AP_3v3)
Crystal frequency:  40MHz
USB mode:           USB-Serial/JTAG
MAC:                44:bd:8d:6a:c1:8c

Changing baud rate to 460800...
Changed.

Enabling default SPI flash mode...
WARNING: XMC flash chip boot-up failure detected! Running XMC25QHxxC startup flow.
WARNING: XMC flash boot-up fix failed.
XMC flash chip boot-up fix successful!
Configuring flash size...
NOTE: In case of failure, please set a specific flash size.
SHA digest in image updated.
Flash will be erased from 0x00000000 to 0x001b3fff...
Wrote 1783296 bytes at 0x00000000 in 23.4 seconds (610.4 kbit/s).
Hash of data verified.

Hard resetting via RTS pin...

More Information

The flash appears to complete, but board is stuck in bootloop with the output:

SPIWP:0xee
mode:DIO, clock div:1
load:0x3fce2820,len:0xeac
load:0x403c8700,len:0xc28
load:0x403cb700,len:0x2ff8
entry 0x403c88ac
E (31) bootloader_flash: XMC flash startup fail
E (31) boot.esp32s3: failed when running XMC startup flow, reboot!
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0x3 (RTC_SW_SYS_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)

additionally, "esptool flash-id" shows:

WARNING: XMC flash chip boot-up failure detected! Running XMC25QHxxC startup flow.
WARNING: XMC flash boot-up fix failed.
XMC flash chip boot-up fix successful!
Flash Memory Information:
=========================
Manufacturer: 20
Device: 7018
Detected flash size: 16MB
Flash type set in eFuse: quad (4 data lines)
Flash voltage set by eFuse: 3.3V

ive tried a ton of troubleshooting, but nothing changes the warning messages, or boot loop. things tried:
flashing at different offset (gave expected error regarding missing header)
--no-stub option
-fm dio option
flashing from both usb ports
powering from both usb ports
different micropython variants: 4mb, spiram
manually setting --flash-size to 8MB and 16MB

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[github-actions]

Hi @snuq! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Here's an analysis based on the esptool source and known XMC startup logic.

What's happening

The confusing log sequence (WARNING: XMC flash boot-up fix failed. immediately followed by XMC flash chip boot-up fix successful!) is itself a hint that something is off, but looking at the actual logic in esptool/cmds.py, the "successful" message is printed unconditionally after the fix attempt, regardless of whether the check right before it failed — this looks like a logging bug where the success message is not gated behind the actual verification result. [XMC startup flow]

The flash chip identified is Manufacturer 0x20, Device 0x7018. The XMC detection logic (is_xmc_chip_strict) only recognizes XMC vendor ID 0x20 with specific mfid/cpid ranges (e.g., mfid == 0x40 with cpid 0x13–0x20, mfid == 0x41 with cpid 0x17–0x20, mfid == 0x50 with cpid 0x15–0x16). In this case the device ID is 0x7018, meaning mfid = 0x70 and cpid = 0x18 — this does not match any of the recognized ranges. [XMC startup flow]

This means:

• esptool detects the XMC vendor ID via SFDP and runs the XMC25QHxxC power-down/wake startup sequence.
• After running the fix, it re-checks with is_xmc_chip_strict(), which fails again because the device ID 0x7018 isn't in the known-good ranges for this flash family.
• Despite that failure, the code path still logs "XMC flash chip boot-up fix successful!" — which is misleading given the logs shown.

The same "strict" detection logic also exists on the ESP-IDF bootloader side (bootloader_flash_xmc_startup in bootloader_flash.c), and it is this ESP-IDF-side check that is failing at boot, producing:

E (31) bootloader_flash: XMC flash startup fail
E (31) boot.esp32s3: failed when running XMC startup flow, reboot!

This confirms the bootloader's own XMC check (using the same is_xmc_chip_strict style logic) also does not recognize this flash chip's device ID as a valid/supported XMC part, so it treats the boot-up as failed and reboots in a loop. [bootloader_flash.c]

Why this isn't a flash-mode/power/wiring issue

The troubleshooting steps already tried (different offsets, --no-stub, -fm dio, different ports, manually setting flash size) rule out the classic causes documented for "Writing succeeds but program doesn't run" (wrong flash mode, insufficient power, missing bootloader, SPI pin conflicts) — none of those apply here since the failure is specifically the XMC startup/verification step reported both by esptool and by the ROM/bootloader itself. [Troubleshooting]

What I'd suggest telling the customer

1. This looks like an unrecognized/unsupported flash chip variant under the "vendor ID matches XMC, but device ID/cpid falls outside the known good ranges" case in both esptool's and ESP-IDF's XMC strict-detection logic.
2. If CONFIG_BOOTLOADER_FLASH_XMC_SUPPORT is enabled (it is by default), and the chip is misidentified as XMC but doesn't match the known cpid ranges, the bootloader will refuse to boot. The ESP-IDF docs note this option should not be disabled "unless you know what you are doing," but that is the setting controlling this behavior on the firmware side. [XMC_SUPPORT config]
3. Recommend they report this directly as a possible unsupported/unrecognized XMC flash device ID (0x7018) in the esp-flasher-stub issue tracker (for the esptool-side behavior) since stub/flash chip identification issues are meant to be reported there, per esptool's own guidance. [Flasher Stub]

I'm not able to confirm from the knowledge sources exactly which flash chip corresponds to device ID 0x7018 or whether a firmware/esptool update exists specifically adding support for it — that level of detail isn't in the provided documentation, so this should be escalated as a potential unsupported-flash-chip bug rather than resolved purely via user-side configuration.

[Dzarda7]

Hello @snuq, thanks for reporting the issue. Unfortunately I think I do not have a good news for you. Even though the esptool reports it failed to start chip, it most probably did not, especially when Hash of data verified. is printed and from boot message I can see the chip is properly trying to boot. I took a look a bit and found these related issues espressif/esp-idf#18947, espressif/esp-idf#9952, espressif/esp-idf#10999. I assume we can consider fixing the log message in esptool, but chip would not boot anyway as esp-idf bootloader does not support it.

[snuq]

Hello @snuq, thanks for reporting the issue. Unfortunately I think I do not have a good news for you. Even though the esptool reports it failed to start chip, it most probably did not, especially when Hash of data verified. is printed and from boot message I can see the chip is properly trying to boot. I took a look a bit and found these related issues espressif/esp-idf#18947, espressif/esp-idf#9952, espressif/esp-idf#10999. I assume we can consider fixing the log message in esptool, but chip would not boot anyway as esp-idf bootloader does not support it.

so if im understanding correctly, the root issue (aside from the incorrect logging) is the bootloader itself, which is esp-idf? is a compiled version of this included with the firmware i download and install (such as micropython), or added by esptool?
if i need to compile my own bootloader, is this possible to do without compiling the entire firmware, or my own version of esptool?

[Dzarda7]

Yes, micropython uses esp-idf's bootloader and that is the main issue I believe, especially this part, you can try to modify it (when you see it booting for flashing, it might be okay to just continue), build bootloader and do something like this:

esptool write-flash 0x0 ESP32_GENERIC_S3-20260824-v1.29.0.bin #Flash the micropython
esptool write-flash 0x0 bootloader.bin #Rewrite its bootloader only

But this is just my assumption, I am just guessing. Anyway this is not part of the esptool, so I cannot help you much more here. If it is okay we will decide, if we should fix this and based on that either close this issue or improve the esptool.

[snuq]

Yes, micropython uses esp-idf's bootloader and that is the main issue I believe, especially this part, you can try to modify it (when you see it booting for flashing, it might be okay to just continue), build bootloader and do something like this:

esptool write-flash 0x0 ESP32_GENERIC_S3-20260824-v1.29.0.bin #Flash the micropython
esptool write-flash 0x0 bootloader.bin #Rewrite its bootloader only
But this is just my assumption, I am just guessing. Anyway this is not part of the esptool, so I cannot help you much more here. If it is okay we will decide, if we should fix this and based on that either close this issue or improve the esptool.

thank you for the assistance, I will look into that.
i now understand its not esptool's bag, but i do believe that having some improved logging and maybe a more detailed error message could be very helpful for folks in the future who might experience this issue.