ESP32 Forum

Hi,

I'm implementing application for ESP32 and got to the point where I need to start thinking of OTA update possibility for it.

I tested the native_ota_example and it worked okay. Only thing I'm having hard time grasping is the way that the 'real world applications' should implement the ota update.

The example pretty much writes the hello_world and after that it doesn't check the OTA updates anymore.

By default there is factory app and two ota - partitions. In native_ota_example the example itself acts as the factory_app as far as I've understood.

What is the proper way to initiate/do ota update once the application is running? Do I implement the functionality in my application or should I boot the device to factory_app that then would do the update? I tried the latter, but most likely due limit of the example it always updated although no changes where made to application that was 'updated' via ota.

Same for the rollback. I'm _guessing_ based on documentation application should call esp_ota_mark_app_valid_cancel_rollback or esp_ota_mark_app_invalid_rollback_and_reboot respectively and bootloader(not factory_app) will handle the rollback (if there is more than one image ie. not the first time for ota-update). I guess in case of first update bootloader would start factory_app?

Documentation has all the function calls etc. but I'm having bit hard time getting the whole picture of the process from there.

The idea is that the factory app is exactly that, the app that's burned in at the factory and doesn't change during the lifetime of the device. The bootloader will only boot that if there's no valid OTA image (or when something like a button is pressed, if you configured that in the bootloader.) Once there are OTA images, the bootloader will always boot into the newest. Normally, both the factory app as well as the OTA apps have the capability to check for and download OTA updates; they will store it in the OTA partition that is unused at that point and as soon as they have validated it's a valid image, the partition is marked as 'current' and a reboot will start that. A rollback will undo this: the most recent image is marked as invalid so whatever (older) image is in the other OTA partition will be loaded after a reboot instead.

I think it's begin to clear.

I think the name 'factory app' threw me off a bit. I home I understood correctly factory_app is my own app that would normally run on device and ota0/ota1 would just contain newer version of that application? That it's not some special application?

And reading your reply I think it cleared other unclear point earlier. I wasn't sure if update should done by factory app or the ota-partition app as well and it seems that all the apps should be possible to do that.

I guess also that I should compile all apps (factory and ota-partition ones) with same partition setup? Ie. factory + two ota partition as that's the default and I don't need any extra partitions? This would be the case if my first assumption is correct ie. that factory and ota-partition apps are the same except different version.

Yes. Note that the nomenclature is based on mass-production of products containing an ESP32: the 'factory' in 'factory app' would be the place where they assemble and first flash your product. That then goes out to your customers, and the OTA updates happen from then on.

In general, you want all apps to be capable of OTA: in practice, they have exactly the same codebase, just different versions: the factory app could be the earliest version that is thoroughly tested to be stable but does not have all the features yet as it needs to be delivered very early, the OTA apps are later versions that have features added.