Memory isolation and runtime protection

The SoftDevice data memory and peripherals can be sandboxed and runtime protected to prevent the application from interfering with the SoftDevice execution, ensuring robust and predictable performance. Sandboxing is available only if the SoftDevice is run on a chip with a Memory Watch Unit (MWU).

Sandboxing1 and runtime protection can allow memory access violations to be detected at development time. This ensures that developed applications will not inadvertently interfere with the correct functioning of the SoftDevice.

Sandboxing is enabled by default when the SoftDevice is enabled, and disabled when the SoftDevice is disabled. When enabled, SoftDevice RAM and peripheral registers are protected against write access by the application. The application will have read access to SoftDevice RAM and peripheral registers.

The program memory is divided into two regions at compile time. The SoftDevice Flash Region is located between addresses 0x00000000 and APP_CODE_BASE - 1 and is occupied by the SoftDevice. The Application Flash Region is located between the addresses APP_CODE_BASE and the last valid address in the flash memory and is available to the application.

The RAM is split into two regions, which are defined at runtime, when the SoftDevice is enabled. The SoftDevice RAM Region is located between the addresses 0x20000000 and APP_RAM_BASE - 1 and is used by the SoftDevice. The Application RAM Region is located between the addresses APP_RAM_BASE and the top of RAM and is available to the application.

The following figure presents an overview of the regions.

Figure 1. Memory region designation
Memory region designation

The SoftDevice uses a fixed amount of flash (program) memory. By contrast, the size of the SoftDevice RAM Region depends on whether the SoftDevice is enabled or not, and on the selected Bluetooth® Low Energy protocol stack configuration. See Role configuration for more details.

The amount of flash and RAM available to the application is determined by region size (kilobytes or bytes) and the APP_CODE_BASE and APP_RAM_BASE addresses which are the base addresses of the application code and RAM, respectively. The application code must be located between APP_CODE_BASE and <size of flash>. The application variables must be allocated in an area inside the Application RAM Region, located between APP_RAM_BASE and <size of RAM>. This area shall not overlap with the allocated RAM space for the call stack and heap, which is also located inside the Application RAM Region.

The program code address range of an example application:

APP_CODE_BASE ≤ Program ≤ <size of flash>

RAM address range of example application assuming call stack and heap location as shown in Memory resource map:

APP_RAM_BASE ≤ RAM ≤ (0x2000 0000 + <size of RAM>) - (<Call Stack> + <Heap>)

Sandboxing protects the SoftDevice RAM Region so that it cannot be written to by the application at runtime. Violation of sandboxing rules, for example, an attempt to write to the protected SoftDevice memory, will result in the triggering of a fault (unrecoverable error handled by the application). See Error handling for more information.

When the SoftDevice is disabled, all RAM, with the exception of a few bytes, is available to the application. See Memory resource map and usage for more details. When the SoftDevice is enabled, RAM up to APP_RAM_BASE will be used by the SoftDevice and will be write protected.

The typical location of the call stack for an application using the SoftDevice is in the upper part of the Application RAM Region, so the application can place its variables from the end of the SoftDevice RAM Region (APP_RAM_BASE) to the beginning of the call stack space.

1 A sandbox is a set of memory access restrictions imposed on the application.