MD5 Error while Flashing the boot.bin to ESP32

[ESP_Angus]

Hello !!!!
I am facing the same issue,i have gone through the whole discussion but didn't find the solution. Can you please help me to understand the issue? I have two ESP32s boards and updated the new esptool.py.

Hi Peter,

Sorry to hear you've hit this as well. I have a few questions to help track this down:

• Exactly which board or module do you have and how is this connected? If it's a bare module, how are you powering it?
• Is anything connected to GPIO12?
• Are you getting a different MD5Sum each time or is it the same each time?
• What is the output of esptool.py read_flash_status?

Thanks,

Angus

[dereklai]

[

• 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.

Thanks a lot! Angus!

Now I understand the 1.8v issue that causing random flash MD5 error issue and the real story about the rule of entering ROM Basic!

I use GPIO12 as a hspi MISO pin and wired without the pull-up resistor. So far all test boards work very well. Thanks!

[Resch2061]

Ran into this error as well. Since it's been almost a year since this error was last reported, apparently, I wonder if the flow for this error has been changed since the last post.

I will still post whatever information I can either way.

~/esp32/esp-idf$ esptool.py --port /dev/ttyUSB1 read_flash_status
esptool.py v2.0.1
Connecting........___
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Status value: 0x0002
Hard resetting...

esptool.py --port /dev/ttyUSB1 flash_id
esptool.py v2.0.1
Connecting........___
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 0)
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 4016
Detected flash size: 4MB
Hard resetting...

Flash Md5 is different every time.
As far as I can tell from the hardware schematics (we designed our own print; it's a huge one with lots of different components), an SD card component has been connected to GPIO12. I'm not precisely sure about the way it's connected, or the power supply. I will have to ask our hardware engineer.

It'll also outright stop flashing at times, cutting the progress midway...

[khizar.thinks]

IT WORKS, I AM SO GRATEFUL FOR THE GUY WHO FACED THE ISSUE AND THE GUYS WHO CAME UP WITH THE 3.3V REQUIRING GPIO12 TO BE LOW AND FLASH BEING AT 1.8V WHEN THE BOARD HAS POWER FAILURE AND GPIO12 IS LEFT HIGH SETTING THE WRONG VOLTAGE FOR FLASHING.

THANK YOU SO SO SO SO SO MUCH. I WAS ON THE VERGE OF GIVING UP, AFTER SCOURING THE INTERNET FOR 2 HOURS, NO ANSWER HELPED BUT CONNECTING GPIO 12 TO GND FIXED IT.

Amazing work truly. This is approximately 7 years later, but honestly better than 90 percent of other forums.