This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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.

image description

image description

image description

image description

image description

image description

image description

  • Finally, a new insight is that this does not just happen on service discovery, but actually just on connection. So it seems like any BLE events are causing this (advertising timeout and connection specifically)

  • Hi Seth

    What is your progress on your case? Have you tried to run example codes on your custom board, or to run your custom code on a standard development kit, to ensure that this is not a hardware problem?

    If you see the same error when running this on development kit, with the same softdevice and your custom application, then there is surely something in your code that is causing this behavior. Try to gradually comment out blocks/functionality from your code to see when the problem goes away. Hopefully you will get more idea about what is causing the problem.

    I would be happy to try out your code on my side if you have it in a format that I can run on standard hardware.

    Let me know about your findings.

  • This was very foolish and I'm not sure why the upgrade to the new SDK caused it, but there was a path through my code where the err_code never got set to any value, so it must have been throwing the garbage it was set to initially. Sorry for the time you guys spent thinking about it.

Related