3. Bootloader基础
说实话，很多工程师写了几年嵌入式代码，对启动流程的理解还停留在“上电后自动跑到main”这个层面。我早年带团队时，有个同事调试了整整三天，发现程序跑飞是因为中断向量表没重映射——这种坑，踩过一次就忘不了。
这一章，咱们把MCU从复位到main的每一步掰开来看。你理解了启动流程，才能理解Bootloader为什么能接管系统、为什么能跳转到APP、为什么中断能正常工作。
3.1 复位后的第一行代码在哪里？
MCU上电或复位后，CPU从哪开始执行？答案是：复位向量。
ARM Cortex-M系列内核在复位后，会自动从0x00000000地址读取栈顶指针（MSP），从0x00000004地址读取复位向量（Reset_Handler的地址）。然后跳转到Reset_Handler执行。
我习惯把这个过程叫做“硬件自动完成的两次读操作”。你想想看，CPU还没初始化，连C环境都没有，它只能靠硬件逻辑去固定地址拿数据。
- 0x00000000 → 栈顶指针（MSP初始值）
- 0x00000004 → 复位向量（Reset_Handler入口地址）
- CPU自动加载这两个值，然后跳转执行
这里有个容易忽略的细节：0x00000000存放的不是代码，是数据。栈顶指针的值由链接脚本决定，通常是SRAM的最高地址。我见过有人把这里误写成代码地址，结果复位后直接HardFault。
3.2 启动文件的完整流程
复位后，CPU进入Reset_Handler。这个函数通常写在启动文件（startup_xxx.s）里。它干的事很固定，我总结为“三板斧”：
- 初始化栈和堆：设置栈指针、堆边界
- 拷贝数据段：将.data段从Flash拷贝到SRAM
- 清零BSS段：将.bss段全部清零
做完这些，C环境才算就绪。然后调用SystemInit()配置时钟，最后跳转到main()。
我曾经在一个项目里发现，程序偶尔跑飞是因为BSS段没清零，全局变量初始值随机。从那以后，我每次检查启动文件都会确认BSS清零循环的地址范围是否正确。
; 典型的Reset_Handler伪代码（ARM Cortex-M）
Reset_Handler:
LDR R0, =_estack ; 栈顶地址
MSR MSP, R0 ; 设置主栈指针
BL SystemInit ; 初始化时钟
LDR R0, =__data_start
LDR R1, =__data_end
LDR R2, =__data_flash
BL CopyData ; 拷贝.data段
LDR R0, =__bss_start
LDR R1, =__bss_end
BL ZeroBss ; 清零.bss段
BL main ; 跳转到C主函数
B . ; 死循环3.3 中断向量表的结构与重映射
中断向量表是MCU中断系统的“电话簿”。每个中断源对应一个表项，存放中断服务函数（ISR）的地址。Cortex-M的向量表默认放在Flash起始地址（0x08000000或0x00000000）。
但Bootloader场景下，APP的向量表不能和Bootloader冲突。怎么办？重映射。
ARM Cortex-M3/M4提供了SCB->VTOR寄存器，你可以把向量表基址改到任意地址。比如APP从0x08010000开始，那就在APP启动时设置：
// 中断向量表重映射示例
#define APP_VECTOR_TABLE (0x08010000)
void app_entry(void)
{
// 设置向量表偏移
SCB->VTOR = APP_VECTOR_TABLE;
// 重新设置栈指针（从新向量表读取）
__set_MSP(*(uint32_t*)APP_VECTOR_TABLE);
// 跳转到APP的Reset_Handler
void (*app_reset_handler)(void) =
(void (*)(void))*(uint32_t*)(APP_VECTOR_TABLE + 4);
app_reset_handler();
}这里有个关键点：重映射后，所有中断都会从新向量表查找ISR地址。如果Bootloader和APP用了同一个外设中断，必须确保中断向量表指向正确的处理函数。
3.4 启动模式选择
大多数MCU支持多种启动模式，通过BOOT引脚的电平选择。以STM32为例：
| BOOT0 | BOOT1 | 启动区域 | 说明 |
|---|---|---|---|
| 0 | X | 主Flash | 正常启动，从0x08000000执行 |
| 1 | 0 | 系统存储器 | 内置Bootloader，用于串口/USB下载 |
| 1 | 1 | SRAM | 从SRAM启动，调试用 |
启动模式的选择直接影响向量表的映射方式。比如从系统存储器启动时，向量表在系统存储器的起始地址；从SRAM启动时，向量表在SRAM起始地址。
我个人的建议是：产品量产时固定从主Flash启动，BOOT引脚通过电阻上拉或下拉固定电平。不要把BOOT引脚悬空，否则干扰可能导致启动模式跳变。
3.5 启动流程全景图
下面这张图把整个启动流程串起来了。从复位信号产生，到main函数执行，每一步都有明确的硬件或软件动作。
3.6 启动流程中的常见陷阱
我整理了几个实际项目中反复出现的启动问题，你遇到了可以直接对照排查：
- 栈溢出发生在main之前：启动文件里调用的函数如果嵌套太深，栈指针可能溢出到未初始化区域。我建议在Reset_Handler开头就设置好栈边界检查。
- 中断在初始化完成前触发：SystemInit还没跑完，外设中断就来了。解决方案：在进入main之前，全局中断默认是关闭的，别提前开。
- 向量表地址对齐问题：Cortex-M要求向量表按512字节对齐（VTOR的低9位为0）。APP偏移地址必须是0x200的整数倍。
- 跳转APP后外设状态残留：Bootloader用过的DMA、定时器，跳转前必须复位。我习惯写一个
DeInitAllPeripherals()函数。