This hands-on tutorial uses:
You can use an nRF52 DK or nRF52833 DK instead of the nRF52840 DK, but you will need to adapt the steps for those boards.
First, let’s practice running the debug version of the bootloader to understand how the bootload process works. The bootloader will run at boot since there is no other application in place (actually, when programmed, it always runs at boot). Later, we will run the bootloader by pressing a button. Buttonless operation will be covered at the end of the document.
The Heart Rate application is programmed to time out and stop advertising after 3 minutes without a connection. Press the reset button on the DK to restart advertising.
To run the DFU process again, press and hold button 4 on the DK while cycling power. LEDs 1 and 2 will light and you can repeat the process from step 3 above.
In the following steps, we will walk through the DFU build process from a normal customer perspective. In this case, the customer wants to program the SoftDevice, Bootloader, Settings file and Application via SWD during production, and also allow for over-the-air updates in the field by pressing a button when powering up. In both cases, the application must run after the device is booted. However, the bootloader always runs first and will determine if a valid application is in memory via a CRC check. If there is, execution transfers to the application. If not, execution remains at the bootloader.
nrfutil keys generate priv.pemnrfutil keys display --key sk --format hex priv.pem
nrfutil keys display --key pk --format hex priv.pem
nrfutil keys display --key pk --format code priv.pem
nrfutil keys display --key pk --format code priv.pem --out_file dfu_public_key.c
Do a DIR to verify that new dfu_public_key.c and priv.pem files have been created.
Bootloader Settings File
Open a command window in the C:\NordicWork folder and use the following command to create a settings file:
Creating a DFU Package
When we perform the next DFU, it will be more interesting to transfer a completely different application. In that way, we’ll know for sure that the code has changed. For that reason, we’re going to create a zip package using the GLS example.
Note that using the button triggered DFU requires no changes at all to your application. The buttonless DFU approach, however, requires that you add an additional service to be advertised by your application. A mobile app can then connect to that service and transmit a code which causes the nRF52 to reboot into DFU mode and advertise as a DfuTarg.
A buttonless DFU template has been included in the nRF5-SDK for you to add this service. See: https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/ble_sdk_app_buttonless_dfu.html?cp=8_1_4_4_1
It is important, if at all possible, to provide a fail-safe for the DFU process if the buttonless process becomes inoperative, usually via a programming mistake in the application code. A coding mistake that breaks the buttonless process will render the device unable to be updated. This can be quite costly and there is no way for Nordic to provide any form of “fix”. Use a button, a DFU timer or other backup technique to alternately trigger the DFU. It may save a lot of money and frustration.
Thanks for the post. Very interesting. I'm particularly interested in the last paragraph. What would be the preferred way of dealing with a broken app updated thru OTA? How would it be best to trigger the DFU? I would be thankful for any pointers to resources that could be useful.