[Answered]: Building apps for OTA distribution ...
Posted: Sat Jan 06, 2018 4:49 am
I've been reading about OTA. Imagine I have two partitions for OTA program storage. Lets call them ota_1 and ota_2. I also believe I need the "factory" application.
Imagine I distribute an ESP32 pre-loaded with my end-user application. My understanding is that it will be hosted in the "factory" partition. When the device boots, it will run the factory application code ... end of story. Now imagine there is a button on the ESP32. When pressed, it should "check for new application versions". When I press the button, the logic in my "application" will connect to the network and determine (say by an HTTP request or socket call) whether or not a new version of the app is available. If there is one, then the ESP32 downloads it and saves it (using the OTA APIs) in partition ota_0. Now I reboot the device. Instead of running the "factory app", it now runs the app contained in partition "ota_0" and factory app is ignored. If I now press the button again and there is another new update, the story repeats with the new version loaded into partition "ota_1" and on boot the app in "ota_1" is executed, the code in both factory and ota_0 partitions are now ignored. If we repeat this story we toggle between partitions "ota_0" and "ota_1".
This is my model of understanding. Now some questions if I may ...
1) What is the purpose of the "factory" partition? Why not just have "ota_0" and "ota_1" with the app pre-loaded in "ota_0" and then toggle between "ota_0" and "ota_1"?
2. Do I need to prepare my applications in any special way to make them work? For example, if I'm reading the partition maps correctly then factory app starts at 0x1 0000, ota_0 at 0x11 0000 and ota_1 at 0x21 0000. Is the code we have built position independent code or is there some form of flash memory address mapping at work? I'm not sensing how compiled code can "live" at distinct flash memory addresses (and presumably distinct addresses spaces in the ESP32 memory map) and still run.
Imagine I distribute an ESP32 pre-loaded with my end-user application. My understanding is that it will be hosted in the "factory" partition. When the device boots, it will run the factory application code ... end of story. Now imagine there is a button on the ESP32. When pressed, it should "check for new application versions". When I press the button, the logic in my "application" will connect to the network and determine (say by an HTTP request or socket call) whether or not a new version of the app is available. If there is one, then the ESP32 downloads it and saves it (using the OTA APIs) in partition ota_0. Now I reboot the device. Instead of running the "factory app", it now runs the app contained in partition "ota_0" and factory app is ignored. If I now press the button again and there is another new update, the story repeats with the new version loaded into partition "ota_1" and on boot the app in "ota_1" is executed, the code in both factory and ota_0 partitions are now ignored. If we repeat this story we toggle between partitions "ota_0" and "ota_1".
This is my model of understanding. Now some questions if I may ...
1) What is the purpose of the "factory" partition? Why not just have "ota_0" and "ota_1" with the app pre-loaded in "ota_0" and then toggle between "ota_0" and "ota_1"?
2. Do I need to prepare my applications in any special way to make them work? For example, if I'm reading the partition maps correctly then factory app starts at 0x1 0000, ota_0 at 0x11 0000 and ota_1 at 0x21 0000. Is the code we have built position independent code or is there some form of flash memory address mapping at work? I'm not sensing how compiled code can "live" at distinct flash memory addresses (and presumably distinct addresses spaces in the ESP32 memory map) and still run.