ESP Tool fails consistently on one computer and works on another with ESP32-Pi board from Sequent Microsystems (ESPTOOL-1186)

[tjhayko]

Operating System

Windows 11

Esptool Version

5.1.0

Python Version

Python 3.11.0

Chip Description

ESP32-Pi (https://sequentmicrosystems.com/products/esp32-pi-low-cost-replacement-for-raspberry-pi?_pos=1&_psq=ESP32&_ss=e&_v=1.0)

Device Description

None.

Hardware Configuration

https://sequentmicrosystems.com/products/eight-mosfets-8-layer-stackable-card-for-raspberry-pi (i2c device)

How is Esptool Run

Windows Terminal (although same result from Arduino IDE or Visual Studio Code with Platform.IO)

Full Esptool Command Line that Was Run

"D:\old-pc\d-drive\Software\esptool\esptool-windows-amd64\esptool" -t --chip esp32 --port "COM5" --baud 460800 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size 4MB 0x1000 "D:\Dev\8MOSFET Dew Heater\ESP32-Dew-Heater.pio\build\esp32doit-devkit-v1\bootloader.bin" 0x8000 "D:\Dev\8MOSFET Dew Heater\ESP32-Dew-Heater.pio\build\esp32doit-devkit-v1\partitions.bin" 0xe000 C:\Users\tomha.platformio\packages\framework-arduinoespressif32\tools\partitions\boot_app0.bin 0x10000 .pio\build\esp32doit-devkit-v1\firmware.bin

Esptool Output

output logs are large.  One from a machine where it works properly most of the time, the other from the one that always fails.

More Information

2025-09-26-working.txt

2025-09-26 - Not working.txt

Other Steps to Reproduce

The board in question is a Sequent Microsystems ESP32-Pi (https://sequentmicrosystems.com/products/esp32-pi-low-cost-replacement-for-raspberry-pi?_pos=1&_psq=ESP&_ss=e&_v=1.0) , which I think from board schematic has GPIO0 connected to DTR, and EN connected to RTS, both on CH340.

I Have Read the Troubleshooting Guide

• I confirm I have read the troubleshooting guide.

[github-actions]

Hi @tjhayko! Please be aware that (1) the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems, (2) burning eFuses and enabling security features are irreversible operations and can damage your ESP32 device. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Based on the information provided and the Espressif documentation, here are some steps and considerations to help troubleshoot why esptool works on one Windows 11 machine but fails on another with your Sequent Microsystems ESP32-Pi board:

1. Automatic Bootloader Circuitry

Your board uses GPIO0 connected to DTR and EN (CHIP_PU) connected to RTS via a CH340 USB-to-serial chip, which matches the standard Espressif auto-reset circuit for ESP32. This setup should allow esptool to automatically enter bootloader mode, provided the serial control lines are correctly connected and the reset circuit is implemented as per Espressif’s guidelines. If the board is missing a capacitor (1uF–10uF) between EN and GND, automatic reset may be unreliable, especially on Windows. Adding this capacitor can improve reliability if it is not already present on your board Automatic Bootloader – ESP32.

2. Serial Port and Driver Issues

• Driver Conflicts: Ensure the correct CH340 driver is installed on the problematic machine. Windows sometimes uses a generic or outdated driver, which can cause issues.
• Serial Port Access: Make sure no other application (including serial terminals, Arduino IDE, or PlatformIO) is holding the COM port open. Only one application can access the port at a time.
• RTS/DTR Behavior: Some serial terminal programs or drivers may assert RTS/DTR lines differently, potentially holding the ESP32 in reset. If you use a serial terminal, ensure hardware flow control (RTS/CTS) is disabled Automatic Bootloader – ESP32.

3. Power Supply

• USB Power: The ESP32 requires a stable 3.3V supply with sufficient current (up to 200–300mA peak). Some USB ports or hubs may not provide enough current, especially on laptops or through unpowered hubs. Try a different USB port or a powered hub Writing to Flash Succeeds but Program Doesn’t Run – ESP32-P4.

4. Baud Rate

• Lower Baud Rate: If flashing fails partway or fails to connect, try lowering the baud rate (e.g., -b 115200). Some USB-to-serial adapters or drivers are unreliable at higher speeds Basic Options – ESP32.

5. General Troubleshooting Steps

• Check Connections: Ensure all required pins (GPIO0, EN, GND, TX, RX) are properly connected.
• Manual Bootloader Mode: If auto-reset fails, try holding down the BOOT button (GPIO0) while pressing and releasing the EN button (CHIP_PU) to manually enter bootloader mode Flashing Troubleshooting – ESP32.
• Check for Interference: Remove any other devices connected to the ESP32’s GPIOs that might interfere with boot or flashing Troubleshooting – ESP32.

6. Windows-Specific Notes

• RTS Default State: On Windows, some drivers or serial adapters may assert RTS by default, holding the ESP32 in reset. This can be mitigated by ensuring the reset circuit is implemented as per Espressif’s reference, or by disabling hardware flow control in the serial driver/software Automatic Bootloader – ESP32.

---

Summary of Recommendations:

• Double-check the CH340 driver version on the failing PC.
• Try a different USB port or cable.
• Lower the baud rate to 115200.
• Ensure no other software is using the COM port.
• If possible, add a 1uF–10uF capacitor between EN and GND on the board.
• Try manually entering bootloader mode if auto-reset fails.

If these steps do not resolve the issue, please provide the full esptool output logs from both the working and non-working machines for further analysis.

---

References integrated from Espressif documentation:

• Automatic Bootloader – ESP32
• Flashing Troubleshooting – ESP32
• Troubleshooting – ESP32
• Basic Options – ESP32
• Writing to Flash Succeeds but Program Doesn’t Run – ESP32-P4

[jedi7]

Thanks for the info, @tjhayko. To help narrow this down, a couple of questions:

• Are the USB ports on both computers USB 2.0 or USB 3.0 ?
• How is the HW powered? (e.g., solely through USB, or using an external power supply?)
• What operating system is the second computer running?

From the log traces, it appears the ESP32 is failing to enter download mode on both systems. We can see entries like "Connecting to SAVE AP", which indicates the chip is still running in its normal application mode and hasn't been reset into the bootloader.

To move forward, it would be very helpful to see the signal behavior on the strapping pins. Are you able to probe the GPIO0 (BOOT) and EN (Enable) pins with an oscilloscope or logic analyzer during the upload attempt? This would tell us definitively if the correct boot sequence is being triggered.

[tjhayko]

Unfortunately, I do not have either a oscilloscope or a logic analyzer. I have a multimeter, but I suspect that's not terribly useful in this scenario.

Are the cheap 8 channel logic analyzers like this one https://www.amazon.ca/Comidox-Analyzer-Device-Channel-Arduino/dp/B07KW445DJ/ref=sr_1_5?sr=8-5 useful enough for this? I'm not opposed to buying an inexpensive one if it is useful enough to be helpful. I will also check my social circle to see if there is one I could borrow.

Just a quick question: if the application I loaded is running on both, how does the download ever work? I read something about being able to specify "reset strategies" for ESPtool. Would that perhaps be something I could try in the meantime?

BTW, I've updated the description of the issue to identify that EN and GPIO0 appear to be connected RTS and DTR respectively.

I've tried both USB 3.0 and USB 2.0 ports on the not working computer, but the behavior is the same.

Both are solely powered via USB, and both computers are running Windows 11 Pro.

[jedi7]

@tjhayko I primarily use a USB oscilloscope for debugging because it allows me to see the voltage levels. However, the best tool depends on your specific use case, so I can't give a definitive recommendation.

Looking at your traces, I can see that even on the old computer, it takes a longer time to switch into download mode. When I run the programming sequence myself, I typically see just one sync sequence (the "UUUUU" strings) before programming starts successfully.

In your traces, however, I see multiple failed sync attempts. The tool is sending the sync command, but the ESP32 isn't in download mode to respond correctly. Instead, we're seeing the serial output from the already-running firmware.

As a reminder, entering download mode is triggered by toggling the RTS and DTR lines (see the Espressif boot mode documentation). This is the point where the process is failing.

From this evidence, it seems like a hardware-related issue. A common culprit is excessive capacitance on the RTS/DTR lines, which can slow down or distort the control signals, preventing a clean entry into the bootloader. It's hard to say for sure without probing the board.

Have you found any relevant discussions in the product's forums or issue trackers that might point to a known hardware design flaw?

[tjhayko]

My discussions with the board designers did result in them sending a replacement board, which has the same problem. After that, it was pretty much "it works for us" :(, although they did say it's remotely possible that it could be a power issue. I've also read that power issues cause all kinds of problems, which is why I originally tried a different computer.

I'm going to try to order both a USB oscilloscope and logic analyzer so I can try to probe the board. Am I correct that we are looking for the signals on both the EN pin and GPIO pin? A logic analyzer would probably be better, because I can capture both pins at the same time.

Thanks for the explanation of what the logs are showing. It's always fun to learn a bit more.

[jedi7]

@tjhayko Exactly, you need to look at the EN and GPIO0 pin. The USB Oscilloscopes have often two channels, so you will be able to see both pins also there.

[tjhayko]

Would a 50Mhz bandwidth oscilloscope be workable for this purpose? I'm trying to get something useful enough, but not overspend.

If I can capture the same information with a logic analyzer, I'll go with one of those as they are significantly cheaper.

[jedi7]

@tjhayko Imho, even 100kHz oscilloscope will be ok for that :-D
There sequence is:

• DTR = false
• RTS = true # chip in reset
• sleep 100ms
• DTR = true
• RTS = false # chip out of reset
• sleep 50ms
• DTR = false # latch the strap pin for some time and release

So as you can see, the times are quite big.
I'm not sure if logic analyzer will be able to see issue with the signal itself. Like too slow signal edges, etc. And If you want to play with electronics, the oscilloscope is better. The logic analyzer can be created from ESP32 ;-)

[tjhayko]

Thanks! I'll get a reasonable one and get some probes done during the attempts to download.

[dobairoland]

Please ping us if this proves to be an esptool issue.

[tjhayko]

thank you. I haven't been able to get traces with an oscilloscope yet, but I should some time this week.

[jedi7]

@tjhayko btw there is missing capacitor on the ENB, so maybe that is the issue.
" capacitor is recommended on the EN (CHIP_EN or CHIP_PU) pin for Espressif modules. The typical recommendation is to add a 1 µF capacitor between the EN pin and GND. This forms an RC delay circuit (with a 10 kΩ pull-up resistor) to ensure stable power-up and reliable reset operation."