[参考译文] CC2541：了解堆内存使用情况

您好、Varun、

正如您发现的、听起来好像您没有堆内存。 我建议对使用情况进行分析、以确定需要节省多少成本来确保应用程序正常运行。 遗憾的是、很难为最小分配内存提供准确的答案、因为它高度依赖于应用程序。

要监视堆，您可以导航到位于 sdk_install_DIR>Documents>TI_BLE_Software_Developer's Guide.pdf 中的软件开发人员指南。 具体而言、导航到第3.4节堆管理器。 您必须设置预处理器符号并重新刷写项目以启用此功能。

尊敬的 Ammar：

感谢你的答复。

我检查了变量 memMax、在运行时、它保存的值为1840字节- 2200字节、在我们的系统中、我们为 堆分配了#define INT_HEL_LEN 3072。

我认为这意味着我们分配的内存足够了吗？ 如果我错了、请纠正我的问题。

但是，当我查看映射文件并计算出与 OSAL 相关的 xdata 存储器时，它是3113字节(3+2+ 10+3085+7+6)。  

2.这是否意味着我需要为     INT_HEAL_LEN 分配额外的43个字节(3113-3072) ？

     

OSAL                       1 481                    3
OSAL_BcpApplication          145                    2                          29
OSAL_ClockBLE                255                   10
OSAL_Memory                  744                3 085
OSAL_PwrMgr                  183                    7
OSAL_Timers                1 217                    6

 

最棒的

瓦伦

(抱歉、我点击橙色按钮、这不是指我将继续处理该线程)

尊敬的 Varun：

静态分配的存储器(如 OSAL 存储器)不应在堆中被考虑在内。

确保在 最坏的情况下取 memMax 的值。

内存堆栈大小也可能是问题的原因。 如果没有工具，可能很难确定这种问题。 因此、我建议您在增加测试的地方运行一些测试、看看它是否有用。

此致、

您好 Clement、

抱歉、我以为 OSAL 存储器会进入堆(根据软件开发人员指南、为堆留出的存储器会显示在 OSAL_Memory 模块下的映射文件中)。

内存堆栈大小也可能是问题的原因。 如果没有工具，可能很难确定这种问题。 因此、我建议您在增加测试的地方运行一些测试、看看它是否有用。

-->只需通过增大 INT_HEAP 的值来确认，对吧？

最棒的

瓦伦

您好！

[引用 userid="492310" URL"~/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum 1059670/cc2541-Understanding heap-memory-usage/392373#3921373"]

内存堆栈大小也可能是问题的原因。 如果没有工具，可能很难确定这种问题。 因此、我建议您在增加测试的地方运行一些测试、看看它是否有用。

-->只需通过增大 INT_HEAP 的值来确认，对吧？

[/报价]

实际上、对于 CC2541、此建议不正确。 在8051中、堆栈溢出不太可能、因为堆栈没有被大量使用。 如果没有有效的间接寻址模式、它主要限于保存返回地址(由 MCU 自动管理)和保存的寄存器(主要以 ISR 为单位)。

您好 Clement、  

系统非常不可预测。 它有时不记得绑定。 有时它不会绑定、因此无法发现它。 我在定期任务中添加了此代码、以确保系统在 未连接时每分钟都保持广播、以便其他设备可以发现它。 但它仍然不起作用。

if(gapRole_state != GAPROLE_CONNECTED && gapRole_state != GAPROLE_CONNECTED_ADV)
      {
        periph_mode = osal_start_timerEx( gapRole_TaskID, START_ADVERTISING_EVT, 1 ); 
      }

最棒的

Varurn

在今天的测试中、我注意到 nV ram 中 bluetooth 器件地址的重复条目

 

这就是我在 FD01特性中存储的内容：

    uint8* ptr1                   = GAPBondMgr_GetBondedAddress(0);
    osal_memcpy(&TPMS_ConfigRespParams_s.Data_au8[1U],ptr1,B_ADDR_LEN);
    ptr1                          = GAPBondMgr_GetBondedAddress(1);
    osal_memcpy(&TPMS_ConfigRespParams_s.Data_au8[7U],ptr1,B_ADDR_LEN);
    ptr1                          = GAPBondMgr_GetBondedAddress(2);
    osal_memcpy(&TPMS_ConfigRespParams_s.Data_au8[13U],ptr1,B_ADDR_LEN);

使用最新的 BLE Stack 1.5.2.0

是否有理由将重复条目存储在 NV RAM 中？

最棒的

瓦伦

尊敬的 Varun：

我不熟悉函数 GAPBondMgr_GetBondedAddress()。

很有意思的是，这个函数是否基本上报告了存储器的内容，即使债券已经失效，或者它是否只报告了有效债券。

在所有情况下、GAP 键合管理器不应在闪存中存储超过 GAP_Bondings_MAX 的债券(请 参阅此处)。 此外、如果具有相同公有地址的器件已经存在债券、GAP 债券管理器不应创建债券(而是更新债券)。

我希望这将有所帮助、

此致、

 

您好 Clement、

抱歉，该函数从 bonds [index].publicAddr 获取值；

最棒的

瓦伦

尊敬的 Varun：

当一个绑定从闪存中擦除时、RAM 会在之后立即更新。 因此不应出现此问题。

鉴于您遇到的 RAM 问题、可能存在一些无法分配的存储器、从而导致覆盖闪存中的绑定(使用0xFF)问题。 因此、键合无法正确擦除、系统进入错误状态。

我希望这将有所帮助、

此致、