• State
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 53 subscribers
  • Views 593 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2652R7: Bluetooth connections fail with some devices

ch701x
Prodigy 115 points
Part Number: CC2652R7
Other Parts Discussed in Thread: SYSCONFIG

I have a CC2652 using SDK 06.30.01.03 and the BLE Stack that comes with it. I am unable to connect to the device with certain devices. The Google Pixel 3A and 5 both failed to connect while a Pixel 6 and Samsung S21 were able to connect without issue. 

I was able to capture the connection request issued by the phone for both the Pixel 3A and the Pixel 6. Unfortunately the device used to capture the packet hangs for a second when it receives a connection request packet so I don't have any further packets in the connection procedure. I know the CC2652 receives the connection request based on logs from my application but I'm not sure if it is responding. The CC stops advertising and scan responses after a failed connection, but not after or during a successful one.

The Pixel 3A Failed Connection:

The Pixel 6 Successful Connection:

The Bluetooth Section of SysConfig

ble.addressMode = "ADDRMODE_PUBLIC";
ble.deviceRole = "PERIPHERAL_CFG+CENTRAL_CFG";
ble.deviceName = "<name>"; // name changed for this post
ble.extAdv = false;
ble.bondManager = false;
ble.bonding = false;
ble.maxBonds = 0;
ble.bondPairing = "GAPBOND_PAIRING_MODE_NO_PAIRING";
ble.noOsalSnv = true;
ble.defaultTxPower = "HCI_EXT_TX_POWER_5_DBM";
ble.disableDisplayModule = true;
ble.scanInt = 3500;
ble.scanWin = 3500;
ble.maxConnNum = 2;
ble.maxNumIcallEnabledTasks = 4;
ble.maxPDUSize = 251;
ble.oadDebug = true;
ble.oneLibSizeOpt = false;
ble.scanDuration = 11000;
ble.advRptFields = ["SCAN_ADVRPT_FLD_ADDRESS","SCAN_ADVRPT_FLD_DATALEN","SCAN_ADVRPT_FLD_EVENTTYPE","SCAN_ADVRPT_FLD_RSSI"];
ble.numOfAdvSets = 1;
ble.radioConfig.codeExportConfig.$name = "ti_devices_radioconfig_code_export_param0";
ble.connUpdateParamsPeripheral.$name = "ti_ble5stack_general_ble_conn_update_params0";
ble.connUpdateParamsPeripheral.paramUpdateDelay = 3000;
ble.connUpdateParamsPeripheral.reqMaxConnInt = 60;
ble.connUpdateParamsPeripheral.reqMinConnInt = 40;
ble.advSet1.$name = "ti_ble5stack_broadcaster_advertisement_set0";
ble.advSet1.advParam1.$name = "ti_ble5stack_broadcaster_advertisement_params0";
ble.advSet1.advParam1.name = "legacyAdvParams";
ble.advSet1.advParam1.primIntMax = 2000;
ble.advSet1.advParam1.primIntMin = 1000;
ble.advSet1.advParam1.txPower = "otherTxPower";
ble.advSet1.advParam1.txPowerValue = 5;
ble.advSet1.advData1.$name = "ti_ble5stack_broadcaster_advertisement_data0";
ble.advSet1.advData1.advertisingFlags = ["GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED","GAP_ADTYPE_FLAGS_GENERAL"];
ble.advSet1.advData1.GAP_ADTYPE_128BIT_MORE = true;
ble.advSet1.advData1.name = "legacyAdvData";
ble.advSet1.advData1.numOfUUIDs128More = 1;
ble.advSet1.advData1.numOfUUIDs16More = 1;
ble.advSet1.advData1.UUID016More = 0xFCFF;
ble.advSet1.advData1.GAP_ADTYPE_LOCAL_NAME_COMPLETE = true;
ble.advSet1.advData1.GAP_ADTYPE_FLAGS = true;
ble.advSet1.advData1.UUID0128More = system.utils.bigInt("FFFFFFFFFFFFFFFFFFFFFFFF",16);
ble.advSet1.scanRes1.$name = "ti_ble5stack_broadcaster_advertisement_data1";
ble.advSet1.scanRes1.name = "scanRespData";
ble.advSet1.scanRes1.GAP_ADTYPE_SERVICE_DATA = true;
ble.advSet1.scanRes1.numOfUUIDs16SD = 1;
ble.advSet1.scanRes1.UUID016SD = 0x192A;
ble.advSet1.scanRes1.UUID016SDData = system.utils.bigInt("FF",16);
ble.advSet1.scanRes1.GAP_ADTYPE_MANUFACTURER_SPECIFIC = true;
ble.advSet1.scanRes1.companyIdentifier = 0xF30A;
ble.advSet1.scanRes1.additionalData = "0xFFFFFFFF00";
ble.connUpdateParamsCentral.$name = "ti_ble5stack_general_ble_conn_update_params1";

