Issue with advertising restart after disconnect...

[mstrouse]

All,

Can anyone tell me what is the fastest time that a ble SD (5.x / 6.x) running on an nRF51 can (re)start advertising from a disconnect. Basically looking to do an [advertise -> connect -> receive (1 byte) -> disconnect] and then back to advertise as quickly as possible... Right now I'm seeing turn around times in the 5-7 second range.

Before you ask ... it is not related to the central (in this case an iOS device) ... already checked that box. Would appear (after doing some debugging) that this issue is in the SD.

I tried to force this by doing a:

sd_ble_gap_disconnect(s_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);

followed by an:

advertising_start();

in another "thread" after the receive (a write to my peripheral handle), and the part does not like that ... causes a fault / reset.

MS.

[FormerMember]

The chip should be able to start advertising right after disconnecting. It means that after calling sd_ble_gap_disconnect(..), advertising_start()/sd_ble_gap_adv_start(..) can be called immediately when receiving BLE_GAP_EVT_DISCONNECTED. If calling advertising_start()/sd_ble_gap_adv_start() before BLE_GAP_EVT_DISCONNECTED, sd_ble_gap_adv_start(..) will return the error NRF_ERROR_INVALID_STATE.

A quick test here showed that it took 80 ms from the LL_TERMINATE_IND (disconnect) was transmitted until the device started to advertise:

The reset could be caused by a function returning an error handled by APP_ERROR_HANDLER(..) that results in a reset. If you run the chip in debug mode, you can set breakpoints at where you think the error may occur, and check if some error codes are returned. It can also be useful to take a look at this post regarding "chip is resetting".

[mstrouse]

"The chip should be able to start advertising right after disconnecting." Can you quantify / prove this statement? Is there anything in the documentation that tells how long it takes for the SD to tear down a current connection (internal structures / resources, etc), and to be ready to start advertising?

And by saying "disconnecting" ... do you mean the act of calling "sd_ble_gap_disconnect()", or does that mean waiting to receive a disconnect event in my "on_ble_evt(ble_evt_t * p_ble_evt)" loop?

As for the reset that occurs when calling "advertising_start()" (immediately after "sd_ble_gap_disconnect"), I'll admit that I am not rigorously error checking. This was done out of expediency to find a solution. That said, I suspect that the reset is caused by the SD not having finished closing the previous connection when I call "advertising_start()".

[FormerMember]

I have updated my answer to answer your questions. Let me know if it is still unclear.

[mstrouse]

So the difference (on my setup) is that the time between sd_ble_gap_disconnect() and receiving BLE_GAP_EVT_DISCONNECTED is not anywhere close to 80mS. It's at least 4 seconds ... sometimes much longer.

And yes, I've verified that the reset is caused from the APP_ERROR_HANDLER() after calling advertising_start()/sd_ble_gap_adv_start() too soon (before I receive BLE_GAP_EVT_DISCONNECTED). If I wait, I'm back to 4+ seconds.

[FormerMember]

Do you have an extra nRF51-DK or a nRF51-Dongle? If so, could you use the sniffer to track the disconnect? And upload the sniffer trace here?

The sniffer should be used with Wireshark, and it works best with version 1.10, not one of the newer versions. Wireshark can be downloaded here:

• www.wireshark.org/.../
• www.wireshark.org/.../