sd_ble_gap_sec_params_reply() returns NRF_ERROR_INVALID_STATE

Question

I have an nRF51822 application using the Soft Device 110. I want to perform bonding with a central without MITM protection. In my on_ble_evt() event handler, when the event ID is BLE_GAP_EVT_SEC_PARAMS_REQUEST, I reply in the same fashion as one of the example apps, like this: 
 err_code = sd_ble_gap_sec_params_reply(m_conn_handle,
 BLE_GAP_SEC_STATUS_SUCCESS,
 &m_sec_params);
 APP_ERROR_CHECK(err_code);
 
 The error_code is then 8, which is NRF_ERROR_INVALID_STATE. 
 The m_sec_params have earlier been set to these values: 
 #define SEC_PARAM_TIMEOUT 30 /**< Timeout for Pairing Request or Security Request (in seconds). */
#define SEC_PARAM_BOND 1 /**< Perform bonding. */
#define SEC_PARAM_MITM 0 /**< Man In The Middle protection NOT required. */
#define SEC_PARAM_IO_CAPABILITIES BLE_GAP_IO_CAPS_NONE /**< No I/O capabilities. */
#define SEC_PARAM_OOB 0 /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE 7 /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE 16 /**< Maximum encryption key size. */
 
 m_conn_handle has been set earlier on, when the BLE_GAP_EVT_CONNECTED event comes into the same handler, like this: 
 m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
 
 I also know the connection event has happened, from my logs: 
 sd_app_evt_wait()
sd_app_evt_wait()
DM_EVT_CONNECTION
BLE_GAP_EVT_CONNECTED
sd_app_evt_wait()
DM_EVT_SECURITY_SETUP
BLE_GAP_EVT_SEC_PARAMS_REQUEST
 
 How can I tell what's invalid about the state I'm in? The central is an Android app and is my code.

Carles · Accepted Answer

Hi there, 
 After a quick analysis, there are 2 conditions that can trigger returning NRF_ERROR_INVALID_STATE when calling sd_ble_gap_sec_params_reply(): 
 
 A call to sd_ble_gap_sec_params_reply() is not pending. This would mean that you are either: 
 
 
 Calling it not in a reply to BLE_GAP_EVT_SEC_PARAMS_REQUEST 
 Your event pulling loop is not correct and you are calling it twice. To avoid this, please make absolutely sure that you initialize your contents of *p_len every time before you call sd_ble_evt_get(), inside the loop. I have seen this in the past and it turns out that sometimes the event is not pulled and the old event is processed twice. Make absolutely sure that the return code for sd_ble_evt_get() is NRF_SUCCESS before you process the event. 
 
 
 The link is being disconnected. This could be triggered locally or remotely. Make sure no one is disconnecting the link. 
 
 Carles

sd_ble_gap_sec_params_reply() returns NRF_ERROR_INVALID_STATE

Top Replies