Windows 11 - ESP32 Won't go into boot loader - ESPTOOL v4.3 (github release .exe) (ESPTOOL-530)

[mitchjs]

Operating System

Windows 11

Esptool Version

V4.3 - prebuilt .exe from github releases

Python Version

unknown (since its a prebuilt exe)

Chip Description

ESP32-WROOM

Device Description

custom board, with standard auto programing DTR/RTS transistors
EN has 4.7k pullup and .1uf cap to ground
GPIO0 has 4.7k pullup

using Silabs CP210x_Universal_Windows_Driver: 02/18/2022, v11.1.0.53
works perfectly on windows 10 with same driver, not on windows 11

Hardware Configuration

no manual reset buttons, no other components connected to GPIO0, GPIO2 is unconnected

How is Esptool Run

esptool .exe from command line/powershell

Full Esptool Command Line that Was Run

esptool.exe chip_id

Esptool Output

PS C:\Users\EZLock\Documents\Drivesoft\ECU9\EZLock-ECM9 Production Firmware(30 Min Sleep)> .\esptool.exe chip_id
esptool.py v4.3
Found 1 serial ports
Serial port COM3
Connecting......................................
COM3 failed to connect: Failed to connect to Espressif device: 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

A fatal error occurred: Could not connect to an Espressif device on any of the 1 available serial ports.

More Information

Works perfectly on WINDOWS 10 computers
i see others with issues on windows 11, but the issues are not clear if there is a solution
it seems like some kind of timing error of DTR/RTS transitions
or maybe something in windows 11 IO Control for the serial port
which i would think is all in the Silabs driver, and since the driver works on windows 10....
the serial port for run works, i can reset it with RTS toggle and watch the boot process in terminal sw at 115200

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[mitchjs]

anyone else having issues with windows 11?

[ajquick]

Yes. This is a known problem. The Silabs chip inverts the DTR/RTS signals on Windows 11 for some reason.

See #706

Currently no fix, but I think Esptool should just run the normal commands and then invert the signals and try again if it doesn't work.

[radimkarnis]

Hello @mitchjs,

you can try to verify if the same issue persists if you install esptool (and not use the prebuilt binary).

If it does, it probably is the mentioned issue with drivers.

We will try to patch esptool to include more reset sequences.

[mitchjs]

@radimkarnis, its been a while since i had to deal with this, but im pretty sure i tried the non prebuilt version too. i will have to see if can get that laptop again and try

[mitchjs]

Yes. This is a known problem. The Silabs chip inverts the DTR/RTS signals on Windows 11 for some reason.

See #706

Currently no fix, but I think Esptool should just run the normal commands and then invert the signals and try again if it doesn't work.

that thread is all over the place, with no confirmed issue.. ie inversion of dtr/rts, if that was the case, id think it be easy fix for silabs...

[ajquick]

that thread is all over the place, with no confirmed issue.. ie inversion of dtr/rts, if that was the case, id think it be easy fix for silabs...

You are correct. So what I have done is gone and bought kits for the Silab's CP2102, CP2104 and CP2102N. I then tested each of the independent chips on several target PC's with different drivers installed. In each and every instance, the RTS and DTR signals were not inverted, a TRUE state was active low @ 0v. It wasn't until connected to the ESP32 through NPN transistors that the behavior became erratic. Perhaps related to issues sinking / sourcing current between the ESP32 and USB chip.

That all being said. I do think it would be wise for ESPTOOL to change the approach to the RTS/DTR handshake. Perhaps it should try 10 attempts at handshakes with increasing time between each switch and if that does not work, try again with the signals inverted. Eventually one of those connection attempts should be successful.

There are many numerous issues with USB programmers and timing issues that may also be in play. Sometimes it doesn't work because its USB3, sometimes it will work when there is a USB hub in the middle of the operation. Sometimes a specific driver will work or not work. Sometimes it will or won't work on Windows 10 / 11.

[mitchjs]

