合宙模块遭遇内存死机问题？教程来啦!

在之前的探讨中，我们分析了了合宙基于移芯平台模块遭遇死机现象的根源与应对策略。

今日，我们将进一步细化视角，聚焦于内存死机这一特定问题，探讨原因和解决方法。

当合宙模块遭遇内存死机时，首要任务是进行细致入微的原因分析。这包括但不限于检查是否存在内存泄漏，即程序未能及时释放不再使用的内存资源，导致可用内存逐渐枯竭；审视内存碎片化情况，即内存空间被分割成众多小块，难以满足大块内存申请的需求；以及评估内存申请策略，确保在内存资源紧张时能够合理、高效地分配资源。

在明确了内存死机的具体原因后，我们便可以着手制定针对性的解决方案。

本文档适用于合宙Air780E、Air780EP、Air780EQ、Air201

关联文档和使用工具：

移芯平台模块出现死机问题分析

trace32工具下载

EPAT抓取底层日志

一、从Ramdump里分析内存泄漏问题

对于遇到内存不足死机的问题，可以从ramdump里找出哪些函数在消耗ram。

进入trace32后，在自动弹出下发图片的窗口里能找到哪个函数在哪个task里用了多少ram没有归还，如果遇到哪个API大量申请了ram没有归还，基本上就是问题点了

为了查找方便，在trace_node选择某个数据，框里面右键 -> 点击format

上图里看到0x00868909 这个API在消耗大量的ram，从map文件，或者从trace_32工具菜单 view -> symbols -> browes 里搜索，Ctrl+F，或者Cov - > list functions，就能找到函数名称。

这样查找问题解答方向上 就相对明确了。

二、从Ramdump里分析栈溢出

需要检查下trace32里有没有freertos文件夹，如果没有可以在这里下载放到根目录freertos

一般来说，栈溢出会有断言的情况，但是也有代码申请了一大块栈空间，导致栈底的ram没有被改变，但是实际上代码已经操作了栈外空间，且freertos不会报错，燃石在trace32里能分析出来。

打开trace32 -> freertos -> stack Coverage -> List Stacks

可以看到ram使用情况，注意这里认为栈空间只有1KB，但是实际上可能是远超的，
不过没关系，如果max里是0%，说明还有很多栈空间，不用去管

Tmr Svc这个task居然用到了93%

右键点击红框，在弹出菜单里选择display memory->dump

距离溢出只有不到70字节，如果用户代码里有类似uint8_t temp[71]，那么很容易就操作了栈外的ram，死机就很正常了。

详细资料获取请点击： www.openluat.com