Adding a memory guard to the softdevice RAM

[Alex Crombie]

We have the following setup:

- nRF52832 XXAA

- SDK 6.0

- S132

I have attempted to add a memory guard into the location preceding the application RAM data block start address to be able to observe cases where the SD ram usage approaches the memory space of the application. When attempting to write to a location prior to APP_RAM_BASE the device experiences, hard faults and issues with the power control commands. 

From this guide the APP_RAM_BASE with the soft device in a minimal configuration is 0x20001628, thus I would expect this region to contain all the DATA and BSS sections required by the softdevice. Furthermore the documentation says that the SD uses the applications stack space, so I would not expect to be trampling over a used stack. Our APP_BASE_RAM is located much higher than this at 0x200064d8, this having been increased by 0x200 for some recent GATT attributes that were added. I would have expected the 0x200 block of memory to be safe to write to without interfering with the operation of the softdevice or overriding any of it's data, especially before calling `nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);` and `nrf_sdh_ble_enable(&ram_start)`.

The simplified verison of the guard we were planning on implementing looks something as follows:

const uint32_t MEM_PATTERN = 0xDEADBEEF;
extern uint8_t __data_start__[];

#define RAM_START ((uint32_t*)((uint8_t*)&__data_start))
#define SOFTDEVICE_RAM_START ((uint32_t*)((uint8_t*)&__data_start__ - 0x200))

void sd_mem_guard_init()
{
    for (uint32_t* ptr = SOFTDEVICE_RAM_START; ptr < RAM_START; ptr++) {
        (*ptr) = MEM_PATTERN;
    }

    g_mem_guard.current = SOFTDEVICE_RAM_START;
}

We will then check the memory usage by finding the DEADBEEF pattern.

As such I have a number of questions:

1) Is my understanding of the softdevice memory usage correct?

2) Is there anything particularly wrong with the above?

3) How would you go about implementing such a guard if the above is not correct?

Many Thanks

[run_ar]

Hi,

The Softdevice memory region is protected using the MWU — Memory watch unit. If you try to write to the SD region in RAM while the SD is enabled you will be getting hardfaults. See Peripheral runtime protection Because if this mechanism I am not sure I understand why you would need an additional memory guard.

Note that the SD will output it's memory requirements during initialization. As long as you keep the App ram base at that limit you will be fine.

[Alex Crombie]

run_ar said:

Because if this mechanism I am not sure I understand why you would need an additional memory guard.

We need this to protect our application from the softdevice running into our application RAM area

run_ar said:

As long as you keep the App ram base at that limit you will be fine

When I check the app ram base from the SDK the SD reports a much lower base than what it is actually using once everything is initialized. This is presumably because we are using custom GATT attributes and the way we initialized/allocated them.

The above also does not answer my questions. There is very little documentation regarding what is defined as the SD memory region that is being protected by MWU, how it determines what memory is available for its use, etc.

[run_ar]

There is a call to sd_ble_enable that contains the app ram start address. The SD will protect the memory located before app ram base. So you could possibly set this to one value, then increase the actual app ram start address to leave some room for the mem pattern. For reference see Memory isolation and runtime protection