sd_ble_gap_connect(), BLE_GAP_EVT_TIMEOUT and BLE_GAP_EVT_CONNECTED

[dbuijsma]

I encountered a scenario where I call sd_ble_gap_connect() and get an event BLE_GAP_EVT_TIMEOUT with source BLE_GAP_TIMEOUT_SRC_CONN. This is followed immediately by an event BLE_GAP_EVT_CONNECTED. I did not think this was possible when looking at this sequence chart. I see this happen on several devices here which are periodically connecting and disconnecting to many sensors.

Timing:

27.802 sd_ble_gap_connect()
28.617 [Event 0x1b (BLE_GAP_EVT_TIMEOUT, source BLE_GAP_TIMEOUT_SRC_CONN)]
28.629 [Event 0x10 (BLE_GAP_EVT_CONNECTED)]
30.602 [Event 0x11 (BLE_GAP_EVT_DISCONNECTED)], reason 0x13 (BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION)

Is this expected behavior? 

# Setup info

I'm running the HCI connectivity example code on an nRF52 with the application code on a Linux device using the serial port (1MBaud) for communications.

Softdevice version: s132_nrf52_3.1.0_softdevice.hex.

Thanks,

Dirk

[Sigurd]

Hi,

What device are you connecting to? Is the advertiser also a nRF52 ?

BLE_GAP_TIMEOUT_SRC_CONN means that the connection request timed out, and the connection was therefore not established. Probably the advertiser did not respond to the connection attempt.(a nRF Sniffer-v2 log could be useful here)

Then it seems like a new connection request was sent, the connection was established, but the peripheral disconnected the link.

[dbuijsma]

Ah yes, the sensors (advertiser) using the nRF52 with the same softdevice. 

The central (Linux device) is the side which calls sd_ble_gap_connect(). It is only doing so once and then waits for BLE_GAP_EVT_CONNECTED  or BLE_GAP_EVT_TIMEOUT. However, it gets both as shown above.

My question is whether that codepath exists in the 3.1.0 softdevice. We can deal with that in our application, but it seems like an issue in the SoftDevice, especially since I see multiple units showing this same sequence.

Getting a sniffer log is going to be very difficult. We have 100's of devices talking to each other. I'll still try, but it's unlikely I'll catch the actual issue.

Thanks for looking into this.

Dirk

[Sigurd]

dbuijsma said:

However, it gets both as shown above.

Are you sure that sd_ble_gap_connect() is only called once ? It's not called again after BLE_GAP_EVT_TIMEOUT?

If you can verify that it's only called once, I will try to reproduce the issue here.