Is USB CDC mode flashing supported in espflash?

[wuwbobo2021]

According to the ESP32-S2 reference manual, the download boot mode can be entered by holding GPIO0 down when the chip is reset (CHIP_PU is hold down). when CHIP_PU becomes high, the ESP32-S2FH4 becomes a USB device with DFU and CDC interfaces (303a:0002, /dev/ttyACM0 on Linux).

espflash failed to flash the chip through USB under this mode:

espflash flash -c esp32s2 -p /dev/ttyACM0 <elf file>

but this works:

espflash save-image --chip esp32s2 <elf file> <bin file>
esptool --chip esp32s2 --port /dev/ttyACM0 write_flash -z 0x10000 <bin file>

More info:

$ espflash -V
espflash 3.1.0
$ espflash board-info -c esp32s2 -p /dev/ttyACM0
[2024-07-24T21:13:34Z INFO ] Serial port: '/dev/ttyACM0'
[2024-07-24T21:13:34Z INFO ] Connecting...
Error: espflash::connection_failed

  × Error while connecting to device
  ╰─▶ Failed to connect to the device
  help: Ensure that the device is connected and the reset and boot pins are not being held down

then:

$ esptool --chip esp32s2 --port /dev/ttyACM0 chip_id
esptool.py v4.7.0
Serial port /dev/ttyACM0
Connecting...
Chip is ESP32-S2FH4 (revision v0.0)
Features: WiFi, Embedded Flash 4MB, No Embedded PSRAM, ADC and temperature sensor calibration in BLK2 of efuse V1
Crystal is 40MHz
MAC: (deleted text)
Uploading stub...
Running stub...
Stub running...
Warning: ESP32-S2 has no Chip ID. Reading MAC instead.
MAC: (deleted text)
WARNING: ESP32-S2FH4 (revision v0.0) chip was placed into download mode using GPIO0.
esptool.py can not exit the download mode over USB. To run the app, reset the chip manually.
To suppress this note, set --after option to 'no_reset'.

[LucaSain]

Any update on this one?

[jessebraham]

I am unsure whether or not we intend to support DFU mode in the upcoming release, based on previous conversation among the team regarding this. Perhaps we will change our minds and choose to include it, but as of right now I'd say this will most likely require contributions from the community for it to be added.

[igrr]

By the way, there seems to be some confusion between CDC and DFU flashing.

but this works:
esptool --chip esp32s2 --port /dev/ttyACM0 write_flash -z 0x10000

Here esptool didn't use DFU to flash, it flashed over CDC.

For DFU flashing, there is nothing ESP-specific about it AFAIK, so the standard dfu-util package can be used. I don't think it makes sense to develop a new tool or to extend espflash to support DFU, when an existing tool does the job.

OTOH, there is no technical reason why espflash shouldn't be able to flash the board over CDC in the above scenario — the protocol is exactly the same as when flashing over UART or USB_SERIAL_JTAG, we are just skipping the reset process since the chip is already in download mode. So this part could probably be fixed. However, as @jessebraham said, this will likely require a community contribution, as support for ESP32-S2 is not a priority for the team right now.

[wuwbobo2021]

@igrr Thanks for the correction.

"support for ESP32-S2 is not a priority for the team right now." Note that ESP32-S2/S3/C3/C6/H2 all support USB CDC flashing under the download boot mode. https://docs.espressif.com/projects/arduino-esp32/en/latest/tutorials/cdc_dfu_flash.html

[horatiu-udrea]

Maybe we can document thisit in the README? The behavior and the decision to not prioritize fixing it.

Because when I read this:

Espressif considers espflash and cargo-espflash to be feature-complete at this time.

I get the impression that ESP32-S2 is included as well, since it worked in previous versions.

[igrr]

I get the impression that ESP32-S2 is included as well, since it worked in previous versions.

I suppose the USB CDC download mode of ESP32-S2 isn't used as often as UART download mode is, which could be the reason why this issue hasn't been raised earlier.

Note that ESP32-S2/S3/C3/C6/H2 all support USB CDC flashing under the download boot mode.

That is true. However please note that ESP32-S3, C3, C6, H2 all have a fixed-function USB_SERIAL_JTAG peripheral which implements USB CDC (along with a vendor-specific USB-JTAG adapter). On the other hand, ESP32-S2 CDC is a software implementation which uses the USB_OTG peripheral. While finally both the USB_SERIAL_JTAG and USB_OTG based CDC implementations should work equally well, there could be some bugs which only occur in the USB_OTG case.

Maybe we can document thisit in the README? The behavior and the decision to not prioritize fixing it.

Having a section about chip-specific limitations such as this one sounds reasonable to me, but I'll defer to someone from esp-rs team whether it's an important enough thing to be added, or if keeping this issue open is enough.