CC2640R2F: simple_peripheral: unexpectedly slow pairing exchange using BLE-Stack and LE Secure Connections

John Whitehouse

Part Number: CC2640R2F

Hello,

I've recently been investigating a problem on a CC2640R2F project where we're getting intermittent pairing problems with certain Android devices. I've replicated the problem using the blestack simple_peripheral example included with SimpleLink SDK v3.20. It looks like this issue was raised previously (see related question).

To align simple_peripheral to the target settings on my project, I have modified simple_peripheral.c as follows (starting at line 560):

// Don't send a pairing request after connecting; the peer device must
// initiate pairing
uint8_t pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
// Use authenticated pairing: require passcode.
uint8_t mitm = FALSE; // JW - modified for 'Just Works' authentication
// This device only has display capabilities. Therefore, it will display the
// passcode during pairing. However, since the default passcode is being
// used, there is no need to display anything.
uint8_t ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT; // JW - modified for 'Just Works' authentication
// Request bonding (storing long-term keys for re-encryption upon subsequent
// connections without repairing)
uint8_t bonding = TRUE;
// Whether to replace the least recently used entry when bond list is full,
// and a new device is bonded.
// Alternative is pairing succeeds but bonding fails, unless application has
// manually erased at least one bond.
uint8_t replaceBonds = FALSE;

// JW - added to enforce LE Secure Connections.
uint8_t secureConnection = GAPBOND_SECURE_CONNECTION_ONLY;

GAPBondMgr_SetParameter(GAPBOND_PAIRING_MODE, sizeof(uint8_t), &pairMode);
GAPBondMgr_SetParameter(GAPBOND_MITM_PROTECTION, sizeof(uint8_t), &mitm);
GAPBondMgr_SetParameter(GAPBOND_IO_CAPABILITIES, sizeof(uint8_t), &ioCap);
GAPBondMgr_SetParameter(GAPBOND_BONDING_ENABLED, sizeof(uint8_t), &bonding);
GAPBondMgr_SetParameter(GAPBOND_LRU_BOND_REPLACEMENT, sizeof(uint8_t), &replaceBonds);
GAPBondMgr_SetParameter(GAPBOND_SECURE_CONNECTION, sizeof(uint8_t), &secureConnection); // JW - added

I have tried this code out with a Samsung Galaxy A10 and a Moto E6 Plus, using the nRF Connect app for triggering bonding operations.

The Galaxy A10 bonds within 1 second.

The Moto E6 Plus normally takes around 20 seconds for all pairing packets to be exchanged, with another 20 seconds before bonding is reported by the app and simple_peripheral terminal.

Occasionally, the Moto E6 pairing packets are exchanged quickly, but there is still a 20 second delay before bonding is reported.

I have tried this with SimpleLink SDK versions 1.50 and 4.10 and get the same result.

If I compile the Stack project included with simple_peripheral with SC_HOST_DEBUG - turning on support for Bluetooth debug keys - both phones bond within 1 second.

If I make the same modification to the blestack5 simple_peripheral example, both phones bond within 1 second. Note that Bluetooth debug keys were not enabled in this case and I was using SimpleLink SDK v3.20.

I'd be grateful for any suggestions on how to fix/workaround this issue.

Thanks,

John

over 5 years ago

0 Marie H over 5 years ago

TI__Guru* 82861 points

Hi John,

Can you post sniffer logs of the pairing process, both with the Samsung Galaxy A10 and the Moto E6 Plus?

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

Please see attached, based on using SDK versions 3.20 and 4.10. All pairing attempts were made using the nRF Connect app. I am using a Frontline BPA low energy analyser.

Please let me know if you need anything else.

Regards,

JohnMoto_E6_Plus_SDK3.20.zip Samsung_A10_SDK3.20.zip Moto_E6_Plus_SDK4.10.zip Samsung_A10_SDK4.10.zip

0 John Whitehouse over 5 years ago in reply to John Whitehouse

Intellectual 620 points

Hello,

Have you managed to make any progress on this issue?

Do you need any further data from me?

Regards,

John

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

Is there any further update on this issue?

Thanks,

John

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

Sorry, I didn't have time to take a look at the sniffer logs yet.

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

For the Moto E6 Plus phone I am looking at the log marked "attempt 2" (since "attempt 1" is not successful).

Looking at the sniffer logs I can see the same pairing method is chosen in both cases: Secure connections Just works unauthenticated. They also use the same connection interval, 7.50 ms.

For the Samsung phone the pairing process takes 0.47 s. For the moto it takes 17.45 seconds. The longest steps are:

waiting for the motorola to supply the Pairing public key (looks like the sniffer missed this packet): 3.60 s
waiting for the motorola to supply the Pairing random value: 3.60 s
waiting for the CC2640R2 to perform the DHKey check: 7.21 s.

I don't know why the motorola spends more time pairing with the 4.10 SDK compared to the 3.20 SDK. For this you will need to reach out to them.

I will try reaching out to out BLE software development team regarding the DHKey check.

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

Thanks for looking into this.

Marie H said:

...

For the Samsung phone the pairing process takes 0.47 s. For the moto it takes 17.45 seconds. The longest steps are:

waiting for the motorola to supply the Pairing public key (looks like the sniffer missed this packet): 3.60 s

waiting for the motorola to supply the Pairing random value: 3.60 s

waiting for the CC2640R2 to perform the DHKey check: 7.21 s.

I don't know why the motorola spends more time pairing with the 4.10 SDK compared to the 3.20 SDK. For this you will need to reach out to them.

On the first point, across the examples I've captured I've not seen the public key from the Motorola side. As such, I don't know if the wait is due to the Motorola or CC2640R2: did you spot this anywhere else in the capture?

