Skip to content

esp-serial-flasher⚓︎

The package ships one command line tool:

  • linux_flasher: upstream utility using explicit address/file pairs

Both tools also accept an optional chip check:

  • -c, --chip <name> validates the detected chip (esp32c3, esp32s3, esp32c6, ...)

Complete usage examples⚓︎

Flash ESP32-C3 bootloader + partition table + app image:

linux_flasher -p /dev/ttyACM0 -c esp32c3 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 firmware.bin

Flash with explicit baudrate and no stub (ROM mode):

linux_flasher -p /dev/ttyACM0 -b 460800 -n -c esp32c3 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 firmware.bin

Typical ESP32-C3 map used by these examples:

  • 0x0000 bootloader.bin
  • 0x8000 partition-table.bin
  • 0x10000 application image

Notes compared to esptool⚓︎

Equivalent address layout for:

esptool --chip esp32c3 ... write_flash 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 app.bin

is exactly:

  • bootloader at 0x0
  • partition table at 0x8000
  • app image at 0x10000

linux_flasher always uses explicit <addr> <file> pairs.

Externalization⚓︎

Externalization: supported means the package can be externalized, but it is enabled only if
EXTERNAL_FREETZ_PACKAGE_ESP_SERIAL_FLASHER=y is selected in menuconfig.

If that symbol is not enabled, binaries remain in /usr/bin as usual.

Note on cdc_acm and AVM devices⚓︎

On FRITZ!Box models such as the 7590 AX, cdc_acm may already be provided by AVM in the stock firmware,
so you do not necessarily need to enable a separate kernel option in Freetz.

If /dev/ttyACM0 appears only after a replug, the practical fix is to make sure cdc_acm is loaded at boot
through the Freetz module list (/tmp/flash/mod/modules), not to add a package dependency.
That means the package can stay usable with a simple module autoload, while the replug symptom usually points
to USB enumeration timing rather than to esp-serial-flasher itself.