Nordic DFU Like a Rockstar
At Dojo Five, we have a lot of experience with the popular Nordic nRF52 family. It’s a pretty awesome family – low sleep current, a really nice peripheral set, and have you played with PPI? Wow! However, one of the easy to overlook features on the Nordic nRF52 family is the device firmware update (DFU).
In this post, I want to give an overview of the DFU process, some of the design choices, and the development tools that are available.
You, too, can DFU Like a Rockstar.
You, DFU’ing like a Rockstar!
Overview
Bootloader
To get the tour bus rolling, let’s talk about the bootloader. Almost all DFU processes use a bootloader to facilitate the process. The bootloader can be user-compiled and loaded onto the device, or it can be in “boot ROM” – etched permanently on the chip at manufacturing time. The Nordic devices use a user-compiled bootloader.
Nordic provides extensive examples in their nRF5 SDK. I’ve always used the example projects as a starting point, and rarely do I need to make modifications to the bootloader. In the 15.3 series of Nordic’s SDK, you’ll find the DFU bootloader example collection here:
nRF5_SDK_15.3.0/examples/dfu/
When the bootloader enters “DFU Mode” it will utilize Nordic’s proprietary DFU protocol to communicate with the outside world, allowing new firmware to be transferred and applied to your embedded system. While your rockstar self is getting ready to take the stage, you should have an idea what you’re walking into with this “DFU Mode” protocol:
Memory Map
Now that we are adding a bootloader to our Nordic nRF52 embedded project, we should make sure we have a clear picture of our internal flash memory map. Here is a generic layout of what the flash memory map will look like:
If your embedded solution is using the flash data storage (FDS) module to save application data to non-volitive memory (NVM), this data will be stored in the “Application Data” flash section above. It is important to note that the “Application Data” flash section will always be allocated just before the bootloader, so make sure you leave yourself enough free space for your application!
The “Bootloader Settings” flash section is critical when pulling a bootloader into our nRF52 embedded project. The bootloader settings information is used to capture firmware validation metrics, DFU configuration, and image versioning. Here’s a printout of the contents of an example bootloader settings file to give you a better idea of its contents:
Bootloader Settings:
-> File: Output/Debug/Exe/settings.hex
-> Family: nRF52
-> Start Address: 0x0007F000
-> CRC: 0xEC9BB0BD
-> Settings Version: 0x00000002 (2)
-> App Version: 0x00000001 (1)
-> Bootloader Version: 0x00000001 (1)
-> Bank Layout: 0x00000000
-> Current Bank: 0x00000000
-> Application Size: 0x0001FC9C (130204 bytes)
-> Application CRC: 0x4D9055E3
-> Bank0 Bank Code: 0x00000001
-> Softdevice Size: 0x00000000 (0 bytes)
-> Boot Validation CRC: 0xEF562FC2
-> SD Boot Validation Type: 0x00000000 (0)
-> App Boot Validation Type: 0x00000001 (1)
The last thing to note is the two user information configuration registers (UICR) that are written automatically when you program the HEX file generated by the sample bootloader projects.
- UICR.NRFFW[0] – Bootloader Start AddressThe bootloader start address will be written to the master boot record (MBR) at the address 0x0000 0FF8 and will allow for execution to jump from the master boot record MBR to the bootloader.
- UICR.NRFFW[1] – MBR Parameter StorageThe MBR parameter storage address will be written to the MBR at address 0x0000 0FFC will allow for the MBR to have a reserved page of flash to track the state of the DFU process.
Design Decisions
There will be a few decisions you’re going to have to make on your way to becoming a star:
Secure vs. Open
When does a rockstar need a bodyguard? Nordic’s secure bootloader only accepts DFU packages that are cryptographically signed with the correct key. The open bootloader accepts anything. All rockstars should have security, and that is why I recommend using the secure bootloader.
Buttonless vs. Button vs. Reset
How will you get into DFU mode? Most applications we see use the “buttonless” DFU, which is a BLE-only path that works in coordination with the Buttonless DFU Service. That service allows a BLE device running an application to get a reboot-to-DFU command over BLE. The “button” DFU approach will require you to specify a GPIO that will be used to trigger DFU mode. The final method that can be used to get into DFU mode is to use the reset pin to trigger entering DFU mode.
BLE vs. USB vs. Serial UART
How are you going to transfer this DFU package over to your embedded solution? From my experience, the BLE transport method is the most commonly used, but Nordic also provides transport support for USB via CDC/ACM (virtual COM port) and serial UART.
Bonded vs. Unbonded
Who will be allowed to update your embedded solution? This is a bonus security perk if you are using BLE as your transport protocol. Bonded DFU guarantees that the identity of the device connecting to the device in DFU is the same device that requested the reboot into DFU mode. Unbonded DFU will allow for any connected device to issue DFU updates.
Development Tools
Like any rockstar, you will need a good supporting cast to be successful. Nordic provides some very useful developer tools that will be critical on your claim to fame!
nRF Utils
The nRF Utils is a development tool for generating everything you need around DFU packages. You will become very familiar with nRF Utils and it offers Windows and Python script support.
Create DFU Packages
Package applications, SoftDevices, and bootloaders into DFU packages that can be interpreted by Nordic’s proprietary DFU protocol.
Generate Cryptographic Keys
Generate your private/public keys and sign your DFU packages if you are using a secure bootloader.
Generate Bootloader Settings
Generate bootloader settings to allow the bootloader to validate and jump execution to your application.
Perform DFU for Testing
Perform DFU updates by sending DFU packages. The supported transport methods are BLE, USB via CDC/ACM (virtual COM port), and serial UART.
nRF Command Line Tools
The nRF Command Line Tools contain a handful of very useful executables that are available for Windows, macOS, and Linux.
nrfjprog
Executable for programming through SEGGER J-LINK programmers and debuggers. I always find this very useful to read out the bootloader settings and UICR to make sure everything is in order.
mergehex
Executable for combining multiple HEX files into a single HEX file. Make things easy on yourself by combining the SoftDevice, application, bootloader, and bootloader settings into one easy to program HEX file.
nRF Connect
The nRF Connect is a cross-platform development tool that is available for Windows, macOS, Linux, Android, and iOS. This will be especially useful if you are using the BLE transport method as you can apply DFU updates right from your mobile device.
nRF BLE Sniffer
If you really want to get into the details or need to troubleshoot an issue that you can’t quite put your finger on, the nRF BLE Sniffer is for you. The nRF BLE Sniffer can be loaded onto various Nordic development boards and interfaces with Wireshark to display the contents of BLE traffic.
Final Thoughts
Hopefully, after reading this you feel a bit more comfortable with the Nordic nR52 family’s DFU module. Having the ability to apply firmware updates seamlessly in the field without having to worry about manually JTAG’ing each device will save you tons of time and effort in the long run.
Good luck ROCKSTAR!
If you would like to work with a team that can help you launch your next DFU project, reach out! At DojoFive, we have talented engineers on hand ready to help you with all aspects of your IoT journey. We are always happy to help with interesting problems that need solving, from security audits to firmware development. You can reach out at any time on LinkedIn or through email!