Unable to flash ESP32-WROOM-32 (ESP32-DEVKIT-V1) when plugged in to custom PCB

Hi! I’m not entirely sure what will be helpful information for this issue. I’m hoping someone can help me.

I am working on building a kinetic sand table. It’s a project I’m doing for school and I’m stuck. I’m trying to flash this PlatformIO firmware on an ESP32-WROOM-32 (ESP32-DEVKIT-V1). It will run on this custom PCB that goes along with the firmware. There is also a separate web interface that gets uploaded as a file system after being built using yarn.

The ESP32 firmware flashes fine when it is by itself and connected to my Mac via USB. But, when I have it plugged in to the PCB, I cannot flash the ESP32. Likewise, if I flash the ESP32 (including the file system) separately and then plug it in to the PCB, the board doesn’t run. Same goes with the file system: I can’t upload the file system when the ESP32 is installed on the PCB, but the file system upload works when the ESP32 isn’t installed.

Although there will be other components connected to the PCB, I have tried it only with the ESP32 and microSD card present. I have also tried it with the buck converter added and a 24V/6A power supply.

When I try to flash the board, here is the output:

Processing dev (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 (6.6.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.20014.231204 (2.0.14) 
- tool-esptoolpy @ 1.40501.0 (4.5.1) 
- 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 65 compatible libraries
Scanning dependencies...
Dependency Graph
|-- ESP Async WebServer @ 1.2.3+sha.f71e3d4
|-- ArduinoLog @ 1.1.1
|-- TMCStepper @ 0.7.3
|-- FastLED @ 3.6.0
|-- SparkFun TSL2561 @ 1.1.0
|-- esp32FOTA @ 0.2.7
|-- WireGuard-ESP32 @ 0.1.5+sha.50e2bfd
|-- RdUtils
|-- RdConfigPinMap
|-- RdJson
|-- RdConfig
|-- RdRestAPISystem
|-- CommandScheduler
|-- RdFileManager
|-- RdLedStrip
|-- RdNTPClient
|-- RdRestAPIEndpoints
|-- RdWebServer
|-- RdWiFiManager
|-- WireGuardManager
|-- RdOTAUpdate
|-- WiFi @ 2.0.0
|-- SPI @ 2.0.0
Building in release mode
Retrieving maximum program size .pio/build/dev/firmware.elf
Checking size .pio/build/dev/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  18.2% (used 59764 bytes from 327680 bytes)
Flash: [========= ]  91.0% (used 1371413 bytes from 1507328 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: /dev/cu.usbserial-0001
Uploading .pio/build/dev/firmware.bin
esptool.py v4.5.1
Serial port /dev/cu.usbserial-0001
Connecting..........
Chip is ESP32-D0WD-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 30:c9:22:32:e4:a8
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
WARNING: Failed to communicate with the flash chip, read/write operations will fail. Try checking the chip connections or removing any other hardware connected to IOs.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00005fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Flash will be erased from 0x0000e000 to 0x0000ffff...
Flash will be erased from 0x00010000 to 0x00160fff...
Compressed 17536 bytes to 12202...

A fatal error occurred: Packet content transfer stopped (received 8 bytes)
*** [upload] Error 2
==================================================== [FAILED] Took 13.67 seconds ====================================================

*  The terminal process "platformio 'run', '--target', 'upload', '--environment', 'dev'" terminated with exit code: 1. 
*  Terminal will be reused by tasks, press any key to close it. 

When I open Monitor, this output loops repeatedly:

rst:0x10 (RTCWDT_RTC_RESET),boot:0x37 (SPI_FAST_FLASH_BOOT)
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
invalid header: 0xffffffff
ets Jul 29 2019 12:21:46

I have looked so many places and haven’t been able to find the answer. If anyone can help, I would greatly appreciate it!

Here is the DEVKIT-V1 board I’m trying to use: Amazon.com

Here is the yarn-compiled web interface: GitHub - acvigue/TranquilVue: A modern Vue 3 / TypeScript web app to control custom built kinetic art robots.

Is one or more strapping pins of the ESP32 connected on your PCB?

The ESP32 chip has the following strapping pins:

  • GPIO 0 (must be LOW to enter boot mode)
  • GPIO 2 (must be floating or LOW during boot)
  • GPIO 4
  • GPIO 5 (must be HIGH during boot)
  • GPIO 12 (must be LOW during boot)
  • GPIO 15 (must be HIGH during boot)

See Section “Strapping Pins” at ESP32 Pinout Reference: Which GPIO pins should you use? | Random Nerd Tutorials

Thank you so much for the reply!

Here is the pinout for the DevKit V1 board that I’m using.

51FzgrVl-cL.AC

If I’m reading the pinout and schematic correctly,

  • GPIO 0 is not one of the pins on the DevKit V1 board.
  • GPIO 2 is connected to the microSD card with a 10k resistor to DevKit V1 3V3
  • GPIO 4 is connected to the microSD card with a 10k resistor to DevKit V1 3V3
  • GPIO 5 is not one of the pins on the DevKit V1 board.
  • GPIO 12 is connected to the microSD card with a 10k resistor to DevKit V1 3V3
  • GPIO 15 is connected to the microSD card with a 10k resistor to DevKit V1 3V3

Looking at the link you posted, it says:

These are used to put the ESP32 into bootloader or flashing mode. On most development boards with built-in USB/Serial, you don’t need to worry about the state of these pins. The board puts the pins in the right state for flashing or boot mode. More information on the ESP32 Boot Mode Selection can be found here.

I admittedly don’t know a lot about circuitry. I’m more of a coder. Despite the above quote that the board should take care of itself when using the USB to boot/flash, I’m guessing the resistors connected to the board’s 3V3 are pulling up the voltage and causing the problem. But, the DevKit board needs to be able to communicate with the microSD card in order for the firmware to run.

Thank you so much for any additional help you can provide!

I’m limited to posting one image per post because I’m a new user. Here is the schematic.

I saw this and I am wondering if maybe this is part of the problem.

No because you said: when its running outside the custom pcb, flashing works fine.

Check the the pins which must stay at a given level when the esp32 is booting (see the link to randomnerdtutorials). Especially the bootstrap pins.

1 Like

I appreciate your continued support! Here are the voltages when connected only to external (not USB) power:

  • GPIO 0 - No Pin, but measuring at chip reads 3.26V
  • GPIO 2 - 1.31V
  • GPIO 4 - 2.48V
  • GPIO 5 - 3.26V (I was wrong above about there not being a pin)
  • GPIO 12 - 2.48V
  • GPIO 15 - 3.26V

I confirmed that VIN is at 5.02V.

When connected only to USB, the voltages are the same except at VIN, it reads 5.26V.

Not sure if it makes a difference, but I noticed that when external power is provided and the board is connected via USB, the USB COM port (/dev/cu.usbserial-0001) is not accessible.

OMG. I think I solved it! Hopefully I’m not speaking prematurely.

The PCB and code uses sdmmc instead of SPI to talk to the microSD card, which is on the PCB. Because it uses GPIO12, there is a conflict between bootstrap and SDIO. I found this:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/sd_pullup_requirements.html#strapping-conflicts-dat2

It is also mentioned in the github for sdmmc: esp-idf/examples/storage/sd_card/sdmmc/README.md at master · espressif/esp-idf · GitHub

The solution was to run this:

espefuse.py set_flash_voltage 3.3V

This removes GPIO12 as a bootstrap pin!

I can now flash the ESP32 while it is installed on the PCB. The board no longer is in an endless boot loop and the firmware actually runs! (Jury is still out on whether the rest of the components will work as expected once they are connected to the PCB.)

@sivar2311 Thank you for your advice. Although you didn’t provide me with the direct answer, it was your link to the bootstrap pins that led me down this path. Thank you!

1 Like

I am pleased that I was able to point you in the right direction, even if I could not give you a direct answer.
I only ever use the GPIOs from 16 to 39 on an ESP32 to be on the safe side.

For some time now I have only been using ESP32-S3, which offers even more GPIOs.

Good luck with continuing your project!

1 Like