In our use of ESP32-S3, we specify three app partitions. One is a small factory partition that we use for factory reset and recovery, and the other two are OTA partitions we use for running our main application and updating in an A->B fashion.
By default cargo-espflash flash (and espflash flash) look at the provided partition table and flash the application from the provided (or built) ELF file into the first app partition found. This usually results in an error in our case because the application we are flashing doesn't fit into the factory app partition.
We're able to work around this by building separately, converting the ELF to a .bin, and then using write-bin, but it makes our tools more complicated and fragile.
I know not everyone is using three apps like this, but I bet there are others interested in targeting either the ota_0 or ota_1 partition when flashing a binary.
In our use of ESP32-S3, we specify three app partitions. One is a small factory partition that we use for factory reset and recovery, and the other two are OTA partitions we use for running our main application and updating in an A->B fashion.
By default
cargo-espflash flash(andespflash flash) look at the provided partition table and flash the application from the provided (or built) ELF file into the first app partition found. This usually results in an error in our case because the application we are flashing doesn't fit into the factory app partition.We're able to work around this by building separately, converting the ELF to a .bin, and then using
write-bin, but it makes our tools more complicated and fragile.I know not everyone is using three apps like this, but I bet there are others interested in targeting either the
ota_0orota_1partition when flashing a binary.