How to burn firmware using esptool?

General
#1
  1. My goal is to verify that it will be possible to burn firmware to ESP32 DevKitC from the IO pins instead of from the USB port, using linux on the host machine (eventually our design will have just the ESP32-WROOM on it instead of the entire DevKitC).
  2. My actions are: I have connected an FTDI friend to the Gnd, 3.3v, TXD and RXD pins on the ESP32.
  3. The result I see is: I can communicate with the ESP32 fine (for example, both ‘mos console’ and miniterm can communicate with a program previously loaded into the ESP32. I can put the ESP32 into bootloader mode by grounding IO0 and cycling EN, the chip responds with:
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x3 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download
  1. My expectation & question is: I would expect to be able to put the ESP32 into bootloader mode, then be able to do a ‘mos flash’ and have it complete. Instead, ‘mos flash’ just keeps trying to connect:
Loaded sti-gateway/esp32 version 1.1.0 (20190515-201437/1.1.0-gfe70279-master)
Using port /dev/ttyUSB0
Opening /dev/ttyUSB0 @ 115200...
Connecting to ESP32 ROM, attempt 1 of 10...
Connecting to ESP32 ROM, attempt 2 of 10...
Connecting to ESP32 ROM, attempt 3 of 10...
Connecting to ESP32 ROM, attempt 4 of 10...
Connecting to ESP32 ROM, attempt 5 of 10...
Connecting to ESP32 ROM, attempt 6 of 10...
Connecting to ESP32 ROM, attempt 7 of 10...
Connecting to ESP32 ROM, attempt 8 of 10...
Connecting to ESP32 ROM, attempt 9 of 10...
Connecting to ESP32 ROM, attempt 10 of 10...
Error: /build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/flash/esp/rom_client/rom_client.go:156: failed to connect to ESP32 ROM
/build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/flash/esp/rom_client/rom_client.go:108: failed to connect to ROM
/build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/flash/esp/rom_client/rom_client.go:94: failed to create ROM client
/build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/flash/esp/flasher/common.go:43: Failed to talk to bootloader.
See https://github.com/espressif/esptool/wiki/ESP8266-Boot-Mode-Selection
for wiring instructions or pull GPIO0 low and reset.
/build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/flash/esp/flasher/flash.go:55: 
/build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/flash.go:201: 
/build/mos-i_6ltm/mos-2.13.1+2034cc0~bionic0/obj-x86_64-linux-gnu/src/cesanta.com/mos/main.go:178: flash failed

Is it possible to use esptool directly to load mongoose os firmware into ESP32?

1 Like
#2

Yeah, unzip the file, see manifest.json for offsets, and use esptool to burn individual pieces.

#3

Just an experience I’ve made: If I have a lot of “busy” code on the device, which almost completely occupies the processor and doesn’t have many timing slots to catch interrupts, etc., the flashing will sometimes fail as you described. Often it helps to disconnect and reconnect the device from USB or reset it while MOS is trying to flash. At least that’s how I always got there. Sometimes you also need some patience. My approach then was to try to find the code for time-consuming loops etc. (which are usually not necessary), if these are “cleaned”, the problem was mostly gone.

#4

Issue ended up being a hardware issue with the UART.

#5

@dwegscheid thanks for following up

#6

How often did you perform it like this?

From my point of view there is happening some magic in between which will be done by mos tool.

For example the boot_cfg section does only describe the start address, the size and the value to fill in case there is no other information:

"boot_cfg": {
  "addr": 28672,
  "fill": 255,
  "size": 4096
},

But in fact, there will be not just FF, but information about start address of application firmware etc.

Am I wrong?