On the second point, I agree that the Motorola appears to take 3.60s to respond to 'Pairing Confirm' from the CC2640R2 with a 'Pairing Random'. However, during that time the Motorola is sending a large number of empty keep-alive packets to the CC2640R2F which are not responded to (frames 1282 to 1936) until the CC2640R2 sends its own empty packet. It's like the Motorola is waiting for the CC2640R2 to be awake again before sending its next data.

I think the CC2640R2 is also taking a very long time to come up with its 'Pairing Random' response (again, 3.60 seconds).

Noting your third point, there seems to be some kind of 'sync' onto a multiple of 3.60 seconds (7.21s in this case).

Marie H said:

I will try reaching out to out BLE software development team regarding the DHKey check.

Thanks for doing so.

John

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

As a further thought - which I mentioned in passing in my original email - I didn't see the same issue with the Motorola when using the ble5stack simple_peripheral example modified in the same way.

If it's useful, I can prepare some sniffer captures of that setup for you?

Thanks,

John

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

Thank you for alerting me to that. I didn't notice it. It's good luck that the connection has such a long supervision timeout, if it didn't the connection would e broken.

No need to post the ble5stack logs. However if you have a sniffer log of the fail when you tested with 4.10 SDK it would be helpful.

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

I've reattached the sniffer logs I've taken when using v4.10 of the SDK.

Hope that's helpful.

Thanks,

John3124.Moto_E6_Plus_SDK4.10.zip 8078.Samsung_A10_SDK4.10.zip

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

Thank you.

Can you check the android version on your smart phones?

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

Please see below.

Moto E6 Plus

Android version: 9

Kernel version: 4.9.117+

Build number: PTAS29.401-25-2

Android security patch level: 1 February 2020

Samsung A10

Android version: 9

Kernel version: 4.4.111-16046393

Build number: PPR1.180610.011.A105FNXXS3ATD2

Android security patch level: 1 April 2020

Hope that helps.

John

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

Have you managed to make any progress on this issue?

Many thanks,

John

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

I am awaiting feed-back from the software developer team.

Did you consider using legacy pairing (instead of secure connections) as a work-around?

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

I've not looked at legacy pairing as a workaround as that's not viable for our current project.

Please keep me informed of feedback from the software developer team.

Thanks,

John

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

Can you do a quick test and check the ICall heap when this happens?

We have a description for how to check it here:

0 Evan W over 5 years ago in reply to Marie H

TI__Mastermind 40600 points

Hi John,

Could you also provide what you have for the two settings below in your application?

// Minimum connection interval (units of 1.25ms, 80=100ms) for parameter update request

#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 80

// Maximum connection interval (units of 1.25ms, 104=130ms) for parameter update request

#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 104

Android devices will typically cycle the connection parameters down to 7.5ms to execute GATT discovery as quickly as possible and then recycle back to a slower connection event later on. There is a theory that this parameter, in addition to an additional connection parameter update that occurred prior to this request for 7.5ms has potentially caused an issue.

We would like to understand:

1) What are your current settings for min connection interval in the peripheral device and are you able to set the desired min connection interval to something like 48.75ms so that the android device will not cycle the connection to a quicker connection event?

2) are you able to disable the android device from sending this connection parameter request to go to 7.5ms? You can reference the Android Bluetooth GATT section that discusses the various parameters that can be chosen when developing your Android app. Specifically "CONNECTION_PRIORITY_BALANCED" may be a great option or "CONNECTION_PRIORITY_LOW_POWER".

https://developer.android.com/reference/android/bluetooth/BluetoothGatt

0 John Whitehouse over 5 years ago in reply to Evan W

Intellectual 620 points

Hi Evan,

In the example I have, the settings are as follows (defaults for simple_peripheral example):

#define DEFAULT_DESIRED_MIN_CONN_INTERVAL 80

#define DEFAULT_DESIRED_MAX_CONN_INTERVAL 800

As far as I understand, the central can still force a connection interval of 7.5ms: the values above are preferences rather than mandatory.

I have been using the nRF Connect app for the testing. I'm not sure it provides the facility to stop the connection parameter request.

Thanks,

John

0 John Whitehouse over 5 years ago in reply to Marie H

Intellectual 620 points

Hi Marie,

I'll see if I get chance do that in the next few days. Has this come up as a potential source of the problem from the development team's investigation?

Thanks,

John

0 Marie H over 5 years ago in reply to John Whitehouse

TI__Guru* 82861 points

Hi John,

Were you able to do the test?

Since the CC2640R2 has a relatively limited RAM size it's often relevant to check RAM memory (heap and stacks) when there are runtime issues with this device.

0 Evan W over 5 years ago in reply to Marie H

TI__Mastermind 40600 points

Hi John,

We believe we have found the root cause of this issue but it will require a stack update. Would you be willing to wait until the 4.30 SDK which will be available within the first few weeks of October?

If not, we can discuss other options offline with you and Franz.

0 John Whitehouse over 5 years ago in reply to Evan W

Intellectual 620 points

Hi Evan,

Many thanks for the update.

We're presently targeting a design freeze in September, so it would be useful to understand the other options with you and Franz.

Kind regards,

John

0 John Whitehouse over 5 years ago in reply to Evan W

Intellectual 620 points

Hi Evan,

If you could get in touch with me offline then I'd be keen to discuss the options through with you:

Many thanks,

John

0 Evan W over 5 years ago in reply to John Whitehouse

TI__Mastermind 40600 points

Hey John,

I'm working with Franz to set up a call so we can discuss next steps. For privacy, i'm editing your post to remove your email.

Bluetooth®︎

Bluetooth forum

CC2640R2F: simple_peripheral: unexpectedly slow pairing exchange using BLE-Stack and LE Secure Connections