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()".