• 状态
  • 已锁定 已锁定
  • 回复 8 回复
  • 订户 0 订户
  • 视图 3 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2541：几小时后、CC2541 停止从 GATT 指示接收新消息

admin
Guru**** 2763595 points

Other Parts Discussed in Thread: CC2541

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1604139/cc2541-cc2541-stops-receiving-fresh-messages-from-gatt-indication-after-a-few-hours

器件型号： CC2541

您好、  

我正在努力在 CC2541 中央器件上完成从 1.4.0 到 1.5.2 的堆栈升级。 外设在回来时迁移到 1.5.2A。  

在长时间测试（6-12 小时）中、我注意到 1.5.2 栈中央时间戳的 GATT 消息变得过时、但 1.4.0 栈上不会出现此问题。 通过每 40ms 通过 GATT_Indication 发送一次外设、将其设置为“流“数据。 Central 将接收指示并处理数据以及时间戳、以检查这是新消息还是过时消息。 对于较旧的栈、它似乎没有任何问题、但对于较新的栈、几个小时后、时间戳会显示它不再收到新消息。  

我需要一些关于如何进一步找出问题根源的见解。 我问过的问题和我尝试过的事情：

  1. 时间戳检查代码是否正确？ 是的、它与旧栈相同、对于旧栈来说似乎不是问题。 我尝试打印出刷新失败的时间戳、时间戳的值不变。 因此、检查不会将正常消息误认为过时。  
  2. 连接间隔已更新。 较短的连接间隔似乎会延迟此问题的发生、但不确定它是否 100%相关。 当使用 40ms 连接间隔时、这似乎会在建立连接后大约 10 分钟内发生。 现在、它处于 8ms 连接间隔、进入连接需要数小时。  
  3. 在这种情况下、数据包嗅探和调试器不起作用。 TI 数据包监听器在捕获大约 1-2 分钟的数据后崩溃、Wireshark 可能会达到可能的 10 分钟、那么时间对它来说也太多。 CC 调试器将不会持续数小时到会话中、此时 IARworkbench + CC 调试器无响应并开始导致其他意外问题。  
  4. 在流式传输时通过有效连接定期轮询栈和堆大小。 通过每 5 秒轮询一次测试了一种情况。 不会根据堆大小变化注意到大内存消耗/泄漏。  
  5.  我还尝试向外设发出另一个 GATT 写入、以指示其再次开始流式传输、但外设代码的结构是在发生链路建立事件时翻转流式传输开关。 这适用于较旧的栈中央器件。  

目前的解决方法是结束 BLE 活动并强制重新连接、但不应该这样做、有时需要很长时间才能重新连接。  

 

如果您能向我指出正确的方向、找出我还能做些什么来找出问题的根源、我将不胜感激。  

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    您正在谈论的部分数据的时间戳是否在 GATT 指示中？ 如果是、这是否意味着问题是中央器件仍在接收来自外设的数据包、但有之前 GATT 指示的数据？ 在这种情况下、您可以检查的一点是打印传递到 GATT 指示函数的缓冲区内容、以确保您提供给堆栈的数据是正确的。

    此外、1.4.0 到 1.5.2 可能是一个重大升级。 您可以尝试逐步升级、以确定导致问题的版本。

    此致、
    Lea   

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Lea：

    感谢您的快速响应。

    堆栈升级已逐步执行、现在达到 1.5.2。 时间戳来自 GATT 指示`pMsg->msg.handleValueInd.pValue`前两个字节。  

    在中央侧、时间戳和数据会复制到另一个数组以进行处理/解释。 我检查的两个位置：

    1.在 ATT_Handle_Value_IND   和 ATT_Handle_Value_Noti 的情况下检查 simpleBLECentralProcessGATTMsg 函数内的情况  。 这样、外设是否重复旧消息并不断通过无线方式发送。 ==>在这种情况下、我没有观察到任何打印内容。  

    2.在 osal 计时器到期时定期检查,以准备一条消息报告流中的最新消息。 如果最新消息的时间戳与上一个周期的时间戳匹配、则可能不会通过无线方式收到新消息。 ==>这是我看到的。  

    请记住、外设保持不变、我只在该测试的中央加载了不同的固件。  

    除了在堆栈版本中向后移动之外、请告诉我如何才能找出问题。  

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    当您说您正在逐步执行升级时、这是否意味着您首先尝试了 1.5.1 并且没有遇到任何问题、但升级到 1.5.2 会导致您的问题？

    查看 BLE 连接的无线日志会很有帮助。 在我目前工作的办公室、我们有用于在连接之后通过无线方式嗅探 BLE 数据包的硬件等 我知道、由于您拥有的工具的限制、您说的数据包嗅探和调试器在这种情况下没有什么帮助、但确保即使在问题发生后数据包仍在传输会非常有帮助。 如果使用较长的连接间隔、您可能会在开始连接后 10 分钟左右出现此问题、或者您可以在 8 分钟左右设置嗅探器、或者仅在出现此问题后才设置？

    另一个值得注意的问题是、您的连接在出现问题后不会停止。 如果中央服务器没有响应、或者忽略了所有数据包、连接监视值将在一段时间内未接收数据包后停止连接。 这意味着栈仍在处理数据包、但不会将数据包传递到应用层。 您是否知道外围设备是否收到了正确发送数据包的确认？ 您可以尝试检查所使用的 GATT 函数的返回值。

    此致、
    Lea

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Lea：

    感谢您的更新。  

    我同意最好嗅探数据包并清楚地看到正在发生的事情。 按照您提到的关于办公室嗅探设置的主题、我假设您有比 TI 数据包嗅探器或 Wireshark 更好的工具。 您能否分享有关您的设置的更多信息、也许我可以尝试获得类似的设置并按原样捕获数据包。  

    关于更改连接间隔以强制问题发生、我最初是在 1.5.0 和 1.5.1 年前开始的、但连接间隔较长时出现了问题。 已按照以下主题中的说明解决问题：  
    CC2541：指示意外停止 

    根据此处的另一篇帖子： https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/388372?how-to-increase-Data-Rate-on-CC2541- 

    我相信、如果我恢复到更长的连接间隔、应该会再次发生这种情况。 您认为再次执行此操作仍然有价值吗？  

     

    我开始探索更多基于你的陈述“另一件事,想到的是,你的联系不会停止后的问题。 如果中央器件无响应、或忽略所有数据包、连接监视值将在一段时间内未接收数据包后停止连接。 这意味着栈仍在处理数据包、但不会将数据包传递到应用层。  “我现在可以确认、在经过一段时间（现在 2 秒）断开连接之前、它不会触发间隙层连接终止。 我想知道是否只通过无线方式发送空 PDU 以保持连接处于活动状态、但没有随它发送 GATT 消息。 您建议如何进行验证？ 应用程序层似乎仅在消息通过无线传输的有效负载时才被触发。  

    我目前正在检查 中央侧的返回状态。  

     

    status = ATT_HandleValueCfm( pMsg->connHandle );
