iOS MTU sd_ble_gatts_exchange_mtu_reply crash

[BitsAndBytes]

We are using SDK nRF5_SDK_13.0.0_04a0bfd with the NRF52832 chip. Using peripheral role, the nRF is fatal crashing right after connecting with iOS nRFConnect (and our custom app) when the following function is called.

ret_code_t errCode = sd_ble_gatts_exchange_mtu_reply(connectHandle, BLE_GATT_ATT_MTU_DEFAULT);

APP_ERROR_CHECK(errCode);

I know how to fix the firmware crash, but the problem is it made it into the wild. It didn't get caught in QA process since not all iOS phones cause the crash and doesn't seem to happen on Android. We can't get connected long enough to do a DFU to fix the issue. Our customer base have a wide spread of mobile phone makes/models.

Does anyone know how to workaround this?

Thoughts:

1) Start DFU immediately before MTU negotiations start.

2) If possible, prevent iOS/CoreBluetooth from sending the MTU request.

Has anyone had similar or a suggestion?

Thanks

[Einar Thorsrud]

Hi,

This all depend on the implementation in the iOS side, but I doubt that an iOS app will have time to initiate DFU before MTU negotiation starts, as that typically happen more or less immediately after connection. For the second option, I have not been able to find any way for the app to prevent iOS from sending the MTU request, but I might have missed it.

Most likely the only option you have is to recommend users with "bad" iOS devices to use a different device to perform the DFU upgrade to the application firmware version that fixes this issue. It is not very elegant, but I suspect that is the most (perhaps only) viable solution.