Unexpected connection termination

[ahodder]

We are developing BLE 5.0 products using the nRF52832 running the Nordic S132 v6.0.0 softdevice and SDK version 15.0.0.

We noticed that one of our test devices, a Huawei Nexus 6P, would be disconnected after about 30 seconds from the microcontroller with a timeout error code (0x08). The error code that the microcontroller presented on disconnect was BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT (0x22). At first we thought it was an issue with our Android app, so we used the nRF Connect app for debugging and got the same result.

We experience this issue seemingly only with the Huawei Nexus 6P (Android 8.1). We tried to reproduce the issue on a Samsung Galaxy Tab S4 (Android 8.1), Pixel XL (Android 7.1.2) and Pixel 2 (Android 9.0) and had stable connections.

What causes this error code to be used? Are we incorrectly setting up our connection to handle devices that do not support BLE 5.0?

[run_ar]

Hi,

Can you capture a sniffer trace so we can see what is happening on air?

Please also check that you are handling the BLE_GAP_EVT_PHY_UPDATE_REQUEST and BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST. This should normally be handled in sdk 15, but they might not if you have updated your project from an older sdk.

[eric-appion]

Our code is using SDK 15.0.0 and S132 6.0.0.  There was already code for BLE_GAP_EVT_PHY_UPDATE_REQUEST, but I have added code for BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST, and that doesn't seem to have made a difference to the behavior.

case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
{
    NRF_LOG_DEBUG("GAP PHY update request.");
    ble_gap_phys_t const phys =
    {
        .rx_phys = BLE_GAP_PHY_AUTO,
        .tx_phys = BLE_GAP_PHY_AUTO,
    };
    err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
    APP_ERROR_CHECK(err_code);
} break;

The following code for BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST is from SDK 15.0.0 examples/peripheral/usbd_ble_uart/main.c
Different code is in the S132 nRF52 5.0.0 migration document, which passes NULL instead of &dl_params.

case BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST:
{
    ble_gap_data_length_params_t dl_params;
    NRF_LOG_DEBUG("GAP data length update request.");
    // 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;
 

Here are traces captured from the Pixel XL (android 7.1.2), showing no connection failure, and the Nexus 6P (Android 8.1), which consistently drops the connection after about 35 seconds. In both cases the phone was running nRFConnect app, and some time after connection establishment the firmware version string is read from the device information service, but no other BLE traffic is specifically requested using nRFConnect.

The Pixel XL connection starts at sequence #152 and the Nexus 6P at sequence #365 of their respective traces.

There are various differences between the traces, but two in particular stand out:

1) When the S132 sends an LL_LENGTH_REQ, the Pixel XL replies with an LL_LENGTH_RESP, but the Nexus 6P never replies.

2) After the S132 sends an LL_FEATURE_RSP (seq #378), the Nexus 6P sends an LL_REJECT_IND. I don't know if the two are related or what's going on with either packet.

There doesn't appear to be any BLE activity at the time of the disconnect. The firmware just goes back to advertising.

nexus_6p.pcapngpixel_xl.pcapng

[run_ar]

Could you also test with Nexus 6P using S132 v6.1? the s132_nrf52_6.1.0 is binary compatible with s132_nrf52_6.0.0. Hence existing applications running on s132_nrf52_6.0.0 does not need to be recompiled unless the new features are needed.

[eric-appion]

I just tested it with SDK 15.2.0 and S132 6.1.0. With Nexus 6P, the connection still fails after about 35 seconds. With all other Android devices at our disposal this doesn't happen. It appears that the Nexus 6P has a bug causing it to fail to reply to the LL_LENGTH_REQ, but it also appears that it is the S132 that is timing out and closing the connection.

If it is the S132 timing out the connection, it would be better if it didn't do that (e.g., the Robustness Principle: Be conservative in what you do, be liberal in what you accept from others).

[run_ar]

Could you try to add a delay before sending the LL_Length_request and also the Exchange MTU Request from the peripheral? I'll ask our softdevice team to take a look.