Simplest way for app to set next boot from factory.

[fly135]

I'm asking this because in my experience I always do something the hard way before some says "oh just do this"

I know the flash address range from the partition file, but I'm not sure how to get the factory partition for the OTA API. So given I know the address I could use the SPI flash API to erase the range of the OTADATA partition.

Should I just call spi_flash_erase_range(0xd000, 0x2000). Numbers from csv file.

Or maybe I should call esp_partition_find on the factory and use the partition_t to call esp_ota_set_boot_partition.

Any advice?

John A

[loboris]

Or maybe I should call esp_partition_find on the factory and use the partition_t to call esp_ota_set_boot_partition.

This is the simplest and most efficient way. The system will boot from the selected partition until you set a different one or do the ota upgrade.

[chegewara]

This is interesting question. I think the second option is simpler to write code and natural, but you may want to consider situation when you restart from factory partition and for some reason esp32 reboot one more time before you perform new ota_update update. In this case, I may be wrong, esp32 will boot from old ota partition because ota_data partition is still valid.

[fly135]

Or maybe I should call esp_partition_find on the factory and use the partition_t to call esp_ota_set_boot_partition.

This is the simplest and most efficient way. The system will boot from the selected partition until you set a different one or do the ota upgrade.

Also it won't break the app if in the future someone changes up the partitions. I did use spi_flash_erase_range(0xd000, 0x2000) right now and it works. I guess it doesn't get any simpler than that if you can assume the partitions won't change.

John A

[ESP_Angus]

Also it won't break the app if in the future someone changes up the partitions. I did use spi_flash_erase_range(0xd000, 0x2000) right now and it works. I guess it doesn't get any simpler than that if you can assume the partitions won't change.

In general, I'd recommend using the partition APIs (ie esp_partition_erase_range() or esp_ota_set_boot_partition()) for this reason (and because a typo is less likely to break the entire system). But erasing the range explicitly will work fine, with the caveat you mention.