ESP32 flashing issue on custom hardware

[ashesman]

Hi,

Using a custom hardware design based closely on the WRover dev kit, I am having some trouble flashing a new ESP32. It it partially working. I am using a FTDI USBN-UART cable to flash using "make flash". My project builds and flashes ion the dev kit, but not custom hardware. I am using a button for the GPIO0 boot mode selection, RTS for the EN pin (directly connected). I get the following error when trying to flash:

Code: Select all

$ make flash
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5
Compiler version: 5.2.0
Python requirements from C:/msys32/home/Ashley/esp/esp-idf/requirements.txt are satisfied.

App "sd_card" version: 2f52862-dirty
Flashing binaries to serial port COM12 (app at offset 0x20000)...
esptool.py v2.7-dev
Serial port COM12
Connecting....
Chip is ESP32D0WDQ5 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
MAC: 30:ae:a4:d3:c5:b0
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Warning: Could not auto-detect Flash size (FlashID=0x0, SizeID=0x0), defaulting to 4MB
Flash params set to 0x0220
Compressed 24480 bytes to 14629...
Wrote 24480 bytes (14629 compressed) at 0x00001000 in 1.3 seconds (effective 150.3 kbit/s)...

A fatal error occurred: Timed out waiting for packet header
make: *** [/home/Ashley/esp/esp-idf/components/esptool_py/Makefile.projbuild:67: flash] Error 2

I think it has flashed the bootloader. When powered up I get this message showing the reset reason (power on) and pin states).

Code: Select all

$ make monitor
Toolchain path: /opt/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc
Toolchain version: crosstool-ng-1.22.0-80-g6c4433a5
Compiler version: 5.2.0
Python requirements from C:/msys32/home/Ashley/esp/esp-idf/requirements.txt are satisfied.
MONITOR
--- idf_monitor on COM12 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0xf (UART_BOOT(UART0))

After doing some looking into the ESP32 WROVER KIT schematic (https://dl.espressif.com/dl/schematics/ ... _SCH-2.pdf, The only difference I can spot with it and the custom firmware is there is a 100n cap and 10k pulup on the EN pin vs a 1n cap and 12k on the dev kit. I dont know if that is significant in terms of the flash tools timing? Also the dev kit has transistors to control the EN and GPIO pins from RTS and DTR as described herehttps://github.com/espressif/esptool/wi ... -Selection.

Can anybody guide me on working out what is going on here?

[ashesman]

RESOLVED:

GPIO2 was not held low during startup as is required. The rst:0x1 (POWERON_RESET),boot:0xf (UART_BOOT(UART0)) line says that GPIO2 was high (bit 3 set). I must have had brain failure when reviewing the pin states as it is quite obvious! Changing GPIO2 state to low at startup allowed me to flash as expected...

I cannot see how GPIO2 is held low on the WROVER kit but...

[ashesman]

I am still stuck a little bit on this!!! GPIO2 needs to be held low at startup (typically via a pull down), but a pullup is required for this pin to be used for the SD interface. The WROVER dev kit only has a pullup as far as I can see on the SD card lines.

How is control of the GPIO2 pin normally achieved? A transistor that could pull it low while GPIO0 was driven low at startup could possibly do the trick?

Any suggestions?

[ESP_Sprite]

I think that's actually what the wrover devkit does, indeed.

[ashesman]

I certainly cant see where they do it! Any indication as to where on the schematic they do it? I can see a transistor or EN and IO0 lines, but not IO2!

[ESP_Sprite]

It's there, but only in the current releases of the boards: the very first releases (of which the schematics pop up if you ask Google...) don't have them. V4.1 is probably what you're looking for.