delayed disconnect with sd_ble_gap_disconnect()?

RE: delayed disconnect with sd_ble_gap_disconnect()?

Hung Bui — Wed, 20 Jun 2018 13:15:36 GMT

Hi Ben,

Great to get back after 8 months :)

I think I know what's wrong here. What kind of central device do you have ?

Disconnect event 0x22 means BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT. This happens when the central stopped communication for too long end the connection terminated because of the timeout. So when the peripheral send connection terminate request ( because of sd_ble_gap_disconnect() ) it would expect an ACK from the central before it actually stop the connection and throw BLE_GAP_EVT_DISCONNECTED event back to the application.

But in this case, it seemed that the central stopped immediately after it receive the connection terminate request. It forgot to send the last ACK packet back to the peripheral. This results in the peripheral kept waiting for that ACK until timeout.

(Or it could be that the last ACK was lost and the peripheral never receive it, and there is no retransmission, of course)

RE: delayed disconnect with sd_ble_gap_disconnect()?

benkokes — Wed, 20 Jun 2018 05:05:41 GMT

HI Hung,

Yes, I have the line m_conn_handle = BLE_CONN_HANDLE_INVALID; inside BLE_GAP_EVT_DISCONNECTED event handler inside on_ble_evt(). (I don't have a function explicitly named ble_evt_handler().)

so if I call sd_ble_gap_disconnect() then immediately printout the value of m_conn_handle, I see that it has a value ( of 0, verifying its not 0xFFFF).

Putting in a few more checks, I see I hit the BLE_GAP_EVT_DISCONNECTED in about 4 seconds. The disconnect reason is a 34 (0x22). I check the value of m_conn_handle after that, and its the expected value of 0xFFFF.

Could there possibly be some sort of negotiation going on between the peripheral and central? Maybe I am not sending some expected parameters OR maybe I am missing some sort of disconnect data from the central?

Is there some way to see if the softdevice is waiting on some response from the central or maybe there is a timer somewhere that needs handling?

Thanks!

RE: delayed disconnect with sd_ble_gap_disconnect()?

Hung Bui — Tue, 31 Oct 2017 15:33:23 GMT

I don't really understand it.

Could you verify that you have the code m_conn_handle = BLE_CONN_HANDLE_INVALID; inside BLE_GAP_EVT_DISCONNECTED event handler inside ble_evt_handler() ?

After that command the m_conn_handle should be 0xFFFF. Are you saying the line of code doesn't have any effect on m_conn_handle?

If it's not, then it must be assigned somewhere else, most likely because the central tried to connect again ?

It's pretty easy to find how long it would take to get BLE_GAP_EVT_DISCONNECTED event, simply print out some text on UART/RTT when you receive the event, I suggest to also do the same with BLE_GAP_EVT_CONNECTED

RE: delayed disconnect with sd_ble_gap_disconnect()?

benkokes — Tue, 31 Oct 2017 15:08:39 GMT

Hi Hung, Sorry, I thought that I answered that question from Martin. Anyhow, Yes, It does hit the BLE_GAP_EVT_DISCONNECTED within on_ble_evt() the second time. As to how 'immediate' it is, that is difficult for me to quantify due to not being able to step through the code whilst Softdevice is active ( as you know). It SEEMS close to immediate, because it happens within 1 second of obtaining time from the server. The disconnect is programmatically planned, so other than setting GPIOs to determine actual timing, I cannot guarantee the timing immediacy. However it does happen soon after the command to disconnect from the central.

I was counting on the m_conn_handle to be reset to 0xFFFF the second time, but after I get out of the switch statement containing the BLE_GAP_EVT_DISCONNECTED code, my m_conn_handle still is 0x0;

RE: delayed disconnect with sd_ble_gap_disconnect()?

Hung Bui — Tue, 31 Oct 2017 14:44:12 GMT

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.

RE: delayed disconnect with sd_ble_gap_disconnect()?

benkokes — Tue, 31 Oct 2017 14:41:28 GMT

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!

RE: delayed disconnect with sd_ble_gap_disconnect()?

Hung Bui — Tue, 31 Oct 2017 11:24:26 GMT

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.

RE: delayed disconnect with sd_ble_gap_disconnect()?

benkokes — Sun, 29 Oct 2017 22:16:22 GMT

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!

RE: delayed disconnect with sd_ble_gap_disconnect()?

MartinBL — Fri, 27 Oct 2017 08:55:40 GMT

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?