sd_ble_gap_connect() in S120 2.1.0

[Dan Danknick]

Is there a calling context restriction for sd_ble_gap_connect()? Either in the function call or where the peer address pointer is in memory?

I based my Central project off the reference one in SDK 8.1.0, specifically in \examples\ble_central\ble_app_hrs_c\main.c

but I moved the storage of the peer_addr to my own RAM and I make the call to sd_ble_gap_connect() from my while(1) loop in main.c

sd_ble_gap_connect() does not return any error but I also never see a DM_EVT_CONNECTION event in the device manager handler. Thus, no connection to the peer. And no timeout event, either.

However, if I alter the code in my example to match the SDK example, that is: to make the call to sd_ble_gap_connect() from within the BLE_GAP_EVT_ADV_REPORT event in the on_ble_event() handler, with a pointer to the peer address provided in as a parameter to that handler, it DOES connect.

What is going on here? I have been fighting this for five days and this is my first hint at solving the issue.

Thanks Nordic techs for your help. Dan

[Dan Danknick]

After discussing this with an associate, I figured out what the problem was. The calling context of sd_ble_gap_connect() is temporal, that is, you have to try to initiate a connection when the peripheral's radio is active in Rx mode. Which it is only for a short amount of time after it issues an advertising packet. That's why the example code has the call in the BLE_GAP_EVT_ADV_REPORT event handler.

Section 8.6.1 in Robin Heydon's book BLE Developer's Handbook also explains this quite well. As usual, things like this are strikingly obvious in hindsight.

[Susheel Nuguru]

What you said is correct but sd_ble_gap_connect() will internally make sure that it only sends connect request after receiving adv packet after making this function call. The only advantage of making a connect request in BLE_GAP_EVT_ADV_REPORT is that the central is sure that the peer is still advertising and is active.