要理解STM32的RAM我建议先忘掉PC上的内存条这三个字。前阵子有个刚转嵌入式的同事问我为什么他定义了一个1MB的全局数组编译直接报错明明电脑上16GB内存跑得好好的。这个问题我遇到过太多次了很多从PC软件开发转过来的朋友对MCU的RAM有着天然的误解。STM32的RAM不是插在主板上的条状内存它是一块嵌入在芯片内部的SRAM总容量以KB为单位而且它的硬件结构、地址映射、程序在内存中的分布方式和PC内存条完全是两套逻辑。这篇文章我会从硬件结构讲起把STM32的RAM到底长什么样、地址空间如何划分、程序运行时内存里发生了什么以及当Keil报RAM溢出时怎么定位和优化全部拆开讲一遍。不管你用的是F1、F4还是H7系列只要理解了这套机制任何一颗MCU的RAM问题你都能自己分析。1. 先回答那个最容易被绕晕的问题STM32的RAM和PC内存条根本是两种东西1.1 SRAM和DRAM的运行机制差异PC内存条用的存储介质是DRAMDynamic Random Access Memory动态随机存取存储器而STM32内部集成的是SRAMStatic Random Access Memory静态随机存取存储器。两者最大的差别在于动态和静态这两个词。DRAM的动态指它必须不断刷新。DRAM的每个存储单元由一个晶体管加一个电容组成电容会漏电电荷存不住所以内存控制器要周期性地对所有存储单元进行充电刷新否则数据就会丢失。这也是DDR内存条上密密麻麻芯片的无奈之处——它们本质上是一个需要持续续命的电荷容器。SRAM的静态是指存储单元不需要周期性刷新只要供电不中断数据就能一直保持。SRAM的存储单元通常由6个晶体管组成的锁存器构成每个比特是一个双稳态电路只要通电它的状态就稳定在那不像电容那样会漏。这带来两个直接结果一是SRAM的读写速度比DRAM快得多因为它不需要等待刷新周期也不需要预充电的过程二是SRAM的集成度远低于DRAM同样面积的晶圆SRAM能做的容量可能只有DRAM的十分之一甚至更低。举个例子一颗STM32F103ZET6内部SRAM是64KB而一根普通DDR4内存条容量是8GB差了十几万倍。这不仅仅是STM32很小气的问题而是在相同制程下SRAM单元的物理面积决定了它做不大。你可以把SRAM理解成一个用六个晶体管死磕一个比特的奢侈存储把DRAM理解成一个用一个晶体管加一个电容凑合存一个比特的经济型存储。MCU需要的是低延迟、可确定性的存储所以选择SRAM是工程上的必然。1.2 为什么芯片内部不用DRAM你可能要问既然DRAM能做那么大的容量为什么STM32不直接把DRAM集成到芯片内部呢这里面有几个非常现实的工程原因。首先是工艺不匹配的问题。MCU的逻辑电路通常是低功耗、低频率的工艺节点逻辑和SRAM天然兼容可以在同一块晶圆上直接做出来。DRAM的电容则需要特殊的工艺要把这两种工艺合在一起成本会急剧上升。你可以想象一个厨房里既要装西餐烤箱又要装中餐爆炒灶台地方就那么大设备却要求完全不同的环境最后的结果往往两头不讨好。其次是引脚和接口的复杂性。即使能在片内集成DRAMDRAM的刷新机制也需要额外的控制器逻辑。STM32作为一颗以低成本和易用性为核心卖点的MCU片内直接集成需要刷新控制的DRAM会引入太多的不确定性和额外功耗。SRAM只要加上电CPU就能以SRAM总线速度直接访问不需要等待不需要刷新调度这在实时性要求高的场合是决定性优势。而且STM32面向的应用电机控制、传感器采集、简单人机界面通常只需要几KB到几MB的RAM这个量级用SRAM是完全够用的。真到了需要大容量内存的场景STM32也提供了外部存储控制器接口比如FMC/FSMC可以外接SDRAM那是另一套方案后面会专门讲。1.3 从容量和成本看硬件差异从使用者的角度看STM32的RAM容量和价格之间的关系也非常敏感。片内SRAM大小直接决定了芯片的定位和价格比如STM32F103C8T6是20KB SRAMSTM32F103ZET6是64KB SRAM后者在片内RAM、FLASH和引脚数量上都更豪华价格也相应更高。你在选型时RAM容量往往是比CPU主频更优先考虑的因素因为程序跑不动还可以优化算法但RAM不够就只能换芯片或者外扩这意味着硬件改动和成本上升。这里补一个实用认知STM32数据手册里标注的RAM容量有些是物理RAM总容量有些是连续地址RAM容量两者不完全一样。比如F4系列有CCM RAM它和主SRAM不连续不能通过DMA访问。如果你照着手册的最大RAM数去分配连续数组链接器会报错。这就是我后面要展开的内存映射问题。2. 芯片手册上的内存地图0x20000000那串地址是怎么规划的2.1 主流型号的RAM地址分布STM32是32位MCU理论上可寻址4GB空间。芯片设计者把这段地址空间划分成了不同的区域其中SRAM区域通常固定在0x20000000起始向高地址延伸。以最常见的STM32F103系列为例它的内存映射大概是这样起始地址区域说明0x00000000FLASH别名区可通过不同启动模式重映射0x08000000主FLASH存放代码和只读数据0x1FFFF000系统存储器Bootloader出厂烧录0x20000000SRAM存放变量、栈、堆0x40000000外设寄存器GPIO、USART、TIM等寄存器从地址规划上就能看出一个大原则不同功能的存储和外设分别占用了独立的地址段。RAM从0x20000000开始这不仅仅是约定它是由芯片内部的AHB总线矩阵和存储控制器决定的。你在写C语言时定义一个int a 0;编译器会把它分配到0x20000000之后的某个地址上。如果你用调试器查看变量地址会发现所有用户变量地址都落在0x2000xxxx或0x2001xxxx这种范围这就是SRAM区域的直接体现。不同系列的SRAM地址规划有明显差异。F1的SRAM就是一块连续的64KB大容量型号从0x20000000到0x2000FFFF。F4系列则复杂一些比如STM32F407有128KB主SRAM加64KB CCM RAM主SRAM又分成SRAM1、SRAM2和SRAM3三个子块它们在地址上连续排列SRAM1从0x20000000到0x2001BFFF112KBSRAM2从0x2001C000到0x2001FFFF16KBCCM RAM则在0x10000000到0x1000FFFF。这里的CCM RAM就是那个不在主SRAM区块、CPU可以直接访问但DMA访问不了的特殊内存块。2.2 同一颗芯片里RAM还分好几块F4的CCM和H7的多域SRAM很多人在用F4时会在CCM RAM上踩坑。STM32F407的CCM RAM全称是Core Coupled Memory紧耦合内存。它挂在CPU内核的私有总线上不走AHB总线矩阵所以CPU访问它的速度比访问主SRAM更快但它也因此不在DMA的控制范围内。如果你想把外设接收的数据DMA到CCM RAM里DMA控制器根本找不到那部分地址数据传输会失败。我当时写一个ADC采样程序为了缓存数据把DMA缓冲区放在了CCM RAM里结果DMA一直不工作数据全是0。后来看参考手册才明白CCM RAM是不连接DMA总线的。从那以后我就记住一条经验DMA缓冲区必须分配在DMA能访问到的SRAM里而CPU高频访问的热数据、中断栈可以考虑放到CCM RAM。到了H7系列RAM分区更复杂。H743内部RAM总量接近1MB但被分成了D1域、D2域、D3域和AXI SRAM等多个区块每个区块连接到不同的总线域访问延迟和可达外设都不一样。用H7的工程师必须仔细读内存映射表否则很容易出现某个外设的数据无法访问某块RAM的诡异问题。在主流的F1/F4项目中一个常见的需求是把大缓存数组放在外扩SRAM或特定RAM块里。链接脚本的MEMORY指令里可以定义多个RAM块然后通过__attribute__((section(.ccmram)))这类语法把变量指定到某块RAM。后面我会给出具体配置方法。2.3 位带操作与RAM映射内存映射表里还有一细节点值得注意SRAM的位带区域。ARM Cortex-M3/M4内核支持位带操作对于SRAM地址0x20000000开始的1MB区域对应位带别名区0x22000000开始的32MB区域。你可以把某个普通变量地址映射到位带区的一个32位字然后通过读写这个字来原子性地置位或清零某个比特。搞懂这个机制对RAM的理解有帮助位带区并不是额外增加的RAM它只是把同一个物理SRAM比特通过地址映射的方式重复暴露了32倍。你在位带区写一个32位字本质上是在操作原SRAM地址里的一位。这解释了为什么0x20000000的1MB对应0x22000000的32MB——因为1位变成了32位。实际项目中位带操作经常用于对某个IO寄存器置位清零但理解它需要先吃透RAM的地址映射逻辑。2.4 启动模式与存储器重映射RAM在启动时还有一段变身的戏码。STM32支持从不同存储器启动通过BOOT0和BOOT1引脚的电平组合选择。最常见的是从主FLASH启动BOOT0接低电平此时0x00000000地址被映射到主FLASH也可以从系统存储器启动BOOT0拉高BOOT1拉低进入出厂Bootloader还可以从内置SRAM启动BOOT0和BOOT1都拉高。从SRAM启动时0x00000000地址被重映射到SRAM的起始地址。存储器重映射的含义是CPU在复位后从0x00000000取第一条指令但0x00000000这个地址可以对应到不同的物理存储介质上。如果你把程序编译到SRAM地址并从中启动就可以在没有FLASH的调试场景下运行程序但一旦断电SRAM里的程序就消失了。这个机制也告诉我们在地址映射面前FLASH和RAM不是绝对的物理身份而是可以被伪装的角色。理解重映射对调试裸机程序和Bootloader都有帮助。3. 一上电RAM里就被分成了四块栈、堆、data段和bss段3.1 启动文件和链接脚本如何划分RAM程序烧录进FLASH后FLASH里存放的是代码、只读常量和初始值。但变量必须放在RAM中因为RAM是可写的。上电之后C运行环境初始化之前RAM里的内容是不确定的可能是上电随机值也可能是上一次运行的残留值所以启动代码要干的第一件事就是把RAM划分好并且把该搬的数据搬好、该清的数据清掉。这套分成几个区域的逻辑定义在启动文件和链接脚本里。以MDK环境下最常见的STM32F1启动文件startup_stm32f10x_hd.s为例开头会有下面这两行Stack_Size EQU 0x00000400 Heap_Size EQU 0x00000200Stack_Size是栈的大小我平时用的F1工程默认是1KB。Heap_Size是堆的大小默认512字节。这两个值直接决定了RAM分区的边界一旦栈设置过小程序运行时栈溢出表现往往是程序毫无规律地跑飞函数返回后变量被改写这类让人抓狂的问题。Cortex-M3内核上__initial_sp指向栈顶启动文件里设置好栈顶地址后Reset_Handler会依次调用SystemInit和__main。__main里完成三件事把FLASH里的.data段数据复制到RAM、把.bss段清零、设置堆栈然后才跳转到main()。如果这块RAM上的初始化顺序和布局出了问题你的全局变量初始值就可能不对或者数组里残留了随机垃圾数据。3.2 栈向下增长一个局部数组就能把它挤爆栈在RAM的布局中通常占据高地址区域它向下增长。也就是说栈顶在高地址每次压栈时栈指针SP减小。在启动文件里设置Stack_Size为1KB就意味着栈的可用范围是那个从高地址向下的1KB空间。如果你的函数里定义了一个char buffer[2048];那么当函数调用时一旦程序开始使用这个数组它会瞬间越过栈的边界进入其他数据区产生不可预知的内存踩踏。我在一个项目里遇到传感器数据错乱的问题查了三天最后用调试器看SP指针和变量地址才发现中断服务函数里的局部数组太大把主循环里的全局变量给覆盖了。从那以后我给自己定了一个规矩局部大数组一律不定义在栈里要么定义成static要么用malloc要么单独指定一个全局缓冲区。栈里只适合放小变量、函数调用帧和返回地址。Cortex-M内核还带一个栈溢出检测机制如果配置了MPU可以用MPU把栈底区域的访问权限设置成不可写一旦溢出就会触发HardFault。但在许多开发板上MPU默认没配置所以栈溢出常常无声无息地破坏数据。我的建议是在开发阶段把Stack_Size适当调大然后等程序稳定后再根据map文件里的最大栈使用量回调到合适值。3.3 data段和bss段从FLASH搬运与清零全局变量和静态变量被编译器分成了两个主要段.data和.bss。.data段存放的是有初始值的全局变量和静态变量。比如你在文件里写了一个int global_count 100;这个global_count的初始值100需要存放在FLASH里因为FLASH断电不丢失而它在RAM中也占了一个位置。启动代码负责把FLASH中的这段初始值逐字节复制到RAM的对应位置这个过程叫加载时复制。所以.data段在FLASH里占了一份空间存放初始值在RAM里也占了一份空间存放运行时的变量。.bss段存放的是没有初始值或者初始值为0的全局变量和静态变量。int big_array[1024];如果在全局作用域定义且没有显式初始化它就会被放进.bss段。启动代码只需要把这块RAM区域清零即可FLASH中不用为它存任何内容。这也是为什么在C语言里未初始化全局变量的默认值是0而不是随机值——因为启动代码帮你清了零。搞清楚.data和.bss的区别对你理解RAM占用有直接帮助。假设你定义了一个很大的查表数组但内容在运行时不变如果你不把它规划成const数组它就会被放进.data段既占用FLASH存初始值又占用RAM运行时副本。这是个典型的RAM浪费场景。3.4 堆STM32里malloc到底能不能用堆是从Heap_Size里切出来供malloc/free使用的动态内存池。PC上用malloc天经地义但在STM32里用malloc要谨慎。因为嵌入式环境的堆往往很小比如刚才说的默认512字节你随便分配一个稍微大点的结构体数组堆就满了malloc返回NULL而代码如果没有判空就会直接解引用空指针程序立刻崩溃。还有一个更隐蔽的问题堆的内存管理库比如newlib里的_sbrk实现本身是有开销的而且多次malloc/free会产生内存碎片。在长时间运行的嵌入式设备上碎片可能慢慢吞掉堆空间最终导致分配失败。我以前维护过一个设备运行一个月后偶发死机后来定位到是某处malloc失败后没检查返回值直接操作了野指针。所以在实时控制类的STM32项目中我建议尽量采用静态内存分配所有缓冲区在编译期就确定大小全局数组代替动态申请。如果你的程序确实需要动态内存可以用一个简单的固定大小块内存池按相同大小分配和释放这样可以规避碎片问题性能也更可控。实在要用标准库的malloc至少保证每次分配后都做判空处理并且把Heap_Size调到够用。4. 当编译报No space in execution regions或RAM不够用时我是怎么排查和优化的4.1 先从map文件里找出谁占了RAMKeil或IAR编译链接之后都会生成一个.map文件IAR是.mapKeil是htm/map这是定位RAM占用最核心的文档。很多人编译报错后只看错误提示不看map文件这是不对的。错误提示只告诉你空间不够但具体是谁占的空间、每部分占多少map文件里写得清清楚楚。在Keil的map文件里查看RAM占用主要看两部分Image component sizes列出每个编译单元.o文件的代码大小Code、只读数据大小RO Data、读写数据大小RW Data和零初始化数据大小ZI Data。Execution Region RW_IRAM1列出链接后的实际RAM区域分配显示每个变量、每块缓冲区的Name、Size和Address。比如你看到Image component sizes中某个.o文件的RW Data和ZI Data特别大那说明这个源文件的全局变量占了很多RAM。再点进去看到具体的Execution Region里的Symbol列表就能定位到是哪个变量。有一次我优化一个音频项目通过map文件发现一个fft_buf数组占了48KB而主SRAM才128KB一眼就知道问题所在。4.2 四个立竿见影的RAM优化手段找到RAM占用大户后根据不同的情况可选的优化手段有下面这几种我按优先级和你分享一下我的使用习惯。第一招把大常量数组改成const。在编译器的语法下const修饰的全局变量会被放进只读数据段RO Data它只占用FLASH不占用RAM。如果你的程序里有一张几KB的三角函数表、字模数组、滤波系数表并且运行时不会修改它们务必加上const。这往往是最简单也最有效的RAM释放方式。// 原来占用RAM uint16_t lookup_table[2048] {0x1234, 0x5678, /*...*/}; // 优化后只占用FLASH const uint16_t lookup_table[2048] {0x1234, 0x5678, /*...*/};第二招减少栈空间和堆空间。如果栈使用量没有你想象中那么大可以把Stack_Size从2KB调回1KBHeap_Size如果不是必要直接设成0都不影响。启动文件里Heap_Size设为0可以防止误用malloc同时也省下一块RAM。不过调整前务必确认没有函数递归调用和大的局部数据结构。第三招利用编译器的优化等级。Keil的-O3优化可能将一些局部变量优化到寄存器中减少栈和RAM的使用。不过优化等级提高会带来调试困难需要结合实际情况权衡。通常CPU的浮点运算、循环展开等场景优化等级影响最大而对于RAM占用优化等级能帮的忙有限只能作为辅助手段。第四招重新设计数据结构。这是最有技术含量的一种方式。例如把int32_t的数组改成int16_t甚至按位存储用位域压缩状态标志位。一个传感器状态结构体如果用8个uint8_t的字段来存标志位总共占8字节改用位域后1个字节就够了。在RAM极度紧张的项目里位域、联合体、枚举类型都是好用的抠内存工具。不过要注意代码可读性和可维护性建议在关键位置加注释。4.3 外扩SRAM的正确姿势FSMC/FMC接线与配置当片内RAM实在不够用比如你要做GUI缓冲、音视频处理可以考虑外扩SRAM。STM32F1系列通过FSMC灵活的静态存储器控制器接口外扩F4及以上的FMC接口则更强大除了SRAM还能接SDRAM、NOR Flash等。外扩SRAM芯片常见的是IS62WV51216512KB16位宽度这类并行SRAM。接线时地址线A0~A18连接FSMC_A0~A18数据线D0~D15连接FSMC_D0~D15控制信号线有片选NE1、读使能NOE、写使能NWE、字节掩码NBL0/NBL1如果需要8位/16位混合访问。配置FSMC的关键是时序参数。你可以在标准库或HAL库的BSP里找到类似这样的配置SRAM_HandleTypeDef hsram; FSMC_NORSRAM_TimingTypeDef timing; timing.AddressSetupTime 1; timing.AddressHoldTime 1; timing.DataSetupTime 4; timing.BusTurnAroundDuration 0; timing.CLKDivision 1; timing.DataLatency 1; timing.AccessMode FSMC_ACCESS_MODE_A; hsram.Instance FSMC_NORSRAM_DEVICE; hsram.Init.NSBank FSMC_NORSRAM_BANK1; hsram.Init.DataAddressMux FSMC_DATA_ADDRESS_MUX_DISABLE; hsram.Init.MemoryType FSMC_MEMORY_TYPE_SRAM; hsram.Init.MemoryDataWidth FSMC_NORSRAM_MEM_BUS_WIDTH_16; hsram.Init.BurstAccessMode FSMC_BURST_ACCESS_MODE_DISABLE; hsram.Init.WaitSignalPolarity FSMC_WAIT_SIGNAL_POLARITY_LOW; hsram.Init.WrapMode FSMC_WRAP_MODE_DISABLE; hsram.Init.WaitSignalActive FSMC_WAIT_TIMING_BEFORE_RS; hsram.Init.WriteOperation FSMC_WRITE_OPERATION_ENABLE; hsram.Init.WaitSignal FSMC_WAIT_SIGNAL_DISABLE; hsram.Init.ExtendedMode FSMC_EXTENDED_MODE_DISABLE; hsram.Init.AsynchronousWait FSMC_ASYNCHRONOUS_WAIT_DISABLE; hsram.Init.WriteBurst FSMC_WRITE_BURST_DISABLE;配置完成后FSMC会把SRAM映射到地址0x60000000BANK1开始的区域你可以直接把一个指针指向那个地址把它当成一个普通的大数组来用uint16_t *external_sram (uint16_t *)0x60000000;这样操作外扩SRAM就和操作片内数组一样简单了。但要注意访问速度相对片内SRAM慢不少时序参数设得保守的话更明显需要评估实时性是否受影响。4.4 把变量固定到指定RAM区域除了外扩SRAMFlash较小但RAM紧张的型号还可以利用片内不同RAM块。以前面提到的F4的CCM RAM为例在MDK中可以通过链接脚本把指定的段放到CCM RAM区域。在分散加载文件.sct中增加一个执行域RW_CCMRAM 0x10000000 0x10000 { *.o (.ccmram) }在源文件里声明变量时用__attribute__指定它uint8_t fast_buf[256] __attribute__((section(.ccmram)));这样fast_buf就会被分配到CCM RAM的首地址0x10000000附近。使用CCM RAM的前提是数据不需要DMA访问且CPU访问频率较高适合放中断栈、热数据、临时运算缓冲。不过不同厂商编译器语法略有差异跨IDE移植时注意适配。还有一个常见的坑如果分散加载文件的RAM区设置不当链接器可能把栈或堆也分配到CCM RAM里而一旦某段代码通过DMA访问栈就会莫名其妙地失败。我在项目里习惯明确划分CCM RAM只放显式标记的段其他默认变量全部放在主SRAM。5. STM32开发者必须建立的KB级内存观——和PC编程的几个关键思维转变5.1 没有MMU所有地址都是物理地址PC上的程序为什么能随便定义大数组因为操作系统给每个进程提供了独立的虚拟地址空间你申请1GB的堆空间实际上可能只有一小部分被映射到物理内存剩余部分是硬盘上的页面文件在撑腰。STM32没有MMU没有虚拟内存机制CPU访问的每一个地址都是真实的物理地址RAM就那么大你用多少就是多少没有任何操作系统帮你假装没看到。这意味着你写STM32代码时必须时刻清楚每个变量放哪里、占多大。PC程序里一个疏忽的全局变量可能只是浪费几百MB虚拟内存无伤大雅MCU上多定义一个4KB的数组直接可能导致链接失败或运行时溢出。从另一个角度讲没有MMU也带来了好处你可以精确控制每比特内存不存在缓存一致性问题有些带Cache的高性能MCU另说没有页错误没有上下文切换的内存开销。对于裸机程序来说内存的使用是可预测、可审计的这在工业控制中至关重要。5.2 动态内存分配在高实时性场景下的风险PC上malloc失败的概率极低有虚拟内存兜底有操作系统的堆管理。STM32上不行内存碎片一旦产生即使总剩余空间足够也无法分配出连续的大块内存。高实时性场景还要求中断服务函数执行时间可预测而malloc和free的执行时间是不固定的它可能要遍历空闲链表、合并碎片这会让中断延迟变得不可控。我参与的一个电机控制项目最初主循环里用了malloc创建队列节点低负载时一切正常换到高负载时偶发控制周期超时。后来把队列改成固定数组环形缓冲彻底消除了不确定性。这是典型的DMA缓冲区、中断数据缓存、控制循环上下文必须静态分配的场景。对于帧长不固定的通讯协议解析可以用双缓冲加链表池但链表池本身在初始化时就把所有节点固定分配好运行时不申请不释放。5.3 用结构体、位域和联合体抠RAM的土办法最后分享几个我自己常用的土办法对RAM少几个字节都很敏感的项目特别有用。办法一用枚举和位域减少状态存储。如果一组标志位不超过8个用一个uint8_t加宏定义即可如果超过8个但不超过16个用uint16_t。不要写8行uint8_t flag_xxx。结构体里可以用位域精确控制每个字段的位数typedef struct { uint8_t state : 3; // 0~7 uint8_t enabled : 1; uint8_t mode : 2; uint8_t rfu : 2; // 预留 } status_flags_t;这个结构体只占1字节RAM而用原始字段可能要占3~4字节。办法二用联合体重用互斥使用的缓冲区。如果你的两个功能模块不会同时运行或者它们的大缓冲可以共享可以用联合体让它们占同一块RAM。比如一个解析协议的工作缓冲和一个计算FFT的临时数组不会同时存在就可以共享一块内存。用联合体改完之后内存立刻省下一大块而且没有性能损失。union { uint8_t protocol_buf[1024]; complex_t fft_buf[512]; } shared_buf;办法三压缩时间戳和计数器。很多场景下uint32_t的数据其实可以用uint16_t甚至uint8_t来存只要确认数值范围。比如采样计数的累计值若不会超过30000就用uint16_t瞬间省一半。不过抠RAM要讲究平衡牺牲可读性来抠字节是不可取的。我的经验是先在项目开始时按合理的预估规划好RAM分配表再在编译文件里确认每个模块的对象占用最后才针对异常大的对象做精细优化。别把时间浪费在省那几个字节上项目的稳定性和可维护性始终是第一位的。