@ajquick, i havent had any issues till this and it was windows 11, and just one laptop... im afraid to update my personal desktop to windows 11 and be stuck... its not my laptop but a customers (who uses the product i developed with the esp32) and wanted to update firmware, i asked them to ship me the laptop... course that hasn't happened yet... but they said they would

[ejagombar]

Are there any temporary fixes for this issue?

[mitchjs]

im a bit perplexed on this issue, got a new DELL 5320 with windows 11 pro on it, and it all JUST WORKED!
the other windows 11 laptop was an HP
both using the same silabs drivers
HP = failed

[ejagombar]

I am running Windows 11 Pro Build 22621.963

My driver is WinChipHead USB-SERIAL CH340/CH341 Driver version 3.5.2019.1 which is the driver meant for my board as I am using the DFRobot Firebeetle 2 (which uses the ESP32-WROOM-32E chip). I cannot use the Silabs CP210x driver as it is not compatible with this board.

The issue seems to be present across multiple drivers and both Windows 11 and Windows 11 Pro. Does this suggest that it is not the driver at fault? It is strange how it worked out of the box for you on the new laptop.

Edit:
I fixed the issue for my board. This will only be relevant to anyone using the Firebeetle 2 from DFRobot, but the pinout of the official wikipedia page is wrong/very confusing and it labels A0 as GPIO pin 0 however D5 is actually GPIO pin 0. Pulling this pin to ground and pressing reset allows me to upload code to the board with no issues.

[ajquick]

If you are using the CH340 driver that's because you don't have a board with the Silabs' chip. This problem seems to be related to Silabs' chips/driver's only.

…

Message ID: ***@***.***>

[Dork57]

I'm running Windows 11, too. My Board has the CH340 USB-Serial Chip. I have the same issue. I have to press the bootloader Button on upload.

[ajquick]

That could very well be due to poor hardware design and not the fault of the USB chip.

…

On Tue, Jan 17, 2023, 8:40 AM Dirk ***@***.***> wrote: I'm running Windows 11, too. My Board has the CH340 USB-Serial Chip. I have the same issue. I have to press the bootloader Button on upload. — Reply to this email directly, view it on GitHub <#790 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSIOS2FQBX5QTVCSXVWPEDWS24NRANCNFSM6AAAAAARJQY23A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Dork57]

The same Board (DevKit V1) works on Windows 10. I want to say, Windows 11 with USB3.0 the different.

[ajquick]

See if you have an old USB 2.0 hub laying around and plug that in between the computer and devkit. There are reports that USB 3.0 may be the culprit in that instance.

…

On Tue, Jan 17, 2023, 12:04 PM Dirk ***@***.***> wrote: The same Board (DevKit V1) works on Windows 10. I want to say, Windows 11 with USB3.0 the different. — Reply to this email directly, view it on GitHub <#790 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSIOSYHZW6W3W5UZQ2MVM3WS3UKPANCNFSM6AAAAAARJQY23A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Dork57]

A USB 2.0 Hub can't be the solution, may be a work around.

I think the developers of espressif should to thread with this topic. It's not just a issue with the Silabs chip, but also a issue with CH340 chip and CH9102 chip (I had also tested). The official flash download tool has the same issue.

Ironicaly, the download on DevKitV1 with CP2102 chip works on my hardware.

ESPTool 4.4 is used on my platformio installation.

I asked wch.cn to check their driver.
This is the answer:
Hello,

the DTR and RTS pins provided by the CH340 USB to serial port chip can be used to control the download of MCU, but the control of this pin is automatically controlled by the download software. No driver or chip active control is required. You can compare the time sequence that can be downloaded normally, see the difference points, and then compare and troubleshoot the problem.

[radimkarnis]

@Dork57 I am actively trying to solve this and make the reset sequence more robust on all platforms. A similar issue has been recently solved on Linux/MacOS.

