[参考译文] CC2340R5：调用 GATT_DiscAllChars 后的响应长度无效

您好！

您不应获得 ATT_READ_BY_GRP_TYPE_RSP、因为 GATT_DiscAllChars 返回使用不同结构的 ATT_READ_BY_TYPE_RSP。

https://dev.ti.com/tirex/content/simplelink_lowpower_f3_sdk_8_10_01_02/docs/ble5stack/ble_user_guide/doxygen/ble/html/group___a_t_t___g_a_t_t.html#gac824af509fbd28c84ae6a1d1d4a1ba11

您是否接收到 ATT_READ_BY_GRP_TYPE_RSP、而不是 ATT_READ_BY_TYPE_RSP？ 您是否介意发送您的处理代码以便我进行审核？

此致！

Nima Behmanesh

尊敬的 Nima：  

感谢您指出这个错误。 我发布了错误的代码片段。  请在下面找到我的 GATT_EvenHandler。

static void GATT_EventHandler(uint32 event, BLEAppUtil_msgHdr_t *pMsgData)
{
  gattMsgEvent_t *gattMsg = ( gattMsgEvent_t * )pMsgData;
  switch ( gattMsg->method )
  {
    case ATT_FLOW_CTRL_VIOLATED_EVENT:
      {
          MenuModule_printf(APP_MENU_PROFILE_STATUS_LINE, 0, "GATT status: ATT flow control is violated");
      }
      break;

    case ATT_MTU_UPDATED_EVENT:
      {
          MenuModule_printf(APP_MENU_PROFILE_STATUS_LINE, 0, "GATT status: ATT MTU update to %d",
                            gattMsg->msg.mtuEvt.MTU);
          Log_printf(LogModule_App1, Log_INFO, "MTU updated to: %d", gattMsg->msg.mtuEvt.MTU);

      }
      break;
    case ATT_READ_BY_GRP_TYPE_RSP:
    {

        MenuModule_printf(APP_MENU_PROFILE_STATUS_LINE, 0, "GATT status: ATT MTU update to %d",
                          gattMsg->msg.mtuEvt.MTU);

        attReadByGrpTypeRsp_t *resp = (attReadByGrpTypeRsp_t *)&(gattMsg->msg.readByGrpTypeRsp);

        Log_printf(LogModule_App1, Log_INFO, "response len: %d", resp->len);
        Log_printf(LogModule_App1, Log_INFO, "num groups: %d", resp->numGrps);
        if(resp->len)
        {
            sendSvcDiscRsp(resp->pDataList, resp->len); // save data to queue.
        }

    }break;

    case ATT_READ_BY_TYPE_RSP :
    {
        attReadByTypeRsp_t * resp = (attReadByTypeRsp_t *)&(gattMsg->msg.readByTypeRsp);


        Log_printf(LogModule_App1, Log_INFO, "response len: %d", resp->len);
        Log_printf(LogModule_App1, Log_INFO, "numPairs: %d", resp->numPairs);
        Log_printf(LogModule_App1, Log_INFO, "dataLen: %d", resp->dataLen);
        for(int i=0; i < resp->len; i++)
        {
            Log_printf(LogModule_App1, Log_INFO, "%d", resp->pDataList[i]);
        }
    }break;
   
    default:
      break;
  }
}

我正在接收" ATT_READ_BY_TYPE_RSP "解析逻辑出现在上述代码片段中。

我打印" attReadByTypeRsp_t "结构并获得 一个非常 值的  数据长度字段。  

我还打印了" attReadByTypeRsp_t "以下内容是不同句柄搜索的结果。

gattMsg->msg.readByTypeRsp.len = 7；
gattMsg->msg.readByTypeRsp.numPairs = 0x05；
gattMsg->msg.readByTypeRsp.pDataList = 0xC3、0x43、0x00、0x20；  
gattMsg->msg.readByTypeRsp.dataLen = 0xEB11；// 很大

0x05、0x00、 0x07 、0x00、0xC3、 0x43、0x00、0x20、0x11、0xEB

您好！

这当然很奇怪、通过读取 attReadbyTypeRsp_t 结构、您也许不需要这个字段。

