OTA clarification

imtiaz
Posts: 106
Joined: Wed Oct 26, 2016 1:34 am

OTA clarification

Postby imtiaz » Tue Feb 14, 2017 11:42 pm

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

imtiaz
Posts: 106
Joined: Wed Oct 26, 2016 1:34 am

Re: OTA clarification

Postby imtiaz » Thu Feb 16, 2017 5:09 am

can anyone shed some light ? @ESP_igrr

WiFive
Posts: 1218
Joined: Tue Dec 01, 2015 7:35 am

Re: OTA clarification

Postby WiFive » Thu Feb 16, 2017 6:35 am

imtiaz wrote:When it restarts it runs the Bootloader (in esp32 internal ROM) , which reads the OTA data partition and jumps to the selected partition.

Stage 2 bootloader is in flash and you can see the source code in esp-idf and modify if necessary
Q1 : If one of the App partitions are running i.e. OTA_0 or OTA_1 - how do we trigger another OTA update?

Well your active firmware has to support update function somehow
Q2) : Does the bootloader check the integrity of the APP_Partition that it is selected by the OTA data partition before it loads it?

Yes but I don't think it recovers from failures yet
https://github.com/espressif/esp-idf/bl ... art.c#L394
Q3) : Is it possible to just have one OTA partiton and what are the dangers? so thats just having Factory and OTA_0.

Should be OK if you don't mind booting into factory before performing an update because you can't erase/write active flash partition
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.

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.

imtiaz
Posts: 106
Joined: Wed Oct 26, 2016 1:34 am

Re: OTA clarification

Postby imtiaz » Thu Feb 16, 2017 7:20 pm

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

WiFive
Posts: 1218
Joined: Tue Dec 01, 2015 7:35 am

Re: OTA clarification

Postby WiFive » Fri Feb 17, 2017 3:48 am

Buttons are cheap, people love buttons, put a button!

imtiaz
Posts: 106
Joined: Wed Oct 26, 2016 1:34 am

Re: OTA clarification

Postby imtiaz » Thu Feb 23, 2017 12:46 am

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

ESP_igrr
Posts: 870
Joined: Tue Dec 01, 2015 8:37 am

Re: OTA clarification

Postby ESP_igrr » Thu Feb 23, 2017 12:52 am

ets_delay_us function will delay for a given number of microseconds.

imtiaz
Posts: 106
Joined: Wed Oct 26, 2016 1:34 am

Re: OTA clarification

Postby imtiaz » Thu Feb 23, 2017 8:50 pm

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

imtiaz
Posts: 106
Joined: Wed Oct 26, 2016 1:34 am

Re: OTA clarification

Postby imtiaz » Thu Feb 23, 2017 9:50 pm

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

ESP_Angus
Posts: 617
Joined: Sun May 08, 2016 4:11 am

Re: OTA clarification

Postby ESP_Angus » Thu Feb 23, 2017 11:55 pm

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

Who is online

Users browsing this forum: No registered users and 7 guests