Memory Layout

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 dfu_bootloader_flash_sec to understand flash access operations better.

Dual Bank Flash Layout

The DFU Bootloader project uses a memory layout similar to the of the nRF51822 Bluetooth examples, except that the memory region from 0x3C000-0x40000 has been reserved for the DFU Bootloader, and application data is written below the bootloader instead of at the end of the flash. The memory layout can be seen in Figure 1.

Figure 1: Memory Layout of 256kB nRF51 chip using banked memory scheme.

The table below lists the memory ranges when using a SoftDevice. The SoftDevice will be using region 1 memory spanning from address 0x0 to 0x16000. Region 1 will contain the application and bootloader.

Note: SoftDevice end address of 0x00016000 refers to nRF51822 s110 v7.0.0-alpha. Other SoftDevices may have a different size.

Memory Range	Usage
0x0003C000 - 0x00040000	DFU Bootloader and data
0x00016000 - 0x0003C000	Application Code (BANK 0), Free / Swap (BANK 1), and data
0x00001000 - 0x00016000	SoftDevice
0x00000000 - 0x00001000	Master Boot Record (MBR)

The Application Data size is default set to 0x0000, meaning that all Application Data will be erased during a Device Firmware Update procedure. This behaviour can be configured by the developer to ensure persistency of the Application Data by specifying:

#define DFU_APP_DATA_RESERVED 0x0000

to a different value. Specifying DFU_APP_DATA_RESERVED to 0x1000 will ensure that 4 pages of Application Data are preserved during the DFU procedure.

Note: The value given in DFU_APP_DATA_RESERVED must be a multiple of the Flash page size, such as 0x400, 0x800, 0xC00, ......

Flash handling - SoftDevice update (including Bootloader (optional))

The steps of transferring a new SoftDevice (with/without Bootloader) is illustrated in the figure below.

	Detailed description
Step 1	Start DFU packet received, SoftDevice (Code: 0x01) or SoftDevice with Bootloader (Code: 0x03). Current application will be erased to prepare for new SoftDevice.
Step 2	DFU Data packets with SoFtDevice image are received.
Step 3	Data transmission completed and image is validated. System resets and replace current SoftDevice (and Bootloader) with newer versions.

Figure 2: DFU Flash operations for SoftDevice update.

Flash Handling - Application

The steps of the Application or Bootloaderr update procedure are illustrated in the figures below.

	Detailed description
Figure 3	Before the Bootloader initializes, the active Application resides in Bank 0, while the content of Bank 1 is undefined.
Figure 4	As a first step the Bootloader erases Bank 1, where the received new Application will be copied. This ensures that if the update is interrupted the old Application is still available.
Figure 5	During transfer the received packets of the new Application are written into Bank 1. It is assumed that the packets are transmitted in the right order.
Figure 6	After all packets of the new Application are received, both the old and the new Application are present in the memory. This ensures that fallback to the old Application is possible if the new Application cannot be activated.
Figure 7	If the activation of the new Application is successful, Bank 0 is erased to accommodate the new Application. If DFU_APP_DATA_RESERVED is set, Application Data will be preserved.
Figure 8	As part of of activating the new Application it is moved from Bank 1 to Bank 0.
Figure 9	After the copy procedure is complete, the system can be reset with running the new Application in Bank 0. Bank 1 won't be erased until the Bootloader initializes again.
Figure 10	If Application Data from the old Application was preserved, the new Application will append any new data written.

Figure 3: Before starting DFU

Figure 4: The DFU Bootloader initializes

Figure 5: Transfer of the new Application image is in progress

Figure 6: Both the old and the new Application are present

Figure 7: Upon successful activation the old Application is erased

Figure 8: The new Application is moved to Bank 0 before reset

Figure 9: Following a reset the new Application is started

Figure 10: The new Application will not overwrite old Application Data (if preserved)