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.

RTOS/CC2640R2F: How to turn off the CCCD reset of the BLE disconnection?

Part Number: CC2640R2F

Tool/software: TI-RTOS

Hi everyone!

How to turn off the CCCD reset of the BLE disconnection?

I want to enable the default setting of the CCCD in the peripheral so that the center can transfer data without setting the CCCD.

I use project zero for test, the test target is : after connecting, if button 0 is pressed, central can receive button 0 data without setting CCCD.

I found gattServApp_ResetCharCfg() calls GATTServApp_InitCharCfg() after each disconnection.

I can't find and don't know how to modified the code of gattServApp_ResetCharCfg().

So I changed the code of GATTServApp_InitCharCfg() directly and got the test target.

void GATTServApp_InitCharCfg( uint16 connHandle, gattCharCfg_t *charCfgTbl )
{
  // Initialize Client Characteristic Configuration attributes
  if ( connHandle == INVALID_CONNHANDLE )
  {
    uint8 i;
    for ( i = 0; i < linkDBNumConns; i++ )
    {
//      charCfgTbl[i].connHandle = INVALID_CONNHANDLE;
//      charCfgTbl[i].value = GATT_CFG_NO_OPERATION;
      charCfgTbl[i].connHandle = 0;
      charCfgTbl[i].value = GATT_CLIENT_CFG_NOTIFY;
    }
  }
//  else
//  {
//    gattCharCfg_t *pItem = gattServApp_FindCharCfgItem( connHandle, charCfgTbl );
//    if ( pItem != NULL )
//    {
//      pItem->connHandle = INVALID_CONNHANDLE;
//      pItem->value = GATT_CFG_NO_OPERATION;
//    }
//  }
}

Although it works fine, I just avoided the initialization problem.

(gattServApp_ResetCharCfg() is still working, but GATTServApp_InitCharCfg() is modified as above)


Is there a way to not modify GATTServApp_InitCharCfg() and close the reset?

Can I turn off or modify the code of gattServApp_ResetCharCfg()?

  • Hi Gary,

    What you're describing (getting notifications/indication on first connection without setting the CCCD to 1) is not permitted by the Bluetooth Core Spec.

    However, if the devices are paired and bonded, the CCCD value will be stored between connections. This means that on the first connection you will have to set CCCD to 1, but on subsequent connections it is stored so you will not need to write 1 to CCCD.
  • Hi Marie,

    I know it is not permitted by the Bluetooth Core Spec, what happens if I don't follow the Bluetooth core specification?
    For example, can't connect with a mobile phone?

    I want to design it to transfer data quickly without binding or pairing.
    Each action includes a connection and disconnection, so if the preset CCCD is enabled, the transmission time should theoretically be reduced.

    Many thanks, Gary
  • Hi Gary,

    We have written our software to follow the Core Spec. I am not sure what would happen if you tried setting the CCCD to 1.

    I get that service + characteristic discovery will take up some time that you don't want to spend.

    Did you consider doing the data transfer over advertisements? Then you don't even have to connect..
  • Hi Marie,

    I have tried to use broadcast to transfer data. It work fine!

    But if I want to transfer data more securely, then the connection is more secure than broadcasting, right?

    I want design two-way authentication in connect, the transmission direction of broadcast and scanner is one-way.

    (Although there is a way to use multiple roles, it still less securely than connection :

    ex: Broadcaster/Scanner ←→Scanner/Broadcaster )

    Many thanks, Gary
  • Hi Gary,

    In a connection you can use encryption and authentication. Most of these features require that the devices are paired and/or bonded. So if you're just connecting, it's not really more secure.

    If you're planning to use authentication, you should implement pairing and bonding. Please see the BLE Security Fundamentals lab for more information: dev.ti.com/.../
  • Hi Marie,

    I want to design another authentication method under just work, such as challenge/response.

    Maybe this method is not as secure as "pairing and/or binding", but it can take less time each time.

    What I am trying is that each action contains:

    Key action>Initiate connection>Write command>Two-way verification>Disconnection

    Many thanks,
    Gary
  • Hi Gary,

    If you're using bonding, the information is stored locally so you don't need to re-do the pairing on every connection. Since this will also let you store the CCCD value you're saving a lot of packets on the subsequent connections.

    If it were me I would use the security enablers in the Bluetooth Core Spec since it's a mature solution. (I don't know what kind of security background you have but your design sounds a little bit like "security by obscurity".)

    If you don't care about Bluetooth compliance and don't want to use the in-built features you could go for a proprietary solution based on a Bluetooth PHY. That way you can send whatever packets you want in whatever order.
  • Hi Marie,

    Thanks, I will try to use the security of the Bluetooth Core Spec.

    On the other hand, can you provide more information about proprietary solutions based on Bluetooth PHY?

    Many thanks,
    Gary
  • Hi Gary,

    You can start with the Proprietary RF labs in SImpleLink Academy ( dev.ti.com/.../ ). Using SmartRF Studio you can choose BLE PHY directly.