Primary Services Discovery Fails After 8 Connects

[EvanJohnson]

Hey All,

I'm using the nrf52840 for gathering device information from Bluetooth devices having an nrf52 chip on board. The application runs through connect/disconnect routines, on a unique server every time, and I'm using the sd_ble_gattc_primary_services_discover to get characteristics and descriptors from the same server service UUID. After exactly 8 connects, my application fails in the same location. For clarity, I'm not doing anything differently between connection routines. From really rudimentary debugging by placing NRF_LOG_WARNING prints all over the app (I don't have a uart for the dongle and don't connect to J-Link), I'm seeing that the sd_ble_gattc_primary_services_discover from ble_gatt.c starts successfully each time. For the first 7 connects, I receive a BLE_GATTC_EVT_PRIM_SRVC_DISC_RSP back. For the 8th, I don't and the application fatally errors.

I'm thinking that there may be a memory space I'm pushing up against that's causing the error. Is there an erase or stop routine that releases data from the primary services discover that I'm missing here?

Thanks in advance

[Kenneth]

Hi,

Which SDK + SD are you using?

Can you enable debugging and fault handler so you may find the exact file name, line number and error code?

Best regards,
Kenneth

[EvanJohnson]

Hey Kenneth,

I'm using SDK 15.0.3 with sd140. Hardfault handler is enabled, but doesn't seem to catch the fault when the application quits. I could possibly be missing something.

I may resort to soldering a header onto the dongle to debug the app over SES. Let me know what you suggest.

[Kenneth]

EvanJohnson said:

I may resort to soldering a header onto the dongle to debug the app over SES. Let me know what you suggest.

I think that is the best suggestion.

Kenneth

[EvanJohnson]

Kenneth,

For some reason after enabling debugging for the J-link, I'm now very consistently getting errors with the nrf_cli. Here's the call chain:

Any ideas why this would be...?

[EvanJohnson]

Kenneth, 

Seems there was a seg fault in NRF_CLI_HISTORY. Let's disregard this, and get back to the issue of the softdevice not returning an event, then fatally errors.

[Kenneth]

Do I understand it correctly that enabling debugging and fault handler still doesn't catch any issue?

Can you provide a description of how I may recreate your setup here? For instance can I use the \ble_app_multilink_central example in the SDK to recreate the same?

Any change if you modify NRF_SDH_BLE_CENTRAL_LINK_COUNT or NRF_SDH_BLE_TOTAL_LINK_COUNT?

Looking at discovery_start() I can find that the error code from sd_ble_gattc_primary_services_discover() isn't really checked or forwarded in any way, the function will actually always return NRF_SUCCESS. Can you print out the actual err_code when calling sd_ble_gattc_primary_services_discover()?

Thanks,
Kenneth

[EvanJohnson]

Hey Kenneth,

Sorry for not replying earlier. The basis of this app is the example experimental\ble_app_interactive on the SDK mentioned previously. The issue was with a seg fault in primary_services_discovery_rsp handler. If you want to look into it for fixing the example you can, but my issue is resolved now.

Thanks for pushing me to get the J-link debugger up and working, it helped.