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:具有2个使用旧编码 PHY 的广播集的 GAP_EVT_ADV_END 事件丢失

Guru**** 2587365 points
Other Parts Discussed in Thread: SYSCONFIG

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

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1389476/cc2642r-missed-gap_evt_adv_end-events-with-2-advertisement-sets-using-legacy-and-coded-phy

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

工具与软件:

您好!

我们的产品使用 CC2642R1、通过配置2个广播集在旧模式和编码 PHY 模式下进行广播。 固件每2s 发送一次对这两个广播集的广播、并使用广播结束事件(GAP_EVT_ADV_END)来对传感器的读取次数进行计时并更新广播数据。 仅对为旧模式广播收到的 GAP_EVT_ADV_END 事件完成此处理。
我们发现、广播事件不时会停止一段时间、或者几个旧版 GAP_EVT_ADV_END 事件似乎遗漏了。

我们有一个计时器、用于检查 过去12秒内是否存在任何 GAP_EVT_ADV_END 事件、因此当时通常会计数6个旧模式 GAP_EVT_ADV_END 事件、但有时不会计数到任何事件、甚至只有几个事件(例如1、2或3)。
我不确定在 GAP_EVT_ADV_END 没有报告时是否真正发送了广播消息。 我将看到我是否可以设置监听器来检查它。
当使用不同的 PHY 运行两个广播集时、这是预期行为吗?堆栈中是否存在错误?

我无法通过修改 simple peripheral 示例来重现此问题、但我可以向您发送一个削减版的应用程序来进行调查。 我宁愿不公开发布、因此请告诉我如何将其发送给 TI。

我们使用以下版本:
SimpleLink CC13xx CC26xx SDK 7.40.77
SysConfig 1.18.1
编译器 TI Clang 2.1.2.LTS

此致、

Charles

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

    尊敬的 Charles:  

    感谢您的咨询。 您可以尝试切换 LED 以查看何时发送广播消息、这样您就可以无需监听器即可确认。 但如果这样不起作用、我可以在我们这边检查。  

    如果您能够在 simple peripheral 应用中重新出现此问题、会有所帮助、因为这将有助于我们进一步调查此问题。  

    此外、您在上是否看到类似的行为 最新的 SDKSysConfig 合规器?  

    此致

    Ivan

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

    伊凡、您好!

    感谢您的答复。

    我已经升级到最新的 SDK 7.41.00.17、SysConfig 1.20.0和编译器3.3.2.LTS、但仍然存在问题。

    我尚未设法通过修改版的 simple peripheral 示例使问题发生、但我将再尝试一些更改、以使其与我的应用更相似、并看看如何变化。

    此致、

    Charles

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

    伊凡、您好!

    我设法解决了 simple_peripheral 示例的修改版本问题。

    该问题有时需要一段时间才能发生(可能需要几个小时)。

    只需在 simple_peripheral.c (我修改的版本附加在 e2e.ti.com/.../8105.simple_5F00_peripheral.c)和 simple_peripheral.syscfg 中进行更改。

    更改如下:

    • 编辑 syscfg 以将 BLE -广播设备配置-广播集数量设置为0 (以便可以在代码中定义广播集和数据)。
    • 向 simple_peripheral.c 添加了广播参数和广播数据
    • 添加了2个时钟。 当存在旧广播结束事件时、postBleClock 开始、并使用更新的传感器数据更新广播数据。 CheckBleEventClock 每12秒运行一次、并检查广播结束事件是否仍在发生。
    • 在主任务中添加了处理  post_BLE_EVT 和 check_BLE_EVENT_EVT  的代码。
    • 添加了一些代码来模拟我的传感器(温度、压力和 SAMPLE_COUNT)。
    • 检测到问题后、执行"Display_printf (dispHandle、SP_row_debug+1、0、"Adv Events has stopped");"行(将点击 simple_peripheral.c 中的953)。

    请注意、我认为此问题可能与 post_BLE_EVT 和 check_BLE_Events_EVT 的处理方式有关。 当我以与 SP_READ_RPA_EVT 相同的方式处理这两个事件(即时钟处理程序使用 SimplePeripheral_enqueueMsg ()传递事件)时、我不认为问题发生了。

    平地机、

    Charles

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

    伊凡、您好!

    请注意、问题发生所需的时间可能比我指明的要长。 我昨天在启动器件30分钟内发生了这种情况(具有我发送给您的修改后的简单外设示例)、但随后却没有在隔夜发生(12小时或更长时间)。

    此致、

    Charles

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

    伊凡、您好!

    有人是否能够使用我修改后的简单外设示例重现问题?

    此致、

    Charles

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

    尊敬的 Charles:

    对于延迟、我们深表歉意。 由于我们的升级、我尚未成功重现问题、但我将尝试在今天结束之前重现问题、并回复给您。  

    您知道 是否 使用了1个 PHY、您仍然会看到问题吗?  

    此致

    Ivan

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

    伊凡、您好!

    如果仅使用1个 PHY、则不会出现问题。

    另请注意、虽然在12秒的检查时间内没有事件发生、但很少发生、因此通常只会统计2或3个事件。

    此致、

    Charles

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

    尊敬的 Charles:  

    您是否都测试过两个 PHY? 如果您使用单个 PHY、两者是否都能正常工作? 此外、您在测试期间是否成功获得了监听器日志?  

    我已运行您修改过的 simple_peripheral 30分钟、但尚未遇到问题。 将在我完成复制并设置监听器后为您提供更新。  

    此致

    Ivan

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

    伊凡、您好!

    如果我刚使用标准的 Phy、问题肯定不会发生、但我还没有尝试看看当使用编码的 Phy 时是否会发生这种情况(这不是一种应用程序使用的模式、因为它需要使用 iPhone)。 但这很值得一试。

    我还没有机会捕获嗅探器日志、但会这样做。

    感谢你的帮助。

    此致、

    Charles

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

    伊凡、您好!

    我已成功捕获了显示发生问题的监听器日志。

    调试输出显示了发生在84秒左右的问题(这意味着在72秒到84秒之间没有1M PHY 广播结束事件)、而 Wireshark 捕获显示的是63秒到91秒之间没有来自电路板的广播消息。 请注意、捕获文件中过滤掉了其他蓝牙设备。 根据调试输出、在这段时间内没有丢失任何代码 PHY 广播消息。  

    这是压缩的 Wireshark 捕获文件。

    e2e.ti.com/.../missed_2D00_adv_2D00_events.zip

    这只捕获了1M PHY 消息、我将看到是否可以在问题发生时捕获编码的 PHY 消息。

    此致、

    Charles

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

    伊凡、您好!

    使用监听器观察编码 PHY 可以看到没有错过的编码 PHY 广播、而连续有6个错过的1M PHY 广播。

    我的监听器似乎一次只能观察一个 PHY、因此当设置为显示编码 PHY 时、它不会捕获1M PHY 消息。

    此致、

    Charles

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

    伊凡、您好!

    您是否成功重现了此问题?
    我做了更多的测试、对于仅在一个 PHY 上广播、它不会错过广播事件(无论它是1M PHY 还是编码 PHY)。

    我还注意到、当它在编码 PHY 和1M PHY 上广播时、错过的主要是1M PHY 广播、而编码 PHY 广播更规律。 在隔夜测试中、有一个12秒的周期内没有1M PHY 广播、但有6个编码的 PHY 广播(如预期所示)。 因此、当使用两个 PHY 进行广播时、我似乎至少可以通过触发对编码 PHY 广播事件的采样来改进我的固件。

    此致、

    Charles