4、内存映射与链接脚本：Flash与RAM分区规划、链接脚本（.lsl/.ld）编写、段定义与地址绑定
好，咱们今天聊点硬核的——内存映射和链接脚本。
说实话，很多刚入行的工程师觉得这玩意儿是编译器的活，跟自己没关系。但我在项目里吃过亏，才明白这块要是搞不清楚，后面调试起来真要命。你想想看，Bootloader跑飞了，连个打印信息都看不到，你都不知道是代码放错了地方，还是数据被覆盖了。
4.1 为什么内存分区这么重要？
先问个问题：Bootloader和应用程序，能不能放在同一个Flash区域？
答案当然是不能。但为什么？
我举个例子。有一次，我负责的一个项目，Bootloader和APP共用一个Flash扇区。结果OTA升级到一半，突然断电了。再上电，Bootloader自己也被擦掉了——因为擦除扇区的时候，把Bootloader的代码也一起干掉了。嗯，这就是典型的「自杀式升级」。
所以，内存分区的核心目的就两个：
- 隔离：Bootloader和APP互不干扰
- 保护：关键数据不能被意外擦写
核心原则：Bootloader必须放在一个独立的、受保护的Flash区域。这个区域，APP永远不能碰。
4.2 Flash分区规划实战
以我常用的Infineon TC3xx系列为例，Flash通常这样划分：
| 区域 | 起始地址 | 大小 | 内容 |
|---|---|---|---|
| Bootloader | 0x80000000 | 128KB | 启动代码、诊断服务、Flash驱动 |
| 参数区 | 0x80020000 | 16KB | 校准参数、配置信息 |
| APP区域 | 0x80024000 | 1MB | 应用程序代码 |
| 备份区 | 0x80124000 | 1MB | OTA升级时的备份 |
这里有个细节：参数区我习惯放在Bootloader后面。为什么？因为参数区需要频繁擦写，而Bootloader几乎不动。如果参数区放在APP区域，每次升级APP，参数也得跟着搬，麻烦得很。
我的习惯：参数区单独划一个扇区，并且加上写保护。只有Bootloader通过UDS 0x2E服务才能修改。这样APP就算跑飞了，也改不了关键参数。
4.3 RAM分区规划
RAM分区很多人容易忽略。但我要说，RAM分区比Flash分区更容易出问题。
为什么？因为Bootloader和APP共用RAM。如果Bootloader退出前没把RAM清理干净，APP启动时读到脏数据，那画面太美我不敢看。
我一般这样划分RAM：
- Bootloader专用区：存放Bootloader的堆栈、全局变量。APP不能碰。
- 共享数据区：存放复位原因、升级标志等。Bootloader和APP通过这里通信。
- APP专用区：APP的堆栈和变量。Bootloader退出前必须释放。
注意：Bootloader跳转到APP之前，一定要把Bootloader用到的中断向量表、堆栈指针恢复成默认值。否则APP一开中断，直接跑飞到Bootloader的ISR里，那就乱套了。
4.4 链接脚本编写——以GCC .ld为例
好了，分区规划好了，怎么告诉编译器？靠链接脚本。
链接脚本说白了就是一张地图。告诉编译器：代码放哪，数据放哪，堆栈放哪。
我以GCC的.ld文件为例，给你看一个典型的Bootloader链接脚本：
/* Bootloader链接脚本示例 */
MEMORY
{
/* Flash区域 */
FLASH_BOOT (rx) : ORIGIN = 0x80000000, LENGTH = 128K
FLASH_PARAM (rw) : ORIGIN = 0x80020000, LENGTH = 16K
FLASH_APP (rx) : ORIGIN = 0x80024000, LENGTH = 1M
/* RAM区域 */
RAM_BOOT (rw) : ORIGIN = 0x60000000, LENGTH = 64K
RAM_SHARED (rw) : ORIGIN = 0x60010000, LENGTH = 4K
RAM_APP (rw) : ORIGIN = 0x60011000, LENGTH = 512K
}
SECTIONS
{
/* Bootloader代码段 */
.text :
{
*(.text*)
*(.rodata*)
} > FLASH_BOOT
/* Bootloader数据段 */
.data :
{
*(.data*)
} > RAM_BOOT AT > FLASH_BOOT
/* Bootloader BSS段 */
.bss :
{
*(.bss*)
} > RAM_BOOT
/* 共享数据段 */
.shared_data :
{
*(.shared*)
} > RAM_SHARED AT > FLASH_PARAM
}
这里有个关键点：.data段用了AT > FLASH_BOOT。意思是数据在Flash里存着，启动时再拷贝到RAM里。嗯，这就是所谓的「加载时地址」和「运行时地址」的区别。
我曾经遇到过一个坑：.data段没加AT，结果编译器把数据直接放在RAM里。一断电，数据全丢了。启动后变量全是乱的，查了两天才找到原因。
4.5 段定义与地址绑定
段定义，说白了就是给代码和数据贴标签。
比如，我想把UDS诊断服务相关的函数放在一个单独的段里，方便做地址校验。可以在代码里这样写：
/* 在C代码中指定段属性 */
__attribute__((section(".uds_code")))
void UDS_Service_ReadData(uint8_t* data, uint16_t len)
{
// 实现代码
}
然后在链接脚本里，把这个段绑定到Flash的特定地址：
.uds_code :
{
*(.uds_code*)
} > FLASH_BOOT
这样做的好处是什么？
我举个例子。有一次客户要求，Bootloader里的UDS服务必须放在Flash的前64KB内，因为硬件有读保护限制。如果没有段定义，我得手动算地址，改一个函数就得重新算一遍。有了段定义，我只需要在链接脚本里改一下起始地址，所有UDS函数自动对齐。
避坑指南：我曾经把中断向量表放在了一个错误的段里，结果跳转到APP后，中断响应全乱套了。后来我养成了一个习惯——每个段都加上起始和结束符号，在代码里做边界检查。
/* 在链接脚本中定义边界符号 */
.uds_code :
{
__uds_start = .;
*(.uds_code*)
__uds_end = .;
} > FLASH_BOOT
/* 在C代码中引用 */
extern uint32_t __uds_start;
extern uint32_t __uds_end;
void Check_UDS_Integrity(void)
{
uint32_t* start = &__uds_start;
uint32_t* end = &__uds_end;
// 对UDS代码段做CRC校验
}
4.6 知识体系总览
说了这么多，我画张图帮你理一理思路：
这张图把整个知识体系串起来了。从上到下，先规划内存分区，再通过链接脚本把代码和数据绑定到具体地址。每一步都环环相扣。
4.7 小结
内存映射和链接脚本，说白了就是给嵌入式系统画一张「房产证」。哪块地归谁，多大面积，边界在哪，都得写得清清楚楚。
我个人觉得，这块知识最考验的是「全局思维」。你不能只盯着Bootloader看，还得想着APP怎么用，OTA怎么升级，甚至要考虑将来会不会加新功能。提前留好余量，比后面改分区要省心得多。
嗯，今天就聊到这。记住一句话：链接脚本写得好，调试少烦恼。