Bootloader/DFU Architectural Overview

The Bootloader/DFU example makes it possible to receive an application image and write it to the internal flash of the nRF51.

The image can be transferred using serial wire (UART) or over BLE.

During system start-up, the Bootloader/DFU will be started and during start-up it will determine if a valid application is present in bank 0 at Address 0x00016000 (see also Single Bank Flash Layout or Dual Bank Flash Layout for detailed description). If a valid application is present in Bank 0 the Bootloader will start the application, otherwise the Bootloader will be in DFU mode expecting a Device Firmware Update. If it is desired to put a device with an existing application, restart with device with Button 7 pressed. Note that SoftDevice S110 uses bank 0 at Address 0x00016000 and SoftDevice S310 uses bank 0 at Address 0x00020000.

A schematic overview of the blocks in Bootloader/DFU is seen in Figure 1.

Figure 1: Architectural overview of Bootloader/DFU.

Bootloader/DFU BLE Transfer

The Bootloader/DFU supports transferring of an image using BLE.

The DFU BLE Transport uses a BLE Service for data transfer (see DFU Service). The BLE DFU Service relies on S110/S310 SoftDevice for data transfer. The DFU Bank Handling will ensure the writing of received data packets to flash.

Figure 2 shows a schematic overview of the Bootloader/DFU project with BLE Support.

Figure 2: Architectural overview of Bootloader/DFU supporting BLE transfer.

Bootloader/DFU Serial (HCI) Transfer

The Bootloader/DFU supports transferring of an image using UART. The UART will use HCI Transport layer for increased robustness of the transfer. A detailed description of HCI is found in HCI Transport.

The DFU Bank Handling will ensure the writing of received data packets to flash.

Figure 3 shows a schematic overview of the Bootloader/DFU project with UART Support.

Figure 3: Architectural overview of Bootloader/DFU supporting Serial transfer.

The DFU State Machine

The DFU bootloader has an internal state machine independent of the transport layer used. All initializing and writing to non-volatile memory is controlled by the DFU module.

Figure 1 illustrates the transitions in the state machine:

Figure 4: State machine transitions in the DFU.

Entry point indicates that the bootloader is started up, and would initialize the DFU. In this initialization the DFU would prepare the non-volatile memory region for the new application. Either using all available memory overwriting the old image, or using banked memory where the old application is retained until a new application is uploaded and validated. Also the selected transport layer would be initialized in this phase.

DFU Event Message Types

Message type	Description
- dfu_init	Message initializing the Device Firmware Update module.
- dfu_image_size_set	Message setting the DFU image size.
- dfu_data_pkt_handle	Message containing a portion of the new application.
- dfu_init_pkt_handle	Message for optional customer specific data.
- dfu_image_validate	Message triggering validation of the new application.
- dfu_image_activate	Message activating the transferred image after validation has successfully completed
- dfu_sys_reset	Can occur any time, making the DFU go into a reset of the chip. A bootloader time-out or an external message can trigger the system reset.