if (status != SUCCESS)
{
    //error print out
}
     

    未能发送确认信息时、不会出现打印错误。 这是否指的是“您可以尝试检查您使用的 GATT 函数的返回值“？

    谢谢！  

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好！

    对于返回值、是的、我想到了这一点、但也想到了其他函数、例如在外围设备中发送指示的函数。 您可能会收到错误消息、例如没有更多的 TX 缓冲器或其他问题。 您可以尝试的其他操作是通过侦听 外设中的 ATT_Handle_Value_CFM 消息来检查是否确实收到指示确认、并打印出任何错误。

    对于嗅探器,我们拥有非常高端的设备,我们不建议您购买这些问题,因为这可能是太贵. 我不能推荐你任何特定的产品,但有很多便宜的 USB 蓝牙嗅探器,你可以在线购买. 确保它们至少与蓝牙 5 兼容、并且支持嗅探 GATT 消息和过滤特定设备。 如果您的蓝牙连接已加密、嗅探也会变得困难。

    关于连接间隔、似乎堆栈在处理数据速率过高时遇到问题。 如果您的目标是实现高吞吐量、我建议您保持连接间隔为 8。

    此致、
    Lea

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Lea：

    关于嗅探器,我看不到任何廉价的 USB 蓝牙嗅探器可以在会议期间重新连接而不中断连接,并保持记录数小时。 租赁也是另一种选择、而不是购买。 因此、如果您可以共享您的设置以进行中期捕获、那将会非常好。  

    过去两天我一直试图弄清楚是空 PDU 还是保持连接的活动状态。  

    收到跟踪指示/通知。  

        // Enable connection event notifications to detect empty PDUs
    HCI_EXT_ConnEventNoticeCmd(simpleBLEConnHandle, simpleBLETaskId, CONN_EVENT_NOTICE);
    ...
    ...
    case ATT_HANDLE_VALUE_IND:
    case ATT_HANDLE_VALUE_NOTI:
        gattNotificationCount++;  // Added counter all notifications for diagnostics

    计算空 PDU： 

    if(events & CONN_EVENT_NOTICE)
    {
        connEventCount++;
        // Calculate empty PDUs: connection events with no GATT notifications
        unsigned int gattDelta = gattNotificationCount - connEventCountAtLastGatt;
        if(gattDelta == 0)
        {
            emptyPduCount++;  // Connection event fired but no GATT notification
        }
        else
        {
            // Update tracking - don't report burst (causes rollover artifacts)
            connEventCountAtLastGatt = gattNotificationCount;
        }
        
        return (events ^ CONN_EVENT_NOTICE);
    }

    一旦时间戳签出、计数器就会复位 

     // Reset counters when packet passes freshness check
    gattNotificationCountAtLastCheck = gattNotificationCount;
    emptyPduCount = 0;
    connEventCount = 0;

    现在、我正在等待 3.7 秒、确认没有新数据包、然后结束 BLE 活动以强制重新连接。 在断开这两者之前、我会得到一份打印输出

    gattNotificationCountAtLastCheck, gattNotificationCount, emptyPduCount, connEventCount

    前两个具有相同的值、表示没有新的指示/通知到达、并且 emptyPduCount 和 connEventCount 在 0x16C 到 0x174 之间几次运行、按照您的建议 (10ms)、连接间隔设置为 8、它显示空的 PDU 正在保持连接活动。  

    此空 PDU 检查对您是否有意义？  

    接下来我将介绍外设。  

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Lin、

    如果存在器件是否仍在发送数据包的问题、一种简单的方法是使用功率分析仪检查功耗是否与发送的数据包相匹配。 由于对讲机 TX 是迄今为止耗电量最大的操作、因此在电源日志上很容易识别它。

    您可以使用例如 XDS110-EVM ET 板。

    谢谢、

    Marie H

  • 0
    TI__Guru**** 2763595 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Marie：

    当前、指示停止时、出现空 PDU。 我假设空 PDU 仍会消耗功率、因为空气中会发生传输。  

    您是否说仅包含空 PDU 的数据包与包含数据的数据包将具有不同的功耗特征？  

    谢谢、

    LIN