md5 Error while flashing ESP32-WROVER

[llewellyn]

Hi
I am getting the following error on one of my ESP32-WROVER modules.

Flashing binaries to serial port /dev/cu.usbserial-00000000 (app at offset 0x10000)...
esptool.py v2.1
Connecting....
Chip is ESP32D0WDQ6 (revision 1)
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x0220
Compressed 19392 bytes to 11453...
Wrote 19392 bytes (11453 compressed) at 0x00001000 in 0.1 seconds (effective 1083.3 kbit/s)...
File md5: 5fccb3890a2beb7031f939e14e40e714
Flash md5: 61aeb2895e29be5b3b05e302d557d621
MD5 of 0xFF is f0aaf80a43c39fcbf175b82c66317d3a


I couldn't find anything related to this error.

Does anyone have an idea why this is?

Regards

[kolban]

Because we are transmitting data over a serial link and a serial link can introduce bit errors, it is a good practice to validate that what we "hoped" to transmit is what we "actually" received. My understanding is that a "hash" (checksum?) is calculated on the source data and transmitted with that source data. The ESP32, upon receipt of the data then recalculates the hash and compares what it actually received against what it expected. If they differ, then something got corrupted in transmission.

Some tests I would suggest running.

1. Perform the flash a number of times. Do the hash values remain constant across the transmissions or do they vary for each run? If the later, then it would be indicative of a bad transmission link and look for bad wiring or horrible noise.

2. If the hash values do remain constant ... then things get more "interesting" (sorry ... interesting is relative) and we'd want to look at how the app was being prepared and transmitted. We'd want to learn where the source hash is coming from. For example, is it generated at link/bin prep time and the hash being generated is wrong/different from that being expected by the ESP32? Another possibility would be that the hash is being generated correctly but before transmission, the actual data is being "patched" somehow which would result in a hash that does indeed differ from data.

[llewellyn]

Hi Kolban,

Thanks for your detailed explanation.

So this is a problem that occurred on one of my production boards. We have completed a production run for 500 Units where this problem is occurring on one of the units. This rules out
-> Bad Serial Cable
-> Shady Connections for the programmer to the board.

I do not know at what stage the md5 is being calculated.
Since each of the production board has a different firmware since the AWS certificates are different for each board,
There could be an issue with this particular firmware only. I can try flashing a firmware for another board on the non-working board and see if that works out. This will eliminate some issue in the firmware. or a particular case which is pertaining to the firmware which is causing the md5 to be calculated wrongly.

I will get back to you with these tests.


Regards

[WiFive]

Also doesn't rule out a bad flash chip

[dmaxben]

Every once in a while I too get that random MD5 error when reflashing the ESP32. Cycling power always fixes the problem though...

[ESP_Angus]

Hi Llewellyn,

Do you get the error every time you try to flash this board?
Do you get the same "Flash md5" every time?
Is there anything connected to the SPI flash GPIOs (GPIOs 6-11) of the WROOM module?

[Nespressif]

(0x8000) Offset of partition table I had the same problem and it was that this configuration was like 0x001.

Regards

[mgsscorr1]

I am running into the same issues using the Lyra-TD MCS. I have tried everything that has been suggested but cant seem to resolve the issue.

Anyone have any idea of how to fix this issue on the Lyra-TD?