Problems with iOS connection,

[kleonhardt]

Hi Nordic

I have a similar problem as described in the following case:

Cannot connect to nRF52840 from iPhone/iPad running iOS 14 using nRF Connect App - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

However we are using the SDK17.1.0 on nRF52833-DK. And iPhone Xr with iOS 17.2.1. (Tried with few other iPhones, which does not work either.)

I have added the switch-case for BLE_GAP_EVT_PHY_UPDATE_REQUEST, and tried with BLE_GAP_PHY_AUTO  and BLE_GAP_PHY_2MBPS. 

On the device I got following trace:

0000007.126/app/MESSAGE: ConnectionParamsEvent=1
0000007.127/plf/PLF: BUS_EventHandler: BLE_GAP_EVT_CONNECTED
0000007.127/app/MESSAGE: BEKEY_BLE_CONNECTION_CREATED
0000007.135/app/MESSAGE: Generate AKEP_HELLO_REQ!
0000007.327/plf/PLF: PHY update request.
0000008.587/app/BLE_ADV_EVT_FAST
0000008.587/plf/PLF: BUS_EventHandler: BLE_GAP_EVT_DISCONNECTED
0000008.587/plf/PLF: BAPI_EventHandler: BLE_GAP_EVT_DISCONNECTED
0000008.588/plf/PLF: BleEventHandler: BLE_GAP_EVT_DISCONNECTED

On the iOS end there is no trace of any BLE connection. The device application works on a similar Android app.

Our iOS developer has traced back that some communication in the GATT is different. It comes visible using the nRF Connect app for Android. 

The application is actually a port of an application on nRF51822 with SDK 12.3.0. The only change of BLE code is for adapting to the changes in the SDK from version 12.3.0 to 17.2.1. Primary the advertising data construction had to be rewritten.

Do you have any clue how to investigate this problem?

[Edvin]

Hello,

It is difficult to say the exact reason for the disconnection at this point, but here are a few pointers:

1: Make sure that your phone is not bonded with the nRF chip. This means that at some point, the same nRF chip was used in a connection with bonding, so that the phone may have stored encryption keys for the BLE device with that specific BLE address. On iOS, go to the phone settings -> Bluetooth, and see if any of the known devices in that list may be for that chip running some previous application. If you find it, select it and click remove device. 

2: I don't think this is the case, because I believe the log would say something about it, but make sure that you don't have bonding information on the nRF either. The easiest way to delete this is to erase the entire flash and re-program it. 

2.5: In general, when developing, bonding data that is out of sync is something to be aware of. If one of the devices has stored an LTK (Long Term Key), and the other one has deleted it, then the device with the key will say: Let's encrypt using our pre-known key, while the other doesn't know that key. This usually leads to a disconnection, because for the device with the key, it looks like the other device is an imposter. 

3: It could be timing related issues. You are running this application on a new set of HW/PCB, where the timing may be different, or a bit off. What you are seeing could be that the Android device will accept this as an outline, but the iOS device will start missing packets. If this is the case, you can check the disconnect reason. Add this to your disconnection event in main.c's ble_evt_handler():

        case BLE_GAP_EVT_DISCONNECTED:

            NRF_LOG_INFO("Disconnected. conn_handle: 0x%x, reason: 0x%x",
                         p_gap_evt->conn_handle,
                         p_gap_evt->params.disconnected.reason);
            break;

The disconnect reasons will correspond to the BLE_HCI_STATUS_CODES, found in SDK\components\softdevice\sXXX\headers\ble_hci.h.

If you see 0x08, then it is a timeout, and it may be timing related. If you see 0x16 ro 0x13, it means that one of the devices determined to disconnect, and then we need to find the reason for that. 

4: You can capture a sniffer trace using the nRF Sniffer for Bluetooth LE. This is a bit more work to set up, but it will most likely give the reason for the disconnect.

5: The log that you posted looks like a custom log. Did you try to enable the default logging module? Does it say anything useful?

Best regards,

Edvin

[kleonhardt]

Thanks.

1: No paired devices. So not the problem.

2: I do not think out code supports bonding. Any way we are not using the persistent storage module. As I remember the SDK uses the PS for bonding information. So not the problem.

3: I added the code, and got reason 0x13: BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION. This was expected.

4: My colleague did indeed in the mean time setup the nRF sniffer on a nRF52833DK. But it seems hard to read. So we postponed this.

5. I struggled to enable the log system on the SDK using the Segger RTT. However I could not understand why no logs was produced during connection. Especially from the GATT module. I realized that the initialization of the GATT module was slipped out of the main file in the migration to the SDK v. 17.

Now it works. Thanks a lot.

[Edvin]

I'm glad to hear that you figured out the cause of the issue, and thanks for sharing!

Best regards,

Edvin