nRF51 SDK: Bootloader/DFU Architecture

| nRF51 SDK

- Home
- Related Pages
- API Reference
- Data Structures

All Data Structures Functions Variables Typedefs Enumerations Enumerator Groups Pages
Bootloader/DFU Architecture

# 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 `0x00014000`(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 Address `0x00014000` and SoftDevice S310 uses bank 0 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.