Esptool 4.8.1 cannot get official Devkitc (WROVER-E) in bootmode (ESPTOOL-988)

[sim0njo]

Operating System

Windows10

Esptool Version

4.81

Python Version

3.11.2

Chip Description

ESP32 WROVER-E

Device Description

Official ESP-DEVKITC-VE on custom PCB

Hardware Configuration

GPIO 32/33/21/18/19/27/26/25/34

How is Esptool Run

From ESP-IDF plugin for Visual Studio Code OR from ESP-IDF Terminal

Full Esptool Command Line that Was Run

C:....\esp\v5.3.2\esp-idf\components\esptool_py\esptool\esptool.py', '-p', 'COM3', '-b', '460800', '--before', 'default_reset', '--after', 'hard_reset', '--chip', 'esp32', 'write_flash', '--flash_mode', 'dio', '--flash_freq', '40m', '--flash_size', 'detect', '0x1000', 'bootloader/bootloader.bin', '0x10000', 'e32P2M-4Mb-pV3.bin', '0x8000', 'partition_table/partition-table.bin', '0xd000', 'ota_data_initial.bin'

Esptool Output

esptool.py v4.8.1
Serial port COM3
Connecting......................................

A fatal error occurred: Failed to connect to ESP32: Wrong boot mode detected (0x13)! The chip needs to be in download mode.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html

More Information

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 when seated onto my custom PCB. So no issues there.

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...

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[Honza0297]

Hello @sim0njo! Do you know how to use git bisect (https://git-scm.com/docs/git-bisect)? It can help to find the exact commit when the flash stopped working and we can then easily fix it.

[sim0njo]

Git bisect on which sources?

[sim0njo]

I had a look at the different commits between v3.0 and 4.8.1... doesn't say anything to me...

[Honza0297]

Thank you for your cooperation so far! The idea is to git bisect esptool repository and find in which commit the flash stops working. The reason I am not doing it myself is that, unfortunately, I cannot replicate your issue (with just the devkit). However, If we manage to find the commit where the flash stops working, I will be able to identify the culprit and fix it even without replicating the issue.

If are are still willing to help, I can write a step by step guide what to do

[sim0njo]

Ok, tell me

[Honza0297]

Thanks, here's the guide:

1. Build your application.
2. Open new terminal window, clone esptool repo and install it as an editable package (pip install -e <path-to-esptool-repo>).
3. Being in the esptool repository folder, start git bisect with git bisect start.
4. Choose a bad commit. We know it fails with esptool 4.8.1, so this will be our bad commit: git bisect bad 1e9df29 (release of 4.8.1 version).
5. Choose a good commit. That will be esptool 3.0: git bisect good 4fa0bd7 (release of 3.0 version).
6. Now, in a terminal window used in step 1, navigate to your app's build folder (<path to your app>/build) and try to flash your ESP32 with this command: esptool.py -p <port> -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader/bootloader.bin 0x10000 e32P2M-4Mb-pV3.bin 0x8000 partition_table/partition-table.bin 0xd000 ota_data_initial.bin. Note that you need to specify correct port.
7. If the flash will be successful, write git bisect good into the esptool terminal window. By this, you notify git bisect that the current commit is good. git bisect will automatically switch to the next commit to test. If the flash will be unsuccessful, write git bisect bad.
8. Repeat steps 5 and 6 until you find the commit when the flash stops working. It will take approx. 8 steps.
9. Git bisect will finally show you the first bad commit. Please, copy its commit hash.

Do not hesitate to ask if any point of the guide is unclear.