NRF_ERROR_INVALID_PARAMS with sd_ble_gap_data_length_update

[Seth Foster]

I'm using nRF5_SDK_14.0.0_3bcc1f7 and SD132 v5.0.0. In response a DATA_LENGTH_UPDATE_REQUEST event, I'm calling sd_ble_gap_data_length_update as follows:

ble_gap_data_length_params_t response = {
    .max_tx_octets = 73,
    .max_rx_octets = 73,
    .max_tx_time_us = BLE_GAP_DATA_LENGTH_AUTO,
    .max_rx_time_us = BLE_GAP_DATA_LENGTH_AUTO
};
ble_gap_data_length_limitation_t lims;
uint32_t err
    = sd_ble_gap_data_length_update(m_conn_handle, &response, &lims);

and getting NRF_ERROR_INVALID_PARAMS. I'm not entirely sure what's invalid about this request, since i'm specifying auto for the time fields and 73 is lower than 251.

Edit: This also occurs if I specify both octets fields with BLE_GAP_DATA_LENGTH_AUTO. The only way I can call this function and get NRF_SUCCESS in response is with NULL as the p_dl_params parameter.

[Seth Foster]

It's a custom application using serialization. I'm calling sd_ble_gap_data_length_update() only in response to a BLE_GAP_EVT_DATA_LENGTH_UPDATE received from the peer, in my SDH observer.

The peer is an Android phone and it seems to be issuing the data length update after the Android application requests an extended MTU. Viewing a sniffer output when I use BLE_GAP_DATA_LENGTH_AUTO in all the parameters, the message sequence looks like this, where the NRF52 is the peripheral and the android device is the central:

1. Central->Peripheral: Exchange MTU request, client Rx MTU 41
2. Peripheral->Central: Exchange MTU response, server Rx MTU 69
3. Central->Peripheral: LL length request, Rx octets 251, rx time 2120, tx octets 45, tx time 472
4. Either nothing, if sd_ble_gap_data_length_update called with params, or 251/251/2120/2120 response.