Updating firmware in the field has always been a critical component to nearly every embedded system since the dawn of embedded systems. Access to programming tools like a JTAG or SWD programmer and physical access to the programming port has often necessitated the need to update firmware using an alternative interface such as USB, CAN, a serial port and so on. With many devices now gaining access to the internet and becoming IoT devices, performing Over-the-Air updates has increasingly become needed. In today’s post, we will explore OTA using Amazon Web Services (AWS) and FreeRTOS.
An OTA Overview using AWS
OTA updates can be a bit intimidating the first time (or several times) that a developer encounters them. There are quite a few pieces that go into the process, but overall, the OTA process can be broken down into the simple diagram shown below:
Image Source: Beningo Embedded Group
As you can see, there are three main pieces to the firmware update:
- An OEM who releases a new firmware update
- AWS who store the image and facilitates the update
- Deployed devices that receive the firmware update
Obviously in this example AWS plays a pretty important part in the entire process. First, the new firmware image is uploaded to an S3 bucket which is used to store firmware images. Next, with the new firmware in the S3 bucket, the OEM uses the IoT Core to schedule a job that will notify deployed devices that a firmware update is available. Finally, the deployed devices download the new image, validates it and then updates their application code. At that point, the devices are updated and run the new application code until the process restarts and a new update is available.
OTA Support in Microcontrollers
The overview honestly makes OTA updates look simple and that is because all the heavy lifting is already done for developers. If a team were to decide that they wanted to build their own solution from scratch, they would find that they would be in for quite the development effort. Teams really don’t want to build their own OTA solutions but instead leverage existing solutions so that they can focus on their own products features and differentiators. For teams that are planning to use FreeRTOS, they can leverage Amazon’s FreeRTOS libraries and OTA example to get up and running with an OTA solution extremely quickly.
One nice thing about the AWS OTA solution is that it is supported by a number of microcontroller vendors. For example, if you were to visit the AWS Partner Device Catalog you would find that there are nearly three dozen silicon vendor partners with almost 60 different development boards supported! Now, not all of these support the OTA solution but quite a few do. This gives developers a pretty wide range of devices to select from and there really isn’t anything stopping a developer from porting the examples to a processor that isn’t supported.
OTA Features and Capabilities
Over the last few weeks, I’ve specifically been trying the AWS OTA demo code with FreeRTOS on an Infineon/Cypress PSoC 64 Standard Secure – AWS Wi-Fi BT Pioneer Kit for a course that I am going to be teaching. I mention this kit because I find it is particularly interesting from a security standpoint in that they don’t just support “traditional” OTA or bootloaders but have gone to great lengths to ensure that not only the firmware update can be secure but that the boot process on the microcontroller establishes a secure root-of-trust.
This brings me to the point that not all OTA or bootloader solutions are created equal and, in many circumstances, there is room for customization and configuration. For example, the PSoC 64 OTA demo by default is configured to provide a standard binary file output for the firmware that is pushed to the S3 bucket. However, within the Cypress toolchain, there is a Secure SDK tool that includes several policies that can be used to encrypt the firmware image. The devices onboard secure bootloader then decrypts and authenticates the new firmware image before ever writing it to flash.
When looking at potential OTA solutions that work with microcontrollers, there are several features that should be kept in mind such as:
- The microcontroller establishes a root-of-trust
- The microcontroller includes a secure bootloader (which verifies integrity, authenticates and decrypts the image)
- The firmware images can be encrypted
- Ease of generating a firmware update job
- Ease of managing fleets of deployed devices
Conclusions
OTA updates are quickly becoming a requirement for nearly every IoT device. These solutions help developers update their firmware in the field with minimal effort which allows them to focus more on the product than common device design elements like the bootloader and OTA. When experimenting with my Cypress PSoC 64 development board and AWS OTA demo, I found that I was able to configure AWS and my development board to perform a firmware update in about an hour the first time I did it. That’s really not too bad given that starting such a solution from scratch would normally take several months.
