softdevice returns error when using a chunk of buffer

[Alex Zhang]

Hi Expert,

I found a weird case that at my 51822 plaform with s110 enabled, if I define a global buffer like:

static uint8_t system_buffer[1024];

it obviously will be referred in some code logic(anywhere). Then, I can see a strange software reset when system is up and doing initialization. The root cause is because sd_ble_enable or sd_ble_gap_ppcp_set returns error number, but I am confused that this system_buffer is nothing to do with these two SVCs. My 51822 has 32K RAM, and also I check that stack/heap seems okay then.

If I change the buffer size as 512 or smaller, then verything will be OK. Why does a global buffer affact softdevice？ I see for sd_ble_enable, error # shows a assert deadbeef, but for sd_ble_gap_ppcp_set, error number is 16 which means NRF_ERROR_INVALID_ADDR. Any clues shared to me? Thanks.

[Ulrich Myhre]

Hi Alex,

This will happen in two cases:

1. If you are using an older SoftDevice that do not support the 32K RAM variant, e.g. S110 7.0.0 or earlier.

2. If the RAM ranges are incorrect. The RAM ranges has changed somewhat with versions, so these need to be double-checked against your specific SoftDevice version/revision. They also need to be modified if you are using the extended ATT size functionality.

What you are seeing in case 2 is that the application starts eating into parts of memory that it shouldn't. Likely its own callstack. What happens then is anyone's guess, but errors and crashes are very likely. The compiler should catch this, but only if it has the right idea about the memory available.

[Ulrich Myhre]

All 7.x.x SoftDevices are API compatible, so you should be able to just replace the SoftDevice without even recompiling the application. There are some special additions for IC revision 2 chips mentioned in the release notes, but these do not apply to your IC rev. 3 chip. (All this is taken from the nRF51 Series Compatibility Matrix).