Flashing

  • flashing
  • OTA
  • flash_project_args
  • flasher_args.json
  • esptool.py
  • 32MB
  • WSL

Tests show that esptool flashing speed saturates above 1152000 baud. Is this due to a hard rate limit imposed by the driver or protocol layer to keep communication stable?

This happens because host-side and chip-side processing time has already become the main bottleneck. Simply increasing the baud rate no longer provides a meaningful improvement in download speed.

esptool itself does not enforce such a limit. Under the current conditions, there is no practical way to further increase flashing speed.

When using 32MB SPI Flash on ESP32-S3, why does an OTA partition above 16MB fail to boot with OTA app partition slot 0 is not bootable or invalid segment length 0xffff7fff?

ESP-IDF supports 32MB SPI Flash, and OTA partitions can be placed above the 16MB address range when the partition table and Bootloader configuration are correct.

For QSPI Flash, the Bootloader only enables 32-bit address cache mapping for the first 16MB address range by default. If an OTA app partition is placed above 16MB without enabling the required configuration, the Bootloader may fail to parse the image and report OTA app partition slot 0 is not bootable or invalid segment length 0xffff7fff.

Enable the following options in sdkconfig:

  • CONFIG_IDF_EXPERIMENTAL_FEATURES
  • CONFIG_BOOTLOADER_CACHE_32BIT_ADDR_QUAD_FLASH

References:

How can I find the .bin file paths and flash addresses for standalone flashing when ESP-IDF is not installed?

After the project is built, ESP-IDF generates a flash_project_args file under the build/ directory.

This file contains the full flashing arguments, including the relative paths of each .bin file and the corresponding flash addresses. For standalone flashing on a machine without ESP-IDF, use this file as the source of truth for esptool.py, Espressif Flash Download Tool, or other offline flashing tools.

After running idf.py flash in an ESP-IDF environment under WSL, which flashing files are generated and how can they be shared with others?

Before idf.py flash runs, ESP-IDF first completes the idf.py build flow and generates a set of binary files for flashing, not a single firmware file. These usually include the application image, Bootloader, and partition table. Each file has a fixed Flash address.

You can obtain the BIN files and their addresses in the following ways:

  • Check the complete flashing command printed at the end of idf.py build or idf.py flash.
  • Check build/flash_project_args.
  • Check build/flasher_args.json.

When sharing the flashing content with others, provide both the .bin files and their Flash addresses. The recipient can then flash them with Espressif Flash Download Tool, esptool.py, or another flashing tool.