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 (This page)
Bootloader/DFU Architecture	Architectural 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	Image transfer description using DFU
Flash Memory Layout	DFU Transport Layers description. Detailed description of HCI over UART Transport and Bluetooth Low Energy, BLE, Transport Layers.
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.