Updating firmware in the field has always been a critical component of even the earliest of embedded systems. Access to hardware interfacing tools like a JTAG or SWD programmer provides physical access to embedded system programming ports. Other access methods for firmware updates include interfaces such as USB, automotive CAN, a serial port, and so on. Wireless port connectivity has gained prominence as more embedded devices become part of the IoT. In today’s post, we will explore such wireless, over-the-air (OTA) communications using Amazon Web Services (AWS) and FreeRTOS.
OTA Overview using AWS
OTA updates can be a bit intimidating the first time that a developer encounters them. While the process is somewhat complex, it can be broken down into fairly simple components.
Beningo Embedded Group
|Breaking down the OTA process into simple elements.|
There are three main pieces to the firmware update:
- An OEM that releases a new firmware update.
- The AWS that stores the firmware image and facilitates the update.
- Deployed devices that receive the firmware update.
The AWS plays a pretty important part in the entire process. The new firmware image is uploaded to a Simple Storage Service (S3) bucket which is used to store firmware images. Next, 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 product 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 a 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
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.
Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees which include a Master of Engineering from the University of Michigan. Feel free to contact him at email@example.com at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter.