链接脚本基础：链接脚本的作用、基本语法与常见MCU示例

在TFLite Micro的部署过程中，模型权重、算子内核、激活缓冲区（arena）最终都要落到MCU的Flash和RAM中。而决定这些数据如何排布、对齐、定位的“总指挥”，正是链接脚本（Linker Script）。对于嵌入式开发者而言，链接脚本往往是最容易被忽视却又最致命的一环——它不像C代码那样有直观的逻辑，却直接决定了程序能否启动、arena能否对齐、内存是否溢出。本章将系统讲解链接脚本的核心作用、三大基本语法（MEMORY、SECTIONS、ENTRY），并通过一个典型的ARM Cortex-M4 MCU链接脚本示例，为后续定位arena段位打下坚实基础。

上图展示了链接脚本在整个编译-链接-部署流程中的核心地位。链接器读取目标文件、库文件和链接脚本，经过符号解析与重定位后，生成包含完整内存布局信息的可执行文件。最终，MCU的Flash和RAM被划分为不同的段（Section），而TFLite Micro的arena段正是这些段中的一个特殊存在。理解这张图，就理解了链接脚本的全局意义。

3.1 链接脚本的核心作用：从“编译产物”到“可运行镜像”的桥梁

编译器的输出是若干目标文件（.o），每个目标文件内部包含代码段（.text）、只读数据段（.rodata）、已初始化数据段（.data）、未初始化数据段（.bss）等。但这些段只有相对地址，没有绝对地址。链接脚本的作用，就是将这些“漂浮”的段，按照目标MCU的内存布局，安放到具体的物理地址上。

判断一个链接脚本是否“健康”，可以从三个维度入手：第一，查看生成的.map文件，确认每个段的起始地址和大小是否符合预期；第二，检查Flash和RAM的占用率，确保没有溢出；第三，验证关键符号的对齐属性，例如arena的起始地址是否满足TFLite Micro要求的对齐条件（通常为8字节或16字节）。

链接脚本功能	对应命令/语法	对TFLite Micro的影响
定义内存区域	MEMORY	决定arena可用的RAM范围
段放置规则	SECTIONS	决定arena段在RAM中的具体位置
程序入口	ENTRY	决定启动后第一条指令位置
符号导出	PROVIDE / EXTERN	暴露arena起始地址给C代码
对齐控制	ALIGN / SUBALIGN	确保arena满足对齐要求

3.2 基本语法详解：MEMORY、SECTIONS、ENTRY

链接脚本的语法虽然简洁，但每个关键字都有严格的语义。下面逐一拆解最核心的三个命令。

3.2.1 MEMORY：定义目标芯片的内存资源

MEMORY命令用于描述目标MCU的物理内存布局。它定义了每个内存区域的名称、属性、起始地址和大小。常见的属性包括：r（只读）、w（可写）、x（可执行）、a（可分配）。对于MCU而言，Flash通常标记为rx，RAM标记为rw。

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

这段定义表明：Flash从0x08000000开始，共1MB；RAM从0x20000000开始，共128KB。链接器会严格按照这个范围分配地址，如果段的总大小超过LENGTH，链接就会报错。在实际项目中，如果TFLite Micro的arena需要64KB，而RAM只有128KB，那么必须仔细规划其他段的大小，否则链接失败。

3.2.2 SECTIONS：控制段的放置与对齐

SECTIONS是链接脚本的核心，它定义了输出文件中的每个段如何由输入段组成，以及这些段在内存中的排列顺序。每个段可以指定加载地址（LMA）和运行地址（VMA）。对于MCU而言，通常LMA在Flash，VMA在RAM，启动代码负责将.data段从Flash拷贝到RAM。

SECTIONS
{
  .text :
  {
    *(.text*)
    *(.rodata*)
  } > FLASH

  .data :
  {
    _sdata = .;
    *(.data*)
    _edata = .;
  } > RAM AT> FLASH

  .bss :
  {
    _sbss = .;
    *(.bss*)
    *(COMMON)
    _ebss = .;
  } > RAM

  .arena (NOLOAD) :
  {
    . = ALIGN(8);
    _arena_start = .;
    . = . + 64K;
    _arena_end = .;
  } > RAM
}

