CC2642R: Bluetooth abnormal disconnection

Hi Alex,

Thank you for reaching out to us. We will look into your questions and get back to you as soon as possible. In the meantime, can you provide the SDK where this behavior is observed? Is this behavior occurring on an unmodified example project? If not, then can you share which example project was used as a base for the custom project as well as the general modifications made?

Best Regards,

Jan

Hi，Jan

thanks for your reply，I will provide you with relevant information later

Best Regards,

Alex

1.simplelink_cc13x2_26x2_sdk_4_10_00_78、simplelink_cc13xx_cc26xx_sdk_6_10_00_29
    Both versions of the SDK have this behavior.
2.I used：examples\rtos\CC26X2R1_LAUNCHXL\ble5stack\simple_peripheral
  There are no changes to the Bluetooth connection/disconnection section。

Hi Alex,

Can you specify the part number they are using? Are they using a TI LaunchPad?

In addition, could you please specify the connection interval, connection timeout, peripheral latency used?

Best regards,

1. We use CC2642R1F

2.You can specify connection parameters，However, the current disconnection phenomenon is that

it is sent before the controller sends a request to update the connection parameters

(in the routine, it is the default to update the connection parameters after Bluetooth is connected for 3s)

Hi,

If this abnormal disconnection occurrence 1% only happens during pressure testing, then the tests is the factor that causes the abnormal disconnection. Which means you need to improve the hardware to survive the tests 100%. 

-kel

1. We have shipped a large number of products, and the user has reported abnormal disconnection issues.

2. The pressure test is to reproduce this problem before using Ellisys to capture packets for analysis.

3.Can you help me analyze whether the packet capture in the above figure is caused by the Channel Map not being synchronized. For a complete packet capture log, it can also be sent to you.

Hi Alex,

Please share the Bluetooth sniffer log.

Regards,

208s和421s处出现异常断连.zip

hi team:

Ellisys' packet capture sniffer LOG is as follows:

Abnormal disconnection at 208s and 421s

We conducted pressure testing, with the phone 0.5m away from the controller, and Ellisys and the controller placed together.

Model: CC2642R1F

SDK:.simplelink_cc13x2_26x2_sdk_4_10_00_78、simplelink_cc13xx_cc26xx_sdk_6_10_00_29   Both versions of the SDK have this issue.

After Master sends LL_CHANNEL_MAP_IND ，Before the corresponding ‘instant’ arrival，the interaction is normal

After the 'instant' arrival, Slave cannot receive the Master's package and eventually times out and disconnects.

Is it caused by the Channel Map not being synchronized?

thank you 

Hi Alex,

I will take a look at the sniffer log soon and get back to you as soon as possible. In the meantime, could you specify how frequently you are able to observe the issue? You mention that it occurs around 1% of the time, but does it happen on all devices or only a certain subset of devices?

Best Regards,

Jan

As I mentioned earlier, the frequency of pressure testing is to establish a connection every 1 minute, and the problem occurs 5 times after 600 connections.

It occurs on all devices, but the probability of occurrence is relatively low.

From the performance of pressure testing, the probability of occurrence is 1%.

Corresponding to our actual product, users have also received a large amount of feedback on this issue. However, there is no statistical analysis of the frequency of this issue in actual application scenarios, as user feedback only accounts for a small portion of the problem and cannot provide a specific probability. The connection disconnection operation in actual application scenarios is certainly not as frequent as pressure testing, but is the probability of abnormal disconnection related to frequent operations? If that's okay, is the probability of pressure testing occurring the probability of problems in actual scenarios.

Hi Alex,

I am seeing a large amount of unknown packets, errors and warnings in the log you have provided. Can you share the modifications you have made to your project in general terms?

Also can you confirm if this is occurring on a custom board or a LaunchPad evaluation boar? I would like to rule out HW as a possible cause if possible.

Best Regards,

Jan

We have not made any modifications to the protocol stack,

This packet capture was made on the Launchpad evaluation board.

Hi Alex,

Have any modifications been made to the application code of the project? If not, then can you clarify if this behavior is occurring un an unmodified simple_peripheral example?

Best Regards,

Jan