4、内存布局核心概念：栈、堆、静态数据、模型权重、激活缓冲区的分配策略

在STM32H7上部署TinyML模型，内存布局的合理性直接决定了推理能否成功、实时性是否达标以及系统是否稳定。STM32H7系列（如H743、H750、H723等）通常内置1MB~2MB的RAM，分为DTCM（数据紧耦合内存）、AXI SRAM（主系统SRAM，通常512KB~1MB）、SRAM1/2/3（各128KB~512KB不等）以及备份SRAM。这些物理上分散的SRAM块，加上Cortex-M7内核的Cache机制，使得内存布局远比普通MCU复杂。本章将围绕栈（Stack）、堆（Heap）、静态数据（Static Data）、模型权重（Model Weights）和激活缓冲区（Activation Buffer）这五类核心内存对象，系统讲解其分配策略、约束条件与工程实践。

上图展示了STM32H7双区SRAM（DTCM与AXI SRAM）的典型内存布局。DTCM直接连接到Cortex-M7内核，零等待访问，适合放置栈和实时性要求最高的数据；AXI SRAM通过AXI总线连接，容量大且支持DMA，适合放置模型权重和激活缓冲区。SRAM1/2/3则作为通用扩展区域，用于非实时数据或备份。下面我们将逐一剖析每类内存对象的分配策略。

4.1 栈（Stack）的分配策略

核心原理

栈是函数调用、局部变量、中断现场保存的临时存储区。在Cortex-M7上，栈指针（SP）指向DTCM时，访问延迟为0周期，这是栈分配的首选位置。STM32H7的DTCM容量为128KB，但实际可用栈空间需要扣除启动代码、RTOS内核（如果使用）以及中断服务程序（ISR）的占用。栈的生长方向是向低地址增长，因此栈顶（初始SP值）应设置在DTCM的最高地址。

判断方法与操作流程

• 栈大小估算：使用静态分析工具（如GCC的 -fstack-usage）或动态监测（在栈底填充特定模式，运行时检查水位）。对于TinyML推理，建议栈大小不低于8KB，若使用RTOS，每个任务栈至少2KB。
• 放置位置：在链接脚本（.ld文件）中，将栈段（.stack）显式分配到DTCM区域。例如：

  _estack = ORIGIN(DTCM) + LENGTH(DTCM);
  /* 栈顶指向DTCM末尾 */
  .stack (NOLOAD) : {
    . = ALIGN(8);
    _sstack = .;
    . = . + 16K;  /* 预留16KB栈空间 */
    _estack = .;
  } > DTCM

• 中断栈：在裸机或RTOS中，主栈（MSP）用于中断和异常处理，任务栈（PSP）用于线程模式。建议将MSP放在DTCM，PSP放在AXI SRAM（若任务较多）。

案例拆解：栈溢出导致的推理异常

某工业视觉项目使用STM32H743，部署MobileNetV1模型（输入224×224×3）。初始配置将栈放在AXI SRAM，推理时频繁进入HardFault。通过调试器观察，发现栈指针在推理过程中下探到AXI SRAM的未初始化区域，覆盖了模型权重。分析原因：MobileNetV1的中间计算涉及大量局部数组，栈需求超过12KB，而AXI SRAM的Cache延迟导致栈访问变慢，同时栈与权重区域相邻。解决措施：将栈移至DTCM，预留16KB，并在链接脚本中设置栈保护区（MPU）。修改后，HardFault消失，推理时间从85ms降至62ms（栈访问零等待带来的收益）。

常见误区与复盘

• 误区1：所有栈都放DTCM。若RTOS任务数超过8个，每个任务栈2KB，DTCM将耗尽。此时应将低频任务栈放AXI SRAM。
• 误区2：忽略中断嵌套。Cortex-M7支持中断嵌套，每层嵌套需额外栈空间。建议在中断服务函数中避免大型局部变量。
• 复盘：栈分配应遵循“实时关键放DTCM，批量任务放AXI”的原则，并定期检查栈水位。

4.2 堆（Heap）与动态内存管理

核心原理

堆用于运行时动态分配内存（如malloc/new）。在TinyML场景中，堆的使用应尽量克制，因为动态分配会导致碎片化，且分配时间不确定。STM32H7的堆通常放置在AXI SRAM或SRAM1/2/3中。若使用CMSIS-RTOS2，堆由RTOS内核管理；裸机环境下，可使用newlib的malloc或第三方内存池（如FreeRTOS的heap_4）。

判断方法与操作流程

