BLE pairing issues with Lenovo X240

[ohtap]

Hi,

We have a BLE peripheral device that is used as a mouse/keyboard (nRF52832 SDK 14.0)

The peripheral pairs with most central devices just fine (including Mac and PC), except it seems with some models of Lenovo laptops.

When attempting to pair with the X240 model (Windows 10) , we get "Driver error" on the Bluetooth menu. Pairing with an example Nordic keyboard seems to work fine. The problem is reproduced with different 53832 boards.

Sniffing yields the results in the attached file.

We tried updating the drivers and disabling/enabling the Bluetooth device (via Device Manager) but it only fixes the issue once every few dozen attempts. When it actually manages to pair, it works just fine, but getting there is a problem. The "fix" itself is also temporary and has to be done again if the device is unpaired.

We're not sure if it's an issue with our app or some issues with the drivers. Would appreciate help.

Thanks.

Pairing with x240.pcapng

[Susheel Nuguru]

Hi there,

It is really hard to say what went wrong with the information provided. Have you tried taking a sniffer log and see of few phones are doing something differently in air which is not compatible with the BLE spec. If you attach a sniffer log when trying to pair with Lenovo (or devices that does not pair), then we will try to narrow it down.

[gkovelman_tap]

Also, this issue is reproducible with example HID projects when increasing the ATT MTU to higher than 23.

Further checking that with reducing ATT MTU to 23, the above Lenovo is able to pair successfully with our device.
Was this experienced ever? Could the SoftDevice be exchanging MTU incorrectly?

We need the higher MTU for part of our application.

[Susheel Nuguru]

we can do a small workaround without breaking the state machine of the SDK

in nrf_ble_gatt.c->on_connected_evt replace

        err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);

with 

        // err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);
        err_code = NRF_ERROR_BUSY;

This will tell the module to retry it after sometime (after getting new ble event). This should work fine in your case. 

[ohtap]

We've added a 5 sec delay to the MTU exchange process, it seems it gives the central device enough time to initiate the exchange correctly.  

We had to edit nrf_ble_gatt.c (on_connected_evt specifically), so we're hoping not to introduce new issues. Do you have any recommendations to make sure the rest of the environment wasn't negatively affected?

Thanks

[Susheel Nuguru]

where exactly have you added 5 secs delay? i hope that you did it in thread context and not inside any ISR

[ohtap]

The delay was added in on_connected_evt using a FREERTOS timer.

After the callback, sd_ble_gattc_exchange_mtu_request uses the connection handle and the desired MTU, so we save those before we start the timer (conn_handle, p_link).

Any danger of possible races? any external entities changing those parameters?

Thanks

[Susheel Nuguru]

on_connected_evt happens in SWI2 interrupt context and adding a synchronous busy delay in any ISR is not recommended (if not forbidden). There will be a lot of side affects to it, 

1) no other events will be able to processed during this time. trying to test the softdevice events buffering capacity on a busy link

2) FreeRTOS tick handler is running on lower priority than SWI2 interrupt. So for 5 seconds, you are not allowing it to update ticks. If you set configUSE_DISABLE_TICK_AUTO_CORRECTION_DEBUG = 1 in your project, this will make the RTOS timer completely wrong. But if you do not disable autocorrection of internal timers, then the FreeRTOS will try to recover as soon as tick event gets a chance to run.

Did you try the suggestion I gave? Did it not work?

[ohtap]

Maybe I phrased it improperly - we're not using osDelay, instead we're using osTimer (asynchronous) with a callback to a new function we created inside nrf_ble_gatt.c. There we use sd_ble_gattc_exchange_mtu_request.

Unfortunately the original suggestion didn't work, possibly because the next MTU exchange request came too soon after the first one (Slave->Master). After adding the delay, the sniffer shows the Master initiating the exchange about 1 second after the initial connection, which succeeds.

Our main concern with the timer we added is some race caused by external events related to the parameters passed to sd_ble_gattc_exchange_mtu_request. Can those parameters change in short time periods?

[Susheel Nuguru]

You way of adding a timer and letting master do an MTU exchange seems safe. There is nothing i can think of that could cause problems this way.