Getting an address as an error code on service discovery after update to SoftDevice 8

[Seth]

I just updated to SoftDevice 8 and now I'm getting the address 0x200023C4 in my apps error handler function. This error happens to be the start address for the ble_evt_buffer defined in softdevice handler. From looking at the terminal in MCP, it seems to be failing on reading CCCDs for my custom characteristics. If I change the order in which I initialize services then it fails on different characteristics, but always on a CCCD. It does successfully read some values from my custom services. I haven't changed any of my services after upgrading to softdevice 8. Looking at the release notes I thought it might have to do with the new variable size attribute table, but I set that the to default value which is what it should have been with the last softdevice (7.1) so I don't think that is the issue.

Any help would be greatly appreciated,

Seth

EDIT

This is definitely an issue with RAM, but I'm not sure what. When I change IRAM1 to 20002400 the error becomes 200027C4, and when IRAM1 is 20002600, the error is 200029C4. So the error is 0x3C4 greater than IRAM1. I tried changing the size of IRAM1 from 2000 to 2600, but got the original error of 200023C4.

EDIT#2

I just got the exact same error after advertising for a while, presumably when the advertising timed out and it tried to begin advertising again. My theory is that this is some issue with the ble event buffer as that is still the address that is being thrown as an error.

[Seth]

Looking at the .map file, the number being thrown as an error is the address of the beginning of the memory allocated for BLE_EVT_BUFFER. I'm trying to dig down beyond this, but if this means anything yo you, let me know.

[Stefan Birnir Sverrisson]

You seem to have all SDK 8 components in place for softdevice 8, so that should be fine. You apparently have second revision nRF51822 chip.

I am running SDK8+SD8 examples without problems with the same packs setup as you on the second revision chip with 16kB of RAM and do not experience anything abnormal. Your RAM and ROM settings in Keil are correct for your chip and SD 8.0.0.

Are you able to run standard SDK examples from SDK 8.0.0? Are you using any malloc in your code? What is the stack and heap size you have in arm_startup_nrf51.s file? Just thinking you are using malloc without proper heap size for it. The RAM usage of your application does not seem to big, seems to be all right.

[Stefan Birnir Sverrisson]

What happens if you remove some services or characteristics, does the problem go away.
What happens if you run on anthoer nRF51 chip?

[Stefan Birnir Sverrisson]

Hi Seth

I forgot about one thing that is mandatory when using softdevice 8.0.0 together with second revision of nrF51. You must enable CPU blocking, which will make the softdevice block the CPU during radio activity. It was blocked as default for SD 7.1.0 but for SD 8.0.0 it is unblocked by default because it is targeted for third revision nrF51. Here is a thread that describes how to unblock the CPU, but it should be straigtforward to see from this code how to block it as well.

[Seth]

No malloc, and I've tried both with default heap and 0 heap with no change in behavior. I've also tried removing services and characteristics, no change. I also tried the CPU blocking idea but saw nothing. I've included my code for that below as it seemed promising and I may have an issue in the code:

uint32_t opt_id = BLE_COMMON_OPT_RADIO_CPU_MUTEX;
ble_opt_t cpu_blocking_enabled;
cpu_blocking_enabled.common_opt.radio_cpu_mutex.enable = 1;
ble_stack_init();
err_code = sd_ble_opt_set(opt_id, &cpu_blocking_enabled);
APP_ERROR_CHECK(err_code);

I am about to run some example projects but haven't gotten to it yet. I am now running the code on my custom hardware that has this Taiyo module www.yuden.co.jp/.../TY_BLE_EYSFCNZXX_Overview_V1.0_20131225.pdf and I get the same behavior.