• 堆大小设定：根据模型推理的临时对象需求估算。例如，TensorFlow Lite Micro（TFLM）的MicroAllocator需要预分配arena（竞技场），建议将arena放在堆中或静态分配。
• 分配策略：优先使用静态分配（编译时确定），避免运行时malloc。若必须使用堆，采用固定大小块的内存池，减少碎片。
• 放置位置：堆放在AXI SRAM的末尾区域，与模型权重分开，防止堆增长覆盖权重。链接脚本示例：

  .heap (NOLOAD) : {
    . = ALIGN(8);
    _sheap = .;
    . = . + 32K;  /* 32KB堆 */
    _eheap = .;
  } > AXI_SRAM

案例拆解：TFLM的Arena分配

在STM32H750上部署语音唤醒词模型（DS-CNN），TFLM需要约40KB的arena用于张量存储和中间结果。初始方案使用malloc动态分配arena，导致推理延迟波动（最大抖动达15ms）。改为静态分配：在AXI SRAM中定义全局数组alignas(16) uint8_t tensor_arena[40KB]，并传递给TFLM的Interpreter。结果：推理延迟稳定在28ms±0.5ms，且内存占用可预测。

常见误区与复盘

• 误区1：堆大小设置过大，挤占模型权重空间。应通过链接脚本的MAP文件检查堆实际使用率。
• 误区2：在中断中调用malloc。中断上下文可能无法获取锁，导致死锁。中断中应使用专用内存池。
• 复盘：堆分配应遵循“静态优先、池化次之、malloc最后”的原则。

4.3 静态数据与全局变量的布局

核心原理

静态数据包括全局变量、常量（const）、以及RTOS内核对象（任务控制块、信号量等）。这些数据在编译时确定地址，生命周期贯穿整个程序。在STM32H7上，静态数据应分为两类：只读数据（如查表、模型元信息）可放在Flash（通过LMA/VMA机制），可读写数据（如全局状态、RTOS对象）放在DTCM或AXI SRAM。

判断方法与操作流程

• 分类放置：在链接脚本中，将.data段（已初始化全局变量）和.bss段（未初始化全局变量）分配到DTCM或AXI SRAM。例如：

  .bss (NOLOAD) : {
    . = ALIGN(8);
    _sbss = .;
    *(.bss*)
    *(COMMON)
    _ebss = .;
  } > DTCM

• 常量优化：使用const修饰的数组（如正弦表）应放在Flash，通过__attribute__((section(".rodata")))指定。
• 对齐要求：Cortex-M7支持双精度浮点，8字节对齐可提升访问效率。使用ALIGN(8)确保。

案例拆解：全局缓冲区冲突

某电机控制项目在DTCM中放置了32KB的全局数据缓冲区，同时栈也分配在DTCM。当栈增长时，覆盖了缓冲区，导致电机控制参数突变。通过MPU配置，将DTCM划分为两个区域：栈区（16KB，可读写不可执行）和数据区（112KB，可读写）。设置MPU的Region 0为栈区，Region 1为数据区，并启用溢出检测。修改后，栈溢出时触发MemManage Fault，问题被及时捕获。

常见误区与复盘

• 误区1：所有全局变量都放DTCM。若全局数据超过64KB，应转移部分到AXI SRAM。
• 误区2：忽略.data段的初始化时间。上电时从Flash拷贝到RAM，若数据量大（>100KB），会延迟启动。可考虑使用__attribute__((zero_init))减少拷贝。
• 复盘：静态数据布局应遵循“高频访问放DTCM，低频大块放AXI”的原则。

4.4 模型权重的分配策略

核心原理

模型权重是TinyML中最占内存的对象。以MobileNetV1为例，float32权重约4.2MB，int8量化后约1.1MB。STM32H7的AXI SRAM（512KB）无法容纳大模型，因此需要将权重存储在外部Flash（如QSPI NOR Flash），推理时按需加载到RAM。若模型小于512KB，可直接放在AXI SRAM，利用Cache加速访问。

判断方法与操作流程

• 模型大小评估：使用模型转换工具（如STM32Cube.AI或TFLM）生成C数组或二进制文件，查看weights.h的大小。
• 放置策略：
  • 模型 ≤ 512KB：直接放在AXI SRAM，声明为const uint8_t model_data[]，链接到AXI SRAM。
  • 模型 > 512KB：放在外部QSPI Flash（内存映射模式），通过XIP（Execute in Place）访问，或按层加载到AXI SRAM。
• 对齐与Cache：权重数组按32字节对齐（Cache line大小），启用AXI SRAM的Cache（SCB_EnableDCache），可显著提升推理速度。

案例拆解：QSPI Flash中的大模型

部署YOLOv5s（int8量化，约1.8MB）在STM32H743上。AXI SRAM仅512KB，无法容纳。采用方案：将权重存储在外部QSPI Flash（W25Q128，16MB），使用内存映射模式（XIP）。推理时，TFLM通过DMA将当前层的权重从QSPI加载到AXI SRAM的临时缓冲区（128KB）。实测推理速度：单次前向传播约320ms，其中权重加载占40%。优化：使用双缓冲（ping-pong）预取下一层权重，将加载时间隐藏，推理降至210ms。

