Have Softdevice recover from (disconnection) errors from service discovery

[Userta]

Hi there,

I am trying the test the robustness of a BLE use-case. This means that i have to create error scenarios and further observe and analyze how it's possible to recover from them.

In this particular test use case between 2 BLE peers, one being a GAP peripheral +GATT server and the other being a GAP central +GATT client, i was able to disrupt the connection exactly when GAP central peer was doing services discovery, leading to a forced disconnect  event from the softdevice. Now the problem becomes apparent when i try to restart my BLE use case, the GAP peripheral is advertising as before (without any problems), but the GAP central seems to be in an inconsistent state, as after starting the scan, it 's not getting events form the softdevice anymore. Only a power-cycle brings the GAP central device functional again. Please find below a snippet of the logs:

GATT ATT MTU on conn-id 0x0 changed to 247
BLE_GATTC_EVT_EXCHANGE_MTU_RSP. current MTU: 247
BLEMainNordic::s_ble_notify(). Unprocessed event-id: 0x24
discovered primary service. uuid: 0x2000, type: 2, start-handle: 0x001D, end-handle: 0x001F
--> found a service-uuid: 0x2000

discovering char's (0x001D)..
rcvd char discovery resp, char count: 1
char-decl-handle: 0x001E, service-uuid: 0x2000, uuid-type: 3, value-handle: 0x001F
read resp for char-decl-handle: 0x001E
char-properties: 0x06
--> found a char-uuid: 0x0001
read resp for char-value-handle: 0x001F
updated the value of char-uuid: 0x0001
rcvd char-value (4): 0x1C03A180

discovering char-desc's (0x0020)..
error: on_evtgattc_desc_discovery_resp(): 0x101

discovering char's (0x0020)..
BLEMainNordic::on_evtgap_disconnected(): Connection 0x0 has been disconnected. Reason: 0x13
BLEMainNordic::s_disconnected()

I am aware that one can disable and re-enable the softdevice in order to recover from any critical errors.

Now my question is this: 1. does the above test case count as a critical error for the softdevice?
                                              2. and is there any "softer" way to have the softdevice recover from this kind of error?

Much thanks in advance for your prompt answer

[Jørgen Holmefjord]

Hi,

My guess would be that you get an error code somewhere, that puts the application in the error handler, or that you did not check the error code from a softdevice call - leaving the application in an unwanted state.

Please try debugging the application to check for error codes, and make sure you check the error code returned from any function call.

Best regards,
Jørgen

[Userta]

Hi Jørgen,

much thanks for your inputs. you are right, the reason lay in the application itself. handling of the the above mentioned error use case in the application was only partly done, with the side-effect that the scan procedure wasn't started afterwards and as a consequence no advertising reports were received. in nutshell, the problem is resolved and softdevice doesn't have any problems recovering from the error and simply proceeding to the next connection cycle.