• 状态 Resolved
  • 已锁定 已锁定
  • 回复 13 回复
  • 订户 0 订户
  • 视图 931 视图
  • 用户 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.

[参考译文] CC2640R2L：连接参数更新和&quot；LL Ping & quot；冲突

admin
Guru**** 2386740 points
Other Parts Discussed in Thread: CC2640, CC2640R2F, CC2640R2L
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1000916/cc2640r2l-connection-parameter-update-and-ll-ping-collision

器件型号：CC2640R2L
主题中讨论的其他器件：CC2640、 CC2640R2F

您好！

我们有两个器件、其中 CC2640R2充当中央器件、而 NXP QN9083充当外设。 当我们尝试从中央更改连接参数时、有时它会与"LL Ping "事务发生冲突、并且连接参数更新失败、并收到来自主器件的 LL_reject_EXT_IND 消息。 请参阅下面的监听器屏幕截图。 链路层消息之间的这种冲突是否是 TI 堆栈的已知问题？ 随附监听器日志(软件链接： fte.com/.../bpalowenergy.aspx)。

一些观察结果：

  • 主器件(CC2640)拒绝其自己的连接参数更新。 请求更新的是 LL_CONNECTION PARAM_RSP 中的参数、与 LL_CONNECTION PARAM_REQ 中的参数完全匹配。
  • CC2640的 LL_reject_EXT_IND 消息显示错误代码"Invalid LMP Parameters"、但来自外设的 LL_CONNECTION PARAM_RSP 消息中的所有参数似乎都无效。 它们与 CC2640发送的数据匹配。
  • 中央应用程序在1分钟或2分钟后重试了完全相同的参数(未显示)、并且在两者之间没有 LL_PING_RSP 时工作正常。
  • 请注意、LL_ping 请求和响应不仅是空的连接事件、它们是核心规范5.2第6卷 B 部分第4.4.6节中定义的实际消息。

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

    您好！

    感谢您的查询。 我通知了一位同事、他将尽快回复。

    此致、

    拉斐尔

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

    您好！

    我有几个问题可能会帮助我们更有效地达到这一目标。 您使用的是哪个 SDK 版本？ 您提到 CC2640R2充当中央设备、您的项目是否基于 simple_central 示例项目？ 您使用的是 BLE 还是 BLE5堆栈？  在定制硬件或 CC2640R2 LaunchPad 上是否观察到此问题？

    此致、

    1月

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

    您好、Jan、

    • 它基于定制硬件。
    • 我们不是将项目基于 simple_central 示例项目。 CC2640位于自定义 USB 软件狗上、我们通过 PC 上运行的脚本向其发送 HCI 命令。

    我不确定 SDK 版本、我将从团队成员那里了解并汇报。

    -Kev

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

    您好、Kevork、

    感谢您提供更多信息。 您是否能够连接到其他外围设备以验证所有设备或仅  NXP QN9083设备是否出现此问题？ 还要确认、器件是 CC2640R2L？ 您提到 了 CC2640、因此我想确认一下。 SDK 版本是否有任何更新？

    此致、

    1月

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

    您好、Jan、

    我们将 CC2640R2F (不是我之前所说的 CC2640R2L、抱歉、是这样)与 BLE 4.2 SDK 2.30.00.28版一起使用。

    我们尚未使用其他外设进行测试、但鉴于 CC2640发送的 LL_PING_REQ 和 LL_CONNECTIVE_PARAM_REQ 数据包、来自 NXP QN9083器件的响应数据包似乎有效且符合预期。 CC2640拒绝了它自己请求的连接参数更新。

    谢谢、

    keV

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

    您好、Kev、

    是否可以测试 CC2640R2 5.10 SDK 上是否出现此行为？ 2.30 SDK 在相当长的一段时间之前发布、并且涵盖了所有版本、因为许多错误和问题都已得到解决。 这种行为可能在其中一个版本中得到纠正。 以下指南展示了将项目从旧版 SDK 移植到新 SDK 需要执行的步骤。

    迁移指南

    此致、

    1月

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

    您好、Jan、

    这可能需要一段时间、因为硬件不是由我们的团队设计的。 此外、我们的监管流程要求我们对第三方工具进行正式测试/验证、然后才能将其用于当前用途、因此更新固件需要我们重复多次测试。 在任何情况下、我们都可以尝试使用较新的版本并报告。

    同时、如果新 TI 固件在等待 LL_PING_RSP 数据包时收到用于更新连接参数请求的 HCI 命令、是否可以通过分析查看该固件将执行什么操作？ 使用我们当前的 TI 固件、它已发送序列号为0的 LL_PING_REQ、当应用程序请求更新连接参数时、它立即发送序列号为1的 LL_CONNECT_PARAM_REQ、而无需等待 LL_PING_RSP。 我不确定是否可以连续发送两个不同的 LL 数据包。 然后、外设发送 LL_PING_RSP、后跟 LL_CONNECT_PARAM_REQ、NESN=1和序列号为0。

    如果最新的 TI 固件以相同的方式处理它、则升级无法解决我们的问题、我们的团队需要以不同的方式进行故障排除。

    提前感谢、

    keV

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

    您好、Kev、

    我们有理由相信、此问题可能已在后续 SDK 版本中得到解决。 通过查看 3.10 SDK 的发行说明 、我们可以看到问题  BLESTACK-4571 (加密启动请求后的 LLCP 冲突会因 MIC 故障导致终止)已得到解决。 我认为这个问题与您看到的问题相对应。 我建议移植到最新的 SDK 作为测试、以验证此问题是否存在。 如果无法移植到最新的 SDK、我建议至少移植 到3.10或3.20版本。

    此致、

    1月

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

    你好。 感谢您的反馈。

    我们在 SDK 版本5.10中尝试过此操作、并观察到相同的结果。 新的监听器日志再次附加。

    e2e.ti.com/.../Sniffer-Log-with-SDK-5.10.zip

    基本上、TI SDK (中央)在接收到第一个请求(LL_PING_REQ 和 LL_CONNECT_PARAM_REQ)的响应之前连续发送2个请求。 当然、外设会通过连续发送两个响应(LL_PING_RSP 和 LL_CONNECT_PARAM_RSP)来尝试响应、但 TI SDK 会拒绝第二个响应(LL_CONNECT_PARAM_RSP)。 我认为、即使 SDK 发送了两个连续的请求、它也会对接收两个连续的响应感到困惑。 可能是尝试将 LL_PING_RSP 响应解析为 LL_CONNECT_PARAM_RSP 响应、反之亦然。 这将解释 SDK 发送的错误代码"Invalid LMP Param"(0x1E)。

    此外，我检查了数据包9309和9574之间所有数据包的序列号(SN)和下一个预期序列号(NESN)字段，包括空的连接维护数据包，但没有发现问题。  当 TI SDK 发送两个连续请求(即不对不同的数据包使用相同的 SN)时、它会正确地递增 SN 字段。 发送两个连续响应时、外设还会正确递增其一侧的 SN 字段。

    我很乐意通过缩放或其他一些工具来分享到目前为止我对监听器日志所做的分析。

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

    您好、Kev、

    感谢您验证最新 SDK 中是否存在此问题。 这很有帮助。 我将与团队协商、以达到这一目的。 预计几天内会有更新。 同时、如果您遇到任何新信息、请使用新信息进行回复。 任何新的数据都有助于更有效地解决这一问题。

    此致、

    1月

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

    您好、Kev、

    我已将此行为传达给开发团队、并记录了内部票据中所述的所有行为。 他们将在能够做到这一点后立即对此进行研究。 我向他们提供了您提供的所有信息(包括监听器日志)、这些信息将非常有用。 如果您发现任何其他信息、请告诉我、我会尽快将其发送给开发团队。

    此致、

    1月

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

    您好、Jan、

    感谢你的帮助。 我们没有任何其他信息、但如果有、我会报告。 如果有更新、请告知我们。

    谢谢、

    keV

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

    您好、Kev、

    研发部门仍在研究这一问题，并将解决这一问题。 我对拖延时间的延长深表歉意。 我会在收到回复后立即更新您的信息。

    此致、

    1月