ESP32 can't be flashed, can't be formatted (ESPTOOL-979)

[Uefi1]

Operating System

windows7

Esptool Version

4.8.1

Python Version

13.1

Chip Description

ESP32-Wroom

Device Description

ESP32-D0WD-V3

Hardware Configuration

No response

How is Esptool Run

cmd

Full Esptool Command Line that Was Run

esptool --chip auto --port com51 -b 115200 erase_flash

Esptool Output

>esptool --chip auto --port com51 -b 115200 erase_flash
esptool.py v4.8.1
Serial port com51
Connecting...
Failed to get PID of a device on com51, using standard reset sequence.
.
Detecting chip type... Unsupported detection protocol, switching and trying agai
n...
Connecting...
Failed to get PID of a device on com51, using standard reset sequence.
.
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme
None
Crystal is 40MHz
MAC: MY:MAC=)
Uploading stub...
Running stub...
Stub running...
Erasing flash (this may take a while)...

A fatal error occurred: Packet content transfer stopped (received 8 bytes)

More Information

No response

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[Uefi1]

When I try to flash:

>esptool --chip auto --port com51 -b 115200 --before default_reset --after hard_reset write_flash 0x10
000 0x10000_firmware.bin
esptool.py v4.8.1
Serial port com51
Connecting...
Failed to get PID of a device on com51, using standard reset sequence.
..
Detecting chip type... Unsupported detection protocol, switching and trying agai
n...
Connecting...
Failed to get PID of a device on com51, using standard reset sequence.
...
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme
None
Crystal is 40MHz
MAC:MY:MAC
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash will be erased from 0x00010000 to 0x000fcfff...
Compressed 968736 bytes to 612509...
Writing at 0x0001af4b... (5 %)Traceback (most recent call last):
  File "esptool\__init__.py", line 1314, in _main
  File "esptool\__init__.py", line 1036, in main
  File "esptool\cmds.py", line 646, in write_flash
  File "esptool\loader.py", line 127, in inner
  File "esptool\loader.py", line 1132, in flash_defl_block
  File "esptool\loader.py", line 510, in check_command
  File "esptool\loader.py", line 479, in command
  File "esptool\loader.py", line 412, in read
StopIteration

A fatal error occurred: The chip stopped responding.

[Uefi1]

When I try to change the memory voltage:

>espefuse --chip auto --port com51 --do-not-confirm set_flash_voltage 1.8V
espefuse.py v4.7.0
Connecting...
Failed to get PID of a device on com51, using standard reset sequence.
.
Detecting chip type... Unsupported detection protocol, switching and trying agai
n...
Connecting...
Failed to get PID of a device on com51, using standard reset sequence.
.
Detecting chip type... ESP32

=== Run "set_flash_voltage" command ===

A fatal error occurred: Can't set regulator to 1.8V is XPD_SDIO_TIEH efuse is al
ready burned

[Uefi1]

Help me, kind people, please, I tried uploading the firmware to different addresses and this is what it turned out to be:

Successful flashing with the command:
esptool --chip auto --port com51 -b 115200 --no-stub --before default_reset --after hard_reset write_flash 0xe000 0xe000_boot_app0.bin

Successful flashing with the command:
esptool --chip auto --port com51 -b 115200 --no-stub --before default_reset --after hard_reset write_flash 0x8000 0x8000_partitions.bin

This is how it is sometimes flashing about 1 time out of 40:
esptool --chip auto --port com51 -b 115200 --no-stub --before default_reset --after hard_reset write_flash 0x1000 0x1000_bootloader.bin

Doesn't flashing at all:
esptool --chip auto --port com51 -b 115200 --no-stub --before default_reset --after hard_reset write_flash 0x10000 0x10000_firmware.bin

[dobairoland]

This looks to me a hardware issue or a Windows driver issue. You need to debug this and ensure that the serial communication is reliable over time. You can connect a serial program and observe the output. More tips are in https://docs.espressif.com/projects/esptool/en/latest/esp32/troubleshooting.html.

You can see that chip detection is flaky and it detects the chip after several unsuccessful attempts. The partition table is the smallest and the firmware is the largest. You are getting successes or failures proportional to their size. If you flash a small binary like the partition table then it is likely to succeed because you likely hit a window when the serial communication is stable. You cannot flash the firmware because it is large and the communication cannot stay stable for a longer period of time necessary to flash it.

[Uefi1]

This looks to me a hardware issue or a Windows driver issue. You need to debug this and ensure that the serial communication is reliable over time. You can connect a serial program and observe the output. More tips are in https://docs.espressif.com/projects/esptool/en/latest/esp32/troubleshooting.html.

You can see that chip detection is flaky and it detects the chip after several unsuccessful attempts. The partition table is the smallest and the firmware is the largest. You are getting successes or failures proportional to their size. If you flash a small binary like the partition table then it is likely to succeed because you likely hit a window when the serial communication is stable. You cannot flash the firmware because it is large and the communication cannot stay stable for a longer period of time necessary to flash it.

Probably the device memory is broken =(

[sim0njo]

Hi,
I use the official Espressif ESP32-DEVKITC-VE, when working with the old ESP-IDF 4.4 under Eclipse (esptool.py v3.0-dev) this module is flashable in 99,9% of the cases.

Now I am upgrading to ESP-IDF 5.3.2 under Visual Studio Code and esptool.py v4.8.1 is not able to switch the ESP32 to boot mode., although it is possible to read the ESP32. Esptool is just not handling the RTS/CTS signals correctly to force boot mode.

So now I force the DEVKITC into boot mode by hand when esptool is in the connecting phase, now it is able to flash the ESP32.

===
Connecting................................
Detecting chip type... ESP32
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 08:b6:1f:ed:54:fc
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Auto-detected Flash size: 8MB
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000d000 to 0x0000efff...
Flash will be erased from 0x00010000 to 0x00101fff...
Flash params set to 0x0230
SHA digest in image updated
Compressed 25328 bytes to 15641...
Wrote 25328 bytes (15641 compressed) at 0x00001000 in 0.7 seconds (effective 281.3 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 143...
Wrote 3072 bytes (143 compressed) at 0x00008000 in 0.1 seconds (effective 270.2 kbit/s)...
Hash of data verified.
Compressed 8192 bytes to 31...
Wrote 8192 bytes (31 compressed) at 0x0000d000 in 0.1 seconds (effective 494.4 kbit/s)...
Hash of data verified.
Compressed 990096 bytes to 645710...
Wrote 990096 bytes (645710 compressed) at 0x00010000 in 16.3 seconds (effective 487.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...

This makes me think of the Depeche Mode song: Going backwards (armed with new technology)

[dobairoland]

@sim0njo Please open a separate task for your issue. Do you know how to use git bisect (https://git-scm.com/docs/git-bisect)? It could help find which change introduced the issue for you. We could then easily fix it.

[dobairoland]

As for this issue, I'm closing it.