SDK 15.2.0, SD 132, nRF52832-QFAA, sd_ble_gap_data_length_update() sometimes errors with 0x08 (INVALID_STATE)

[markuckermann]

Hi there,

We have a product using an nRF52832-QFAA, with the SDK15.2.0, the 132 Softdevice, and an application based around the Nordic UART service (nus). Customers are reporting crashes and we have narrowed it down to this code:

case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
    {
        ble_gap_data_length_params_t dl_params;

        // Clearing the struct will effectivly set members to @ref BLE_GAP_DATA_LENGTH_AUTO
        memset(&dl_params, 0, sizeof(ble_gap_data_length_params_t));
        err_code = sd_ble_gap_data_length_update(p_ble_evt->evt.gap_evt.conn_handle, &dl_params, NULL);
        APP_ERROR_CHECK(err_code);
    } break;

The returned error code is 0x08 (INVALID_STATE)

This rarely happens and is inconsistent. Unpairing and repairing their phone to our device make the issue goes away. We have not been able to reproduce it, data length request changes using the nrf Connect for Desktop work fine.

Can you explain what would cause an INVALID_STATE?

Can you tell us if reducing BLE_NUS_MAX_TX_CHAR_LEN and BLE_NUS_MAX_RX_CHAR_LEN to 20 and therefore reducing the characteristic's max_len to 20 is likely to prevent this?

Thanks a lot,
Mark

[Einar Thorsrud]

Hi Mark,

You will get NRF_ERROR_INVALID_STATE returned from sd_ble_gap_data_length_update() is when the link is about to be disconnected (so the internal state in the SoftDevice for that link is "disconnecting"). As far as I can see, that is the only situation that would cause this return value.

Einar

[markuckermann]

Ah ok, that's interesting, thanks for looking that up.

What could cause the SoftDevice to be in the "disconnecting" state? A call to sd_ble_gap_disconnect() or can the SoftDevice decide by itself to get into that state?

We call sd_ble_gap_disconnect() after a BLE_GAP_EVT_AUTH_STATUS event where pairing has failed, for PM_EVT_CONN_SEC_FAILED or a BLE_GATTC_EVT_TIMEOUT / BLE_GATTS_EVT_TIMEOUT.

Would it be safe to call sd_ble_gap_disconnect() when we receive NRF_ERROR_INVALID_STATE from sd_ble_gap_data_length_update() just to make sure?

Or maybe we should just ignore that INVALID_RETURN all together because it is disconnecting already anyway.

Btw, we still haven't been able to reproduce it. It must be reasonably rare, 8 reports in 2 months with daily users in the thousands.

[Einar Thorsrud]

markuckermann said:

What could cause the SoftDevice to be in the "disconnecting" state? A call to sd_ble_gap_disconnect() or can the SoftDevice decide by itself to get into that state?

A call to sd_ble_gap_disconnect() will make the SoftDevice enter this state. However, it can also enter this state when disconnecting due to an error on the link which should cause a disconnect.

markuckermann said:

Would it be safe to call sd_ble_gap_disconnect() when we receive NRF_ERROR_INVALID_STATE from sd_ble_gap_data_length_update() just to make sure?

That is safe, though perhaps not of any use. But depending on the sate you could get NRF_ERROR_INVALID_STATE or BLE_ERROR_INVALID_CONN_HANDLE, so you should handle that (typically by ignoring it).

markuckermann said:

Or maybe we should just ignore that INVALID_RETURN all together because it is disconnecting already anyway.

Yes, that makes the most sense.