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.

[参考译文] CC2642R:绑定后无法连接到配置为外设的器件

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1196007/cc2642r-unable-to-connect-to-device-configured-as-peripheral-after-bonding

器件型号:CC2642R
Thread 中讨论的其他器件: SysConfig

您好!  

我们一直看到外设在绑定后连接方面存在一个奇怪的问题。 本质上、在使用运行 u-connect 固件(v4.0)的 uBlox Anna-B112时、绑定和连接似乎是相互排斥的事件。 如果我们尚未绑定、则连接到作为外设运行的 CC2642R 可以正常工作、只有在绑定之后、我们才能再连接。  

通过 Wireshark 使用数据包监听器、我们认为我们看到了问题是什么、但我们不确定 CC2642R 侧或 uBlox 侧是否出现了错误行为。 看起来 uBlox 器件将地址分辨率视为强制性步骤、但它可能不会这样做。 但是、CC2642R 绝不会发送任何类型的响应、这也是毫无意义的

下面是一个与另一个 uBlox 芯片通信的 uBlox 芯片示例。 还附加了 Wireshark 日志(Anna 到 Anna)、绑定从数据包1476开始、连接从数据包1552开始、位于 t:

下面是一个示例、其中 uBlox 芯片充当中央角色、CC2642R 充当外设角色。 在 Wireshark 日志(bond-the-connect-fail)中、绑定发生在数据包24918上、连接尝试发生在数据包25212上

我们最初在使用 SDK 2.40和禁用 MIPTM 保护和绑定的自定义固件时发现了此问题。 不过、我们使用简单外设示例和 SDK 6.40再次尝试了相同的测试、并观察到完全相同的行为。 我们可以确认、使用 SDK 6.40构建的简单外设示例确实支持中央地址分辨率特征。绑定后使用智能手机成功连接、但对于我们的代码和简单外设示例都是如此。

