idf.py erase_flash doesn't work

[Prasad]

Does anyone know why my `erase_flash` is not working? I just run the command idf.py -p /dev/tty.usbserial-AB0JNMBP erase_flash and even though it says Chip erase completed successfully it just reboots to the old program.

Btw, I'm using a custom partition table as below for my OTA feature.

I have 16MB of flash and I'm using ESP IDF V4.2

Code: Select all

# Name,   Type, SubType, Offset,   Size, Flags
nvs,      data, nvs,     ,        0x4000,
otadata,  data, ota,     ,        0x2000,
phy_init, data, phy,     ,        0x1000,
factory,  app,  factory, ,        4M,
ota_0,    app,  ota_0,   ,        4M,
ota_1,    app,  ota_1,   ,        4M,
coredump, data, coredump,,	  64K

Below is the console output,

Code: Select all

$ idf.py -p /dev/tty.usbserial-AB0JNMBP erase_flash
WARNING: Support for Python 2 is deprecated and will be removed in future versions.
Executing action: erase_flash
Running esptool.py in directory /Users/Prasad/build
Executing "/Users/Prasad/.espressif/python_env/idf4.3_py2.7_env/bin/python /Users/Prasad/esp/esp-idf/components/esptool_py/esptool/esptool.py -p /dev/tty.usbserial-AB0JNMBP -b 460800 --before default_reset --after hard_reset --chip esp32 erase_flash"...
esptool.py v3.1-dev
Serial port /dev/tty.usbserial-AB0JNMBP
Connecting....
Chip is ESP32-D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:ae:a4:f3:a5:c8
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Erasing flash (this may take a while)...
Chip erase completed successfully in 0.0s
Hard resetting via RTS pin...
Done

[ESP_Sprite]

Code: Select all

Chip erase completed successfully in 0.0s

That is awfully fast for a full erase... that normally takes tens of seconds, depending on the flash chip. What hardware are you using?

[Prasad]

Indeed it definitely can’t be erased in 0.0 seconds. This is custom hardware I did for one of our client’s product. It still runs fine except I cannot update the firmware with OTA or via serial. It downloads the new firmware but reboots to the factory version. Then I thought that the flash might be corrupted and I tried to erase the entire flash but it doesn’t erase the flash. Also, I tried the official flash download tool as well, which also says erase success but restart to the factory firmware. Do you think this might be due to a defective flash chip? I don’t have a spare flash chip with me but I ordered to try that out too.

[ESP_Sprite]

I know that most flash chips have configuration registers that can write-protect some or all of the flash memory. You can read those registers using 'esptoool.py read_flash_status'. Perhaps if you compare the results of that to the datasheet of whatever flash chip you use, that may lead to the reason why this is happening?

[Prasad]

I'm using the GD25Q127 flash chip from GigaDevice and I checked the 'esptool.py read_flash_status --bytes 3' and it gave me '0x4000fe' Which is 010000000000000011111110 and the last two bits are Write Enable Latch and Write in Progress respectively. According to the datasheet(Page #14 attached), if the Write Enable Latch is 1 then you can write to the chip and it can accept erase command. So essentially this chip is not write protected. Am I reading this correctly?

[WiFive]

The Chip Erase (CE) command is executed, only if the Block Protect (BP2, BP1, and BP0) bits are 0 and CMP=0 or the Block Protect
(BP2, BP1, and BP0) bits are 1 and CMP=1.

[Prasad]

You are right @WiFive. I missed that in the datasheet. Thanks for pointing that out. I wonder how that happened as I haven't purposely change any of the status register values before. Anyway, My new flash chips arrived and I just tested and it works fine. I checked 'esptool.py read_flash_status --bytes 3' and returned '0x400002' which is '010000000000000000000010' and writable according to the datasheet. Above BP2, BP1, and BP0 bits are 0, and WEL(Write Enable Latch) is 1.

WEL.png (3.31 KiB) Viewed 15397 times

status register.png (22.06 KiB) Viewed 15397 times

Thanks @ESP_Sprite for pointing out the 'read_flash_status', which I didn't know existed within esptool

[ESP_Angus]

Hi Prasad,

It's also possible to write_flash_status, so depending on the exact command set of the flash chip it may be possible to clear those write-protect bits.

(Hopefully not, but on the offchance it happens to re-enable itself again after being cleared, check your hardware design for any signal integrity problems that might be causing a SPI command to be corrupted.)

[Prasad]

Hi Angus, I have desoldered the old flash chip from my PCB. But I will definitely give it a shot and let you know. Thanks.

[Prasad]

Hi Angus, I have successfully cleared the write protected bits using 'esptool.py write_flash_status --bytes 2 --non-volatile 0'. Now I can write to and read from that chip again.