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.

CC2340R5: CC2642 onto the CC2340

Part Number: CC2340R5


Hi Team,

Regarding the migration of the host program from the CC2642 Bluetooth module to the CC2340,

when the gap_ADTYPE_local_name_complete is obtained,

sometimes the advertisement data is received and sometimes the advertisement response data is received.

Both cannot be received at the same time, causing the Bluetooth name of the slave to not be correctly obtained, as shown in the figure.

Best Regards,

Galaxy

  • HI Team,

                bleStk_GapScan_Evt_AdvRpt_t* pAdvRpt =&scanMsg->pBuf->pAdvReport;
                for(i=0;i<pAdvRpt->dataLen;i++)
                {
                    printf("%02x",pAdvRpt->pData[i]);
                }

    This is printed.

    Best Regards,

    Galaxy

  • Hello Galaxy,

    Please help me with the following questions:

    1. Could you please confirm what SDK version are you using?
    2. Are you using a specific example project, such as basic_ble for instance?
    3. If that is the case, and you are using app_central.c, where in the code are you reading the pAdvReport?
    4. Are you considering a specific peripheral, is this peripheral adverting the local name in both adv data and scan response data (you can check that in the syscfg file?

    Best Regards,

    David.

  • Hi David,

    1.SDK: simplelink_lowpower_f3_sdk_7_20_00_29

    2.Yes,basic_ble for instance.

    3.The location where I read the pAdvReport is void Central_ScanEventHandler(uint32 event, BLEAppUtil_msgHDr_t *pMsgData) -> case BLEAPPUTIL_ADV_report:

    to see the code attached below me. 

    static bool Get_Adtype_Data( uint8 adType, uint8 *pData, uint8 dataLen, uint16 *adTypeData_index, uint16 *adTypeData_len)
    {
      (void)adTypeData_index;       //防止编译报错
      (void)adTypeData_len;         //防止编译报错
    
      uint8 adLen;                  //对应数据段的长度
      uint8 *pCurrent;              //当前位置的指针
      uint8 *pEnd;                  //尾指针
      int i;
      if(pData == NULL)
      {
          my_dbg_printf("find null pointer\r\n",19);
          return false;
      }
      for(i=0; i<dataLen; i++)
      {
         sprintf(printbuf,"%02x ",pData[i]);PRINT_LOG;
      }
      my_dbg_printf("\r\n",2);
    
    
      pEnd = pData + dataLen - 1;   //指向包尾
    
      pCurrent = pData;             //当前指针指向包头
    
      while ( pCurrent < pEnd )     //判断当前指针是否还未到包尾
      {
        adLen = *pCurrent++;        //获取本段数据段的长度
    
        if ( adLen > 0 )
        {
          if ( adType == *pCurrent )                        //如果找到了adType
          {
            *adTypeData_index = (pCurrent + 1) - pData;     //数据段在数据包中的偏移值
            *adTypeData_len = adLen - 1;                    //数据段长度
    
            return TRUE;                                    //返回TRUE
          }
          else                                              //没找到adType则指向下一个数据段
          {
            pCurrent += adLen;
          }
        }
      }
    
      my_dbg_printf("FALSE\r\n",7);
      return FALSE;         //本数据串中没有找到adType
    }
    
    
    void Central_ScanEventHandler(uint32 event, BLEAppUtil_msgHdr_t *pMsgData)
    {
        BLEAppUtil_ScanEventData_t *scanMsg = (BLEAppUtil_ScanEventData_t *)pMsgData;
    
        case BLEAPPUTIL_ADV_REPORT:
        {
            bleStk_GapScan_Evt_AdvRpt_t *pScanRpt = &scanMsg->pBuf->pAdvReport;
            if (pScanRpt->pData != NULL)
            {
                uint8_t indx = 0;
                for (; indx < pScanRpt->dataLen; indx++)
                {
                    //sprintf(printbuf,"pScanRpt->pData=%d\r\n",pScanRpt->pData[indx]);PRINT_LOG;
                    MenuModule_printf(APP_MENU_SCAN_EVENT + indx, 0, "Data: %d", pScanRpt->pData[indx]);
                 }
            }
        
        #if !Change
            uint8 size = Scan_getScanResList(&menuScanRes);
            uint8 scannum[2];
            scannum[1] = size%10 + 0x30;
            scannum[0] = size/10 + 0x30;
        
            bleStk_GapScan_Evt_AdvRpt_t* pAdvRpt = &scanMsg->pBuf->pAdvReport;
            uint16 adTypeData_index = 0;
            uint16 adTypeData_len = 0;
            bool status = FALSE;
            uint8 deviceInfo[40] = {0x00};
            sprintf(printbuf,"evtType=%d\r\n",pAdvRpt->evtType);PRINT_LOG;
        
            status = Get_Adtype_Data( GAP_ADTYPE_LOCAL_NAME_COMPLETE,
                                      pAdvRpt->pData,
                                      pAdvRpt->dataLen,
                                     &adTypeData_index,
                                     &adTypeData_len);
            if(status == TRUE)
            {
              memset(deviceInfo, 0, sizeof(deviceInfo));
              memcpy(deviceInfo,pAdvRpt->pData + adTypeData_index,adTypeData_len);
              //status = addScanInfo(pAdvRpt->addr,pAdvRpt->addrType);
              status = Central_addScanRes(&pAdvRpt);
              if(status == TRUE)
              {
                  SerialSendSimple(deviceInfo,strlen(deviceInfo));
                  SerialSendSimple("\r\n",2);
              }
        my_dbg_printf("--------------------\r\n",22);
            }
            my_dbg_printf("==========\r\n",12);
            // Free report payload data   释放报告有效负载数据
    //            if (pAdvRpt->pData != NULL)
    //            {
    //                ICall_free(pAdvRpt->pData);
    //            }
    #endif
            break;
        }
    }

    4.Yes, the peripheral I use has full local names in both the scan response and the advertisement data.

    uint8_t advertData[] = {
         0x02,   // length of this data
         GAP_ADTYPE_FLAGS,
         GAP_ADTYPE_FLAGS_BREDR_NOT_SUPPORTED | GAP_ADTYPE_FLAGS_GENERAL,
    
         // service UUID, to notify central devices what services are included
         // in this peripheral
         0x03,// length of this data
         GAP_ADTYPE_16BIT_MORE,      // some of the UUID's, but not all
         LO_UINT16(0xffe5), HI_UINT16(0xffe5),
    
         0x11,
         GAP_ADTYPE_MANUFACTURER_SPECIFIC,
         0x00,0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    };
    
    
    uint8_t scanRspData[] =
    {
          // complete name
          0x11,// length of this data
          GAP_ADTYPE_LOCAL_NAME_COMPLETE,
          'T',  'v',  '4',  '1',  '0',  'u',  '-', '0', '0', '0', '0', '0', '0', '0', '0', '\0',
    
          // connection interval range
          0x05,   // length of this data
          GAP_ADTYPE_PERIPHERAL_CONN_INTERVAL_RANGE,
          LO_UINT16(DEFAULT_DESIRED_MIN_CONN_INTERVAL),   // 100ms
          HI_UINT16(DEFAULT_DESIRED_MIN_CONN_INTERVAL),
          LO_UINT16(DEFAULT_DESIRED_MAX_CONN_INTERVAL),   // 1s
          HI_UINT16(DEFAULT_DESIRED_MAX_CONN_INTERVAL),
    
          // Tx power level
          0x02,   // length of this data
          GAP_ADTYPE_POWER_LEVEL,
          0       // 0dBm
    };

    Best Regards,

    Galaxy

  • Hello Galaxy,

    At the moment it seems that the the peripheral is only sending the local name as part of the scan response, that would explain the missing device information at your serial data screenshot. Please enable the Complete Local Name as part of the Advertisement data as seen below:

    Please let me know how it goes.

    BR,

    David.

  • Hi David,

    But when I use the CC2642, I get the broadcast name normally. 

    This is the data that I scanned using the CC2642, which contains the complete advertisement data and scan response data, and scanning other BLE modules can get the full data as well, but the data obtained on the CC2340 is not complete.

    You can see in the data, the above data is advertisement data and scan response data, below is the corresponding advertisement name, my specific device is Tv410u-699E7FF8 on this CC2642 you can see the complete packet.

    1e ff 4c 00 12 19 39 16 75 27 90 22 d7 3d 1c 11 6b bd 42 95 ff 6f 29 40 12 4d ea 93 d4 00 61 02 01 06 12 09 5a 68 65 4c 69 32 30 32 31 30 39 32 38 32 32 37 38 
    ZheLi202109282278
    02 01 1a 02 0a 07 0c ff 4c 00 10 07 3b 1b 13 d6 46 d0 78 02 01 06 03 02 e5 ff 11 ff 37 43 45 32 36 39 39 45 37 46 46 38 00 00 00 00 11 09 54 76 34 31 30 75 2d 36 39 39 45 37 46 46 38 00 05 12 06 00 18 00 02 0a 00 
    Tv410u-699E7FF8
    02 01 1a 02 0a 0c 0a ff 4c 00 10 05 5b 1c 1d f8 a5 02 01 06 03 02 e5 ff 11 ff 36 38 30 41 45 32 34 32 46 39 30 45 00 00 00 00 05 12 f4 01 f4 01 02 0a 0a 10 09 53 6d 61 72 74 4e 6f 73 65 2d 32 46 39 30 45 
    SmartNose-2F90E
    02 01 06 03 02 e5 ff 11 ff 35 34 30 46 35 37 34 34 32 32 44 34 00 00 00 00 05 12 f4 01 f4 01 02 0a 0a 10 09 53 6d 61 72 74 4e 6f 73 65 2d 34 32 32 44 34 
    SmartNose-422D4
    02 01 06 03 02 e5 ff 11 ff 36 38 30 41 45 32 34 32 46 39 30 46 00 00 00 00 05 12 f4 01 f4 01 02 0a 0a 10 09 53 6d 61 72 74 4e 6f 73 65 2d 32 46 39 30 46 
    SmartNose-2F90F
    02 01 06 03 02 e5 ff 11 ff 36 38 30 41 45 32 34 32 46 39 32 35 00 00 00 00 05 12 f4 01 f4 01 02 0a 0a 10 09 53 6d 61 72 74 4e 6f 73 65 2d 32 46 39 32 35
    SmartNose-2F925

    Best Regards,

    Galaxy

  • Hello Galaxy,

    Please help me answering the following questions:

    1. Could you please share with me what project/example are you running on the CC2642 (as the central device) because it is different from the basic_ble running on the CC2340.
    2. Could you please explain what are you modifying on the basic_ble project, to try to reproduce this behaviour?
    3. Is the CC2340 device configured to do passive or active scanning?

    BR,

    David.

  • Hi David,

    1. The example simple_central is used on CC2642, and the SDK version is simplelink_cc13xx_cc26xx_sdk_7_10_01_24.

    2. No project modifications were made, just trying to read the Bluetooth name in app_central.c -> Central_ScanEventHandler ->case BLEAPPUTIL_ADV_REPORT:

    and printing MenuModule_printf(APP_MENU_SCAN_EVENT + indx, 0, "Data: %d", pScanRpt->pData[indx ]);,

    it is found that the broadcast data and response data are separated, unlike CC2642 which is a complete package.

    3. Yes, the CC2340 host is configured for active scanning

    Best Regards,

    Galaxy

  • Hello Galaxy,

    I would suggest comparing both project functionalities: simple_central vs basic_ble. I am also doing that on my side.

    Could you please share how you are printing the scanned report values using the simple_central project?

    It could be the case that the device running basic_ble is receiving duplicate adv reports, considering that the duplicate filter is disabled.

    Best Regards,

    David.

  • Hi David,

    The scanning report of CC2642 is printed in the same place as CC2340.

    static void SimpleCentral_processAppMsg(scEvt_t *pMsg) ->case SC_EVT_ADV_REPORT: 
    -> GapScan_Evt_AdvRpt_t* pAdvRpt = (GapScan_Evt_AdvRpt_t*) (pMsg->pData);
            Get_Adtype_Data( GAP_ADTYPE_LOCAL_NAME_COMPLETE,
                                          pAdvRpt->pData,
                                          pAdvRpt->dataLen,
                                         &adTypeData_index,
                                         &adTypeData_len);
    
    static bool Get_Adtype_Data( uint8 adType, uint8 *pData, uint8 dataLen, uint16 *adTypeData_index, uint16 *adTypeData_len)
    {
      (void)adTypeData_index;       //防止编译报错
      (void)adTypeData_len;         //防止编译报错
    
      uint8 adLen;                  //对应数据段的长度
      uint8 *pCurrent;              //当前位置的指针
      uint8 *pEnd;                  //尾指针
      int i;
      if(pData == NULL)
      {
          //my_dbg_printf("find null pointer\r\n",19);
          return false;
      }
      for(i=0; i<dataLen; i++){
         sprintf(printbuf,"%02x ",pData[i]);
         PRINT_LOG;
      }
      pEnd = pData + dataLen - 1;   //指向包尾
    
      pCurrent = pData;             //当前指针指向包头
    
      while ( pCurrent < pEnd )     //判断当前指针是否还未到包尾
      {
        adLen = *pCurrent++;        //获取本段数据段的长度
    
        if ( adLen > 0 )
        {
          if ( adType == *pCurrent )                        //如果找到了adType
          {
            *adTypeData_index = (pCurrent + 1) - pData;     //数据段在数据包中的偏移值
            *adTypeData_len = adLen - 1;                    //数据段长度
    
            return TRUE;                                    //返回TRUE
          }
          else                                              //没找到adType则指向下一个数据段
          {
            pCurrent += adLen;
          }
        }
      }
    
      return FALSE;         //本数据串中没有找到adType
    }

    1. Through the printed report, I found that the broadcast data and scan response are separated.

    The current processing is to skip the broadcast data and directly receive the scan response data to obtain the local name.

    I just don’t understand why the broadcast data and scan response scanned on CC2642 are together, but the data scanned on CC2340 are separate.

    2. Is there any way to increase the size of data bytes sent by the central device at one time?

    Currently, a maximum of 20 bytes can be sent at one time. Any portion exceeding 20 bytes will be resent as a separate package.

    Best Regards,

    Galaxy

  • Hello Galaxy,

    1. This may be due to the differences between the stacks running on the devices. I will dig more into it and share with you what I can find.
    2. I would suggest looking at the CC2340 User Guide, at the "Maximum Transmission Unit (MTU)" section. The default max size is 23 bytes, but using the LE Data Length Extension (DLE) feature, the length of the LE packet can be set to transmit up to 251 bytes during a connection.

    BR,

    David.

  • Hi David,

    When the host communicates with the slave, when the master sends a string longer than 20 bytes to the slave, the packets are separated when the slave receives it, that is, 20 bytes and 20 bytes are received. But when the slave sends it to the host, it is a complete package when the host prints it out. Both modules are CC2340. The data is as shown below: the master module on the left and the slave module on the right.

    And the PDU size set in syscfg is 247 bytes, as shown in the figure:

    Best Regards,

    Galaxy

  • Hello Galaxy,

    Are you using basic_ble project for this? Could you please share more details about the program running on both devices?

    We also have a UART_over_ble example that could be useful to take a look at.

    What is the RX ring buffer size?

    Best Regards,

    David.

  • Hi David,

    The RX and TX buffers are set the same in the master and slave modules, both are 32.

    Yes, the basic_ble project is currently being used.

    What do more details mean?

    I realize Bluetooth transparent transmission, only the serial port and notification are used.

    Best Regards,

    Galaxy

  • Hello Galaxy,

    I mean more details about the project, but now it is clear you are using the same basic_ble project, thanks.

    Notifications have additional length restrictions that should be considered. For instance, to transfer the 100 bytes of payload data with the default ATT_MTU = 23 bytes, five request or response procedures are required. I would suggest looking into the Users Guide (specifically the Maximum Transmission Unit (MTU) section) for more details about this. Notifications are procedures that are used by the central device to write data into the peripheral, that is why you only see this behaviour when transmitting data at the peripheral side. The Peripheral is most probably using read/write requests procedures.

    Hope it helps,

    David.