Flashing firmware¶
After idf.py build, the app binary is build/<project>.bin. How you flash it
depends on the partition table.
Factory or OTA?¶
Run idftool list and look at the app partitions:
factoryonly: useidftool factory.ota_0,ota_1: useidftool otafor day-to-day flashing. It behaves like a real OTA update, so you're testing the same path your users get.factoryand OTA slots:factoryfor the base image your devices ship with,otafor updates on top of it.
Flash the factory app¶
This writes the app to the factory partition and erases otadata, so the
bootloader boots factory next, whatever OTA slot was running before. Without a
factory partition, it writes ota_0.
Push an OTA update¶
This writes the app to the slot that isn't running, then makes that slot boot next:
The previous build stays in the other slot, so you can switch back to it.
Reflashing is fast¶
Both commands compare the binary with what's already in flash and write only the sectors that differ, or nothing if it's already there. Flashing a small change to a large app takes seconds.
To write everything regardless, add --no-skip-flashed --no-diff. See
Write options.
Switch between builds¶
See which slot boots next:
Go back to the other one:
Or erase otadata and let the bootloader fall back to factory (or ota_0):
None of these touch the apps themselves.
Check a binary before flashing¶
This prints the project name, version, IDF version, build time, and target chip.
idftool refuses to flash a binary built for a different chip; --force
overrides that.
Flash more than the app¶
To write other partitions alongside the app, name each one:
To flash a whole set of partitions from someone else's build, use a bundle.