It is quite difficult to tune the sequence to work in all kinds of environments (different combinations of OS, USB-to-UART bridge, ESP, drivers, ...). If something works on Windows 10 but stops with Windows 11, there is clearly a regression in the OS/drivers.

What's more, the issue doesn't happen on my machine and the reports differ greatly. Someone says updating drivers helps, and someone else says it doesn't, but inverting the DTR/RTS signals does. So you can see it's quite difficult to reproduce and pinpoint the real underlying issue. If we manage to do that, half of the work is done.

[Dork57]

@radimkarnis
Thank you for your answer and your work. Good to know there is someone dealing with it. I'm also a developer. I know what you're talking about.

I will try to record the signal sequence with my oscilloscope.

[Dork57]

Following pictures - yellow Boot signal - blue Enable signal
With Flash download Tool 3.9.3/3.9.2

record Windows 11 USB3.1 with CP2102 chip - it works, because the capacitor gives a delay

record Windows 11 USB3.1 with CH9102 chip - it does not work

record Windows 11 USB3.1 with CH340 chip - it does not work

record Windows 11 USB2.0 with CH340 chip - it works - little different Timing to picture 3 approx. less than 100us

I hope it helps.

[mitchjs]

looking at this, and hopefully i understand how the boot sequence works
BOOT must be low before, the EN(reset) is pulsed low
does boot need to stay low for x amount of time, while reset is low...
then release both?

i also just noticed 2 days ago there was an update to ESPTOOL's reset routine...
might want to grab and try
(unreleased, so maybe grab source and run the python script)

https://github.com/espressif/esptool

but reset.py is where i think it all happens

        self._setDTR(False)  # IO0=HIGH
        self._setRTS(True)  # EN=LOW, chip in reset
        time.sleep(0.1)
        self._setDTR(True)  # IO0=LOW
        self._setRTS(False)  # EN=HIGH, chip out of reset
        time.sleep(self.reset_delay)
        self._setDTR(False)  # IO0=HIGH, done;

looks like they bring EN low 1st, wait a tiny amount, then bring IO0 (boot) low
seems wrong to me
RTS is connected to EN right (same as the reset push button)

Mitch

[ajquick]

@Dork57

It seems those hardware configurations are out of spec for what is required by the ESP32. The top example that works, works because it has a capacitor to hold enable low for a few extra milliseconds to ensure the IO0 line has time to go low first. Do the other examples lack a capacitor?

A USB 2.0 Hub can't be the solution, may be a work around.

It is because the timing of the switch between EN/IO0 is faster on USB2.0 for some reason. In your 2.0 example that works, the IO0 goes low faster than the EN line can go high.

Adding a capacitor to EN on all examples would probably be enough to cause them to work.

@mitchjs

looks like they bring EN low 1st, wait a tiny amount, then bring IO0 (boot) low
seems wrong to me
RTS is connected to EN right (same as the reset push button)

It's how the hardware is designed with the reset handshake. You can only have the following options:

ENABLE = HIGH, IO0 = HIGH
ENABLE = LOW, IO0 = HIGH
ENABLE = HIGH, IO0 = LOW

The signals need to flip flop, there is no option where both are low at the same time. If there were, we wouldn't have any problems with timing.

@radimkarnis

but inverting the DTR/RTS signals does.

I am not certain inverting the signals is the way to go after all. It certainly helps cover all scenarios, but is not foolproof in itself. I believe I was using the CP2102/4/2N chips out of spec with improper filtering capacitors and a lack of a pull up on the reset line (which they claim is not required, but it appears it may have been). Correcting the issues with my hardware designs, my ESP32 now works fine on Windows 8/10/11.. where previously it did not.

[jakub-kocka]

Since the commit 956557b which is fixing glitches on the RTS line on Windows and acting as correct timing for the RTS and DTR (pulling them in the right order on the right voltage levels), this should not be an issue anymore.

It turns out that the automatic port opening function of PySerial was acting unpredictably when the serial lines were not set before the port was opened, which is also solved by the commit.

Because of this, we are closing the issue.