ESP32 bootloader acting weird - Page 1
Forum section: electronics / general

author: HwAoRrDk
author_rank: Super Contributor
timestamp: August 13, 2025, 08:38:00 am
content: I have an ESP32-WROOM-32D module on a DevKitC-V4 board that I last used a couple of months ago. It worked just fine last time I used it, and it has just been sitting in a breadboard untouched since.Now, today, I go to connect it to a new Windows 11 system, and it doesn't seem to want to work any more. First time I hooked it appeared not to run the last code I left on it. When attempting to re-program it, I get the dreaded "Invalid head of packet (0x01): Possible serial noise or corruption" (the exact byte value it reports changes - not always 0x01). Also, I sometimes get, bizarrely, a "This chip is ESP32-S2, not ESP32. Wrong chip argument?".The following things didn't change the situation:- Ensure voltages are good - solid 3.3V.- Changed the USB cable.- Remove the board from the breadboard.- Changed baud rate to something slower - 115200, 9600 even.I broke out the oscilloscope. Serial TX and RX look good, appears to be 115200. Time for the logic analyser...Is it being reset into the bootloader properly with the appropriate EN/IO0 sequence? Yes. I can see on the logic analyser that it comes up and responds with:Code:ets Jun 8 2016 00:22:57rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))waiting for downloadAfter that I can see that there are what appear to be properly-formatted commands and responses going back-and-forth, but things are... weird.On a sample capture that resulted in a "Invalid head of packet (0x01): Possible serial noise or corruption" error, the communications (from ESP32's point of view) proceed as follows:1. RX: A SYNC command.2. RX: Another SYNC command.3. TX: Eight SYNC responses.4. RX: A GET_SECURITY_INFO command.5. TX: Another eight SYNC responses?!6. RX: A READ_REG command.7. TX: A READ_REG response.Nothing further, because esptool errors out at that point.This is what I got out of esptool when run with the--traceoption:Code:esptool v5.0.0Serial port COM3:Connecting...TRACE +0.000 --- Cmd SYNC (0x08) | data_len 36 | wait_response 1 | timeout 0.100 | data0707122055555555 5555555555555555 | ... UUUUUUUUUUUU5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU55555555 | UUUU ---TRACE +0.000 Write 46 bytes:c000082400000000 0007071220555555 | ...$........ UUU5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU5555555555555555 5555555555c0 | UUUUUUUUUUUUU.TRACE +0.110 No serial data received..TRACE +0.053 --- Cmd SYNC (0x08) | data_len 36 | wait_response 1 | timeout 0.100 | data0707122055555555 5555555555555555 | ... UUUUUUUUUUUU5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU55555555 | UUUU ---TRACE +0.000 Write 46 bytes:c000082400000000 0007071220555555 | ...$........ UUU5555555555555555 5555555555555555 | UUUUUUUUUUUUUUUU5555555555555555 5555555555c0 | UUUUUUUUUUUUU.TRACE +0.000 Read 1 bytes: c0TRACE +0.000 Read 1 bytes: 01TRACE +0.000 Read 3 bytes: 080400TRACE +0.000 Read 1 bytes: 12TRACE +0.000 Read 11 bytes: 20555500000000c0c00108TRACE +0.000 Received full packet: 010804001220555500000000TRACE +0.014 Read 68 bytes:0400122055550000 0000c0c001080400 | ... UU..........1220555500000000 c0c0010804001220 | . UU...........555500000000c0c0 0108040012205555 | UU........... UU00000000c0c00108 0400122055550000 | ........... UU..0000c0c0 | ....TRACE +0.000 Received full packet: 010804001220555500000000TRACE +0.000 Received full packet: 010804001220555500000000TRACE +0.000 Received full packet: 010804001220555500000000TRACE +0.017 Received full packet: 010804001220555500000000TRACE +0.004 Received full packet: 010804001220555500000000TRACE +0.000 Read 27 bytes:0108040012205555 00000000c0c00108 | ..... UU........0400122055550000 0000c0 | ... UU.....TRACE +0.000 Received full packet: 010804001220555500000000TRACE +0.000 Received full packet: 010804001220555500000000TRACE +0.018 --- Cmd GET_SECURITY_INFO (0x14) | data_len 0 | wait_response 1 | timeout 3.000 | data ---TRACE +0.000 Write 10 bytes: c00014000000000000c0TRACE +0.000 Read 1 bytes: c0TRACE +0.000 Read 1 bytes: 01TRACE +0.000 Read 9 bytes: 080400122055550105TRACE +0.000 Read 1 bytes: 00TRACE +0.000 Read 11 bytes: 00c0c00108040012205555TRACE +0.000 Received full packet: 010804001220555501050000TRACE +0.211 --- Cmd READ_REG (0x0a) | data_len 4 | wait_response 1 | timeout 3.000 | data 00100040 ---TRACE +0.000 Write 14 bytes: c0000a04000000000000100040c0TRACE +0.000 Read 89 bytes:01050000c0c00108 0400122055550105 | ........... UU..0000c0c001080400 1220555501050000 | ......... UU....c0c0010804001220 555501050000c0c0 | ....... UU......0108040012205555 01050000c0c00108 | ..... UU........0400122055550105 0000c0c001080400 | ... UU..........1220555501050000 c0 | . UU.....TRACE +0.000 Read invalid data:01050000c0c00108 0400122055550105 | ........... UU..0000c0c001080400 1220555501050000 | ......... UU....c0c0010804001220 555501050000c0c0 | ....... UU......0108040012205555 01050000c0c00108 | ..... UU........0400122055550105 0000c0c001080400 | ... UU..........1220555501050000 c0 | . UU.....TRACE +0.000 Remaining data in serial buffer:A fatal error occurred: Invalid head of packet (0x01): Possible serial noise or corruption.I have no idea why it's not working. Is the above sequence of communications normal? The multiple repeated SYNC responses don't seem right to me. I'm not sure what "head" part of any of the received responses it is complaining about. WTF is going on?

author: HwAoRrDk
author_rank: Super Contributor
timestamp: August 13, 2025, 08:39:43 am
content: By the way, I found this Saleae Logic protocol analyser extension that decodes the ESP32 bootloader protocol:https://github.com/usmanrazasaif/Saleae-HLA-ESP32-BootloaderSeems to work great.

author: HwAoRrDk
author_rank: Super Contributor
timestamp: August 13, 2025, 04:40:49 pm
content: I found the problem. The problem was esptool!After some more analysis, as far as I could see, the ESP32 wasn't doing anything wrong. So what else? On a whim, I decided to check what version of esptool I was using, and whether that was the latest version. I'm using the Arduino IDE board package for ESP32, and that currently bundles esptool 5.0.0. So I check out the esptool GitHub repository release, and what do I find? Version5.0.2has a note "Fix buffering issues with CP2102 converter causing connection failures". Wait, my board uses a CP2102! And, the linked commit leads to abug reportvery similar to the trouble I've been having.I tried using the 5.0.2 release of esptool, and now everything works! FFS, why are Espressif bundling a known-buggy version with their latest Arduino board package? Although, to be fair, it sounds like this is partly due to behaviour of the CP2102 driver on Windows, but then I'm just running whatever driver Windows update delivered and didn't get much choice in the matter.

author: m k
author_rank: Super Contributor
timestamp: August 13, 2025, 07:34:36 pm
content: I have an ESP8266 shield with unknown state.Arduino as an USB communicator I can't get anything rational from the ESP.Arduino IDE is also out of the loop, can't see it at all.(timed out waiting for packet header)If strapping pins are externally pulled(0 , 2 and 15 up) the board can be occasionally started by reset so that a blue LED start blinking.But even then the blinking period is not steady, one case is short and other very long.I guess it's gone.

author: m k
author_rank: Super Contributor
timestamp: September 08, 2025, 06:27:57 pm
content: Nope, the shield is fine.UNO's CH340 couldn't support it, separate FT232R had no problems.Can't say what those LEDs were, it's a WiFi scanner now.E,maybe active reset of UNO is not releasing its RS-side signals.