例如、我如何对其进行解析：

        display_index += 1;
        attReadByTypeRsp_t *response = (attReadByTypeRsp_t *)&(gattMsg->msg.readByTypeRsp);
        MenuModule_printf(display_index, 0, "GATT status: Read by type %d", response->numPairs);

        for (int i = 0; i < response->numPairs; i++)
        {
            uint16_t attributeHandle = BUILD_UINT16(response->pDataList[i * response->len + 0],
                                                    response->pDataList[i * response->len + 1]);

            uint16_t endHandle = BUILD_UINT16(response->pDataList[i * response->len + 2],
                                              response->pDataList[i * response->len + 3]);

            display_index += 1;
            MenuModule_printf(display_index, 0, "GATT status: Read by type: Handle: %x | %x", attributeHandle, endHandle);
        }
        break;

您能试一下并告诉我结果吗？

此致！
Nima Behmanesh

尊敬的 Nima：  

我将在明天回到办公室,我将尝试这一保持你张贴。 但获得如此大的值是非常奇怪的、您能找出原因吗？

Sandeep、您好！

我需要联系 R&D、并且同样将问题复制到我这边。 您使用的 SDK 版本是什么？ 我相信这是你原来的帖子遗漏的。

此致！
Nima Behmanesh

尊敬的 Nima：  

我当前使用的 SDK 版本是" simplelink_lowpower_f3_sdk_8_10_01_02 "。

Sandeep、您好！

我还在研究这件事,不会晚于星期五回复你。

此致！
Nima Behmanesh

Sandeep、您好！

在假期、我的回答会有点延迟。 感谢您耐心解决此问题。

此致！
Nima Behmanesh

感谢您发送编修。 我 希望我们能尽快找到解决办法。

Sandeep、您好！

您是否介意对最新的 SDK 进行测试、以查看问题是否仍然存在？

此致！
Nima Behmanesh

尊敬的 Nima：  

下图显示了 SDK 与 CC27芯片组兼容。 我随身携带了 CC27开发板、并且我也在其中加载了上述代码。 我看到 CC27电路板上也出现了同样的问题。 这真的会是一个 SDK 问题吗？

Sandeep、您好！

您是否可以尝试上面粘贴的代码片段？

此致！

Nima Behmanesh

尊敬的 Nima：  

在我们的用例中、上述方法可能不是可行的解决方案、因为我们希望将收到的数据发送到任务并在任务中处理处理数据。  

Sandeep、您好！

解析信息的方式由蓝牙核心规范指定。 如果您需要在不同的任务中处理数据、我建议您可能按照上面所示的方式设置信息的格式、并将其放置在可以在任务之间共享的结构中。

此致！

Nima Behmanesh

尊敬的 Nima：

当你说" 解析信息的方式由蓝牙核心规范指定 "。 因为 strcut 有一个指针字段( pDataList )和一个数据字段,这是我的理解,这 数据 要从中读取的字节数 pDataList .

此外、鉴于您之前已共享的代码片段、正确的做法是假设" Response->numPairs * 4. "捕获 pDataList 的全部内容？  

Sandeep、您好！

我相信这是正确的。 尽管我相信您可以直接复制代码片段、这应该会捕获所有对属性句柄。

此致！

Nima Behmanesh

尊敬的 Nima：

明白了。 因此、假设对于此特定事件、必须使用 numPairs 来解码数据、并且长度字段具有通常较高的值、因为它是默认设置、这是正确的吗？

尊敬的 Nima：  

 在外设上、我有1个服务和5个特性、如下所示。

我参考了上面的代码片段并从中提取了数据。 数字对为5、每个对的长度为7。

数据如下所示。

0x02、0x00、0x18、0x03、0x00、0x01、0xE0、
0x06、0x00、0x18、0x07、0x00、0x02、0xE0、
0x0A、0x00、0x18、0x0B、0x00、0x03、0xE0、
0x0E、0x00、0x18、0x0F、0x00、0x04、0xE0、
0x12、0x00、0x18、0x13、0x00、0x05、0xE0

用于提取上述数据的代码片段:

根据我的理解、前2个字节是开始句柄、字节3和4是结束句柄。 由于我知道我的器件的 UUID、因此我可以放心地说最后2个字节是 UUID。

我看到终端句柄与启动句柄不同步。 由于 数据 字段具有 无效值、是否可能其余字段也不正确？ 我从堆栈中接收到的这个数据是正确的数据吗？

Sandeep、您好！

您是否介意重新附上服务的图片？ 不需要为我加载。

Unknown 说：

我看到末尾句柄与起始句柄不同步。

您是否介意详细说明它们不同步意味着什么？

此致！

Nima Behmanesh