Serial Upload error on previously good board.

[Dark1886]

I'm having issues uploading to my board. I had previously uploaded without issues. I thought maybe I did something to my board and fried it, but another board that I haven't tinkered with also is having the same behavior. From my initial investigation it seems the automatic bootloader reset is not working as expected, but that could be a wrong assumption.

Any ideas why this could be happening?

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (6.1.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - framework-arduinoespressif32 @ 3.20007.0 (2.0.7) 
 - tool-esptoolpy @ 1.40500.0 (4.5.0) 
 - tool-mkfatfs @ 2.0.1 
 - tool-mklittlefs @ 1.203.210628 (2.3) 
 - tool-mkspiffs @ 2.230.0 (2.30) 
 - toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 45 compatible libraries
Scanning dependencies...
Dependency Graph
|-- SparkFun LIS3DH Arduino Library @ 1.0.3
|-- IRremoteESP8266 @ 2.8.6
|-- Adafruit FT6206 Library @ 1.0.6
|-- lvgl @ 8.3.7
|-- TFT_eSPI @ 2.5.31
|-- PubSubClient @ 2.8.0
|-- WiFi @ 2.0.0
|-- Wire @ 2.0.0
|-- Keypad @ 3.1.1
|-- Preferences @ 2.0.0
Building in release mode
Retrieving maximum program size .pio\build\esp32\firmware.elf
Checking size .pio\build\esp32\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [===       ]  34.2% (used 111904 bytes from 327680 bytes)
Flash: [========  ]  84.6% (used 1108533 bytes from 1310720 bytes)
Configuring upload protocol...
AVAILABLE: cmsis-dap, esp-bridge, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa
CURRENT: upload_protocol = esptool
Looking for upload port...
Using manually specified: COM9
Uploading .pio\build\esp32\firmware.bin
esptool.py v4.5
Serial port COM9
Connecting......................................

A fatal error occurred: Failed to connect to ESP32: Invalid head of packet (0x5B): Possible serial noise or corruption.
For troubleshooting steps visit: https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html
*** [upload] Error 2

[Dark1886]

Closing this. It currently appears that a USB port on my PC could not supply enough power for a stable upload. Manually holding GPIO0 low did fix this problem, but is a bad solution for multiple reasons.

If you experience this issue yoou may be able to do one of the following.

1. Different USB port, especially a motherboard USB port and not a front panel port.
2. A powered USB Hub
3. a Y splitter to plug your device into two separate ports on your PC. (I do not recommend this, but it is an option).

[GaryTill]

That's an interesting one.. what is the default charge current on the battery controller, I haven't actually checked. If it's 500ma then there is a chance this will happen occasionally on standard 500ma ports with some USB controllers/cables.

Seems like a minor issue thankfully.

[CoretechR]

@GaryTill the charge current is set to 333mA so that should be ok. But then you have the normal power consumption of the board on top. I have found that the real USB power draw is still pretty low with less than 400mA. Still it might be better to power the ESP from the battery instead from USB, instead of prioritising USB.

@Dark1886 Do you have any way to measure the USB current with your board?

[Dark1886]

@CoretechR I do have a USB power meter laying around somewhere and I can test it with that. I'm not sure if it's necessarily the overall power draw that is causing the problem, but it may have just been the transient spikes from boot-up. I'll take a look at it tonight if I can find the meter.

[Dark1886]

Additionally, It's pretty clear I'm not the only person who has been troubled by this issue. It seems like the different USB port worked for me, but others may still have some problems. According to other threads this may help with reliablitly.

adding a 2.2uF capacitor on EN (connected between EN and GND) fix the problem

[KlausMu]

I have the same problem. No upload is possible, no matter which USB cable I use (short, thick, high quality) and which USB port (mainboard, front panel, powered USB hub). I always have to pull down GPIO0 manually. I do it by connecting R37 to GND (of the USB port). Any better solution or workaround?

[Dark1886]

I have the same problem. No upload is possible, no matter which USB cable I use (short, thick, high quality) and which USB port (mainboard, front panel, powered USB hub).

I always have to pull down GPIO0 manually. I do it by connecting R37 to GND (of the USB port).

Any better solution or workaround?

Unfortunately I have yet to find a different solution, but a powered hub or a different USB port fixes my problems so I didn't continue searching.

I believe uploading from a Linux machine could be helpful as it handles the serial communication differently.

I think adding a cap or a switch to pull down gpio0 would be needed.

[KlausMu]

I believe uploading from a Linux machine could be helpful as it handles the serial communication differently.

Indeed, uploading from the same machine, but using WSL2, worked. Strange ...

[Dark1886]

I believe uploading from a Linux machine could be helpful as it handles the serial communication differently.

Indeed, uploading from the same machine, but using WSL2, worked. Strange ...

Wow, I didn't think WSL2 Would actually work for that. But glad to hear although it is unfortunate.