[参考译文] CC2640R2F-Q1：从一些 HCI 错误代码恢复

您好  François、

以下是一些初步答案、它们可能会随着我对此进行更多研究而发生变化。

如果有 正在进行的广播、这 2 个错误代码中的一个是否能真正停止广播？

是可能的。 当堆已满或没有足够的堆时、HCI_BLE_HARDWARE_ERROR_EVENT_CODE 似乎被触发。 我看到在两种情况下会返回：

1.生成本地 P256 公钥后读取该公钥。

2.通知控制器 DH 密钥生成完成的回调。

在任一种情况下都会分配内存、如果没有足够的堆来分配该内存、则返回此代码。

我不确定这是否会影响正在进行的广告。 我不确定的原因是,这认为堆,所以如果堆是满的或没有足够的内存,只有这可能会对广播产生影响。 我认为更重要的问题是、为什么应用程序中的堆已用尽？ 它们是否会以较小的连接间隔发送大量 GATT 通知/数据？ 内存泄漏？ 我会走几条路径来调试这个问题、但这肯定与存储器相关。

至于第二个代码、我实际上没有在栈代码中经常看到这种调用。 我需要进一步研究这一点。

这些错误代码的唯一来源是 BLE 堆栈、也可以由上述操作系统等生成吗？

BLE 堆栈是这些错误代码的来源、这些错误代码 可能 是由操作系统中的某些组件引起的。 例如、当堆内存不足时、HCI_BLE_HARDWARE_ERROR_EVENT_CODE 会触发。 通过操作系统抽象层分配内存。 你可以这样想:

1.调用 BLE 函数。

2.函数尝试调用 malloc（malloc 来自操作系统）。

3. malloc 失败或返回 NULL（操作系统没有足够的堆）。

4. BLE 函数返回 HCI_BLE_HARDWARE_ERROR_EVENT_CODE。

这两者都有一些区别。  

这 2 个事件是否也是 GAP 事件？ （将 ICALL_SERVICE_CLASS_BLE 作为源、将 HCI_GAP_EVENT_EVENT 作为事件类型）

根据简单的代码分析、是的、它们是 HCI_GAP_EVENT_EVENTS。

有哪些方法可以降低发生这些事件的可能性？ 此帖子 提出了几个建议；还有其他建议吗？

我认为这篇文章提供了一个具体的场景、但总的来说、我认为应该了解以下两点：

1.我分配和释放多少内存? 我可以减少分配的内存量吗？

2.在操作结束后,而不是在操作结束之前调度操作。 我的意思是克莱门特所说的,等到你收到一个事件,说当前操作已经结束,然后再安排另一个。 这将释放队列、从而减少内存使用。

如果发生这 2 个错误之一、操作系统是否仍在运行、调度任务并刷新看门狗？ （他们会询问，因为他们测试了看门狗并正确复位了置位/故障、主机控制器能够检测 BLE 复位并重新启动广播。 但是、如果操作系统仍在运行且只有 BLE 栈卡住，则看门狗不会复位，正确？）

看门狗是基于中断的驱动程序。 如果操作系统正在运行、则无论 BLE 栈如何、看门狗都应能够正常工作。

如果发生这些错误、BLE 栈能否自行恢复、或者主机控制器是否应该捕获错误代码并使 BLE 器件复位？

这是一个好问题、要实现完全透明、如果不能重现、就很难回答。 从代码分析的角度来看、当发生这些错误代码时、它们只是通知控制器、但似乎并不会触发异常处理程序。 理论上、是的、它可以恢复、但我想说、这些错误表明存在应通过软件设计解决的问题。  

堆使用情况是什么？ 对应用程序及其内存使用情况进行分析可能表明我们使用了过多的内存。 我们可能不会一直持续下去、但一些优化可能会使我们永远不会看到这个问题。  

要说的是、这取决于客户满意的方面。 不过、我认为一些内存分析可能会有所帮助。

我希望这对您有所帮助！

此致、

Nima Behmanesh  

尊敬的  Nima Behmanesh：

感谢您的详细回答、这有助于我们更好地理解这些错误。

实际上、问题是我们看到广播在 BLE 器件上停止、我们正在搜索根本原因（这很困难，因为问题很少见，无法重现并且没有任何执行日志）。

因此、我们将注意力集中在上述 HCI_BLE 错误、思考如果其中一个错误发生、它们会影响广播并“冻结“BLE 栈。 因此,我们目前无法确定这些错误实际上会发生,我们正试图通过故意的堆泄漏来强制它们发生。

我们将继续进行分析和调试工作、如果我们需要进一步的支持、请让您关闭此工单。

谢谢您、

Valentin Vasiu

尊敬的  Nima Behmanesh：

我们先进了分析功能、并正在评估恢复功能（在 BLE 芯片复位、故障、冻结或 BLE 芯片和主芯片之间的通信丢失数据的情况下）。

我们有以下问题：
-您是否考虑 SDK 3_40_00_10 和最新 SDK 之间的任何修复 与 SDK 中阻止广播而没有 请求广播本身的潜在问题相关?
-是否有任何 HCI 命令,我们可以从主控制器用于轮询 BLE 芯片,检查广播状态? （例如，含义为“广播是否正在运行？“的 HCI 命令）

谢谢您、

Valentin Vasiu

您好：

您是否考虑 SDK 3_40_00_10 与最新 SDK 之间的任何修复  、该修复涉及 SDK 内可能出现的问题、即在未 请求广播本身的情况下阻止广播？

考虑到此 SDK 相当旧、可能有许多与广告相关的票证。 我可以做的是在更小的 SDK 范围内寻找与广播相关的任何修复。 此外、在较新的 SDK 中进行的任何修复都可能不适用于较旧的 SDK。  

我将看到有关任何相关门票的信息。

-是否可以从主控制器使用任何 HCI 命令来轮询 BLE 芯片、检查广播状态？ （例如，含义为“广播是否正在运行？“的 HCI 命令）

我认为轮询状态的唯一方法是使用广播的句柄调用 GapAdv_enable、并检查 bleAlreadyInRequestedMode。

问题稍微无关、但您是否在软件中使用 GATT 通知/指示？ 如果是、这些通知/指示的发送频率是多少？

此致、

Nima Behmanesh

您好：

感谢您的回答。

关于 GapAdv_enable (HCI_EXT_GAP_make_Discoverable)、我们在启动广播（以及在建立每个链路后重新启动它）时只使用一次、并定期使用 HCI_EXT_GAP_UPDATE_ADV_DATA 更新广播数据。 但最好在更新数据后（或在定期保持活动期间）重新启动广播、即使通常不需要它。 这样一来、如果 BLE 栈中有任何导致广播停止的问题、主控制器将重新启动广播。 我们已经处理 bleAlreadyInRequestedMode  响应。

其次、我们实现了恢复功能、以在 CC 控制器冻结时恢复它（我们根据您的建议模拟了冻结的场景，在 UART 堆栈不再响应主器件之前泄漏动态存储器）。 我们现在考虑的是在处理命令的过程中恢复 CC 控制器的冻结、因此当 SRDY 引脚为低电平时。

为了回答您的问题、我们不在软件中使用 GATT 通知/指示。

总而言之、由于这个问题非常罕见、我们最终无法重现、因此我们更专注于在主端实施强大的恢复机制、该机制可以处理所有事务（从 CC 芯片复位，冻结，通信丢失，握手引脚左阻断等）。

PS:不要犹豫,回到我们在 SDK 方面的一些修复列表,这可能会修复广播功能的意外停止。

感谢您的支持、

Valentin Vasiu

您好：

您是否对票证列表进行了任何更新、这些更新可能解决在  SDK 3_40_00_10 和更高版本之间意外停止广播的问题？ 即使您在较新版本的 SDK 中找到某些内容（由于主要版本增加而引起的中断变化）、如果有移植指南、我们也可以考虑升级 SDK。

谢谢您、

Valentin Vasiu

您好 Valentin、

CC2640R2F SDK 的所有版本均可在此处获取： https://www.ti.com/tool/download/SIMPLELINK-CC2640R2-SDK/4.10.00.10

在每个版本中、您可以通过以下链接列出该版本带来的所有更改和修复：发行说明>新增功能>更改日志

但是、正如 NIMA 所说、在较新 SDK 中进行的任何修复都可能不适用于较旧的 SDK。

NIMA ：我想在这个阶段、我们应该建议在主机端建立一个强大的恢复机制、因为这是客户最终要寻找的。 请告诉我们您的想法。

此致、
François μ s。

你好 Nina、

您如何更新广告？ 更新数据时、广播是否停止？ 当您更新数据并查看堆上分配的内存时、它是否会增加您的预期值？ 当您将数据更改为较小的有效负载时、您是否会看到堆下降？

我们使用  HCI_EXT_GAP_UPDATE_ADV_DATA 命令在广播过程中定期更新广播数据。 在我们可以测试的范围内、这是正常的。 仅在接收到链路建立通知后、主控制器有意重新启动广播（BLE 栈隐式停止广播）。  

根据您的建议、我们正在考虑使用 HCI_EXT_GAP_make_discoverable 命令定期添加广播重新启动（在使用之前的命令更新数据之后或在保持活动计时器上）。 如果 BLE 栈没有问题、它将以 bleAlreadyInRequestedMode 进行响应、这对我们来说不会是问题、但如果 Adv 出于任何原因停止、我们将重新启动它。 因此、这将是一项强大的恢复功能。

关于堆的使用,我们没有监控它,产品运行良好的几个小时甚至几天,我们只有 2 副本的“Adv stop“在我们的客户端.

其中一种恢复方法是监视堆上已分配数据的大小。

这是一个很好的主意,在我们自己的基础上添加一个新的恢复方法。 我们强制堆泄漏并看到足够的泄漏、UART 通信也关闭、这通过我们的保持活动功能来恢复（CC 芯片不再响应保持活动命令，因此我们会复位）。 是否猜测当堆泄漏并变满时 UART 通信是否会“始终“停止？ 还是最好在恢复的基础上添加对堆的监视？

关于 changelog 的最后一点,我发现了这 2 个 TT :

• https://sir.ext.ti.com/jira/browse/EXT_EP-10231
• https://sir.ext.ti.com/jira/browse/EXT_EP-10230

所以,你认为这些修复可以帮助以任何方式克服我们正在经历的突然的广告停止行为? 这意味着我们应该考虑升级 SDK？

谢谢您、

Valentin Vasiu

您好：

我始终认为、如果您有时间和资源迁移、升级 SDK 是一个不错的选择。 最新的 SDK 通常包含许多修复程序、可改进您的应用程序。

考虑到您已链接的这两个票证、我可以进一步了解它们、但我相信、在广告运行时更改数据可能会导致一些未定义的行为。 您在测试中未观察到这一点可能意味着它可能很少发生。 此外、由于无法重现问题、我想说添加我们不确定是否会产生影响的补丁可能会导致更多问题。

此致、

Nima Behmanesh  

您好 Valentin、

您对此主题还有其他问题吗？

此致、
François μ s。

您好 Francois、

没有关于此主题的其他问题。

感谢您的支持！

此致、

Valentin Vasiu

您好 Valentin、

非常好。 感谢您的反馈。 结束本次讨论。

此致、
François μ s。