LAUNCHXL-CC3235SF: OTA Firmware Update example

Hi,

We have 2 examples in the SDK.

One for a Cloud OTA (reference code in this example uses Dropbox or Github as the server, see https://www.ti.com/lit/pdf/swra510 for details on the OTA library and on customizations to other servers).

The other is the Local OTA example that uses the internal HTTP server to allow users to push an update from a mobile device in the local network.

Br,

Kobi 

1. internally we keeps the old firmware and the new firmware temporarily after anOTA download (this is true for any file with fail-safe which is the default for the MCU image).

After reset, the device will be in "test" mode and will run the new firmware. The application should do some sanity testing and then decide whether to commit the new update (i.e. make it operational and delete the old version) or reject it (either by sending a "reject" command or by resetting the MCU once-again, e.g. through a watchdog) which will cause the bootloader to revert to the old firmware and delete the new one.

This fail-safe mechanism is supported by the bootloader, so you can't access the old or new images directly.

 2. yes, you can update user file as well. If you will refer to our OTA image (created by Uniflash), you will see that we create a tar file that includes one or several files to be updated. By default all are considered as one bundle, so the fail-safe protection (mentioned before) can be used to either accept all the OTA files or reject them all.

Again all of this is being presented in the OTA documentation.

Br,

Kobi 

The OTA library first connects to an OTA (CDN) server to look for a TAR file in the users folder. This phase is different between different OTA servers, so for example the supported Github and Dropbox servers use different code and API  (see specific CDN Vendor implementations for github and dropbox).

Once the tar file gets found and its version (timestamp) is verified (i.e. OTA image timestamp is newer than the existing image), a URL to the HTTPS (file) server is being retrieved (from the OTA server).

in the 2nd phase, the library connects to the HTTPS (file) server to download the tar file and install the its content.

If you are using your own server you can skip the first phase and provide the direct URL to the tar file. To enable this, you will need to set the following in the otauser.h:

#define OTA_SERVER_TYPE     OTA_FILE_DOWNLOAD

Look for OTA_FILE_DOWNLOAD in the application and ota library to see how this can be used.

This assumes that you are using the uniflash OTA image (tar file). If so, you will enable the ota_archive to parse and install the content on the fly (as it gets downloaded). This will also enable the full OTA image authentication as explained in the OTA documentation. 

If you don't want to use the tar file as created by uniflash, then the OTA lib is not for you. You can use it as refernce.

Br,

Kobi