This an example of a bootloader with Device Firmware Update, DFU, capabilities. Here is an overview of the Bootloader/DFU example for the nRF51422 and nRF51822 Chip. Device firmware update are envisaged to be performed on a device
a. With no existing application image
b. With an existing application image

In case the device has an existing application image, it may be most desired (provided device has enough resources) to restore the older/existing application image in event the device firmware update either did not succeed or could not be completed. Through out the description for the DFU examples, a bootloader that is capable of preserving the existing application while receiving a new image is referred to as a 'dual bank' update. While the bootloader that is not capable of preserving an existing application once new image update has started is referred to as 'single bank' update. See also Memory layout to understand flash access operations better.

The update can further be desired over a variety of wired/wireless transports. Current examples are with Bluetooth Low Energy and HCI-UART as transport. For more details see Bootloader/DFU Architecture and DFU Transport Layers. The DFU example itself is designed to be transport agnostic. DFU application interface is detailed in Bootloader/DFU API. This examples defines 'control' messages for initiating DFU procedures like Start DFU, Stop DFU, Reset the System, Activate New Image & Reset Device etc. A comprehensive list of the procedures identified along with format each message is detailed in the Bootloader/DFU API section. The firmware itself, being larger than maximum Data Unit of the transport being used, can be transmitted as smaller fragments that fit into the transport Data Unit. Each of such fragment is referred to as a DFU Packet. Current DFU Packet is simple, and does not contain an individual CRC fields. However, an overall CRC check on firmware is provisioned for. The image is expected in binary format.

For more detailed description of the example, please refer to the following sub-pages.

Section	Description
Introduction to Bootloader/DFU	Introduction to the Bootloader/DFU example project
Bootloader/DFU Architecture	Architectual view of the Bootloader/DFU Solution
Bootloader/DFU Keil Project	Description of the Keil project, compiling Bootloader/DFU, and software flash download (nrfjprog)
DFU Transport Layers	Detailed description of HCI over UART Transport and Bluetooth Low Energy, BLE, Transport Layers
Flash Memory Layout	Detailed description of the flash memory layout for SoftDevice, application, and bootloader/DFU
Bootloader/DFU API	API description for modules specific for the Bootloader/DFU Example

Introduction to Bootloader/DFU

The DFU Bootloader is capable of receiving an application image on the HCI-UART or BLE and updating the current running application on the nRF51422 or nRF51822 Chip. The source code and project file for nRF51422 can be found in the folder
<InstallFolder>\Nordic\nrf51422\Board\nrf6310\device_firmware_updates\bootloader
and for nRF51822 in
<InstallFolder>\Nordic\nrf51822\Board\nrf6310\device_firmware_updates\bootloader

The project supports 3 targets: a. dfu_dual_bank_hci - Dual bank device firmware update over UART-HCI. b. dfu_single_bank_hci - Single bank device firmware update over UART-HCI. Note: Single Bank implies that the existing or old application cannot be restored back. c. dfu_dual_bank_ble - Dual bank device firmware update over BLE transport.

If there is no existing application in the nRF device, the device will be started in the bootloader mode. In case the device has an existing application, it will need to be put explicitly in the bootloader mode using button 7.

Experimental, sample PC application to perform device firmware update for nRF51422 have been provided at
<InstallFolder>\Nordic\nrf51422\Board\nrf6310\device_firmware_updates\experimental
and for nRF51822 at
<InstallFolder>\Nordic\nrf51822\Board\nrf6310\device_firmware_updates\experimental.

location. The readme.txt that accompany this sample application provide instructions on how to use them. It is important to note that the sample application accept firmware in hex formats and internally convert them to binary format. The device itself, expects the firmware in binary format and not hex.

The board setup used for the DFU Bootloader can be found at nRFgo Motherboard Setup (nRF6310). The DFU Bootloader example will work both with or without the display module.

Architectural Overview

The firmware update process has been modelled as an event driven state machine. With each event signifying a specific DFU Procedure. The events and procedures are transport agnostic, hence it is possible to to perform a firmware update on any transport. State diagram and events are described in Bootloader/DFU Architecture. Peer or the uploading device can trigger/drive the events by sending a corresponding message on the DFU transport. List of all defined messages can be found at DFU Event Message Types.

