BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE with nRF Connect Desktop on PCA10056

[Austin]

I have been successfully using nRF Connect v2.5.0 on Windows with a PCA10056 v0.9.2 to communicate with our target device, a nRF52840 using S140 v6.0.0, nRF5 SDK 15.0.0.  We're using bonded connection with passcode entry (without LE Secure Connections).

We recently introduced a change in the target device to increase the BLE throughput by modifying NRF_SDH_BLE_GAP_DATA_LENGTH from the default of 27 to 50.  With this change in place on the target, we can successfully bond the PCA10056 with the target, but as soon as an attempt is made to read a secured characteristic the following error occurs in nRF Connect with a subsequent BLE disconnect: BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE

Connecting to device

Connected to device E1:FB:ED:C3:13:E7

ATT MTU changed, new value is 46

Attribute value read, handle: 0x03, value (0x): 53-65-6C-66

Connection parameters updated for device E1:FB:ED:C3:13:E7: interval 60ms, timeout 5000ms, latency: 0

Security updated, mode:1, level:3

Storing bond info for device E1:FB:ED:C3:13:E7

<Read of device characteristic initiated from nRF Connect here>

Disconnected from device E1:FB:ED:C3:13:E7, reason: BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE

I understand that a MIC failure is a result of a failed message integrity check for encrypted connections however there is no reason that I can see that would cause this condition.

Some other observations:

• The target firmware with updated NRF_SDH_BLE_GAP_DATA_LENGTH works correctly when used with a PCA10040 v1.1.1, a Samsung S6 and Samsung J3.
• If NRF_SDH_BLE_GAP_DATA_LENGTH is set to 27 everything works as expected.  This issue appears to be relate to Data Length Extension support.
• nRF52840_xxAA_ENGA is reported as the MCU on PCA10056.
• When the connectivity firmware version from PCA10056 is read back using nRF Connect v2.5.0 Programmer, the SoftDevice detected is id 0x91 (S132, v3.1.0).  This is surprising since this appears to be quite an old SoftDevice and I'm not sure that S132 is supported on the nRF52840?  I would have expected the connectivity firmware for PCA10056 to include SoftDevice S140.
• I tested connectivity to to another PCA10056 running the ble_app_hrs example which uses NRF_SDH_BLE_GAP_DATA_LENGTH of 251 and the connection worked as expected.  For this test pairing was performed but not bonding.

This only seems to be an issue with this specific combination of DLE, PCA10056, bonding and nRF Connect Desktop.

Any ideas on what could be wrong?

[Marjeris Romero]

Hi Austin,

It is hard to say what the issue could be here. You will get a MIC failure when using incorrect encryption keys when you try to encrypt the link with a bonded device. The only think I can think of if you haven't try before is to delete the bond information on both the sides and try bonding again and see if that helps.

Maybe you can attach your code here so I can try to reproduce your issue? Or just attached the code for the peer manager, pm_evt_handler and the security parameters, so I can test the ble_app_hrs example with the same security setup you have and see if that works on my side.

I also did a read back of the connectivity firmware install by nRF Connect the PCA10056 boards I have (I have quite a few versions on my desk) and was also suprise to see that the softdevice detected was indeed S123 v3.1.0, I will ask the nRF Connect team about that, but I am not sure if this have something to do with the problem.

Best Regards,

Marjeris

[Austin]

Hi Marjeris,

Thanks for taking a look at this issue.  My project is too big to share but I've been able to reproduce this issue with some alterations to the ble_app_proximity example app.  I modified the sdk_config.h to match the configuration used by our device, then added the BLE NUS service to the project as well as this is also used by our device.  With this combination of changes I receive a BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE.

Here is my method to reproduce the issue:

• Apply the attached patch to a fresh nRF5 SDK 15.0.0 source tree.  The patch modifies the ble_app_proximity project as described above.
• Compile and download ble_app_proximity to a PCA10056 with S140 6.0.0 loaded.  I'm using the gcc compiler.
• Use nRF Connect for Windows with a second PCA10056 to communicate via BLE with the target using the following sequence.
• Start ble_app_proximity on first PCA10056, holding down button 2 to erase bonds on startup.
• Scan for Nordic_Prox device using second PCA10056 and press Connect.
• Choose Gear Icon > Pair, select Perform bonding (only) and then Pair.  Once pairing complete close pairing window.
• Services from ble_app_proximity will have now been discovered and shown in list, last service is 'UART over BLE'.
• Click on 'UART over BLE' and the fault will be generated with 'Device disconnected' dialog and message in log similar to the following. 'Disconnected from device D7:E7:E8:1D:8F:2D, reason: BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE'

I have tried the same test with a PCA10040 connected to nRF Desktop and no error occurs.

Regards

Austin

ble_hci_conn_terminated_due_to_mic_failure.patch

[Marjeris Romero]

Hi Austin,

Thank you for your really detailed step by step guide in how to reproduce your issue, it was really helpful. I implemented the patch and had zero problems reproducing the BLE_HCI_CONN_TERMINATED_DUE_TO_MIC_FAILURE error and trying to debug it. I tested different versions of the nRF52840 DK and can verify that this error message is only showing in version v0.9.2.

Version 0.9.2 is an engineering A board, meaning that it is a preview, and a lot of fixes were implemented in engineering revision B, and then in C and now we are in version 1 https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52%2Fdita%2Fnrf52%2Ferrata52840.html&cp=2_0_1

The extended list about the fixed anomalies from revision A to revision B is here https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52840.EngB.errata%2Fdita%2Ferrata%2FnRF52840%2FEngineeringB%2Flatest%2Ferr_840_fixed.html&cp=2_0_1_2_2

And as you can see the list is pretty long, so it is a little bit difficult to know exactly what was causing the error after bonding, it could be a timing issue or something else. However this problem does not occur in Engineering version B so it must be something related to the fixed anomalies I linked above.

So the short answer to this problem is getting a newer version of our nRF52840 DK since Engineering version A is deprecated. We always recommend getting the newest release of the hardware since engineering versions are previews that are meant to show a preview of the features in a product but as you can see there are several bug fixes between Engineering A and the final Version 1.

But you can of course continue using the DK you have, just bear in mind that it can have some bugs as for instance it does here.

A funny thing is that I didn't have any error if I read the "UART over BLE" characteristic before performing the bonding (so just on connect with my device), and then bond and read the characteristic again. So you can try and see if this is a possible "fix" for you.

I hope this explanaition helps and that you now can continue working on your project. I am sorry if this issue have bother you, but at least now we know where it is coming from

Best Regards,

Marjeris

[Austin]

Hi Marjeris

Thanks for your thorough investigation.  It's good to know that this error doesn't occur on newer hardware.  I have been through the errata lists multiple times as the project has progressed but it's not always easy to determine the impact of a single errata.  I agree that we should move to newer PCA10056 dev kits.

I'm still interested in any comments your developers may have regarding the SoftDevice version used for connectivity firmware on PCA10056 so when you have an update, please post here.

Thank you

Austin