Windows 11 problem with connecting to ESP32 (ESPTOOL-374)

[sw-dev-code]

Operating System

Windows 11

Version

v3.2

Python Version

3.10.1

Chip Description

ESP32

Device Description

No response

Hardware Configuration

No response

How is Esptool Run

PlatformIO and Console

Full Esptool Command Line that Was Run

esptool.py erase_flash

Esptool Output

esptool.py erase_flash
esptool.py v3.2
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://github.com/espressif/esptool#troubleshooting

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

More Information

Important thing is that in Windows 10 I never got this error. Flashing and Erasing the device worked without any problems.

Other Steps to Reproduce

No response

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[radimkarnis]

Hello @sw-dev-code,

The chip needs to reset into download mode in order to communicate with esptool and accept commands. This usually happens automatically by asserting DTR and RTS control lines of the USB to serial converter chip (more info here).

There might be a regression/difference in Windows 11 drivers causing the DTR/RTS signals to not propagate properly. A temporary solution is putting the chip into the download mode manually. Please try that and let me know if that helps.

At the moment, this is the only report of such behavior and I do not have access to a W11 machine. It would be great if you could help debug the issue, but that would require an oscilloscope or a logic analyzer.

[sw-dev-code]

Thanks for the help @radimkarnis

My other college also has the same problem, so it's not just on my PC.

Yes, that is a solution. So there is something different with Windows 11 drivers. Unfortunately, I don't have an oscilloscope or logic analyzer.

Can you leave the ticket open so if you or anybody else find a solution can give an update?

[radimkarnis]

Thanks for verifying with your colleague.

Can you please install the latest CP210x drivers (if your devkit uses this USB-UART bridge) and try again? We can at least try to rule out as many suspects as possible.

I will leave this ticket open until we have a solution.

[sw-dev-code]

@radimkarnis It was tested with latest drivers

[maxgerhardt]

Maybe using the "CP210x Universal Windows Driver" or the "CP210x Windows Drivers" makes a difference?

[sw-dev-code]

@maxgerhardt I try the one from the link below and now it's working fine. So if anybody else has the same issue they can try.
Not sure if this is a solution, hope more people will confirm it.

https://www.silabs.com/documents/public/software/CP210x_VCP_Windows.zip

[radimkarnis]

Thank you both for investigating. So installing the latest windows drivers (11/17/2021) does solve the issue? That sounds like a solution to me.

@sw-dev-code could you please check with your colleague if this helps in his case?

[sw-dev-code]

@radimkarnis It doesn't work with the latest driver, it works with this one https://www.silabs.com/documents/public/software/CP210x_VCP_Windows.zip.

It's working on the colleague side also, so it's fixed for now. If I find some new issue I will report it.

[cybermaus]

Just confirming the last post (and adding some version numbers):

I originally downloaded and installed CP210x_Windows_Drivers.zip 6.7.6.2130 23-5-2018
Did not work, scope showed RTS and DTR went up at the exact same time, so had to add 2.2uF capacitor to delay IO0

Next I installed above mentioned CP210x_VCP_Windows.zip 19-3-2014 6.7.0.0
And now it did work, without capacitor.

There is also a CP210x_Universal_Windows_Driver.zip on the silabs website, did not test.
And I am keeping the 2.2uF anyway, so it still works when I grab this a year from now to do maintenance on my Shelly's, regardless of what laptop or driver I may be using at the time.

[marcpiulachs]

I'm having the same exact problem :

> Executing task: C:\Users\marcp\.espressif\python_env\idf4.4_py3.8_env\Scripts\python.exe C:\Users\marcp\esp\esp-idf\components\esptool_py\esptool\esptool.py -p COM5 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_freq 40m --flash_size detect 0x10000 smart_device.bin 0x1000 bootloader/bootloader.bin 0x8000 partition_table/partition-table.bin <

esptool.py v3.2-dev
Serial port COM5
Connecting......................................