这段脚本中，.arena段被显式定义在RAM中，起始地址按8字节对齐，大小为64KB。注意NOLOAD关键字——它告诉链接器这个段不需要在Flash中占用空间，也不需要启动代码初始化，因为arena的内容完全由TFLite Micro运行时管理。这种设计避免了在Flash中为arena预留空间，节省了宝贵的存储资源。

3.2.3 ENTRY：指定程序入口点

ENTRY命令定义了程序的第一条可执行指令的地址。对于ARM Cortex-M系列MCU，入口点通常是复位向量Reset_Handler。如果未指定ENTRY，链接器会尝试使用start符号，但MCU开发中必须显式指定。

ENTRY(Reset_Handler)

在启动文件中，Reset_Handler负责初始化栈指针、拷贝.data段、清零.bss段，然后调用main函数。如果ENTRY设置错误，程序可能从错误的地址开始执行，导致立即HardFault。

3.3 常见MCU链接脚本示例：以STM32F4 + TFLite Micro为例

下面给出一个完整的、可直接用于STM32F4系列（Cortex-M4）的链接脚本示例，并标注了与TFLite Micro相关的关键部分。该脚本假设MCU为STM32F407VG（Flash 1MB，RAM 128KB），TFLite Micro模型需要64KB的arena。

/* STM32F407VG 链接脚本 - 适配TFLite Micro */
ENTRY(Reset_Handler)

