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]

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?