Hi Espressif,
I am trying to get my head around the OTA procedure so I can implement it for our product . I have looked at the example readme file. The OTA as it is, is not really suitable for us as our product will be the AP rather than a station. This is my understanding of how the example works, could you please fill in the gaps:
You have a factory app (ota.c) which is simply connecting as a station to the wifi AP and then connecting to a HTTP server (on a specified port and IP) and downloading the file using a "GET" request. It then determines what partition it is currently running - if its factory , it will update OTA_0 , if its OTA_0 it will update OTA_1 and if it is OTA_1 it will update OTA_0 .
It will then download the rest of the file and as it is downloading it writes the selected OTA partition as the data is coming in.
When its done writing the partition it updates the OTA data partion to say " Run selected App partition" on the next reboot.
It then reboots the esp.
When it restarts it runs the Bootloader (in esp32 internal ROM) , which reads the OTA data partition and jumps to the selected partition.
Q1 : If one of the App partitions are running i.e. OTA_0 or OTA_1 - how do we trigger another OTA update?
Q2) : Does the bootloader check the integrity of the APP_Partition that it is selected by the OTA data partition before it loads it?
Q3) : Is it possible to just have one OTA partiton and what are the dangers? so thats just having Factory and OTA_0.
Q4) : Does every APP need ability to perform the OTA? I hope not as this would be prone to get bricked if you have a valid application without the updating ability.
Q5) Finally - our use case is that a mobile APP (wifi STA) will connect to the esp32 and provide the bin file - I think this is much more likely real world scenario - are you guys thinking of having an example for this type of update?
Thank you,
Imtiaz
OTA clarification
Re: OTA clarification
can anyone shed some light ? @ESP_igrr
Re: OTA clarification
Stage 2 bootloader is in flash and you can see the source code in esp-idf and modify if necessaryimtiaz wrote:When it restarts it runs the Bootloader (in esp32 internal ROM) , which reads the OTA data partition and jumps to the selected partition.
Well your active firmware has to support update function somehowQ1 : If one of the App partitions are running i.e. OTA_0 or OTA_1 - how do we trigger another OTA update?
Yes but I don't think it recovers from failures yetQ2) : Does the bootloader check the integrity of the APP_Partition that it is selected by the OTA data partition before it loads it?
https://github.com/espressif/esp-idf/bl ... art.c#L394
Should be OK if you don't mind booting into factory before performing an update because you can't erase/write active flash partitionQ3) : Is it possible to just have one OTA partiton and what are the dangers? so thats just having Factory and OTA_0.
Well it needs to be able to either perform an update or switch to a firmware/partition that can perform an update. And you can have a bootloader function failsafe that can force boot to factory app that can perform an update for example if a button is pressed at boot.Q4) : Does every APP need ability to perform the OTA? I hope not as this would be prone to get bricked if you have a valid application without the updating ability.
Re: OTA clarification
Hi WiFive,
Thank you for the reply.
We dont have a button on our esp32 module that can be used to have a failsafe boot to factory option.
Is there any other way you can think of that we can have a failsafe OTA mechanism - that is in case you load an application that has the updating ability broken . The other spanner in the works is that we do not want a long delay on startup.
I am sure this will be a concern for all serious esp32 users. Solid , unbrickable updating ability out in the field.
All ideas / options welcome.
@WiFive
Thanks
Imtiaz
Thank you for the reply.
We dont have a button on our esp32 module that can be used to have a failsafe boot to factory option.
Is there any other way you can think of that we can have a failsafe OTA mechanism - that is in case you load an application that has the updating ability broken . The other spanner in the works is that we do not want a long delay on startup.
I am sure this will be a concern for all serious esp32 users. Solid , unbrickable updating ability out in the field.
All ideas / options welcome.
@WiFive
Thanks
Imtiaz
Re: OTA clarification
Buttons are cheap, people love buttons, put a button!
Re: OTA clarification
Hi @WiFive,
I need a form of timer to run in the 2nd stage bootloader - blocking is fine. Since I cant use the free rtos vTaskDelay (as far as I can tell) - what are my options?
Thanks
Imtiaz
I need a form of timer to run in the 2nd stage bootloader - blocking is fine. Since I cant use the free rtos vTaskDelay (as far as I can tell) - what are my options?
Thanks
Imtiaz
Re: OTA clarification
ets_delay_us function will delay for a given number of microseconds.
Re: OTA clarification
Hi Guys,
@ ESP_igrr @WiFive,
Thanks for the help so far . I got OTA working quite painlessly so great job there Espressif.
Can you tell me how I can jump from my OTA image to my factory image without setting the boot partition to factory and resetting. This will be really handy for the way I am designing a failsafe OTA mecahnism.
Last piece in the puzzle. I can copy the bootloader code that does this but wondering if there is a cleaner , simpler way.
Thanks
Imtiaz
@ ESP_igrr @WiFive,
Thanks for the help so far . I got OTA working quite painlessly so great job there Espressif.
Can you tell me how I can jump from my OTA image to my factory image without setting the boot partition to factory and resetting. This will be really handy for the way I am designing a failsafe OTA mecahnism.
Last piece in the puzzle. I can copy the bootloader code that does this but wondering if there is a cleaner , simpler way.
Thanks
Imtiaz
Re: OTA clarification
Hi ,
You can ignore the last request. Ive modified teh 2nd stage bootloader to jump to factory app if the OTA image fails verify.
Thanks
Imtiaz
You can ignore the last request. Ive modified teh 2nd stage bootloader to jump to factory app if the OTA image fails verify.
Thanks
Imtiaz
Re: OTA clarification
Hi Imtiaz,
Glad that it sounds like you got everything working.
We'll add these features to the esp-idf built-in OTA mechanism as well.
Regarding image validation failing, it should currently be impossible to set the OTA slot to boot from an invalid app image. However you're entirely correct that the bootloader should fallback cleanly if it happens that the selected OTA image becomes corrupt.
Regarding factory reset, we will also add some generic hooks so it's easier to implement a factory reset procedure of this type. At the moment modifying the bootloader program directly, as you've done, is the best avenue.
Thanks for pointing these items out.
Angus
Glad that it sounds like you got everything working.
We'll add these features to the esp-idf built-in OTA mechanism as well.
Regarding image validation failing, it should currently be impossible to set the OTA slot to boot from an invalid app image. However you're entirely correct that the bootloader should fallback cleanly if it happens that the selected OTA image becomes corrupt.
Regarding factory reset, we will also add some generic hooks so it's easier to implement a factory reset procedure of this type. At the moment modifying the bootloader program directly, as you've done, is the best avenue.
Thanks for pointing these items out.
Angus
Who is online
Users browsing this forum: Google [Bot] and 264 guests