nRF51 SDK: Memory layout

| nRF51 SDK

- Home
- Related Pages
- API Reference
- Data Structures

All Data Structures Functions Variables Typedefs Enumerations Enumerator Groups Pages
Memory layout

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

# 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 0x3C800-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 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 0x14000. Region 1 will contain the application and bootloader.

Memory Range | Usage
--- | ---
0x0003C800 - 0x00040000 | Code Region 1: DFU Bootloader and data
0x00014000 - 0x0003C800 | Code Region 1: Application Code (BANK 0) and data
0x00000000 - 0x00014000 | 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 80KB leaving 176KB 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 has reserved 32KB 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 176KB - 32KB = 144KB. The available memory for an application would be 176KB - 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)

# 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 0x3C800-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 0x14000. Region 1 will contain the application and bootloader.

Memory Range | Usage
--- | ---
0x0003C800 - 0x00040000 | Code Region 1: DFU Bootloader and data
0x00014000 - 0x0003C800 | Code Region 1: Application Code (BANK 0), Swap (BANK 1), and data
0x00000000 - 0x00014000 | Code Region 0: SoftDevice

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

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, while the content of Bank 1 is undefined.
Figure 3 | 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 4 | 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 5 | 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 6 | 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 7 | As part of of activating the new Application it is moved from Bank 1 to Bank 0.
Figure 8 | 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 9 | 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: Both the old and the new Application are present
Figure 6: Upon successful activation the old Application is erased
Figure 7: The new Application is moved to Bank 0 before reset
Figure 8: Following a reset the new Application is started
Figure 9: The new Application will not overwrite old Application Data (if preserved)