What happen with a bad call of sd_ble_gap_connect()?

[Hieu]

I am trying to emulate the case where a scanned peripheral goes offline before the connection was issued by the user by calling sd_ble_gap_connect() with a completely made up address (123456789abc).

The err_code returned by the function was NRF_SUCCESS. I understand that as the connection attempt was initiated successfully, which make sense.

However, all subsequent calls of sd_ble_gap_connect() always return an err_code of NRF_ERROR_INVALID_STATE. What does this mean? This suggests that the softdevice is not in a state where it could initiate a connection attempt.

I have a few questions raised from this situation:

1. Exactly what state would the softdevice be in after a call of sd_ble_gap_connect()?
2. Would the softdevice ever "recover"/get out of from that state if sd_ble_gap_connect() was called with a bad address?
3. Is there a better way to handle bad BLE address then? If yes, what would it be?

[RK]

This is basically covered in the Message Sequence Chart for GAP Central Connection Establishment and Termination which you can find in the Softdevice documentation from the links at the top of this page.

1. It will be scanning until it finds the peripheral and will then connect to it. There's no notion of the peripheral having to be available right now, you've just asked it to connect to a peripheral and it will keep looking until it finds it or ...
2. Yes it will time out at the timeout you gave it in the scan parameters.
3. You can give it a lower timeout or call sd_ble_gap_connect_cancel() to cancel the connection.

And yes NRF_ERROR_INVALID_STATE means it's not in a state to perform the connect because it's already in the middle of performing one.

[Hieu]

Thanks for pointing out that the timeout actually relies on scan parameters. When I was looking for a timeout value I kept looking at the connection params and could not make sense out of it.