[参考译文] CC2652P：BLE 应用中的 PER 和堆内存泄漏（每隔几秒 24 字节堆泄漏）

你好 Carlos！

最可能的答案是您忘记释放软件的内存分配。 我们的 BLE 栈通常自行处理所有必要的分配和取消分配、因此您应该在代码中查找缺少的自由空间。

调试的一种方法是首先检查分配的数量:在 ROV 中,您应该能够看到您提到的可用堆内存的数量,但也可以看到程序生命周期中发生的分配和取消分配的数量。 这将允许您检查它是泄露的 24 字节分配、还是泄露的多个较小分配。

另一个调试步骤可能是查看软件何时泄漏。 您每次收到通知时是否泄漏 24 字节？ 它是否也泄漏在连接外部? 当您已连接但未收到任何通知或 ATT 请求时、它是否会泄漏？

最后、您可以尝试检查正在分配的结构之一是否恰好是 24 个字节。 您可以使用 C 函数 sizeof 来检查该情况、也可以通过自行计算来了解结构的大小。 如果您要分配的结构为 24 字节、并且您不时丢失 24 字节的堆存储器、那么此结构的分配很可能就是问题所在。

此致、
Maxence

您好、Maxence、

非常感谢您发送的消息和详细的调试策略。 我将根据您的建议继续调查、并随时向您提供最新结果。

只是为了添加一些背景:我开始研究这一点的原因是因为我观察到 PER（数据包错误率）突然从 0%跃升至约 50% 一次 堆的总可用大小降至~12 KB 以下 ,然后它保持高 — 即使当 RSSI 和 SNR 仍然非常出色 。

您认为此行为是否与堆内存耗尽或碎片有关？ 在达到临界点之前、泄漏（每隔几秒 24 字节）可能会对性能产生静默影响。

再次感谢、此致、
Carlos

你好 Carlos！

12KB 听起来 BLE 栈有足够的合理空间余量才能正常工作、令人惊讶的是、您看到这种行为。 它是从 0%跳到 50%、还是大约 50%？ 你知道是否每一个其他的数据包都被丢弃,或者它是否是随机的?

此致、
Maxence

您好、Maxence、

让我更详细地解释一下我如何衡量行为以及我观察到的内容。

由于此设置中尚未实现 UART、因此我收集的所有数据（包括堆内存信息和数据包错误率 (PER)) 都通过 BLE 传输。

PER 测量值

PER 会在BtC_processConnEvt函数内进行跟踪、其中我会同时计算正确和错误的数据包。 每次记录 80 个正确的数据包或 80 个错误的数据包（以先到者为准）时,通过 BLE 发送数据BtC_send_info。

堆监视

在处理系统级消息后、堆内存数据在主循环中收集、例如：

• GAP_MSG_EVENT

• GATT_MSG_EVENT

• HCI_GAP_EVENT_EVENT

然后、while循环处理来自其他任务或上下文的消息、使用：

似乎是这样 24 字节泄漏 期间发生 BtC_processApplicationMessage某些消息类型 、我仍在确认。 此函数处理应用程序的自定义消息。

观察结果

• 可用堆大小合计 和 最大块大小 两者均从 13KB 左右开始、并逐渐降至零。

• PER 保持 0% 直到总可用大小降至~12 KB 以下。

• 在那一刻,我就决定好了 50% 、然后继续上升到 80% 随着总可用大小接近零。

• 为了确认效果,我人为地强制释放 24 个字节（通过在循环中添加第二个）ICall_free(pMsg)。 减少 稳定的总可用大小 、但是 “Max Block Size（最大块大小）“仍然减小 增加 24 个字节、PER 仍增加到 80%。

• 堆数据存储在变量中并在中发送  BtC_processConnEvt, together with the PER via BtC_send_info

有道理吗？ 你有什么建议吗?

谢谢、此致。

Carlos。

你好 Lea 我改变了标题,也许你看不到我以前的答案。

谢谢。此致。

Carlos。

您好、Maxence、

实际上我们可以尝试、问题是开发时间、因为我们需要让它快速运行。 你有什么想法我可以尝试吗?

