A fatal error occurred: MD5 of file does not match data in flash! (ESPTOOL-139)

[TTTANG53]

(Please delete any lines which don't apply.)

• Operating system: Windows
• Python version: 3.7
• ESP hardware in use: ESP8285

Full esptool.py command line as run:

C:\esptool\2.8>python esptool.py --port COM3 write_flash -fs 1MB -fm dout 0x0 4gangNormal_1M.bin

Full output from esptool.py (please copy and paste all lines of output)

esptool.py v2.8
Serial port COM3
Connecting....
Detecting chip type... ESP8266
Chip is ESP8285
Features: WiFi, Embedded Flash
Crystal is 26MHz
MAC: c4:4f:33:8a:d0:e2
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Compressed 1048576 bytes to 308292...
Wrote 1048576 bytes (308292 compressed) at 0x00000000 in 27.2 seconds (effective 308.1 kbit/s)...
File md5: 4b98739f0db188e625e4b4b66165d001
Flash md5: e35ca09416f586361b9a6f106bfef588
MD5 of 0xFF is 2fdd6851b32ae931637d4845c037b550

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

What is the expected behaviour?

Should have error write flash as the flash is original backup.

Do you have any other information from investigating this?

Is there any other information you can think of which will help us reproduce this problem?

[TTTANG53]

I try to flash back the original firmware into my switch but having the MD5 of file does not match data in flash error. By right should not have issue right?

[projectgus]

Hi @TTTANG53 ,

Yes, this suggests some problem with the hardware, maybe some of the flash is write protected.

Is the firmware a secret? If not, can you take another dump of current flash contents with esptool.py -p PORT read_flash 0x0 0x100000 command and attach it to this issue, along with the original 4gangNormal_1M.bin file?

[TTTANG53]

Hi @TTTANG53 ,

Yes, this suggests some problem with the hardware, maybe some of the flash is write protected.

Is the firmware a secret? If not, can you take another dump of current flash contents with esptool.py -p PORT read_flash 0x0 0x100000 command and attach it to this issue, along with the original 4gangNormal_1M.bin file?

Hi @projectgus,
No, is not. The firmware is just a sonoff firmware that I backup which I restore back. I have erased the current flash contents and it said successful. And I am sure the current flash still complete. The firmware is in fact latest version of sonoff which I want to restore back the old firmware.
Thanks.

firmware.zip

[projectgus]

Hi @TTANG53,

Thanks. The binary files suggest that some bytes of the new firmware were not written to flash successfully and are still 0xFF. The failed bytes seem mostly random.

If you re-run flashing, do you get the same "Flash md5:" value or a different one each time?

Do you have a good enough 3.3V power supply to the SONOFF when flashing? Bad power during the flash can cause this kind of corruption.

[TTTANG53]

Hi @projectgus,
Yes, re-run flashing the "Flash md5:" value is always the same. I am using my PC USB port as the power supply to the FTDI board.
Thanks.

[projectgus]

@TTTANG53 ,

It's possible that the FTDI board can't supply enough stable current at 3.3V and the chip is browning out during programming.

If you can: try a different board, and/or add a capacitor between the 3.3V and GND pins (on either the FTDI board or the Sonoff).

Angus

[TTTANG53]

@TTTANG53 ,

It's possible that the FTDI board can't supply enough stable current at 3.3V and the chip is browning out during programming.

If you can: try a different board, and/or add a capacitor between the 3.3V and GND pins (on either the FTDI board or the Sonoff).

Angus

@projectgus ,
Thanks for the suggestion. Will try out and let you know.
Thank you.

TTT

[projectgus]

Hi @TTTANG53 ,

Any success?

Angus

[TTTANG53]

Hi @projectgus ,
Sorry, I am a bit busy lately and have yet try it out.
Thanks.

TTT

[surencal]

I used 5 Volts from FTDI to power 3.3 V Sonoff Switch (Jumper pins was set to 5 V ) Voila it worked like a charm no MD5 Error. 4 of my 10 sonoff switches were giving this error but other 6 worked fine on 3.3 v setting.

[rsieiro]

Just wanted to add my 0.02 here in case someone faces the same issue I did and ends up here after a Google search, like me.

I was trying to flash Tasmota/ESPHome in a Sonoff TX and was facing the same error reported here. To be fair, I had this device running the original firmware for a few months and it stopped working recently, so I knew there was something wrong with it. But I was able to put it into programming mode and it was responding to most commands, so I thought it was worth a shot.

I tried to flash it several times and always got this MD5 mismatch error, and it was always the same MD5 value. After a while playing with the verify_flash command (using the --diff option) I noticed that the bad data always started at the same address: 0x00080000. Starting at that address, all the values returned from the device's flash memory were 0xff.

This Sonoff has 1 MB of flash and according to the esptool docs it's divided in two 512KB OTA slots, and the address seems to match the start position for the second slot, so I thought that maybe the second slot was failing somehow (I'm not very familiar with its internal hardware, don't know exactly if it means the flash memory is divided in two separate chips or something, but it kinda made sense in my head).

Since the ESPHome base image is a bit less than 400KB, I created a custom image configured as if my device only had 512KB of flash, instead of 1MB. Then I tried to flash it using -fs 512KB and it actually finished successfully, with no errors.

I'm still not sure if half of my device's flash memory just went bad, but the device is now working again and 100% funcional.

[projectgus]

@rsieiro Thanks for sharing this. What is the output of esptool.py -p PORT flash_id?

[rsieiro]

Right now the device is installed in my living room wall, but I'll take some time during the weekend to check for that info.

[projectgus]

@rsieiro Oh! Look, if it's working then don't worry about too much. I was curious to verify that the flash was actually 1MB in size, according to its flash id. I think otherwise your theory that it's somehow defective is probably the correct one.

[radimkarnis]

Hello everyone,
I’m closing this issue because it seems like it's not relevant anymore. Please reopen if further discussion is needed.

[yo3hcv]

This is happening when your build tool doesn't delete *.bin files produced by 'gen_appbin.py'

This tool, instead of overwriting existing data it will keep append to existing eagle.app.flash.bin file so after a while, will wrap around and write complete mess into chip.

[anthonyR012]

Hola tengo una vasta experiencia en programación, pero son los primeros indicios con electronica y todo este tema de arduino, recientemente tuve el mismo error con mi esp32s al inicio funciono bien (La conexion a internet) y de un momento comenzo a salir este error, no tengo idea de como solucionarlo. y se me es un poco complejo entender lo que dicen

[edwinbeeta]

just go to python and flashthe memory