问题背景 有客户反馈代码运行奔溃,但始终找不到原因,经排查后发现是剩余RAM不足导致的。客户把所有应用内存直接保存到SRAM中,导致内存不足,跑应用时踩内存导致系统奔溃。
问题描述 因为代码全放在RAM中导致内存不足,跑应用时容易踩内存系统奔溃,但如何统计内存使用情况并优化?
问题分析
解决方法 SDK中提供了内存分析工具,以XR806为例,内存分析工具为tools\map_parse_gcc_v3.py,以audio_demo为例,使用方法为:
python map_parse_gcc_v3.py audio_demo.map
稍等片刻在bash中会显示内存统计情况:
=================================
Usage:
map_parse_version: 1.0.4
map_parse_gcc.py xxx.map
=================================
Memory Sections:
RAM 0x0000000000201000 0x000000000004b000 xrw
FLASH 0x0000000000400000 0x0000000000800000 xr
PSRAM 0x0000000001400000 0x0000000000000000 xrw
*default* 0x0000000000000000 0xffffffffffffffff
MEMORY MAP
|===========================================================================|
| MODULE | RAM | FLASH | PSRAM |
|===========================================================================|
| atomic | 0 | 28 | 0 |
| board | 20 | 14 | 0 |
| board_common | 602 | 0 | 0 |
| board_config | 1216 | 304 | 0 |
| captureControl_rtos | 0 | 467 | 0 |
| card_pcm | 0 | 712 | 0 |
................
................
| sys_monitor | 0 | 814 | 0 |
| *fill* | 149 | 1179 | 0 |
|===========================================================================|
| TOTAL (bytes) | 95045 | 1032493 | 0 |
| MEM LIMIT | 307200 | 8388608 | 0 |
| MEM LEFT | 212155 | 7356115 | 0 |
|===========================================================================|
其中lib打头的一般是.a静态库,其余为.o可执行文件,如果确定该section可以放在xip,修改project\linker_script\gcc\appos.ld,在xip.section添加对应的目标,常用的写法如下:
.xip :
{
. = ALIGN(16);
__xip_start__ = .;
*AAA.a: (.text .text.* .rodata .rodata.*) //某个静态库的text和rodata都存到xip中
*AAA.a:bbb.o (.text .text.* .rodata .rodata.*) //某个静态库中的某个.o存到xip中
*AAA.a: (EXCLUDE_FILE (bbb.o) .text) //某个静态库中除了bbb.o的text段,其余放到xip中
*bbb.*.o (.text .text.* .rodata .rodata.*) //bbb打头的所有.o存进xip中,常用于同一个make,但没有编译出静态库的场合