此致。

Carlos。

您好、

可以对程序的关键函数设置多个断点、以便更彻底地检测代码中何时发生泄漏、从而找出应该归咎于哪些分配或函数调用。

我可能会出错、但一旦 RTOS 运行（断点按预期停止工作）、似乎就会出现问题。 我之前已经尝试过、系统在遇到断点时进入未知循环状态。

您好、

RTOS 运行后断点无法正常工作、这听起来是一个很难解决的大问题。 如果您无法在电路板上运行调试器、我几乎无法帮助您调试问题。

您是从一个已知的例子开始您的项目吗? 您是否也在 basic_ble 等示例中看到了这些问题？

我真的建议您从 basic_ble 开始并构建自己的应用程序位置、或者使用 git bissect、因为目前您限制使用 UART 上的打印来调试您的问题、这非常有限。

此致、
Maxence

再嗨 MAXnce、

我正在尝试启用 UART 并使其正常工作。 您是否知道可以通过 UART 检查哪些内容来解决问题？

谢谢、此致。

Carlos。

打印您正在使用 iCall_getHeapStats 在您软件的不同点读取的堆统计信息以了解何时发生泄漏是我认为调试会话的良好开始

我将使用 UART 这样做、希望能尽快获得一些结果。 除此之外、您能告诉我在哪里可以找到 CC2652P 这样的例子吗

您好！

根据 BLE5 堆栈用户指南 ：

CC2652P 与 CC1352P 器件引脚兼容、在功能上与 CC1352P 器件相同、可在 2.4GHz 下运行。 您可以在 CC2652P 器件上运行 CC1352P 软件示例、无需进行任何更改。

这意味着您可以 将 CC1352P 器件的任何示例导入 CCS、然后刷写到 CC2652P 中 。 您可以在  C：\ti\simplelink_cc13xx_cc26xx_sdk_8_30_01_01\examples\rtos\CC1352P_2_LAUNCHXL 下找到 CC1352P 的示例

此致、
Maxence

您好、Maxence、

我一直在忙于调查问题、没有机会查看您提到的版本。 我刚意识到我们目前正在使用 simplelink_cc13x2_26x2_SDK_4_10_00_78 （我知道它是相当老的）。

您是否知道此版本是否受我们看到的问题的影响？
另外、您是否考虑升级到 8_30_01_01 可能会解决该问题？

感谢您的支持。

此致、
Carlos

顺便说一下、为了避免对代码进行太多更改并以最简单的方式进行升级、我应该 先试用版本 5.30.00.56、因为它似乎是经典 SDK 系列的最新版本？

您好、

我认为升级 SDK 是尝试解决您的问题的第一步。 我们通常会提供有关在出现变更时如何将 SDK 从版本升级到版本的指南、但 4.10 与 8.30 之间的差距太大、您必须遵循 4 个不同的 年对年迁移指南。

根据您添加的功能数量和代码库的大小、如果您的工程足够小、那么在最新 SDK 版本的示例中从头开始并从示例中重新添加功能实际上可能会更容易。

此致、
Maxence

尊敬的 Mathieu：

我发现、即使是非常基本的框架实现、在 BLE-STACK 5.1 上运行时也会显示堆内存问题。
（在我之前的消息中，我错误地提到了 4.30、这是另一个对等设备使用的 SDK 版本，而不是我们的版本。）

您是否知道 BLE-STACK 5.1 中是否存在此堆存储器问题？

我的计划是在 SDK 8.30 上运行 Project Zero、亲身确认不再出现堆内存问题、然后开始在该基础上合并/构建我们的固件。

感谢你的帮助。

此致、
Carlos

尊敬的 Carlos：

是的、我认为从 Project Zero 或 basic_peripheral 开始并在上面构建固件是一个好主意。

此致、
Maxence

您好 Mathieu、感谢您的建议。 你知道 5.3 是否也有这样的问题吗?

此致。

Carlos。

尊敬的 Carlos：

在我们的示例中、我们的 5.3 蓝牙栈不会出现任何已知的内存泄漏。

此致、
Maxence