Page 1 of 1

Comparing the ESP32 and Arduino firmware flash procedures

Posted: Mon Apr 26, 2021 9:16 am
by kmulier
1. Question

I'm trying to fully understand the firmware flash procedure - both hard- and software - on ESP32 boards such as the ESP 32 PICO KIT. Instead of asking an open question, I've studied the subject first and will make an in-depth comparison of the ESP32 vs Arduino board firmware flash procedures below. Please let me know if my interpretations are correct.

2. Context

I'm part of a development team creating a new, free IDE for microcontrollers: Embeetle IDE (https://embeetle.com). We're currently making efforts to support the ESP chip family in our IDE. Your help can boost this effort.

3. Comparing the ESP32 and Arduino firmware flash procedures

3.1 Arduino firmware flash procedures

The Arduino Uno board provides a very convenient firmware flash procedure through a virtual COM-port. Observe the ATMEGA328P target microcontroller in the middle of the figure below. On the left is an ATMEGA16U2 which is configured as a USB to UART converter. The PC sends the firmware binary through the USB cable, the ATMEGA16U2 chip converts those USB signals into UART and it finally arrives at the target ATMEGA328P MCU. Only if an uncorrupted bootloader is running on the target, the firmware binary will be flashed properly.

This flash procedure is pretty convenient, because it doesn't require any device installation on the PC. You just need to launch avrdude and connect it to the right COM-port (or tty-port on Linux).

Image

If the target chip has no bootloader - or the bootloader is corrupted - the above mentioned flash procedure won't work. You'll need a "flash probe" such as the AVR ISP mkII or Atmel-ICE. This probe should be connected to the ICSP connector and uses the SPI protocol for flashing (also TPI and PDI protocols are possible, but that would lead us off-topic). The connection itself should look like this:

Image

3.2 ESP32 firmware flash procedures

Just like an Arduino Uno, the ESP32 PICO KIT (https://docs.espressif.com/projects/esp ... o-kit.html) can also be flashed through a virtual COM-port. Based on the PICO KIT v4.1 schematic, I've drawn the following simplified block diagram:

Image

The CP2102N chip converts USB into UART and provides even hardware flow control signals. The ESP32 target chip has a built-in (first-stage) bootloader to write the firmware received over the UART lines. In some way, you can compare this to the bootloader on Arduino MCUs.

However, there is a big difference. While the Arduino MCU bootloaders can be corrupted, the (first-stage) ESP32 bootloader is hardwired in ROM. In other words, it's burned in silicon.

Aside from flashing a firmware through the UART lines, the ATMEGA328P can be flashed through its SPI pins (see ICSP connector on Arduino Uno) if you have an AVR ISP mkII or Atmel-ICE probe. Is something similar possible for the ESP32 chip?

Question: Does the ESP32 chip have an SPI, JTAG, ... interface to flash all of its firmware? Or are the UART lines the only way?
Question: What "firmware flash probes" exist for the ESP32? I'm thinking about something comparable to the AVR ISP mkII or Atmel-ICE probes.

Note: I know about OTA flashing (Over The Air), but I'm not referring to that. Right now, I'm only looking at the typical ways developers flash their MCUs while working on a prototype.

Re: Comparing the ESP32 and Arduino firmware flash procedures

Posted: Wed Apr 28, 2021 5:42 am
by ESP_Sprite
There is support for JTAG flashing in OpenOCD, I think. SPI flashing is not really supported (though I think in theory you could whip up a solution that boots from SDIO/SPI and use that to run some sort of stub, however that is entirely unexplored and partially undocumented territory). SPI flashing also wouldn't really give an advantage: when you do this on an AVR, it allows you to reclaim the flash normally used by the bootloader for something else; as the bootloader is in ROM on the ESP32, it doesn't detract from the available flash in the first place. Note that the ESP32 chips with some sort of USB (-S2 and -C3 at this moment) also support flashing, by emulating an usb-to-serial thing internally and (in the case of the S2) also by using DFU.