The DFU process varies from one chipset and one vendor to another and varies depending on the implementation. However, there are some basics that apply in most cases.
Basic Steps of OTA DFU
Here are the basics of how an over-the-air device firmware update (DFU) process works:
- Firmware Image is created by the Author.
- A manifest (metadata containing important manufacturer information about the image such as version number, device model number, etc.) is created and signed by the Author.
- The firmware image and the manifest could be separate or part of the same package.
- The package(s) will usually be encrypted.
- Firmware Image and manifest are uploaded to a firmware update server that can be accessed by the end-device directly (or that can be accessed by an intermediary device such as a gateway or mobile phone which in turn relays the firmware image to the end-device).
- End-device queries the firmware update server (directly or indirectly) or is informed that a new firmware update image is available.
- End-device fetches the new firmware image and manifest (or both in a single package) and validates it by verifying the digital signature. There are different ways that this could happen. The device may decide to fetch the manifest and validate it first, and then fetch and validate the firmware image (or they could be downloaded and validated as a single package).
- The package will need to be decrypted before it is validated and applied.
- If the update fails at any point (due to a corrupt image, power loss, etc.), the process may be restarted from step #6.
- Steps #6 and #7 are performed by the bootloader.
- If the firmware passes the validation check, the bootloader will “activate” the new firmware and boot into it.
- The end-device will now be running the new firmware image with a new version number.
These are simply generic steps and depending on the chipset used and system design, there will probably be differences in your own implementation.
Example of an OTA DFU process workflow
Let’s look at an example of the DFU process. Here’s an example from the documentation of Nordic’s DFU process:
In this diagram:
- The diagram shows the operations and workflow that occurs on the target device.
- “DFU controller” refers to the device that connects to the target BLE device that needs to be updated and transfers the firmware image to. This could be a mobile phone running an app or nRF Connect on desktop (via an nRF52 DK).
- The target device may be running the bootloader in DFU mode or running the application with DFU running in the background.
- The DFU controller connects to the target device and initiates the transfer of the DFU image.
- The target device will first receive an init packet which it validates (pre-validation phase).
- The init packet contains important information such as the type of image, hash of the image, firmware version, hardware version, allowed versions of the SoftDevice, and others.
- If the init packet is validated, the controller will then initiate the transfer of the DFU image to the target.
- The target will receive the full DFU image and validate it.
- Once the DFU image is validated, the target will reset and the bootloader will activate the new DFU image to replace the original image.
- The process is capable of handling updates to the Bootloader + SoftDevice + Application all in one package. Other subsets of this combination are allowed as well, with some exceptions (more information can be found here).