- Wi-Fi Standalone
- Wi-Fi Network Controller
- Wi-Fi Link Controller
- Wi-Fi RF Front-End Components
- WPA2 Protocol Vulnerability
- Get Started with Wi-Fi for Linux
- Get Started with Wi-Fi for MCUs
- Wi-Fi Smart Devices
- Wi-Fi Interoperability
- Kr00k Wi-Fi® Vulnerability
- PIC32MZ-W1 Wi-Fi® SoC and Module Family
- PIC32MZ-W1 Trust&GO Wi-Fi® Module
- Low Power Wide Area Networks
- Embedded Wireless
- Design Partners
- 3rd Party Module Partners
- RED Frequently Asked Questions
- Over-the-Air Updates
- Zigbee® Solutions
- Embedded Wi-Fi
Using Microchip Wireless Solutions to Enable Over-the-Air (OTA) Software Updates
Vital to an array of Internet of Things (IoT) and other connected applications, Over-the-Air (OTA) updates enable product manufacturers to send new information—like an updated weather forecast—or perform system software updates to their devices via a wireless radio transmission.
Our wireless products can be used to implement OTA updates, which are also known as Device Firmware Updates (DFUs), to install new system software for the following use cases:
- Firmware updates:
- To support new features that were not previously implemented
- To fix bugs present in earlier versions
- To protect against security threats like the Wi-Fi® Protected Access II (WPA2) vulnerability
- Certificate provisioning for granting access to new cloud services
- Certificate updates when keys are changed
- Device tuning
Want to Learn More About OTA Updates?
Based on our ATWINC15x0 family of Wi-Fi network controllers, these three examples show you how to use OTA updates with applications using a connectivity device, a host microcontroller (MCU) and SSL certificates:
on a Connectivity IC
For a device like the ATWINC1500:
- Implement new RF features
- Improve RF performance
- Fix bugs
- Patch a newly discovered security breach
- Tune the device
on a Host MCU
For a 32-bit PIC® or other MCU:
- Update host application firmware
- Fix host firmware bugs
- Patch host firmware security breaches
For AWS or other certificates:
- Perform initial cloud provisioning
- Renew certificates
- Change access key
Memory Space Requirements
Having enough memory space available is a key requirement for performing OTA updates. However, because memory adds costs, most systems offer limited memory space. If you would like to enable your application to perform OTA updates, you will need to plan on generally providing memory that offers storage for more than twice the size of the code to be updated. The bootloader or application that will be managing the OTA update will also need adequate memory space.
New code for the OTA update should be filed locally when downloaded. This enables the download to be checked for authenticity and integrity before the actual update is performed. If the download is interrupted or corrupted, the downloaded file should not be used. Only after the download is checked, the bootloader or the application that is managing the OTA update will be able to update the previous software using one of these two methods:
- Erasing and overwriting the code with the new version, which is a good option for a certificate update
- Placing the new image on a new partition and updating the bootloader to point to the new partition, which is a safer option for code updates
The local memory can be placed in various locations in the system. You might choose to use the host controller’s memory, the wireless network controller’s memory or external Flash or other memory. However, to guarantee higher reliability, using a dual-partition memory on the target itself allows the old and new software versions to coexist in parallel. Instead of overwriting the old version with the new version, this will allow the system to simply update a pointer onto the new code after it is checked for authenticity and integrity. It also makes it easy to roll back to the previous version of the software as a failsafe in case of issues with the new version.
OTA Bootloader Requirements:
A program needs to be executed to perform any type of OTA update. This program can be a dedicated application running on a host, but in most cases the update is handled by a bootloader. Commonly used with MCUs, a bootloader is the code in charge of loading and executing an application program. Bootloaders can include additional features such as validating the code integrity and authenticity, and in some cases the bootloader can be tasked with performing an OTA application update.
Because not all bootloaders include OTA update capabilities, your system needs to be programmed and customized for your specific requirements. It is important that you define your OTA update use case, program the functionality and verify the target firmware available for this type of functionality. See the Documents tab below for links to some user guides that will help you get started.
OTA Server Location
During an OTA update, the image is usually downloaded from a web server. You can use a variety of protocols, including HTTP, FTP or MQTT. Secure HTTP (HTTPS) is currently the most popular protocol used for OTA updates. You can also choose the location of the server for your design.
While some MCU vendors choose to develop their own cloud severs, Microchip provides solutions to assist you with developing applications for Microsoft Azure, Google Cloud and Amazon Web Services (AWS). Microchip offers several evaluation kits to develop applications with these services including these options:
Part Number: AC164160
The AVR-IoT WG development board combines a powerful 8-bit ATmega4808 MCU, an ATECC608A CryptoAuthentication™ secure element IC and the fully certified ATWINC1510 Wi-Fi network controller, which provides the most simple and effective way to connect your embedded application to Google’s Cloud IoT core platform. The board also includes an on-board debugger and requires no external hardware to program and debug the MCU.
Part Number: AC164165
Accelerate adding voice control with Alexa to your existing application with the Wi-Fi Smart Device Enablement Kit. The kit allows you to use an Alexa-compatible smart speaker or the Alexa App to control the board’s General-Purpose Input/Outputs (GPIOs) to interface with your application, interrogate the sensors and change the LED colors.
Another popular option is to implement the software image server on a company-owned domain. This guarantees that the company can remain in control of updates and system availability. While the IP address can be used to point to the location of the server, which requires less memory space, the best option is to use a URL in case the server is moved to a different IP address.
For MiWi™ Protocol IEEE® 802.15.4 Products:
MiWi Software Design Guide – see Section 8
For Wi-Fi Products:
Software Programming Guide for ATWINC1500 Wi-Fi Using SAM D21 Xplained Pro – See Section 4.29