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
