delayed disconnect with sd_ble_gap_disconnect()?

[benkokes]

Hello,

Are there any conditions where the sd_ble_gap_disconnect() will not immediately terminate the link?

My Setup: Nrf52, SDK 13.0.0, own board, based from HRM code(exteeeensive modification).

On initial bootup, I fast advertise. Once I get a connection to the central, I utilize the CTS to get time, pull a few packets of data onto the peripheral, shut down the connection and stop advertising.

a few minutes later via external interrupt, I start advertising( do I need to reinitialize the advertising code again??) connect to the central and pull in time to the peripheral using the CTS. This time, when I call the sd_ble_gap_disconnect, the m_conn_handle keeps it value of 0x0 instead of doing the expected disconnect value of 0xFFFF. I monitor m_conn_handle with a WHILE loop, so when it doesn't change to the expected 0xFFFF, I camp there and softdevice faults me to a halt.

So, the first time around, it works like a charm. The second time through, it doesn't look like it releases the link. What would cause the sd_ble_gap_disconnect() function to hold onto the link?

Thanks for looking!

[MartinBL]

I wasn't able to reproduce this. Have you set a breakpoint in the BLE_GAP_EVT_DISCONNECTED event to confirm that the disconnect event itself is not happening? Is it possible that your peer device is immediately trying to reconnect after the second disconnect?

[benkokes]

Hi Martin, Yes, it hits the BLE_GAP_EVT_DISCONNECTED every time. My central device is running a CTS server whose sole purpose is to serve time. I constantly wait for connections and give time to the peripheral once asked. I would rather not edit the on_disconnected() function in ble_advertising.c if there might be another solution... Thanks!

[Hung Bui]

Hi Benkokes,

Did you hit BLE_GAP_EVT_DISCONNECTED event, immediately after you call sd_ble_gap_disconnect() ? If you want to check if the connection is terminated or not, you should wait for that event, not waiting for m_conn_handle to be = 0xFFFF. Please try not to stay in a loop to check for m_conn_handle, if you do that in an event handler, you are blocking other event to come. Results in infinite loop.

[benkokes]

Hi Hung,

fortunately, I do not perform the blocking loop within the on_ble_evt() function, BUT it still blocks elsewhere in the code, waiting for the handle to be 0xFFFF. My suspicion now is that Martin is on to something, where the immediate re-advertising/reconnect happens. Getting a sequence is difficult, since I cannot step through the code at that point...Thanks!

[Hung Bui]

Could you please answer my question ?

"Did you hit BLE_GAP_EVT_DISCONNECTED event, immediately after you call sd_ble_gap_disconnect() ?"

Note that there is nothing special about m_conn_handle, we simply set m_conn_handle = 0xFFFF when there is a BLE_GAP_EVT_DISCONNECTED event.