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:链路层响应超时

Guru**** 2551110 points


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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1567403/cc2340r5-link-layer-response-timeout

器件型号:CC2340R5


工具/软件:

您好、我们可以观察到一些断开连接 情况、报告为 LL_STATUS_ERROR_LL_TIMEOUT、在我们的诊断系统中、我们仅在设备连接到 Windows 计算机(不是 iOS、Android、macOS)时观察到此问题。

我们观察到的行为是连接最后一段时间(从 30 秒到 60 秒)、然后器件断开连接、报告此链路层超时。

这种行为是否有任何可解释的原因?

使用的 SDK 为 8.20.00.119

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

    您好、  

    当两个连接的器件未能在指定的时间范围内(监督超时周期)交换有效数据包时、会发生链路层超时、从而导致连接监督超时和链路终止。 您可以尝试使用监听器来确定不发送任何数据包的器件是外设还是中央器件。 因为你声称它可以与其他中心一起工作,我会假设问题来自 Windows 本身。

    此致、
    Maxence

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

    Lea 

    感谢您的答复。

    根据您的经验、您是否列出了熟悉此类问题的芯片组/系统?

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

    LEA 我忘了提到,但我们可以观察到,不同的系统建立连接和断开之间的时间始终是 40 秒。

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

    尊敬的 Luca:

    这是非常有用的信息、因为 40 秒恰好是 BLE 规范中用于链路层操作(如参数更新)的超时值。  
    引用 BLE 规范第 5.2 章程序响应超时:

    本节指定应应用于所有的程序超时规则
    第 5.1 节中指定的链路层控制过程、但除外
    存在连接更新和信道映射更新过程
    无超时规则。


    为了能够检测无响应的链路层控制过程、两者都是
    中央和外围设备应使用程序响应超时计时器 T PRT。
    程序启动时、程序响应超时计时器应
    要重置和启动。


    排队等待传输的每个 LL Control PDU 都会重置该过程
    响应超时计时器。


    当程序完成时、程序响应超时计时器应为
    已停止。


    如果程序响应超时计时器达到 40 秒 即 ACL
    连接被视为丢失(请参阅第 4.5.12 节)。 链路层退出
    连接状态、并应转换到待机状态。 主机应为
    已通知连接断开。

    这表示失败的过程是第 5.1 节中表格的一部分。

    但是、我没有显示此状态下失败的芯片组列表。

    此致、
    Lea

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

    Lea 

    由于我们使用  SDK 8.20.00.119、您是否知道最新 SDK 版本中的错误修复、因此我在版本说明中看不到任何相关内容。