ESP32 Forum

Hi,

We are facing issues of ESP32 not getting programmed. While programming through espflash.py tool we are getting error " MD5 of file does not match data in flash! .

We checked further and found below observations :

1. Voltages of OK Modules and Failed Modules are compared. It is observed that Failed modules PIN No. 14 is showing 3.3V and other Pin No. 13, 17, 18, 19, 21 of ESP32 modules are showing 1.8V. Whereas OK Module voltage at Pin no. 14 is 0.

2. Pin No 14 is MTDI, i.e Boot Strapping Pins. This pin decide Voltage of Internal LDO (VDD_SDIO)
If MTDI pin is at logic low then internal regulator is configured for 3.3V supply, if MTDI pin is at logic high then internal regulator is configured for 1.8V

3. Pin No 14 is responsible to power internal SRAM and ROM. As per datasheet "ESP32-Wrover-IB" modules internal regulator works on 3.3V.
Datasheet Comment:
• Internal pull-up resistor (R9) for MTDI is not populated in the module, as the flash and SRAM in ESP32-WROVER-B
and ESP32-WROVER-IB only support a power voltage of 3.3 V (output by VDD_SDIO).

3. Now we are not sure why this happens need help here. In our schematic MTDI Pin is not powered externally. Below are the logs of failed modules.

Test Output:
esptool.py v2.6 Serial port /dev/ttyUSB0 Connecting..... Chip is ESP32D0WDQ5 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None MAC: 34:94:54:ce:db:94 Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size... Auto-detected Flash size: 8MB Compressed 8192 bytes to 31... Writing at 0x00059000... (100 %) Wrote 8192 bytes (31 compressed) at 0x00059000 in 0.0 seconds (effective 4055.5 kbit/s)... Hash of data verified. Flash params set to 0x0230 Compressed 23984 bytes to 14939... Writing at 0x00001000... (100 %) Wrote 23984 bytes (14939 compressed) at 0x00001000 in 0.2 seconds (effective 999.1 kbit/s)... File md5: 6f5c3fe5047156b156ec6f3ff867a22b Flash md5: 4a6770888ed0f2cf57adc01e39ba17a1 MD5 of 0xFF is aaafce55c0d123a0c733139a9a60183f A fatal error occurred: MD5 of file does not match data in flash!

What hardware are you using; are you sure that pin is not shorted by e.g. bad soldering? One way to 'fix' this is to use espefuse.py to force the correct flash voltage; that way it's not dependent on the electrical state of GPIO14 anymore.

The Chip is ESP32D0WDQ5 (revision 1), there is no shorting and soldering defects in fail boards. What may be the root cause behind this issue?
We are getting 2-3 failures modules due to this issue out of 600 per day.

You are talking about GPIO14 or Pin no. 14?
please share the windows tool and binary to resolve this issue.

Ah, sorry, my bad, I mean GPIO12 which is pin 14. You can burn efuses using espefuse.py; it comes with your esp-idf installation.

Hi,

Thanks, we are able to flash the FW successfully after running the espefuse.py script.
Please confirm after running this script is there is any change in functionality/features of the module?

Please refer the the below logs of espefuse.py

C:\Python27\Scripts>espefuse.py.exe --port COM101 set_flash_voltage 3.3V
c:\python27\lib\site-packages\espsecure.py:18: CryptographyDeprecationWarning: Python 2 is no longer supported by the Python core team. Support for it is now deprecated in cryptography, and will be removed in the next release.
from cryptography import exceptions
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
espefuse.py v3.3.1

=== Run "set_flash_voltage" command ===

Enable internal flash voltage regulator (VDD_SDIO) to 3.3V.
The following efuses are burned: XPD_SDIO_FORCE, XPD_SDIO_REG, XPD_SDIO_TIEH.

VDD_SDIO setting complete.

Check all blocks for burn...
idx, BLOCK_NAME, Conclusion
[00] BLOCK0 is not empty
(written ): 0x0000000400000000000014370000a20000e3349454cedb9400000000
(to write): 0x00000000000000000001c00000000000000000000000000000000000
(coding scheme = NONE)
.
This is an irreversible operation!
Type 'BURN' (all capitals) to continue.
BURN
BURN BLOCK0 - OK (all write block bits are set)
Reading updated efuses...
Successful

Nope, functionality should be the same. But it does strengthen my conviction that your GPIO12 (pin 14) is shorted to some other pin... I'd really look into that if you have more of these errors; it could mean that e.g. the solder paste profile used for the chip is wrong.

We double check all the fail boards for SMT defects but no SMT defects found. Thanks again to help us in recovering the fail modules.
But still on daily basis we are getting same failure in modules (2~3 Nos.) out of 600 device production.
Need support for finding root cause for this issue.
Further shall we use the espefuse.py script on all production boards? or only on fail boards.

There's nothing wrong with running the espefuse.py script to fix the flash voltage on boards like this; people do it in production if they need to use GPIO14 for something where the boostrap behaviour interferes, and it's perfectly acceptable to run it on all boards. It's still a bit strange that GPIO14 is pulled down like that on some of your boards, though.

Hello ESP Team,

We have observed that there is voltage difference after running the ESPEFUSE.py script. Please check the attached comparison sheet. Voltages are compared with respect to programmed ESP32. Changes in voltage are observed in pins : 4, 5, 10, 13, 28, 29, 30, 31, 32, 34.
Please refer to the attached comparison sheet.

We need clarity on these change in voltage values, although these pins are not used in our circuit. Is there any issue in the internal circuit.