我们对 TI 的主要问题是:完全忽略按类型读取的中央地址解析的预期行为、为什么?  

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

    我实际上看不到 Wireshark 日志上载正确、是否有附加文件的技巧?  

    已创建一个驱动器链接以解决此问题:  

    先绑定后连接失败:

    https://sendum1-my.sharepoint.com/:u:/g/personal/ben_tuline_sendum_com/EY8hgVpT2U5ApgeNBGHLujsBDd2NFduyau3mrsdFNDJm0w?e=jfUzbq

    安娜到安娜:

    https://sendum1-my.sharepoint.com/:u:/g/personal/ben_tuline_sendum_com/EV9I1zqE_flLv0NCb1GvATgBQZcF5h53Fuy2ySLcq3vFKg?e=LagVha 

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

    您好 Ben、

    感谢您发帖。

    我已通知 BLE 团队进行进一步评论。

    谢谢、
    Toby

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

    您好 Ben、

    有关信息、我无法对监听器日志进行解码、因为它需要我们无法访问的插件。

    为了缩小问题的范围、我建议检查更改 CC2642R 使用的地址模式是否有帮助。 为此、您可以在 CCS 工程中使用 SysConfig 修改器件使用的地址模式。 在这里、我建议使用"公共地址"进行首次测试。

    让我们及时了解最新信息、

    此致、

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

    您好、Cl é ment、

    我们已经尝试了所有 ADDRMODE 设置、在 RPA 上看到了与公共 ID 相同的问题。 默认情况下、我们使用公共地址、  

    如果有用、这里是 CC2642R 忽略的单个数据包的扩展版本。  

    如果信息不足、您会建议您使用什么数据包监听器  

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

    您好!

    感谢您提供的详细信息。 您是否想提供有关 connect_IND 数据包的详细信息(这似乎是第一个没有被器件应答的数据包)?
    如果可能、我希望看到有效的 CONNECT_IND 数据包与失败的数据包之间的差异。

    例如、您可以将 www.ti.com/.../用作监听器。

    另一种探索方法是 CC2642R 是否启用了某些地址过滤(允许或拒绝列表-在白名单和黑名单之前调用)。 在这种情况下、它可以解释器件为何不应答连接请求。

    此致、

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

    以下是一些 CONNECT_IND 消息、以防其有用

    出现故障之前的 CONNECT_IND。  

    粘结时发生的 CONNECT_IND:

    未尝试绑定的正常连接上发生的 CONNECT_IND:

    我将尝试设置该监听器、但希望这现在可以正常工作。 我还将查看是否实现了地址过滤。 我不会假设、因为只要我们尚未绑定、连接到 CC2642R 就可以正常工作。  

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

    您好!

    感谢您提供的元素。

    我提到过、始终使用 CC2642R 的公有地址来建立连接(请参阅 RxAdd)。 如果外设(CC2642R)启用了隐私保护、则情况不正确。 这显然是由另一个供应商 https://github.com/zephyrproject-rtos/zephyr/pull/6417修复的问题
    由于我无法访问您的设备所使用的固件的详细信息、我是否可以要求您验证此修复程序是否已应用于您的软件?

    此致、

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

    我不认为已经应用了该修复、固件使用的是旧版本的 Nordic Soft Device。 但是、如果我们认为情况可能是这样、我可以再次检查。  

    我检查了隐私设置、看起来像 我们设置了 ADDRMODE_PUBLIC、我的理解是、为了实现隐私、我们需要将地址模式设置为 ADDRMODE_RP_ATH_PUBLIC_ID、以便根据 https://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr.html?highlight=gap#null 启用隐私。 因此、我猜可能还有其他事情发生。  

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

    您好!

    在进一步调试之前、请确保使用适用于所有相关器件的最新软件版本。 像你一样、我相信其他事情正在发生、我希望确保我们不会尝试修复已经修复的问题。

    此致、

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

    您好、Clement、是的、我们一直在使用最新6.40 SDK 中的简单外设示例来重现此问题。 但是、我们的定制应用程序是在一段时间前在2.40 SDK 上启动的。  

    此外、我们更倾向于尝试在此时获取信息、而不是修复。 我们可能有多种方法来实现这一目标、从而使我们的产品能够运行。 我们真正希望大家了解 SDK 是否应响应我们显示的消息、这些 Wireshark 日志中将忽略这些消息。  

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

    您好 Ben、  

    我知道。  
    目前、我无法确定器件是否应该或不应该在这里回答。 正如我所提到的,有一些对我来说似乎不正确的因素,我建议首先处理这些因素。  

    如果您有兴趣考虑其他方法、或者提供新数据点以了解问题的方法、我建议尝试使用不同的中央设备进行绑定。 例如、您可以尝试使用智能手机或 TI 器件(CC2640R2或 CC2642R)作为中央设备。 然后、目标是收集蓝牙跟踪并与最初收集的跟踪进行比较。  

    我希望这将有所帮助、  

    此致、  

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

    您好 Clement、  

    我们尝试了一款智能手机作为一个中央设备、它运行良好。 它在粘接后能够连接。 但是、它没有发送 CC2642R 忽略的消息。  

    我不太清楚如何强制不同的中心发送那些被忽略作为比较点的相同消息。 最好能获得一些测试建议。 我希望 Wireshark 日志足以确定 CC2642R 是否出现错误行为。  

    此外、仅供参考、其他人可能会从我们的末尾很快接管此问题  

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

    您好!

    感谢大家的观看。

    如果可以、我怀疑电话或任何其他中央设备可能会跳过 CONN_IND 数据包的发射。 如果未清除、则忽略的数据包为 CONN_IND、之后忽略的所有数据包(ATT 请求)仅是第一个数据包被忽略的结果。

    此致、

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

    抱歉,我的措辞很奇怪,手机没有跳过 CONN_IND 数据包,它跳过的是中央地址解析请求消息。

    我认为此时尝试在 BTool 中收集监听器日志可能是有道理的、如果您没有安装 Wireshark 插件、您可以进行更详细的查看。 我认为 Wireshark 插件可以很好地呈现数据、但显然很难通过文本和屏幕截图进行通信。