The procedures and state machine is identical for single and dual bank transfers. However, each transport may differ in the way the actual message is transferred, for this, please refer to transport specific pages. For example, for Bluetooth Low Energy all control messages are requested by writing to Control Characteristic. However, in serial, no logical data points are created for control or data messages. It should also be noted that no sequence numbers or DFU Packet loss mechanisms have been added for optimized exchange, DFU assumes a reliable transport. Therefore, it is left to the transport or transport-DFU shim to ensure reliable data transfer. It is also responsibility of the transport to submit the DFU packets in the right order and one at a time. DFU does not handle out-of-order DFU packets.

Bootloader/DFU API

DFU interfaces with the transport using the Application Interface (API), each API signifies a sub procedure request. It should be noted that the APIs itself are designed to be non-blocking, but, the CPU is halted on flash operations, hence, hence operation that result in flash access given the impression of a blocking API. Please refer to the section on Non Volatile Memory Controller in nRF Reference Manual for more details on impact of flash access. It is recommended that the flash access times are well understood when expecting a response/acknowledgement for a message on any transport.

For detailed description of APIs and DFU procedures, please refer Bootloader/DFU API section.

Bootloader/DFU User Interface

Instructions on how to set up the nRFgo Motherboard: nRFgo Motherboard Setup (nRF6310).

LED assignments:

For Bluetooth Low Energy Transport Layer:
- LED 0: Advertising
- LED 1: Connected
For both Bluetooth Low Energy and Serial Transport Layer:
- LED 2: Bootloader Mode Active
- LED 7: Asserted (i.e. an assert check in the application has failed)

Button assignments for Bluetooth Low Energy Transport Layer:

Button 7: Enter Bootloader Mode

Testing

Using Bluetooth Low Energy Transport Layer

Before testing the Bootloader/DFU example, erase the device and program the SoftDevice. Have two compiled and linked application HEX files ready for the update procedure. The Bootloader/DFU example can be tested using the Master Control Panel (MCP) as follows:

Compile and program the application. Observe that the Bootloader Mode Active and the Advertising LED is lit.
Select to the device from MCP, the device will be advertising as 'DfuTarg'. Connect and perform service discovery. Observe that the Connected LED is lit, and the Advertising LED is off.
MCP automatically recognizes that the device supports Device Firmware Update, and the 'DFU' button becomes available on the application's user interface.
Click the 'DFU' button and pick a compiled and linked HEX file. After clicking 'Open', observe that the update procedure starts and wait until the progress bar reaches 100%. The new application is started automatically, observe that the Advertising LED is lit.
In MCP go back to device discovery and observe the device advertising with the updated firmware.
To perform another update, reset the device while holding down the Enter Bootloader Mode button. Observe that the Bootloader Mode Active and the Advertising LED is lit.
Repeat steps 2-4.

Using Serial Transport Layer

For testing the Bootloader/DFU example using the Serial Transport Layer, a 32-bit windows application is provided for nRF51422 in the folder
<InstallFolder>\Nordic\nrf51422\Board\nrf6310\device_firmware_updates\experimental
and for nRF51822 in the folder
<InstallFolder>\Nordic\nrf51822\Board\nrf6310\device_firmware_updates\experimental
Please refer to the readme.txt that accompany these sample applications for instructions on how to use them.

Troubleshooting

This section covers some known issues and their solution for the Bootloader/DFU project

Error	Solution
linking... ._build\bootloader.axf: Error: L6406E: No space in execution regions with .ANY selector matching .....	This error message will be seen if the Bootloader/DFU image does not fit into the Size specified in the project setting, try using higher optimization level, -O3, or increase the Bootloader/DFU code area as described in Bootloader/DFU compile targets
No Algorithm found for: 10001014H - 10001017H Partial Erase Done (areas with no algorithms skipped!) No Algorithm found for: 10001014H - 10001017H	Those error messages are seen when trying to flash with the J-Link Target Driver, as it does not support writing of UICR. Use `nrfjprog.exe` instead.
Bootloader/DFU project suddenly stopped working after changing Bootloader/DFU Start address and re-flashing	After changing the Bootloader/DFU Start address, the nRF51822 Chip should be erased and re-programmed with the SoftDevice and then with the Bootloader/DFU.
— Error: failed to execute '"nrfjprog.exe" .....	nrfjprog.exe could not be found in windows path. Add nrfjprog.exe to windows %PATH% or specify full path to nrfjprog in Keil-'Options for Target'-'Utilities' as seen in Figure 3.
Uploaded application does not run	Verify that the application has been compiled with the correct start address. For S110 SoftDevice this would be Address `0x00016000` and for S310 SoftDevice it would be `0x00020000`.