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.