ESP32: A fatal error occurred: Invalid head of packet (0x80), Secure Download Mode

Development Platforms
1

I have a strange problem with my custom PCB. It has worked flawlessly for some weeks, but a few days ago the problems started. At first, I couldn’t upload code to my ESP32 anymore the Error messages I got were different each time:

  • A fatal error occurred: Invalid SLIP escape (0xdb, 0xEE)
  • A fatal error occurred: Failed to write compressed data to flash after seq 18 (result was 8000)
  • A fatal error occurred: Invalid head of packet (0xE0)

After I restarted my computer, it worked again for some time. Today the problems reoccurred.

I already tried many things:

  • Changed USB cable
  • Used the Arduino IDE
  • Reduced upload speed
  • Added upload_flags = --no-stub
  • Used a different FT232RL

The ESP32 I used is the ESP32-WROOM-32E(M113EH2800PH3Q0) / ESP32-D0WD-V3.

If I google “Chip is ESP32 in Secure Download Mode” I encounter articles about Flash encryption, is it possible that I somehow bricked my ESP32?

Processing esp32dev (platform: espressif32; board: esp32dev; framework: arduino)
-----------------------------------------------------------------------------------------------------------Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (3.4.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (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.10006.210326 (1.0.6)
- tool-esptoolpy 1.30100.210531 (3.1.0)
- tool-mkspiffs 2.230.0 (2.30)
- toolchain-xtensa32 2.50200.97 (5.2.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 31 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <ESP Async WebServer> 1.2.3
| |-- <AsyncTCP> 1.1.1
| |-- <FS> 1.0
| |-- <WiFi> 1.0
| |-- <ArduinoJson> 6.18.5
|-- <ArduinoJson> 6.18.5
|-- <SPIFFS> 1.0
| |-- <FS> 1.0
|-- <WiFi> 1.0
Building in release mode
Retrieving maximum program size .pio\build\esp32dev\firmware.elf
Checking size .pio\build\esp32dev\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [= ] 13.3% (used 43492 bytes from 327680 bytes)
Flash: [======== ] 77.0% (used 1009550 bytes from 1310720 bytes)
Configuring upload protocol...
AVAILABLE: 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...
Auto-detected: COM5
Uploading .pio\build\esp32dev\firmware.bin
esptool.py v3.1
Serial port COM5
Connecting.....
Chip is ESP32 in Secure Download Mode
Changing baud rate to 460800
A fatal error occurred: Invalid head of packet (0x80)
*** [upload] Error 2
======================================= [FAILED] Took 4.54 seconds =======================================
The terminal process "C:\Users\Maximilan\.platformio\penv\Scripts\platformio.exe 'run', '--target', 'upload'" terminated with exit code: 1.
2

Either there was an error in the serial transmission with some bit being interpreted as 0 although it being sent as 1 (bad / long cables?) or your chip is really in secure download mode. Which is suprising if you only ever used PlatformIO with the chip, because PlatformIO does not have the capability to activate Secure Boot or Flash Encryption out of the box.

The easiest way to see whether something is wrong with the computer, PlatformIO or the chip is to grab another ESP32 dev board and see if you can upload to that. If that works, the problem is likely localized in your chip.

3

Thanks for your reply!

I can upload my code to my other ESP32. I have also connected to my ESP32 via Putty and that’s the output I receive:

invalid header: 0xffffffff

invalid header: 0xffffffff

ets Jul 29 2019 12:21:46

rst:0x10 (RTCWDT_RTC_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))

waiting for download

I also measured the voltage of some pins:

IO0: 0.9V

IO12: 1.0V

That’s seems very low to me, maybe there is really something wrong with my Board?

4

Are there pull-down or pullup resistors on these lines or are they connected to an auto-reset circuit? Standard circuits per e.g. NodeMCU-32s page 11 show a pair of transistors driving EN and GPIO0 with additional 12K pullup to 3.3V on GPIO0 and EN. Do you put the board manually in downloading mode by connecting GPIO0 to GND? But it still shows up as ~1V? Or is the thing left floating?

5

That’s my circuit:

Circuit
Circuit604×626 20.6 KB

I don’t use an additional Pullup for IO0. Is that recommended?

But I think I found the issue. The resistance from IO0 to ground was very low, so I desoldered the Boot-button and also resoldered some connections. Now, I was able to upload my code. The voltage on IO0 is now at 1.5V, which seems still too low. Shouldn’t be it on ~3.3V?
,
Edit: The Pins 1 and 4 of the Boot-Button are not connected. I moved them to make a screenshot and thereby they got accidentally connected.

6

Sounds to me like the pin is still floating or being pulled up and pulled down by about equal resistances? (like 10K up, 12K down) .

Well although the datasheet (https://cdn.sparkfun.com/datasheets/IoT/esp32_datasheet_en.pdf page 9) says there are internal pullups and pulldowns on these pins, at least some people at https://www.esp32.com/viewtopic.php?f=12&t=9381&start=10 say that they needed the pullup. I’m not from Espressif so I can’t give out best practices / recommendations on ESP32 hardware design.

7

Yep, I still have 3.7 KOhm to ground. So it seems to be a Hardware problem. I will check all my connections.
Thanks for your help.