I've run a similar BLE configuration on a CC1352 with SDK 04.40.04.04 and can connect without any problems.

  • 0
    TI__Mastermind 42320 points

    Hi,

    Thank you for reaching out to us. We will look into your queries and get back to you. In the meantime, I have a few questions that may help us resolve this as efficiently as possible. Is this behavior visible on the 6.40 SDK version? Can you share the specific Android version and build version of the devices that experience the issue as well as the devices that do not experience the issue? What it the reproducibility of the failure to connect behavior? Does it occur every time or only a portion of the time?

    Best Regards,

    Jan

  • 0 in reply to Jan
    Prodigy 115 points
    • Is this behavior visible on the 6.40 SDK version?
      • Yes
    • Can you share the specific Android version and build version of the devices that experience the issue as well as the devices that do not experience the issue?
      • Pixel 6 (No problem) - Android 13, build  TQ1A.230205.001
      • Pixel 5 (problem) - Android 13, build TQ1A.230205.001
      • Pixel 3A (problem) - Android 12, build SP2A.220505.008
    • What it the reproducibility of the failure to connect behavior? Does it occur every time or only a portion of the time?
      • It's every single time for the problem phones. Never for the phones that don't experience this problem.

    It's also worth noting, this problem also occurred on an iPhone, though I don't know what version of iOS it was on.

  • 0 in reply to ch701x
    TI__Genius 14651 points

    Hello,

    Do you experience the same behavior if you run the simple peripheral demo?

    Kind Regards,

    Rogelio

  • 0 in reply to RogelioD
    Prodigy 115 points

     No, the simple peripheral example works fine.

  • 0 in reply to ch701x
    Prodigy 115 points

    Anything more I can try? This problem is starting hinder development. Thank you.

  • 0 in reply to ch701x
    Prodigy 115 points

    I found disabling extended advertising on the simple peripheral example disallowed my phone to connect to it, so that's been re-enabled in the above sysconfig, though it did not resolve the issue. I replicated the all my peripheral settings on the simple peripheral example aside from extended advertising but my phone was still able to connect.

    Making the simple peripheral example into a peripheral+central didn't appear to be an easy task, so I opted to remove the central component from my build. I am still unable to connect to the device.

    I have noticed that an attempted connection will cause the CC to suddenly draw another 3 mA. Not sure what that means, but if I had to hazard a guess something is getting  into a bad state; either the radio or the stack is suddenly caught in a infinite loop.

  • 0
    Prodigy 115 points

    I'd like to thank everyone for their help thus far.

    After a lot of experimenting, we've found if we force the 1M PHY, we can connect to all phones. Doing so obviously cuts our transmission rate in half which isn't ideal as we sometimes move megabytes of data over BLE. It also increases the power consumption, also not ideal for our low power devices.

    We'd like to get this 2M problem resolved if possible.

  • 0 in reply to ch701x
    TI__Genius 14651 points

    Hi ch701x,

    Thanks for the progress made so far, if you could list the changes done to the connection parameters.

    The big one obviously being changing to 2M PHY cant connect to these particular phones. 

    Kind Regards,

    Rogelio

  • 0 in reply to RogelioD
    Prodigy 115 points

    In the initialization of HCI we use

    • HCI_LE_WriteSuggestedDefaultDataLenCmd(251, 2120);
    • HCI_EXT_OverlappedProcessingCmd(HCI_EXT_ENABLE_OVERLAPPED_PROCESSING);
    • HCI_LE_SetDefaultPhyCmd(HCI_PHY_USE_PHY_PARAM, HCI_PHY_1_MBPS, HCI_PHY_1_MBPS); // this one being the fix

    In connecting to the CC with the older phones, we found the phone would try to negotiate to use the 2M PHY and this negotiation would put the CC into a bad state. Using the line in the last bullet point disallows the negotiation.

  • 0 in reply to ch701x
    TI__Genius 14651 points

    Thanks,

    This is definitely strange behavior, ill look deeper into it.

    Kind Regards,

    Rogelio

  • 0 in reply to ch701x
    TI__Mastermind 42320 points

    Hi,

    My apologies for the extended delay and any inconvenience this delay may have cased. Are you still observing this issue? If so, then can you try connecting to your device via 1M PHY and once the connection is established, you swap to using the 2M PHY? The simple_peripheral example implements this functionality and can be used as a reference for this.

    Best Regards,

    Jan