MEMORY
{
  FLASH (rx)  : ORIGIN = 0x08000000, LENGTH = 1024K
  RAM   (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

_estack = ORIGIN(RAM) + LENGTH(RAM);  /* 栈顶指向RAM末尾 */

SECTIONS
{
  .isr_vector :
  {
    . = ALIGN(4);
    KEEP(*(.isr_vector))
    . = ALIGN(4);
  } > FLASH

  .text :
  {
    . = ALIGN(4);
    *(.text*)
    *(.rodata*)
    . = ALIGN(4);
    _etext = .;
  } > FLASH

  .data :
  {
    . = ALIGN(4);
    _sdata = .;
    *(.data*)
    . = ALIGN(4);
    _edata = .;
  } > RAM AT> FLASH

  .bss :
  {
    . = ALIGN(4);
    _sbss = .;
    *(.bss*)
    *(COMMON)
    . = ALIGN(4);
    _ebss = .;
  } > RAM

  /* TFLite Micro arena 段 - 8字节对齐，64KB */
  .arena (NOLOAD) :
  {
    . = ALIGN(8);
    _arena_start = .;
    . = . + 64K;
    . = ALIGN(8);
    _arena_end = .;
  } > RAM

  /* 堆区域（可选） */
  .heap (NOLOAD) :
  {
    . = ALIGN(8);
    _heap_start = .;
    . = . + 8K;
    _heap_end = .;
  } > RAM
}

在这个脚本中，_arena_start和_arena_end符号会被导出，TFLite Micro的C代码可以通过extern声明来获取arena的地址和大小。例如，在main.c中：

extern uint8_t _arena_start;
extern uint8_t _arena_end;

uint8_t* tensor_arena = &_arena_start;
size_t arena_size = &_arena_end - &_arena_start;

这种做法的好处是：arena的大小和位置完全由链接脚本控制，修改模型时只需调整链接脚本中的64K数值，无需修改C代码。同时，由于arena被声明为NOLOAD，它不会占用Flash空间，也不会被启动代码清零，避免了不必要的初始化开销。

3.4 案例拆解：一次arena溢出导致的HardFault排查

某智能家居项目使用STM32F411（RAM 128KB）部署TFLite Micro，模型为语音唤醒词检测。开发者在链接脚本中将arena设置为48KB，但实际模型推理时，系统频繁进入HardFault。初始现象是：程序启动正常，但第一次调用tflite::MicroInterpreter::Invoke()时崩溃。

关键输入数据：模型文件大小为35KB，算子内核占用Flash约120KB，.data段约4KB，.bss段约20KB。RAM总容量128KB，其中栈预留2KB，堆预留4KB，arena设置为48KB。初步计算：4KB（data）+ 20KB（bss）+ 2KB（栈）+ 4KB（堆）+ 48KB（arena）= 78KB，远小于128KB，理论上应该足够。

分析判断过程：使用arm-none-eabi-nm工具查看生成的.elf文件，发现_arena_start地址为0x20005000，_arena_end地址为0x20011000。而RAM的末尾地址为0x20020000。看起来arena没有超出RAM范围。但进一步检查发现，_estack（栈顶）被设置为0x20020000，栈向下增长。当TFLite Micro在推理过程中使用大量栈空间（例如递归调用或大型局部变量）时，栈指针可能下探到arena区域，覆盖了arena中的数据，导致推理结果错误或HardFault。

实际操作步骤：（1）在链接脚本中将栈大小从2KB增加到8KB，并显式定义栈段；（2）将arena大小从48KB缩减到40KB；（3）在启动代码中增加栈填充模式（0xCC），以便在调试时检测栈溢出。修改后重新编译，HardFault消失，模型推理正常。

结果对比：修改前，arena和栈共享RAM空间，存在重叠风险；修改后，栈有独立区域，arena大小虽然减小，但通过优化模型输入（将音频帧从640ms缩短到480ms），推理精度损失小于1%，满足产品需求。

复盘经验：链接脚本中的内存分配不能只看“总和是否小于RAM”，还要考虑栈的增长方向、堆的动态分配、以及TFLite Micro内部临时缓冲区的需求。建议在链接脚本中为栈和堆预留足够空间，并使用NOLOAD段将arena与栈、堆隔离。

3.5 常见误区与总结复盘

在编写和调试链接脚本时，开发者常犯以下错误：

• 误区一：忽略对齐要求。TFLite Micro的arena需要至少8字节对齐，某些加速指令（如SIMD）甚至需要16字节对齐。如果链接脚本中未使用ALIGN(8)，arena起始地址可能落在非对齐边界，导致总线错误。
• 误区二：将arena放在.bss段内。虽然.bss段也是未初始化数据，但启动代码会将其清零。如果arena被包含在.bss中，每次启动都会清零arena，导致模型权重被破坏（如果权重存储在arena中）。正确做法是使用独立的NOLOAD段。
• 误区三：忘记导出符号。如果C代码中无法访问_arena_start，通常是因为链接脚本中未使用PROVIDE或未在C文件中正确声明extern。确保符号名称完全一致，且链接脚本中的符号定义在SECTIONS内部。
• 误区四：LMA与VMA混淆。对于.data段，LMA在Flash，VMA在RAM。如果误将.data段的LMA也放在RAM，启动代码将无法从Flash拷贝初值，导致全局变量初始值错误。

检查项	命令/方法	预期结果
查看段布局	arm-none-eabi-objdump -h firmware.elf	每个段的VMA、LMA、大小清晰可见
检查符号地址	arm-none-eabi-nm firmware.elf | grep arena	_arena_start和_arena_end地址符合预期
验证对齐	arm-none-eabi-readelf -s firmware.elf	arena符号的Value为8的倍数
检查内存占用	查看.map文件末尾的Memory Configuration	Flash和RAM占用率均小于100%

总结而言，链接脚本是嵌入式系统中连接软件与硬件的关键纽带。对于TFLite Micro开发者，掌握MEMORY、SECTIONS、ENTRY三大语法，理解LMA与VMA的区别，并学会为arena段设置独立、对齐、NOLOAD的段定义，是确保模型稳定运行的前提。在下一阶段，我们将深入探讨如何利用链接脚本精确控制arena的起始地址，以及如何通过修改链接脚本实现多模型共存的内存复用策略。