MD5 Error while Flashing the boot.bin to ESP32

[ESP_Angus]

I have the MD5 not match problem today with two ESP32s boards. They can "read_flash_status" to be 0x3300. And after write_flash_status --nonvatile 0, it's still 0x3300 and can't flash any bin file with "MD5 not match" messages.

Hi dereklai,

What's the output of 'esptool.py flash_id'?

Thanks,

Angus

[dereklai]

Hi dereklai,

What's the output of 'esptool.py flash_id'?

Thanks,

Angus

~/esp/esp-idf/components/esptool_py/esptool$ ./esptool.py --port /dev/ttyUSB0 flash_id
esptool.py v2.0-dev
Connecting...
Detecting chip type... ESP32
Uploading stub...
Running stub...
Stub running...
Manufacturer: ef
Device: 4016

[dereklai]

For each 'make flash', there is a different Flash md5. What's wrong?

Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.0-dev
Connecting...
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Attaching SPI flash...
Configuring flash size...
Erasing flash...
Unc size 4480 comp size 2835 comp blocks 3
Wrote 2835 bytes at 0x00001000 in 0.0 seconds (610.4 kbit/s)...
File md5: b56dc5625044a256c39b47f368fd008f
Flash md5: a5dadc6c524302f21b4839c839cc1a6b

A fatal error occurred: MD5 of file does not match data in flash!
make: *** [flash] Error 2

--------

Flashing binaries to serial port /dev/ttyUSB0 (app at offset 0x10000)...
esptool.py v2.0-dev
...
Wrote 2835 bytes at 0x00001000 in 0.0 seconds (611.6 kbit/s)...
File md5: b56dc5625044a256c39b47f368fd008f
Flash md5: bae78013e12db5fab500a0c5d29bc09c

A fatal error occurred: MD5 of file does not match data in flash!
make: *** [flash] Error 2

---------

Wrote 2835 bytes at 0x00001000 in 0.0 seconds (654.5 kbit/s)...
File md5: b56dc5625044a256c39b47f368fd008f
Flash md5: b6bc9f5084550d01e02af976ffffda45

A fatal error occurred: MD5 of file does not match data in flash!
make: *** [flash] Error 2

---------

The esptool.py is from https://github.com/espressif/esptool/blob/bugfix/write_fails_cmp_bit_set/esptool.py.

[ESP_Angus]

Hi dereklai,

Thanks for providing those details. A couple of things that should help:

• You don't need the bugfix branch of esptool.py any more, in fact that branch is out of date. I should have deleted it and removed the link from the post, my mistake. If you have the current esp-idf master branch then the esptool that's included there is the one to use (the commands git pull origin; git submodule update should get you back up to date).
• The flash status bit that is being reported by read_flash_status is SRP1, which needs a power cycle to clear. If you power cycle the boards, does the problem go away?
• Are all these ESP32S boards failing to flash the very first time that you flash them?

Cheers,

Angus

[dereklai]

Hi dereklai,

Thanks for providing those details. A couple of things that should help:

• You don't need the bugfix branch of esptool.py any more, in fact that branch is out of date. I should have deleted it and removed the link from the post, my mistake. If you have the current esp-idf master branch then the esptool that's included there is the one to use (the commands git pull origin; git submodule update should get you back up to date).
• The flash status bit that is being reported by read_flash_status is SRP1, which needs a power cycle to clear. If you power cycle the boards, does the problem go away?
• Are all these ESP32S boards failing to flash the very first time that you flash them?

Cheers,

Angus

Thanks Angus.

* I have got the current esp-idf master branch. The two md5-error modules are still showing md5-error.

* I have power cycle serveral times. After power on again, it's flash status shows "0x3200". And it's still md5-error.

* Yes. the two failed boards failed at the first time with md5 mismatch error. I guess the flash memory has something wrong. Can I fix them by sending some commands?

I have another two 'normal' boards which failed to flash with md5 mismatch error for several times but works fine later with the new esptool.py. Were they fixed by some secret commands?

[ESP_Angus]

Hi derekali,

The status bits that are being reported are QIE, LB2, LB3. (You can see in section 7 of the flash datasheet.) According to the datasheet, none of these status bits should be preventing writing to the flash.

Also, the fact you get a different md5 each time implies that different data is being written (or read back) each time. Which makes this sound a bit like a hardware problem. Check your power supply isn't possibly browning out (if you're using a bare ESP32S module then this is very possible), add capacitors to power if you can, and check nothing else is connected to the SPI pins.

[dereklai]

Hi derekali,

The status bits that are being reported are QIE, LB2, LB3. (You can see in section 7 of the flash datasheet.) According to the datasheet, none of these status bits should be preventing writing to the flash.

Also, the fact you get a different md5 each time implies that different data is being written (or read back) each time. Which makes this sound a bit like a hardware problem. Check your power supply isn't possibly browning out (if you're using a bare ESP32S module then this is very possible), add capacitors to power if you can, and check nothing else is connected to the SPI pins.

Thanks Angus!!

Yes, check nothing else is connected to the SPI pins....

Finally found the problem is triggered by a pull-up resistor to HSPI-MOSI-GPIO12.

The ESP32 entered the "very BASIC ROM console"!

[ESP_Angus]

Finally found the problem is triggered by a pull-up resistor to HSPI-MOSI-GPIO12.

The ESP32 entered the "very BASIC ROM console"!

Aha! I'm glad you sorted this out.

Do you mean it entered the ROM console while it was supposed to be flashing, or at some later time?

[dereklai]

Aha! I'm glad you sorted this out.

Do you mean it entered the ROM console while it was supposed to be flashing, or at some later time?

It entered the ROM Console first and I tried to flash it then during the boot sequence. 8-(

I suppose the boot priority should be program-mode first with GPIO0-Low, no matter GPIO12-High or not.

Hope no more people to suffer the md5-mismatch program-mode issue with this secret gate feature.

[ESP_Angus]

Do you mean it entered the ROM console while it was supposed to be flashing, or at some later time?

It entered the ROM Console first and I tried to flash it then during the boot sequence. 8-(

I suppose the boot priority should be program-mode first with GPIO0-Low, no matter GPIO12-High or not.

Sorry, I didn't really understand what you were seeing when I replied last week. Over the weekend I realised what was happening:

• GPIO12/MTDI selects the SPI flash voltage on reset - LOW (default) is 3.3V, HIGH is 1.8V. This is overrideable via EFUSE as well, there will be a command line tool in esp-idf soon which can set this override.
• ESP32S modules appear to ship with a 3.3V SPI flash chip, however it must almost work at 1.8V. So it looks to the ESP32 like it's working, but it's actually browning out during flash erase/write cycles (and maybe also during reads) so there is garbage data.
• If you program the chip with GPIO12 high, the flash is being powered at 1.8V. It looks to the ESP32 like it's being programmed, but it's actually quietly browning out and failing - and the ESP32 sees this when it reads back the flash to verify the MD5. This is why the MD5 is different every time, because the corruption is coming from the undervoltage condition so it's random failures.
• On a normal boot (ie GPIO0 HIGH) the ROM BASIC interpreter runs if the flash fails to read a valid-looking bootloader image at 0x1000. Which is happening due to to the 1.8V issue as well, it doesn't see a correct-looking flash image so it runs the BASIC interpreter.

For now, the solution is to keep GPIO12 low or unconnected on reset. Soon (I'll post back here) there will be a tool in esp-idf that permanently sets the flash voltage on the chip via EFUSE, so this pin can be pulled up on reset without side effects.