合宙模块遇到内存死机如何分析

内存死机也是在我们对模块在进行二次开发中常见的问题，今天我们就来详细探讨一下，在使用合宙的模块的时候，遇到内存死机应该要如何排查原因和分析。

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

• 使用的工具：

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

• trace32工具下载

• EPAT抓取底层日志

可能导致模块内存死机问题的主要原因有哪些呢？

以下是一些常见的原因：

1. 内存泄漏

• 定义：内存泄漏是指程序在运行过程中，无法释放已经不再使用的内存空间。这些内存空间虽然被程序占用，但实际上已经没有用途，导致可用内存逐渐减少。

• 影响：随着内存泄漏的累积，系统可用内存逐渐减少，最终可能导致内存不足，进而引发死机。

2. 内存碎片化

• 定义：内存碎片化是指内存中的空闲空间被分割成多个小块，这些小块可能无法满足程序一次性申请较大内存块的需求。

• 影响：内存碎片化会降低内存的利用率，增加程序申请内存的难度，严重时可能导致程序无法申请到足够的内存而崩溃。

3. 内存申请失败

• 原因：程序在运行时可能需要动态申请内存来存储临时数据。如果系统内存不足或内存管理策略限制，可能导致内存申请失败。

• 影响：内存申请失败可能直接导致程序无法继续执行，进而引发死机。

4. 不合理的内存使用

• 定义：包括但不限于过度申请内存、频繁的内存分配与释放、使用错误的内存管理策略等。

• 影响：这些不合理的内存使用方式会增加内存管理的负担，降低系统稳定性，进而可能引发死机。

一、从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，死机就很正常了
不到70字节，如果用户代码里有类似uint8_t temp[71]，那么很容易就操作了栈外的ram，死机就很正常了。

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