SD132 sd_ble_gap_disconnect - missing event

[bodlak]

Dear Nordic, 

we are using s132_nrf52_3.0.0_softdevice.hex on nRF52832, nRF5_SDK_12.2.0_f012efa

We have noticed, that sometimes after issuing sd_ble_gap_disconnect(m_device_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION) we do not get disconnect event (BLE_GAP_EVT_DISCONNECTED). It is happening 1 out of 40 cases. What can we actually expect that will happen for sure/probably after this command?

We have designed our application, that it relates on that signal to be emitted (when in connection state), like clearing connection handles and so. And it usually happen, but as I wrote we documented cases when this fails. In both cases we get no error from the command. Our test case is to run continuous connections/disconnections in rounds for several hours.

Is this something that sounds familiar?

Our workaround is to wait limited time after and if the event won't happen, we will do the action manually. 

Thank you for any advice, Jan

[bodlak]

Dear Vidar, 

last 2 questions and we can close the task. 

- is there way how to force connection timeout - I guess no, but I like to ask

- is there other way how to disconnect immediately without chip reset? May I restart the stack before disconnect event arrives?

Thank you, Jan

[Vidar Berg]

Dear Jan,

There is no "clean" way to force an instant timeout or disconnect that I'm aware of. The specification requires the device to wait for the central to acknowledge the disconnect request. A system reset is probably the quickest way to force a disconnect. You could probably disable the Softdevice as well, but you would still need to re-initialize everything related to Softdevice and BLE again.

[bodlak]

Dear Vidar, 

I would like to add one more question and it is regarding the connection parameter negotiation. Are there some rules/specification how fast and how often I can initiate from device the parameter negotiation? 

Thank you, Jan

[Vidar Berg]

Dear Jan,

I have not seen anything in specification stating how fast and often the peripheral may send the connection parameter request, but I would still be cautious with sending the requests too often too fast in case it may trigger issues on the connected central.

Best regards,

Vidar