ESP32 Forum

Hi - am getting this issue on some D2WD devices - sometimes they will flash a few times and then start doing this:


$ make -j 32 flash
project.mk:53: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
project.mk:53: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
Flashing binaries to serial port /COM7 (app at offset 0x10000)...
esptool.py v2.1
Connecting........_____....._____....._____....._____....._____....._____....._____....._____....._
Chip is ESP32D2WDQ5 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Wrote 32768 bytes at 0x00001000 in 2.9 seconds (90.0 kbit/s)...
File md5: 080949b2e22ae4663b43068789233378
Flash md5: b57927e2a299d22002593e4cd309d763
MD5 of 0xFF is fb0d8f08f299b9d5a5a87d75bdfef241

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

$ make -j 32 flash
project.mk:53: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
project.mk:53: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
Flashing binaries to serial port /COM7 (app at offset 0x10000)...
esptool.py v2.1
Connecting.......
Chip is ESP32D2WDQ5 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Wrote 32768 bytes at 0x00001000 in 2.9 seconds (89.9 kbit/s)...
Hash of data verified.
Wrote 950272 bytes at 0x00010000 in 84.1 seconds (90.4 kbit/s)...
File md5: 7cf72d6f072c1c6a2c4e3c2e5b14bbaa
Flash md5: 373d45fa3eb34c14bae19cab9744889c
MD5 of 0xFF is 998b60ed802d5f8e9e0835b0a2459c83

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

$ make -j 32 flash
project.mk:53: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
project.mk:53: esp-idf build system only supports MSYS2 in "MINGW32" mode. Consult the ESP-IDF documentation for details.
Flashing binaries to serial port /COM7 (app at offset 0x10000)...
esptool.py v2.1
Connecting....
Chip is ESP32D2WDQ5 (revision 1)
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Auto-detected Flash size: 2MB
Wrote 32768 bytes at 0x00001000 in 2.9 seconds (89.6 kbit/s)...
File md5: 080949b2e22ae4663b43068789233378
Flash md5: 6cee48796391c29a95071e24ad733608
MD5 of 0xFF is fb0d8f08f299b9d5a5a87d75bdfef241

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

$ python esptool.py --port /COM7 read_flash_status
esptool.py v2.1
Connecting........_____....._____.....
Detecting chip type... ESP32
Chip is ESP32D2WDQ5 (revision 1)
Uploading stub...
Running stub...
Stub running...
Status value: 0xff00
Hard resetting...

$ python esptool.py --port /COM7 flash_id
esptool.py v2.1
Connecting........_____....._____....._____....._____....._____....._____....._
Detecting chip type... ESP32
Chip is ESP32D2WDQ5 (revision 1)
Uploading stub...
Running stub...
Stub running...
Manufacturer: 9d
Device: 7015
Detected flash size: 2MB
Hard resetting...

$ python esptool.py --port /COM7 write_flash_status --non-volatile 0
esptool.py v2.1
Connecting......
Detecting chip type... ESP32
Chip is ESP32D2WDQ5 (revision 1)
Uploading stub...
Running stub...
Stub running...
Initial flash status: 0xff00
Setting flash status: 0x0000
After flash status: 0xff00
Hard resetting...

$

Any thoughts/solutions? What do the SPI flash status bits mean? And why can't it reset them? Thanks.

At what voltage are you running the flash? (Is GPIO12 connected to anything?)

This is at 1.8V, so strapping config is 10K to group from MTDO and 10K to 3.3V from MTDI. Nothing is connected to SD_DATA_0-3, SD_CLK, SD_CMD, GPIO16-17 - everything in the 1.8V domain, except 1uF to ground on VDD_SDIO. Thanks.

Hi iosixllc,

Thanks for the comprehensive set of logs.

iosixllc wrote: Any thoughts/solutions? What do the SPI flash status bits mean? And why can't it reset them? Thanks.

The ISSI flash controller in the ESP32D2WD only has an 8 bit status register, so the upper 8 bits can be ignored - the status register appears to be all zeroes. You can confirm by running "esptool.py read_flash_status --bytes 1".

I noticed the "flash md5" is different for two flashes with the same "file md5". This usually indicates flash or signal integrity problems due to power (if the "flash md5" is always the same wrong incorrect for the same "file md5" then this indicates write protection has been accidentally enabled on some part of the chip.)

Something you can try is reading back the failed flash region with the "read_flash" command and compare the raw binary data.

For approaches to fix this problem, I'd suggest checking the 3.3V regulator capacity, increasing decoupling capacitance on the 3.3V power rail and/or the VDD_SDIO rail.


Angus

I'm suspecting the VSDIO line, as all of these issues started when we moved to 1.8V from 3.3V. We have close to 100uF on the 3.3V main rail, and the regulator is LT3973EDD-3.3. The VSDIO is using internal LDO and only has the recommended 1uF capacitor attached (very close to the pin) with no other traces and nothing else besides the flash on that entire power domain. Do you think we should try to write in smaller chunks? I noticed the bootloader wants to use 16KB chunks.

Or should I consider raising the flash voltage to 3.3V for erase/flashing operations? I am noticing some dirty erase cycles where I have to do a blank check and re-erase once or twice to actually get a 0xF0000 block cleared.

iosixllc wrote:I'm suspecting the VSDIO line, as all of these issues started when we moved to 1.8V from 3.3V.

Can you elaborate on what this means? Unfortunately, if you had MTDI strapped to 3.3V for an extended period, the flash itself may be damaged.

ESP_Angus wrote:

iosixllc wrote:I'm suspecting the VSDIO line, as all of these issues started when we moved to 1.8V from 3.3V.

Can you elaborate on what this means? Unfortunately, if you had MTDI strapped to 3.3V for an extended period, the flash itself may be damaged.

I have older devices that ran at 3.3V that starting having issues when we set the fuses to 1.8V, and I have brand-new devices that never ran at 3.3V showing the same. I'll try the new voltage boost option. Thanks!

This update is working well. However, it seems to require reflash of the bootloader. Any suggestions for OTA? Should I just re-write the bootloader in the field (seems risky)?