A fatal error occurred: Failed to connect to ESP32: Wrong boot mode detected (0x13)! The chip needs to be in download mode.

On Windows 11, haven't tried on other versions of windows. 1% of the time the chip automatically enters in programming mode and the rest by manually pressing the boot button.

I have tried all the drivers (even the working reported https://www.silabs.com/documents/public/software/CP210x_VCP_Windows.zip. without any luck.

[radimkarnis]

Hi @marcpiulachs,
your connection issues might be caused by other reasons than being on Windows 11. Please see the troubleshooting guide for a list of the most common problems and solutions.

[marcpiulachs]

Hi @radimkarnis just tried to program the very same board with a windows 10 machine and the code uploads just fine, no need to press BOOT every time, So it seems to be a problem with my windows 11 setup or drivers

BTW, just noticied the version of esptool.py is 2.6

esptool.py v2.6
Serial port COM5
Connecting........_
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 7c:9e:bd:61:e4:84
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600

[markphelan]

Also having the same issue on Windows 11, could not use esptool to communicate with the device.
Failed to connect to ESP32: Wrong boot mode detected (0x13)!

I added an additional delay in esptool.py v3.2 line 593:

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

Now it works reliably.

[RocketRene]

I have the same problem on a Macbook with the M1 Chip

[radimkarnis]

@marcpiulachs @markphelan thank you for your reports and for investigating!

@RocketRene please follow this issue: #712

[Hexum064]

Noticed something strange. After looking at all the posts I finally decided to scope out RST and DTR as well (EN and GPIO0, I believe) and noticed that the board goes into download mode when DTR is held low and RST is pulsed low during that time. When I check what the CP2102 is outputting, it looks like, if DTR is set low by the python code and then the RST is set low, it only has the effect of setting DTR high again (RST never goes low or high, it just remains high).
I'm on Win 10 with the latest driver. Changing to the old 6.7 driver did not seem to have an effect.

[AlohaCPU]

CP2102 driver installed without error on Win 11.
https://ftdichip.com/drivers/vcp-drivers/
But Win 11 Manager reports an error 28. I've uninstalled and reinstalled the driver, rebooted, but same error 28 and the Arduino IDE shows a greyed-out port. Running on another machine with Win 10 I have no problems. Appears to be a Win 11 issue,
When I tried the above link:
https://www.silabs.com/documents/public/software/CP210x_VCP_Windows.zip
I get an install error stating it could not find any drivers for my machine.

[x00x]

if you have boot button bottom right beside usb port on the esp32 board, just push the boot button and then execute that command.

[NotleSG]

Obrigado, resolvi meu problema!

[ailachance]

Does anyone know if a solution for this problem was ever found? I've just recently upgraded to Windows 11 and ran into this issue. I've tried using all 3 Windows drivers listed on the Silicon Labs site:

• CP210x Universal Windows Driver - v11.1.0 - 3/22/2022
• CP210x VCP Windows - v6.7 - 9/3/2020
• CP210x Windows Drivers - v6.7.6 - 9/3/2020
  but none have fixed the issue.

[ali80]

boot and reset signal didnt properly overlap for me,(boot should be low on reset(en) rising edge)
added a 1uf cap on boot pin and this fixed the issue for me.

[ajquick]

I'm also having this problem on Windows 11 (and probably other computers). I have tried a few different sets of drivers. The chip is a CP2104 and its on custom hardware with an ESP32-MINI-1. There are capacitors and I have adjusted values to try and see if that would do it.

What I think is happening is the driver is no longer asserting the DTR / RTS lines correctly. Here is what my scope is showing:

Enable for some reason is triggering low after IO0, instead of the other way around. I think there is a point where IO0 is supposed to go low, where Enable goes high (to enter bootloader) but for some reason that command is not executed.

If I send commands over Python, it does appear to work:

import serial
import time
ser = serial.Serial('COM3', 19200, timeout=0);
ser.setDTR(False);
ser.setRTS(False);
time.sleep(0.1);
ser.setDTR(True);
ser.setRTS(False);
time.sleep(0.5);
ser.setDTR(False);
ser.setRTS(True);

The sleep times are arbitrary.

This generates the pulse I would expect, but I'm still not 100% certain it is entering the bootloader as I cannot program it yet.

I see this note in the code: # Extra RTS set for RTS as Windows only propagates DTR on RTS setting but this line ends with a DTR and not RTS to accompany it:

esptool/esptool/loader.py

Line 537 in 84918ea

self._setDTR(False) # IO0=HIGH, done

[dazca]

Tried a freezed version of esptool 3.1 using pyInstaller and loaded onto different computers in my office and virtual machines. All of them showed the same behavior: Worked on Windows 10 but not on Windows 11, which I had to press the boot button expressly.

[buganini]

The "working" link above is not with a version number so it changes.
Just make sure you install the 2014 version (or 2020 I forgot which one I installed on someone else's computer) #706 (comment)
And then rollback driver version in the device manager

[liudr]

I was trying to update the latest pip-installed esptool.py but was disappointed to find that the esptool.py-script.py is just a wrapper for esptool.py.exe, which is not source code I could add the delays to. I also tried the 2014 version cp210x driver to no avail. So if I want to manually add the delays, what are my options? Where is the source .py for esptool.py?

[dobairoland]

https://docs.espressif.com/projects/esptool/en/latest/esp32/esptool/configuration-file.html#options

[liudr]

Thank you @dobairoland!

So could you suggest a custom sequence? I tried a sequence in an earlier post in a config file but that didn't work. I'll solder some wires to my board and probe with logic analyzer to see if esptool is actually using the config file. I was using this sequence:

custom_reset_sequence = D1|R1|W0.1|D0|R1|W0.5|D1|R0

[radimkarnis]

@liudr

I'll solder some wires to my board and probe with logic analyzer to see if esptool is actually using the config file.

esptool would tell you if it is using a config file with a Loaded custom configuration from <PATH> message. You need to use version >= 4.5, though.

[liudr]

I have done some probing:
win 10 computer
win 11 laptop: cp2102n-based boards and ft231x-base boards (both my own design)

With the custom config I could create the correct transitions for both cp and ft, only on the surface. If I zoom in, I could see that when RTS is asserted, EN is pulled down. Then when DTR is asserted and RTS is de-asserted, EN is pulled high while IO0 is pulled low. This should work but on win 10 system EN is pulled high and about 0.1ms later IO0 is pulled low. DTR and RTS didn't transition simultaneously but has a short delay. This delay was OK. I guess the bootloader hasn't fully loaded and didn't look at IO0. But on a win 11 system, the delay is 3.5ms. So the processor is brought out of reset and allow to run for 3.5ms before IO0 is set to low (download). This difference in the delay between EN going high and IO0 going to low seems to be the only cause of failure to download.

I tested ft231X, which worked on both win 10 and 11. The delay between EN going high and IO0 going low is about 0.5ms. I wish I could find the exact timing for IO0 to be held low after reset to be counted but I couldn't find that in ESP32's spec sheets. Anyway, if I play with this delay on ft231x to be even a bit over 1ms, then this fails to work. So this may have something to do with driver and how OS handles such serial port requests. From my past experience developing USB host/device, I could guess that a few SOFs passed between cp drive asserts DTR and de-asserts RTS so the delay is too long. FT driver is written differently so it didn't suffer as much delay as cp.

I also tested toggling DTR and RTS using pyserial on python. Same pyserial 3.5, but on win 10 the delay is about 0.1ms and on win 11 it is 3.5ms, that is if you assert DTR then immediately de-assert RTS. So guessing esptool relies on pyserial so we are screwed!

[k9jm]

Any way to fix this?

[mitchjs]

on a side note, i updated my machine to Win11 and have no issue using ESPTOOL (v4.5.1) flashing an ESP32S3
i need to grab a ESP32 Dev board and do a test

YUP No issues

`./esptool.exe -b 921600 write_flash 0x1000 firmware/bootloader.bin 0x8000 firmware/partition-table.bin 0x10000 firmware/code.bin

esptool.py v4.5.1
Found 1 serial ports
Serial port COM5
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting.....
Detecting chip type... ESP32
Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, Coding Scheme None
Crystal is 40MHz
MAC: 30:ae:a4:4e:a1:2c
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00006fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x00010000 to 0x000ccfff...
Compressed 23952 bytes to 14840...
Wrote 23952 bytes (14840 compressed) at 0x00001000 in 0.4 seconds (effective 483.5 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 104...
Wrote 3072 bytes (104 compressed) at 0x00008000 in 0.0 seconds (effective 791.5 kbit/s)...
Hash of data verified.
Compressed 772880 bytes to 441705...
Wrote 772880 bytes (441705 compressed) at 0x00010000 in 6.5 seconds (effective 948.0 kbit/s)...
Hash of data verified.

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

[liudr]

@mitchjs

Does either dev board have capacitors on the EN pin? We've had issues when there aren't any capacitors on the EN pin to slow down the transition for a millisecond or three. This applies more to those who design their own boards, not those who use existing dev boards.

[liudr]

@k9jm My solution is to dual boot with Linux mint. It's been a while since I used mint but it's been great once I managed to disable secure boot etc to install mint. I was able to flash with esptool, thonny, and VSCode + platformio (Arduino). The same laptop had win 10 on it and I don't recall flashing firmware with it but it's definitely able to flash and this time I didn't probe the timing, assuming the EN going back to HIGH precedes IO0 going to LOW with a short enough delay. I recommend installing a second drive and install Linux mint to dual boot. At least you will get most of your dev tools on mint like on windows or mac os.

[mitchjs]

yes,
the dev board one schematic shows 10u, now if thats 10uf, thats huge, so i dont think thats right (i could try to measure) but also 1k pull up to 3.3v and thats strong pull!

the other board is my design 4.7k pull up to 3.3v and .1uf cap to gnd

both go into programming mode every time, no issues

[liudr]

So this really comes down to the designs. Mine have not incorporated any capacitors since those were not needed. I bet a lot of devices have been made with those caps and a lot made without them. I have a dev board from TTGO (I think) and it couldn't enter programming mode. It only has a reset button, no boot button. I don't have a schematic but I'm guessing no caps. A 4.7K + 100nF will give 0.5ms time constant, which is probably not quite enough but did work for you. A 1K and 10uF will be 10ms time constant, really long but I guess it did work (Can't say it will always work). I really wish whoever smarty pants re-vamped the win 11's USB scheduler should re-write their smarty code to prioritize certain things. The DTR and RTS can't be (de)asserted simultaneously because they are two separate USB requests to the chip. So it comes down to why two consecutive requests to do DTR and RTS rom cp210x gets such a long 3.5ms delay under win 11 only. Maybe they laid additional code on top of the CDC class but they don't have such thing for vendor class (not CDC class) USB requests to the device so FT chips are not seeing the delay between DTR and RTS manipulations. This is way beyond what folks here are willing to look into. Same USB UART chips, different behaviors on different OS, that's the OS's problem, a windows problem.

[mitchjs]

as per "esp32_hardware_design_guidelines_en.pdf" they recommend 10k pull up and .1uf on the reset pin
on every microcontroller project with ESP32/ATMEL etc, i always had pull up on reset and cap to ground

[liudr]

Could you do a screen shot with page number in the shot? I read through my 2020 version of that doc and didn't find anything. I just downloaded a 2022 version and there was something about CPU_PU pin. I have a 10K pullup but don't have a cap to gnd. I appreciate your help.

[liudr]

The screenshot was from "esp32_hardware_design_guidelines_en.pdf" page 9 but is meant for the bare esp32:

I'm using ESP32-WROVER-IE and I found this one in its datasheet page 17:

FYI, I also checked the module's schematic and could see that EN on the module is CPU_PU on the bare esp32, with no pullup or caps so these are the responsibilities of the designers using the WROVER module. I'll go ahead to do some tests on the recommended 1uF and your recommended 100nF.

[Wolfleader101]

Hey,

This still seems to be an issue for me. My board has randomly stopped letting me connect to it with esptoolpy and esptool js

[riteshsonawane1372]

I am getting Md5 file error in Windows 11. I tried on Fedora it's working good, but unable to use Serial.print(), which causes the Md5 error

A fatal error occurred: MD5 of file does not match data in flash!
A fatal error occurred: MD5 of file does not match data in flash!

[riteshsonawane1372]

I am getting Md5 file error in Windows 11. I tried on Fedora it's working good, but unable to use Serial.print(), which causes the Md5 error

A fatal error occurred: MD5 of file does not match data in flash!
A fatal error occurred: MD5 of file does not match data in flash!

The Blink code is working good on Fedora but on Windows 11 I get the Md5 error

[KurtPfeifle]

1. Trying to web-flash AhoyDTU via Windows 11 (Version 22H2 Build 22621.1702) onto an ESP8266 yields this error message: "Failed to execute 'open' on 'SerialPort': Failed to open serial port."

   I had installed this Silabs-driver from here https://www.silabs.com/documents/public/software/CP210x_VCP_Windows.zip as was recommended above before this issue was closed.

2. Next, I tried to install it using the NodeMCU PyFlasher. This also failed, with the following messages in the log:

    Command: esptool.py --baud 74880 --after no_reset write_flash --flash_size detect --flash_mode dio 0x00000 C:\Users\kurtp\Downloads\ahoy_v0.6.9.zip --erase-all
   
    esptool.py v3.0
    Found 2 serial ports
    Serial port COM4
    COM4 failed to connect: Cannot configure port, something went wrong. Original message: PermissionError(13, 'Ein an das System angeschlossenes Gerät funktioniert nicht.', None, 31)
    Serial port COM3
    COM3 failed to connect: could not open port 'COM3': PermissionError(13, 'Zugriff verweigert', None, 5)
    ....._____
    COM3 failed to connect: Failed to connect to Espressif device: Timed out waiting for packet header
   

   I have no idea how to fix this "Permission Error". Must be a Windows 11 thing...

3. I tried to run "esptool" in the WSL subsystem of Win11 (running Ubuntu), but I'm unsure about the correct syntax, so it gave an error:

    root@t480-kp:~# esptool --chip esp8266 --after hard_reset write_flash --flash_size detect  /mnt/c/Users/kp/Downloads/ahoy_v0.6.9.zip
    usage: esptool write_flash [-h] [--erase-all] [--flash_freq {keep,40m,26m,20m,80m}] [--flash_mode {keep,qio,qout,dio,dout}]
                       [--flash_size FLASH_SIZE] [--spi-connection SPI_CONNECTION] [--no-progress] [--verify] [--encrypt]
                       [--ignore-flash-encryption-efuse-setting] [--compress | --no-compress]
                       <address> <filename> [<address> <filename> ...]
    esptool write_flash: error: argument <address> <filename>: Address "/mnt/c/Users/kp/Downloads/ahoy_v0.6.9.zip" must be a number
   

4. Back to web-flashing the ESP8266 after installing new ESP software on Windows 11. Now it starts to connect, asks if I want to install AhoyDTU v0.6.9 and initiates the flashing. However, it hangs forever, now since 30 minutes like in the screenshot. No progress, only the round blue line continues to circle around...

[NoSt86]

Had the same issue with Ahoy DTU webinstaller under win11. It worked finally with the CH341 v.3.5.2019.1 driver for the ESP8266. You can find it on this website: https://electropeak.com/learn/how-to-install-ch340-driver/

[jagabtw]

Had the same issue with Ahoy DTU webinstaller under win11. It worked finally with the CH341 v.3.5.2019.1 driver for the ESP8266. You can find it on this website: https://electropeak.com/learn/how-to-install-ch340-driver/

1. Install CH340 in CH341 driver package (CH341 add hardware flow control)
2. Check "Enabling the Serial Port Enumerator(SerEnum)"

System : windows 11

[Dim3390]

Not working in Windows 11, but it works in Windows 10 !!!! I installed many drivers and tried everything. I could not get it working.

[Vovan4ikP]

Hi to all!
After upgrading Windows from version 10 to version 11, there is no connection to the esp32 via the com port.
C tried to enable the enumerator (SerEnum), but it did not help.
Everything worked fine on Windows 10.

[liudr]

If you want a hardware fix, attach a 1uF cap across these two pins if you have space and are OK soldering:

[perlchamp]

My Circuit:
ESP32-S Cam-Module WITH ESP32-CAM-MB. No Connection via USB in Windows 11, but Linux (HomeAssistant on RPI, USB connected on RPI) works fine.
AND:
There are TWO different Board-Types in this combo available ! Take care !
Have an eye on the GND-Pin near the flashlight. Only Boards with 'GND/R' named pins are working in this combo. GND-Boards NOT !
Boards with 'GND' can flashed via a serialTTL-Adapter.
This Board also needs a CH340g-Driver i installed.
But until now i didn't find a way to flash this combo under windows. Over Web-Tools same problem.
I tried the TTL-Adapter without bridgeing the gnd and IO0-pin and with bridgeing. No chance!

So, what to do ?
Many thanks in advance.
Stay healthy !

So long

[fermerafer]

Hi,, clic at link https://sparks.gogo.co.nz/ch340.html , uninstall old driver CH340X , instal setup of new driver downloaded and updated with link proposal. and ready write to Esp8266 .

[adamsb6]

Thanks for those posting about the extra milliseconds of latency when running via Windows 11. I thought perhaps I could get this working via WSL so I wouldn't need to reboot or use a second machine, and indeed it does work for me. Follow steps below to get it working for yourself.

The chip I'm connecting to is ESP32-U4WDH (revision v3.1). I did install version 6.7.0.0 of the CP210X driver in Windows 11, but I don't think that should have an impact, the driver should not be used once the device is passed through to WSL.

WSL passthrough steps

1. Install WSL if you haven't already. wsl --install should setup WSL and the default Ubuntu instance. Microsoft has docs here: https://learn.microsoft.com/en-us/windows/wsl/basic-commands
2. Install usbipd-win: https://github.com/dorssel/usbipd-win/releases/latest
3. Open your WSL instance and install PIP and esptool:

sudo apt install -y python3-pip
pip install esptool 

4. Edit /etc/wsl.conf so that systemd services will start. This is necessary so that udev rules can fire and setup the /dev/ttyUSB0 device. The file does not exist by default, create it and write this to it:

[boot]
systemd=true

5. In a cmd.exe with Administrator privileges run:

wsl --update  # this will halt your running VM and update it to WSL 2, which is required for device passthrough. If it has no effect, run wsl --shutdown.

6. Re-open your Ubuntu instance.
7. In a cmd.exe with Administrator privileges run:

usbipd list  # this lists USB devices. Find your USB to UART bridge and take note of its BUSID
usbpid bind --busid <busid>
usbipd attach --wsl --busid <busid>

5. In your Ubuntu instance run lsusb. You should see your passed through device. You should also see that the file /dev/ttyUSB0 is now present.
6. Now just run esptool.py --port /dev/ttyUSB0 <your commands>.

Microsoft's docs for passing through devices are here: https://learn.microsoft.com/en-us/windows/wsl/connect-usb#attach-a-usb-device