Reference: https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/p/905072/3353877

Installer: simplelink_cc2640r2_sdk_4_10_00_10 (also tested with 1.50 SDK and 3.20 SDK)

Problem description:

The customer described the problem as "pairing with Moto E6 Plus takes very long". By looking at a sniffer log we can see that the CC2640R2 stops responding to connection events for extended periods of time - 3.6 and 7.2 s. This happens in the middle of the pairing process.

Taking (a particular log) as an example:

• The connection is initiated in frame 667.
• In frame 702 the connection parameters are updated (connection interval changed to 7.5 ms). This is valid from instance 0x0004, which happens to be the instance where the pairing request s sent.
• In frame 704 the pairing request is sent.
• In frame 713 the pairing response is sent. The pairing method is Just works unauthenticated with secure connections enabled.
• After sending the pairing response the slave attends one more connection event, then it stops responding. (Time stamp: 8:44:06.487728.)
• The next connection event packet sent from the slave is frame number 1345 (timestamp: 8:44:09.314445). This is 2.82 s later.
• The slave sends its Pairing Public Key (frame 1349). (The sniffer doesn't register a pairing public key from the master. I'm not sure if this is a sniffer error. It happens in all the three attached sniffer logs.)
• In frame 1351 the slave sends its pairing confirm. (Timestamp 8.44.09.316375.) After this is stops responding again.
• The next time the slave wakes up is in frame 2150 (timestamp 8.44.12.921945), 3.60 s later. It receives the master pairing random value (frame 2151). Then is stops responding again. (Last frame 2154, timestamp 8:44:12.923032)
• The next time the slave sends a connection event is frame 2972, timestamp 8:44:16.52944. (3.60 s later). It sends a single connection event containing the srand value. It doesn't respond to more than one connection event.
• The next connection event from the slave is frame 3751, timestamp 8.44.20.137112. (Again it's 3.60 s later.) It also attends the next connection event, frame 3753, timestamp 8.44.20.137571.
• The next time the slave wakes up is fram 4541, timestamp 8.44.23.744443. 3.60 s later...

The connection goes on like this.

Investigation with Motorola G6 phone:

Programmed one CC2640R2 LaunchPad with simple peripheral hex from the 4.10 SDK.

We have two sniffer logs for pairing attempts with Motorola E4 phone. It's not exactly the same as Motorola E6 but it's similar:

1) In frame 6971 the master sends a connection update command to update from 50 ms to 7.5 ms connection interval. This is acknowledged by the slave.

2) In frame 6981 the pairing process starts. It goes well until the slave suddenly stops responding. 

3) Frame 7087 (pairing public key) is the last packet sent by the slave. Please note the connection has not yet changed connection interval.

4) In frame 7117 the connection changes connection interval. This is the second connection event missed by the slave.