NRF51-DK disconnects after second notification

RE: NRF51-DK disconnects after second notification

Hung Bui — Tue, 17 Mar 2015 14:00:33 GMT

@Blackclaws: No, you can add more attribute (service/characteristic) or change the value but you can't modify the attribute properties or remove them. If you want to modify or remove, you would need to disable the softdevice and enable it again.

RE: NRF51-DK disconnects after second notification

Blackclaws — Tue, 17 Mar 2015 11:37:22 GMT

Is it actually possible to change the pointer after adding the characteristic? Or change an added characteristics attributes?

RE: NRF51-DK disconnects after second notification

Hung Bui — Tue, 17 Mar 2015 10:24:10 GMT

@Blackclaws: And one more thing about VLOC_USER is that you would need to make sure the pointer you used should be static or global, and won't be discarded when the function is finished. I don't think there is a simple way to detect if you use "not-good" pointer when calling softdevice API. The softdevice API does check for the range of the input pointer, but just to make sure it's not pointed to the memory area reserved by the softdevice or outside of the maximum range 32kB.

RE: NRF51-DK disconnects after second notification

Blackclaws — Mon, 16 Mar 2015 19:29:23 GMT

OK I think I found the problem. I used BLE_GATTS_VLOC_USER and instead of passing a pointer to the data buffer I accidentally passed a pointer to a pointer to a data structure. This probably meant that as I was writing to my notification it overwrote parts it should not have overwritten, namely parts of the bluetooth stack or other nasty things.

This makes me wonder. Is there any easy way to track illegal memory access operations on the NRF51 platform?

RE: NRF51-DK disconnects after second notification

Blackclaws — Mon, 16 Mar 2015 19:16:47 GMT

The error handler isn't triggered. It is still the default one which loops infinitely when called and this would effectively terminate the application as far as I see it which doesn't happen.

RE: NRF51-DK disconnects after second notification

Vidar Berg — Mon, 16 Mar 2015 18:03:45 GMT

Have you tried to place a breakpoint in the app_error_handler() to see if an error occurred from somewhere else in your program while sending the notifications.

app_error_handler() is declared as [weak] in app_error.c so you can place the breaktpoint there unless you have re-declared it somewhere else. Also remember add "DEBUG" to the pre-processor defintions if you like to read out the error code,etc.