[SOLVED] can't write/erase flash on ESP32-WROVER-E

dvnrrs
Posts: 2
Joined: Sun Dec 26, 2021 7:13 pm

[SOLVED] can't write/erase flash on ESP32-WROVER-E

Postby dvnrrs » Sun Dec 26, 2021 7:37 pm

Hi all,

I'm bringing up a new batch of custom PCBs with integrated ESP32-WROVER-E(M213EH6464PH3Q0) modules. I'm having a strange issue: I can't seem to erase (or, consequently, to write to) the onboard 8MiB flash. I don't think this is a board or connection problem, because I have two separate PCBs, both of which are known to be working correctly with older ESP32-WROVER modules with 4MiB flash, and both of which have the same problem now with the -E chip.

When I try to program with "idf.py flash", I get the following:

Code: Select all

Connecting........
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 48:55:19:b5:43:78
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x00039fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 25440 bytes to 15916...
Writing at 0x00001000... (100 %)
Wrote 25440 bytes (15916 compressed) at 0x00001000 in 0.4 seconds (effective 458.2 kbit/s)...
File  md5: dcb7d93b7e4eeb18452368ec967ed2db
Flash md5: 4c03feeb3298a10ad0ea93ed8c09925b
MD5 of 0xFF is 281039d6031a5a11af6c530e21de18d6

A fatal error occurred: MD5 of file does not match data in flash!
I can successfully read out the contents of the flash:

Code: Select all

me@mypc:~/projects/hello_world$ esptool.py -p /dev/ttyUSB0 read_flash 0x1000 0x7000 flash.img
esptool.py v3.3-dev
Serial port /dev/ttyUSB0
Connecting...................
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 48:55:19:b5:43:78
Uploading stub...
Running stub...
Stub running...
28672 (100 %)
28672 (100 %)
Read 28672 bytes at 0x1000 in 2.6 seconds (87.5 kbit/s)...
Hard resetting via RTS pin...

me@mypc:~/projects/hello_world$ hexdump -C flash.img
00000000  e9 02 02 00 74 f5 09 40  ee 00 00 00 00 00 00 00  |....t..@........|
00000010  00 00 00 00 00 00 00 01  a4 eb ff 3f 04 00 00 00  |...........?....|
00000020  08 c0 fe 3f 00 f0 09 40  b0 0c 00 00 f8 20 f4 3f  |...?...@..... .?|
00000030  f8 30 f4 3f 36 41 00 91  fd ff c0 20 00 88 09 80  |.0.?6A..... ....|
00000040  80 24 56 48 ff 91 fa ff  c0 20 00 88 09 80 80 24  |.$VH..... .....$|
00000050  56 48 ff 1d f0 00 00 00  10 20 f4 3f 00 20 f4 3f  |VH....... .?. .?|
00000060  00 00 00 08 36 41 00 e5  fc ff 21 fb ff 0c 08 c0  |....6A....!.....|
00000070  20 00 89 02 91 fb ff 81  f9 ff c0 20 00 92 68 00  | .......... ..h.|
00000080  c0 20 00 98 08 56 79 ff  c0 20 00 88 02 7c f2 80  |. ...Vy.. ...|..|
...
I can repeatably read from any region of the flash and consistently get the same data. However, when I try to manually erase, the erase doesn't actually do anything (the command looks like it succeeded, but it returns immediately, but it really should take quite some time if it's actually erasing):

Code: Select all

me@mypc:~/projects/hello_world$ esptool.py -p /dev/ttyUSB0 erase_flash
esptool.py v3.3-dev
Serial port /dev/ttyUSB0
Connecting...
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision 3)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 48:55:19:b5:43:78
Stub is already running. No upload is necessary.
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.0s
Hard resetting via RTS pin...
The flash ID (from esptool.py flash_id) is manufacturer c8, device 4017. This corresponds to a GigaDevice GD25Q64C (https://www.gigadevice.com/flash-memory/gd25q64c/).

I checked the flash status registers (with "esptool.py read_flash_status --bytes 3"). The value is 0x200200. From the GD25Q64C datasheet, I can see that this means the QE bit is set to 1 (QSPI mode) which disables the WP# signal. (So the WP#/IO2 pin is IO2, not a write protect input, so the issue should not be a bad signal on this pin.)

So I'm at a loss why I can't successfully erase the flash (and why I consequently can't write to it).

More exact details:

Module: ESP32-WROVER-E(M213EH6464PH3Q0) purchased from Mouser (Mouser part number 356-ESP32WRVE26464PC). (I.e., this is a reputable distributor and I have no concerns about a counterfeit part.)

Board: two custom PCBs, both of which are proven designs that work well with older ESP32-WROVER modules with 4MiB flash.

Software: esp-idf from GitHub, have tried several versions, the latest being the current master (commit f5bc4718f4d662f696bf51d6daccbc0e79fb53a8).

Can anyone offer any suggestions on what the problem might be, and/or how I might troubleshoot further?

Thanks, best regards, and Happy Holidays!
Last edited by dvnrrs on Mon Dec 27, 2021 7:41 am, edited 1 time in total.

ESP_Sprite
Posts: 9589
Joined: Thu Nov 26, 2015 4:08 am

Re: can't write/erase flash on ESP32-WROVER-E

Postby ESP_Sprite » Mon Dec 27, 2021 1:18 am

Could it be that GPIO12/MTDI reads high on startup? If so, you're telling the ESP32 that the attached flash is 1.8V. A 3.3V flash generally doesn't like being ran at 1.8V. (Note you can burn an eFuse instead of reworking your board if this is the case.)

dvnrrs
Posts: 2
Joined: Sun Dec 26, 2021 7:13 pm

Re: can't write/erase flash on ESP32-WROVER-E

Postby dvnrrs » Mon Dec 27, 2021 7:41 am

Hi ESP_Sprite,

Yes, that was the problem, I had external pullup resistors on MTDI. It seems the last batch of modules had 1.8V flash. I removed the pullups on 1 of each board, and both can now load flash correctly.

Thank you!

HenroRitchie
Posts: 1
Joined: Tue Aug 08, 2023 8:56 am

Re: [SOLVED] can't write/erase flash on ESP32-WROVER-E

Postby HenroRitchie » Tue Aug 08, 2023 9:00 am

This also saved me a lot of trouble! Thank you!

Who is online

Users browsing this forum: Troy Mitchell and 108 guests