Constant "A fatal error occurred: MD5 of file does not match data in flash!" after 1st seemingly successful flash (ESPTOOL-730)

Operating System

Linux, Python 3.11.4

Esptool Version

v4.5.1

Python Version

Python 3.11.4

Chip Description

ESP32 WROVER-E with internal SPI flash (16MiB)

Device Description

Custom PCB

Hardware Configuration

No response

How is Esptool Run

No IDE

Full Esptool Command Line that Was Run

python3 esptool.pyc --chip esp32 --baud 115200 write_flash -z 0x1000

Esptool Output

# /opt/bin/flash_esp32.sh
esptool.py v4.5.1
Found 1 serial ports
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-D0WD-V3 (revision v3.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 94:e6:86:24:8b:9c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x0018afff...
Compressed 1611488 bytes to 1041656...
Wrote 1611488 bytes (1041656 compressed) at 0x00001000 in 15.0 seconds (effective 856.6 kbit/s)...
File  md5: 2599e2f42ec0f867821c6e11eb5e867e
Flash md5: 7c66cb69bdf03d0dfeeb988ac7e9eb5e
MD5 of 0xFF is f5031d16530b9c6e7e501fb52423bef0

A fatal error occurred: MD5 of file does not match data in flash!

More Information

We're in the middle of production of ESP32-based PCBs and got the first and second batch of boards using an ESP32 WROVER-E module with builtin 16MiB SPI flash.

All PCBs of the first batch (~100) were successfully flashed UART and are running fine.

Now we received and are flashing the second batch of boards from our manufacturer and while flashing appears to work (at least no error), they behave "weird", which narrows down to flash related operations (e.g. NVS can't be written, nor can files on LittleFS be created). However they definitely were flashed, as they're running our software - except not being able to write to flash.

Attempting to re-flash those boards with esptool via UART constantly results in A fatal error occurred: MD5 of file does not match data in flash!.

The md5 of the read-out of the flash is constant (per board at least), so it's not random noise on the UART.

What's relieving as much as concerning to me, that I can successfully re-flash the ESP32 on these boards if issuing esptool.py write_flash_status --bytes 2 --non-volatile 0 beforehand (as in: before I issue above stated write_flash-call).

I do not know, what esptool.py write_flash_status --bytes 2 --non-volatile 0 exactly does. From what I figure, it clears the flash settings - possibly including the bit for write-protection.

However why would that flash settings be set that way in the first place and why can I flash via UART initially but can't write to flash right after first flashing anymore?

On a additional note, read_flash_status on working boards from the first batch returns the same value as on the boards which show this issue: Status value: 0x0200. However on re-surrected boards -- after executing write_flash_status --bytes 2 --non-volatile 0 -- the status value is 0x0000.

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

[X] I confirm I have read the troubleshooting guide.

Hello @mirko,

has anything changed between the first and second batch? (your firmware, used flash memory chips, esptool version)

Attempting to re-flash those boards with esptool via UART constantly results in A fatal error occurred: MD5 of file does not match data in flash!.

Does this mean that your firmware runs between the first successful flash and the second flash attempt?
Is it possible your firmware is somehow locking (or write-protecting) the flash memory chips?
Does the issue happen if you try flashing twice (without your firmware having a chance to run)?

I am not sure what is causing this, but it seems like the flash chips of the second batch are getting write-protected. Is adding the write_flash_status --bytes 2 --non-volatile 0 step into your flashing process (/opt/bin/flash_esp32.sh) a viable option for you?

espressif / esptool