This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2564CSTBTBLESW: Unexpectedly slow pairing exchange in Secure_Connections mode.

Part Number: CC2564CSTBTBLESW
Other Parts Discussed in Thread: CC2564C

Hi e2e,

We are facing unexpectedly slow pairing exchange when using LE SecureConnections for First time Bonding.

We are using the latest 5.1 Stack CC2564CSTBTBLESW. 

What we face is exactly similar to the following e2e Post  :

cc2640r2f-simple_peripheral-unexpectedly-slow-pairing-exchange-using-ble-stack-and-le-secure-connections

in that link, it is mentioned that Stack Update can fix the issue. Is that possible to do the same fix on cc2564C as well?.

Thanks!

  • Hi Vishnuprasad,

    It is possible that the solution is the same as within the E2E post you reference. However, that is a different Bluetooth stack within TI (BLE only)

    Do you encounter this slow pairing every time you bond with a device for the first time? Does the type of device matter? Can you share the API's you call after opening the Bluetooth stack?

    Best,
    Jacob

  • Hi Jacob,

    Thanks for the reply.

    Do you encounter this slow pairing every time you bond with a device for the first time?

    We face the slow pairing issue on the first time bonding it takes around 30-40 seconds. Once we stored the LTK's and Bonding is done, the consequent connections are fast. 

    Does the type of device matter?

    In some phones, for example, Galaxy J6  & iPhone, it is fast. All the other phones, MI, Samsung's latest series etc is showing a delay of 30-40 seconds.

    Can you share the API's you call after opening the Bluetooth stack?

    -----------------------------------------------------------------------------------------------------------------------------------------------------

    BTPS_Init(BTPS_Initialization);

    BSC_Initialize(HCI_DriverInformation, 0);

    BSC_EnableFeature(BluetoothStackID, BSC_FEATURE_BLUETOOTH_LOW_ENERGY);

    /* Initialize the Default LE Pairing Parameters. */
    LE_Parameters.IOCapability = DEFAULT_LE_IO_CAPABILITY;
    LE_Parameters.BondingType = DEFAULT_LE_BONDING_TYPE;
    LE_Parameters.MITMProtection = DEFAULT_LE_MITM_PROTECTION;
    LE_Parameters.OOBDataPresent = FALSE;
    LE_Parameters.SC = DEFAULT_SC_ENABLE;
    LE_Parameters.Keypress = DEFAULT_KEYPRESS;
    LE_Parameters.P256DebugMode = DEFAULT_P256_DEBUG_ENABLE;

    LE_Parameters.ConnectableMode = lcmConnectable;

    GAP_LE_Diversify_Function(BluetoothStackID, (Encryption_Key_t *)(&IR), 1,0, &IRK);
    GAP_LE_Diversify_Function(BluetoothStackID, (Encryption_Key_t *)(&IR), 3, 0, &DHK);

    GATT_Initialize(BluetoothStackID, GATT_INITIALIZATION_FLAGS_SUPPORT_LE,GATT_Connection_Event_Callback, 0)

    HCI_LE_Read_Buffer_Size(BluetoothStackID, &Status, &LEPacketLength, &NumberLEPackets)) && (!Status) && (LEPacketLength))

    GAP_LE_Set_Pairability_Mode(BluetoothStackID, lpmPairableMode);

    GAP_LE_Register_Remote_Authentication(BluetoothStackID, GAP_LE_Event_Callback, (unsigned long)0);

    GAP_LE_Set_Advertising_Data(BluetoothStackID, Length, &(Advertisement_Data_Buffer.AdvertisingData));

    GAP_LE_Set_Scan_Response_Data(BluetoothStackID, (Advertisement_Data_Buffer.ScanResponseData.Scan_Response_Data[0] + 1), &(Advertisement_Data_Buffer.ScanResponseData));

    AdvertisingParameters.Advertising_Channel_Map = HCI_LE_ADVERTISING_CHANNEL_MAP_DEFAULT;
    // AdvertisingParameters.Advertising_Channel_Map = HCI_LE_ADVERTISING_CHANNEL_MAP_ENABLE_CHANNEL_39;
    AdvertisingParameters.Scan_Request_Filter = fpNoFilter;
    AdvertisingParameters.Connect_Request_Filter = fpNoFilter;

    if (connectionMode == lcmConnectable ){
    AdvertisingParameters.Advertising_Interval_Min = LE_Parameters.ConnectableModeAdvIntervalMin; //
    AdvertisingParameters.Advertising_Interval_Max = LE_Parameters.ConnectableModeAdvIntervalMax; //
    }
    else{
    AdvertisingParameters.Advertising_Interval_Min = LE_Parameters.NonConnectableModeAdvIntervalMin; //
    AdvertisingParameters.Advertising_Interval_Max = LE_Parameters.NonConnectableModeAdvIntervalMax; //

    GAP_LE_Advertising_Enable(BluetoothStackID, TRUE, &AdvertisingParameters, &ConnectabilityParameters, GAP_LE_Event_Callback, 0);

    -----------------------------------------------------------------------------------------------------------------------------------------------------

    After this, when the other side device tries to make the connection we will initiate secure connection procedures.

    Our device is in a peripheral role and the Phone is taking the central role.

    Can you help me to make it fast in the cc2564C stack?

    Thanks!

    vishnu

  • HI Jacob,

    Any update on this ?

    Regards,

    Vishnu

  • Hi Vishnuprasad,

    Thanks for the function calls. I'll try this on my setup to give you an estimate for how long LE Secure Connections should take.

    Best,
    Jacob

  • Hi jacob ,

    I accidently clicked on "This resolve my issue" . Can you  reopen the ticket please.

    Other than the estimate on how long It will take for Secure-connections. I like to know about the fix which was done on the BLE only stack  and I like to know whether that fix is there in the Bluetopia Stack. 

    If the fix is not integrated into Bluetopia stack, what I can do to achieve that.

    thanks !

  • Hi Vishnuprasad,

    I will respond here later today.

    Thanks,
    Jacob

  • Hi jacob,

    Thanks for the update.

    Waiting for the response.

    Regards,

    Vishnu.

  • Hi Vishnuprasad,

    I ran the SPPLEDemo to test how long it takes to pair two CC2564C controllers. These are the commands I ran:

    The pairing took <8 seconds. Is this custom hardware?

    Thanks,
    Jacob

  • Hi Jacob,

    In our Application, there is no need to pair between two CC2564C. In our application Device connects to the Phones only(BLE).

     

    Is this custom hardware?

    Yes, we are using Custom Hardware. I don't think this is a Hardware Issue.

    The exact implementation connects with iPhone and some Android phones very fastly around (1s). Only on some phones (most of the Android) only we are seeing the Trouble. 

    The issue is exactly the same as mentioned in the related post.

    What I want to know is what was the fix done on the 'Bluetooth stack within TI (BLE only) ' stack to fix that Issue.

    Does that fix is there in the Bluetopia stack?

    Regards,

  • Hey Vishnuprasad,

    Can you provide the connection interval parameters as discussed here? Can you try #1 and #2 in this post? If the same problem does exist between the BLE stack and the Bluetopia stack, these questions will help address it.

    In the meantime, I've reached out to find more about the fix in the BLE stack.

    Best,
    Jacob

  • Hi Vishnuprasad,

    One more update: you can view the fixes in the BLE stack in the Changelog here

  • 1

    Hi Jacob,

    In our case, we are not taking the Master Role.

    Phone Initiates the connection, and request for secure_connection.

    The parameters are default Parameters only.

    #define DEFAULT_MINIMUM_CONNECTION_INTERVAL                             500

    #define DEFAULT_MAXIMUM_CONNECTION_INTERVAL                            128

    Regards,

  • Hi Vishnuprasad,

    Thanks for the update. Feel free to update the post when you get a chance to run these commands from the related post above:

    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".
    Thanks,
    Jacob
  • Hi Jacob,

    We were not able to change the connection parameters successfully. It was always trying to keep the phone-dependent values. Different phones give different values.

    Android App let me check.

    Regards,

  • Hi Jacob,

    We were not able to figure out the proper reason for the delay. We tried just using the standard nRFConnect BLE application to do the secure pairing, we observed similar behaviors, that is some phones take a delay of 40 s, and some connect within 2 s.

    Because of the time limitation, we figured out some other way, over the app communications for accomplishing the task.

    We are going ahead with that approach.

    Thanks for the support.

    Unfortunately, we have no time to do the debug on this, at this point.

    If you are able to reproduce the issue and find a solution at your end. We like to know about the fix, which will help us in future designs.

    Thanks!

    Vishnu