NRF52DK - Samsung GATT errors

[jfitter]

I am evaluating NRF for a commercial project. I am also new to this BLE business so trying to learn fast.

I am trying to run the supplied BLE UART example on the NRF52DK and connecting to a Samsung Note 4/Android 6.01.

Using S132 I can maintain a connection for only about 30 seconds then I get a GATT 133 Timeout error. This happens if I build the firmware and if I use the pre-compiled hexfile.

***If I use the precompiled hexfile built for S112 I do not get a gatt error and can remain connected for ever.***

I have not yet built firmware using S112 but will get around to it. I am using VGDB which does not allow building for the NRF58232 with S112. VGDB does allow building with S113 but this also produces gatt errors and disconnects.

I have spent a lot of time examaining the differences between the S132 and S112 builds and can find no differences that I understand would explain the difference in behaviour.

A lot, really lot, of net searching has revealed much discussion about this problem but NO solutions. The threads ask a lot of questions, provide a lot of guesses, but no answers. All I can determine is that Android developers screwed up their implementation and don't seem to have fixed it yet. The android forums are alive with this problem too, but no solutions.

From my perspective, unless there is a workaround I can forget a commercial application. It is not acceptable to expect customers to have one of a selected list of phones in order to use a product just because certain phone manufacturers are incapable of meeting their advertised specifications. I am better off finding another way to implement the product functionality.

The alternative is that there is a workaround at the peripheral end. It would seem this is the case since S112 works and S132 does not. Problem is I can't figure out what the difference is. Not enough experience yet. 

Has anyone got an explanation for this problem and a solution?

[jfitter]

This is getting confusing. I am awaiting a sniffer and will look at this more closely when I get it.

Meanwhile, here is a debug output of a connection. In nrf_ble_gatt.c data_length_update(...) I conditionally disabled all of the code and replaced it with a debug message to indicate the code was being ignored.

The code worked fine and there was no GATT 133 error.

00> <info> app_timer: RTC: initialized.
00> <info> app: Debug logging for UART over RTT started.
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
00> <debug> nrf_ble_gatt: Ignoring data length update to 251 on connection 0x0.
00> <info> app: Connected
00> <debug> nrf_ble_gatt: ATT MTU updated to 247 bytes on connection 0x0 (response).
00> <info> app: Data len is set to 0xF4(244)
00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 260 bytes.
00> <debug> nrf_ble_gatt: Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
00> <info> app: Data len is set to 0xF4(244)
00> <debug> app: ATT MTU exchange completed. central 0xF7 peripheral 0xF7
00> <debug> app: Received data from BLE NUS. Writing data on UART.
00> <debug> app:  68 65 6C 6C 6F         |hello   
00> <debug> app: Ready to send data over BLE NUS
00> <debug> app:  68 69 0A               |hi.     
00> <info> app: Disconnected
00> <info> app_timer: RTC: initialized.
00> <info> app: Debug logging for UART over RTT started.

It is clear in the log where the attempt to change the data length would occur. If this is allowed to occur then soon after there is a gatt error and disconnect - every time.

The mtu is updated without consequence.

The data length is reported as 244 - happy with that, and mtu-3 as expected.

So it seems that any attempt to update the data length causes a disconnect - Samsung Note 4/Android 6.01

??????

[Kenneth]

I am not sure what workarounds that is possible here, other than in some way control not to execute the data length update. Can you on the disconnect event print out the disconnect reason?

Should be passed with the BLE_GAP_EVT_DISCONNECT event in p_ble_evt->evt.gap_evt.params.disconnected.reason, I expect reason to be one of the Bluetooth status codes as listed in ble_hci.h.

I suspect the reason is BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT, so it could for instance be possible to re-connect if that error code occurs and then skip the data length update on next connection. Totally understand it's not ideal, but at least you avoid repeatedly disconnect.

Best regards,
Kenneth

[jfitter]

Thanks for your help. I just ran the test and indeed the reason code is 0x22 as you suspected. Your advice for a work-around is sound and would work now that I know what is happening, but it really does not solve the problem or add to my understanding of BLE.

Time to hit the books and learn about LMP response Timeout