常见误区与复盘

• 误区1：将大模型直接放在AXI SRAM，导致编译失败或运行时溢出。应使用objcopy生成二进制文件，通过文件系统加载。
• 误区2：忽略权重对齐。未对齐的权重会导致Cache miss率上升，推理时间增加20%以上。
• 复盘：模型权重分配应遵循“小模型RAM直放，大模型Flash映射+按需加载”的原则。

4.5 激活缓冲区（Activation Buffer）的分配

核心原理

激活缓冲区存储神经网络中间层的输出（特征图）。其大小取决于模型结构：输入分辨率、通道数、层数。例如，MobileNetV1的激活缓冲区约2.5MB（float32），int8量化后约0.6MB。激活缓冲区是推理过程中动态变化的，通常使用静态分配的全局数组（arena）或堆内存。

判断方法与操作流程

• 大小估算：使用TFLM的MicroAllocator计算所需arena大小。在PC上运行tflite::MicroInterpreter，打印arena_size。
• 放置位置：激活缓冲区应放在AXI SRAM，并启用Cache。若AXI SRAM不足，可放在SRAM1/2/3（但访问速度稍慢）。
• 双缓冲优化：对于流水线推理（如摄像头连续帧），使用双缓冲（两个激活缓冲区交替），可提高吞吐量。

案例拆解：激活缓冲区与DMA冲突

某缺陷检测系统使用STM32H750，模型为ResNet-18（int8），激活缓冲区需求约300KB。初始将缓冲区放在AXI SRAM，同时DMA用于摄像头数据传输（目标地址也在AXI SRAM）。推理时，DMA写入摄像头数据，覆盖了激活缓冲区，导致推理结果错误。解决：将DMA目标地址改为SRAM1（128KB），激活缓冲区独占AXI SRAM的300KB区域。修改后，推理准确率恢复至98.5%。

常见误区与复盘

• 误区1：激活缓冲区使用动态分配。每次推理malloc/free，导致碎片和延迟抖动。
• 误区2：忽略Cache一致性。若DMA写入激活缓冲区，需先执行SCB_CleanDCache再读取。
• 复盘：激活缓冲区应静态分配，并确保与DMA区域物理隔离。

4.6 综合分配策略与工程实践

核心原理

综合以上五类内存对象，STM32H7双区SRAM的分配策略可总结为：实时关键数据放DTCM，大容量数据放AXI SRAM，非实时数据放SRAM1/2/3。同时，利用MPU进行区域保护，利用Cache提升访问速度。

判断方法与操作流程

内存对象	推荐区域	大小建议	Cache策略	MPU保护
栈（主栈+任务栈）	DTCM	8~32KB	无需（零等待）	设置溢出检测
堆	AXI SRAM	16~64KB	写回（Write-back）	可读写，不可执行
静态数据	DTCM + AXI SRAM	按需	高频访问放DTCM	区域隔离
模型权重	AXI SRAM 或 QSPI Flash	≤512KB（RAM）	写回，32字节对齐	只读保护
激活缓冲区	AXI SRAM	100~600KB	写回，双缓冲	与DMA隔离

案例拆解：完整内存布局示例

以STM32H743（2MB Flash，1MB RAM）部署关键词识别模型（KWS，int8，权重200KB，激活缓冲区80KB）为例：

1. DTCM（128KB）：栈16KB，RTOS内核对象8KB，高频全局变量4KB，剩余100KB留空。
2. AXI SRAM（512KB）：模型权重200KB（32字节对齐），激活缓冲区80KB（双缓冲各40KB），堆32KB，DMA缓冲区64KB，剩余136KB留空。
3. SRAM1（128KB）：日志缓冲区32KB，非实时数据64KB，剩余32KB。
4. MPU配置：Region 0（DTCM）可读写，Region 1（AXI SRAM）可读写，Region 2（QSPI Flash）只读。

实测推理延迟：35ms（单帧），内存峰值使用率：DTCM 28%，AXI SRAM 73%。

常见误区与复盘

• 误区1：所有内存都放在AXI SRAM，忽略DTCM的零等待优势。应优先将栈和实时数据放入DTCM。
• 误区2：未启用Cache。AXI SRAM的Cache可提升2~3倍推理速度，但需注意DMA一致性。
• 误区3：MPU配置过于复杂。建议从3~4个区域开始，逐步细化。
• 复盘：内存布局的最终目标是“无碎片、无冲突、无溢出”，通过工具链和运行时监测持续验证。