OTA-Update strategy (regarding IDF updates, bootloader etc.)

novalight
Posts: 27
Joined: Tue Apr 19, 2016 1:13 pm

OTA-Update strategy (regarding IDF updates, bootloader etc.)

Postby novalight » Wed Nov 22, 2017 8:26 pm

This concerns a topic we have been discussing internally for a while.

Imagine you have hundreds of devices deployed in a remote place that can only be accessed by a technician about once per year. A few devices are available for local testing, some are installed in facilities that can be accessed within a year or so.

We develop on IDF master and our customer demands sometimes updates to the devices.

Should we work with a constant IDF or may we update IDF when compiling the OTA update APP. Could there be breaking changes in the app with respect to a then potentially outdated bootloader (which cannot be updated via OTA), e.g. some peripherals disabled which are expected to be present by new app?

I'd love to see an official guide or some best practices collection with respect to IDF updates (use master or use release versions? why?) and how to ensure OTA updates are compatible to the bootloaders of all devices?

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

Re: OTA-Update strategy (regarding IDF updates, bootloader etc.)

Postby ESP_Angus » Mon Dec 11, 2017 5:33 am

Sorry this post somehow got skipped over for so long.

Should we work with a constant IDF or may we update IDF when compiling the OTA update APP. Could there be breaking changes in the app with respect to a then potentially outdated bootloader (which cannot be updated via OTA), e.g. some peripherals disabled which are expected to be present by new app?


The bootloader is backwards compatible, and is designed for it to be safe to OTA update to an app compiled with a newer IDF. However where possible we recommend keeping it up to date with IDF.

If bootloader compatibility changes in a future release (unlikely but possible), it will be mentioned prominently in the release notes along with whatever steps are necessary for maintaining backwards compatibility. If you're working from master there is a chance you may be caught out by this. I'd suggest - in any case - keeping some devices with older bootloaders around that you can use for OTA testing before you deploy to customer devices.

I'd love to see an official guide or some best practices collection with respect to IDF updates (use master or use release versions? why?)


Thanks for the suggestion. Such a guide is something we've been discussing internally as well, and we hope to publish.

In general, it is best to use release versions unless you need some particular feature which is only available on the master branch.

Master branch on github has been through our CI process, so it comes with some guarantees and major breakages are unlikely. However there are always some minor regressions and bugs which are introduced and fixed as part of the development cycle.

Releases are also extensively tested by our QA team, so come with those additional guarantees. We also maintain release branches which you can track to get minor updates (ie the last stable release v2.1.1 was taken from the release/v2.0 release branch.)

We've just released IDF v3.0-rc1 (Release Candidate 1) so this is a good time to switch to this release/v3.0 branch, and settle on the V3.0 final release when it's available (soon).

Regarding OTA updates in general, In IDF v3.1 we plan to add documented methods for adding Reset To Factory and similar functionality to the bootloader. At present, this is still possible by copying the bootloader to "(PROJECT)/components/bootloader" and adding the functionality by hand to bootloader_start.c. You may want to consider this to provide additional options for devices which are receiving OTA updates.

hassan789
Posts: 40
Joined: Thu Jun 29, 2017 2:15 am

Re: OTA-Update strategy (regarding IDF updates, bootloader etc.)

Postby hassan789 » Tue Dec 12, 2017 5:11 am

Angus,
If a new OTA is rolled out that causes the device to get stuck in a bootloop; what can be done to guard again this? It it possible for the bootloader to realize this, and jump to the factory slot? or will it be stuck forever?

Who is online

Users browsing this forum: Baidu [Spider] and 7 guests