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 Bootloader/DFU Flashing 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 dual bank 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)

Single 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.

Note: SoftDevice and bootloader update is currently not supported on Single Bank flash layout.

The memory layout can be seen in Figure 1.

Figure 1: Memory Layout of 256kB nRF51 chip using single bank 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.

Memory Range	Usage
0x0003C000 - 0x00040000	Code Region 1: DFU Bootloader and data
0x00016000 - 0x0003C000	Code Region 1: Application Code (BANK 0) and data
0x00000000 - 0x00016000	Code Region 0: SoftDevice

Code region 1 size will depend on the size of the SoftDevice used. For this example, with a 256kB version of the nrf51 the stack uses 84kB leaving 172kB to the bootloader and the application.

The region is then divided into 3 sub-regions:

Bootloader
Application Data
Application (BANK 0)

The bootloader projects in the SDK have memory reserved for the bootloader and the bootloader settings data. The memory reservation can easily be modified in the project files to match the final size of the bootloader. For the example bootloader provided, the application will get a total of 172kB - 16kB = 156kB. The available memory for an application would be 172kB - (application save data).

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 persistence 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, ......

Upgrading application using Full

Memory Layout

When using Full Memory Layout the bootloader will erase the whole application region (BANK 0) when entering the bootloader mode. The application save data will not be modified. During DFU data transfer each word received by the bootloader will be written to BANK 0 without any buffering.

When DFU validation is performed the written flash in BANK 0 will be validated and the bootloader will write its settings data and perform a system reset.

During start-up the bootloader will read its settings, to see if chip contains a valid application image. If an invalid image was received, the bootloader will start the update sequence as if has never been done. On the other hand, if an valid image was received, it will start the application located in BANK 0.

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

	Detailed description
Figure 2	Before the Bootloader initializes, the active Application resides in Bank 0.
Figure 3	Upon receiving the Start packet the Bootloader erases Bank 0. If DFU_APP_DATA_RESERVED is set, Application Data will be preserved.
Figure 4	During transfer the received packets of the new Application are written into Bank 0. It is assumed that the packets are transmitted in sequential order.
Figure 5	After the copy procedure is complete, the new Application can be activated. If activation is successful, the system can be reset with running the new Application in Bank 0. If the new Application cannot be activated, the Bootloader will be started after reset until a working image is received.
Figure 6	If Application Data from the old Application was preserved, the new Application will append any new data written.

Figure 2: Before starting DFU

Figure 3: The DFU Bootloader initializes

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

Figure 5: Following a reset the new Application is started

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