第4章启动流程分析

第4章启动流程分析：STM32F4上电启动流程、中断向量表重映射、Bootloader与App的跳转逻辑

各位同学，今天我们来啃一块硬骨头——STM32F4的启动流程。说实话，我刚入行那会儿，觉得启动不就是上电就跑吗？有什么好研究的？直到有一次，我做的Bootloader死活跳转不到App，查了三天才发现是中断向量表没重映射……嗯，从那以后，我再也不敢小看这区区几KB的启动代码了。

4.1 STM32F4上电启动流程——芯片醒来后做的第一件事

芯片上电复位后，CPU到底干了什么？说白了，就是三件事：

从0x00000000取栈顶指针——初始化SP寄存器
从0x00000004取复位向量——得到第一条指令的地址
跳过去执行——开始跑代码

你可能会问：「那我的程序明明烧在0x08000000，为什么CPU要去0x00000000读数据？」

嗯，这里有个关键点。STM32F4内部有个映射机制。芯片上电后，默认把Flash（0x08000000）映射到别名区0x00000000。所以CPU读0x00000000，其实读的就是0x08000000的内容。我习惯把这个过程叫做「偷梁换柱」——地址变了，但数据没变。

核心记忆点：

0x00000000 → 栈顶指针（4字节）
0x00000004 → 复位中断向量（4字节）
0x08000000 → 实际Flash起始地址

我在项目中遇到过一种情况：客户说芯片偶尔启动不了。排查后发现，是电源纹波太大导致复位瞬间SP指针读错了，栈都歪了，程序当然跑飞。所以啊，硬件设计时复位电路的稳定性，直接决定了启动的可靠性。

4.2 中断向量表重映射——Bootloader的命门

Bootloader和App是两个独立的程序，各自有各自的中断向量表。问题来了：芯片只有一个默认的向量表位置（0x00000000）。当Bootloader把控制权交给App后，如果发生中断，CPU还是去0x00000000找中断服务函数——那找到的可是Bootloader的ISR，不是App的！

这就好比你把钥匙交给了新房客，但门牌号还是指向老地址。快递员（中断）永远送错门。

解决办法？STM32F4提供了向量表偏移寄存器（VTOR）。我们可以在跳转前，把VTOR指向App的向量表基址。

/* 设置向量表偏移 —— 这是跳转前必须做的一步 */
SCB->VTOR = APP_BASE_ADDRESS;  // 例如 0x08010000

我个人习惯在App的启动代码最开头就设置VTOR，而不是在Bootloader里设。为什么？因为Bootloader跳转后，App的复位向量会先执行，这时候设VTOR最保险。我曾经试过在Bootloader里设VTOR再跳转，结果发现某些中断在跳转瞬间就来了，VTOR还没生效，直接死机……

避坑指南：

我曾经在VTOR设置上栽过跟头。注意：VTOR寄存器要求地址512字节对齐（0x200对齐）。如果你的App偏移量是0x10000，没问题；但如果是0x100（256字节），就不行！因为STM32F4的向量表有82个中断，每个4字节，总共328字节，所以至少需要512字节对齐。你想想看，如果不对齐，VTOR的低位会被硬件忽略，结果指向了错误的位置。

4.3 Bootloader与App的跳转逻辑——临门一脚

跳转逻辑，说白了就是「把CPU的指挥权交出去」。但交权不是简单的一句goto就能搞定的。你得把「现场打扫干净」。

标准的跳转流程如下：

关闭全局中断——跳转过程中不能被打断
清理外设状态——把用过的外设复位到默认状态
设置主栈指针——从App向量表取新的SP值
跳转到App复位向量——用函数指针执行

/* Bootloader跳转到App的标准代码 */
typedef void (*pFunction)(void);

void JumpToApp(uint32_t app_addr)
{
    uint32_t stack_ptr;
    pFunction app_entry;
    
    /* 1. 关闭全局中断 */
    __disable_irq();
    
    /* 2. 关闭所有外设时钟（可选，但推荐） */
    RCC->AHB1ENR = 0;
    RCC->APB1ENR = 0;
    RCC->APB2ENR = 0;
    
    /* 3. 从App向量表取栈顶指针 */
    stack_ptr = *(volatile uint32_t*)app_addr;
    
    /* 4. 从App向量表取复位向量地址 */
    app_entry = (pFunction)(*(volatile uint32_t*)(app_addr + 4));
    
    /* 5. 设置新的栈指针 */
    __set_MSP(stack_ptr);
    
    /* 6. 跳转！ */
    app_entry();
    
    /* 永远不会执行到这里 */
}

这里有个细节我想强调一下：为什么要先取SP再取PC？因为设置MSP之后，栈就切换到App的栈空间了。如果先取PC再设SP，中间万一有个函数调用压栈，压的可是Bootloader的栈，乱套了。

我的小技巧：

跳转前，我习惯把SysTick定时器也关掉。因为SysTick中断可能会在跳转瞬间触发，而App的SysTick处理函数还没准备好。另外，如果用了FreeRTOS，记得把Systick的优先级设成最低，或者干脆在跳转前把PendSV和SVC中断也屏蔽掉。这些坑，我一个个都踩过……

4.4 实战中的注意事项——纸上得来终觉浅

理论说完了，聊聊实战中容易翻车的地方。

问题	现象	原因	解决方案
跳转后死机	App不运行	SP指针取错或VTOR未设置	检查App烧录地址是否正确，VTOR是否对齐
中断不响应	按键中断没反应	VTOR指向了Bootloader的向量表	在App启动代码中重新设置VTOR
跳转后外设异常	串口乱码	外设寄存器状态未清理	跳转前复位所有用过的外设
看门狗复位	反复重启	IWDG未在跳转前刷新	跳转前喂狗或关闭看门狗

我记得有一次，App跳转后串口输出全是乱码。查了半天，发现是Bootloader里初始化了USART1，跳转时没把USART1复位。App启动后又初始化一次，但某些控制位还保留着Bootloader的状态。从那以后，我写跳转函数时一定会加上外设复位这一步。

4.5 总结——启动流程的「三板斧」

好了，这一章的内容就这些。总结下来，STM32F4的启动和跳转，核心就是三板斧：

第一板斧：理解上电映射机制——0x00000000和0x08000000的关系
第二板斧：VTOR重映射——让中断找到正确的家
第三板斧：干净的跳转——关中断、清外设、设SP、跳PC

你想想看，这三板斧砍下去，Bootloader和App之间的「交接仪式」就完成了。下一章我们会讲Flash分区策略——怎么给Bootloader和App分配空间，才能既灵活又安全。到时候我会分享一个我在量产项目中用过的分区方案，保证实用。

嗯，今天就到这里。代码别光看，去开发板上跑一跑。把Bootloader和App的地址调一调，故意设错VTOR，看看死机是什么样子。只有亲手踩过坑，才能真正记住这些细节。

📚 课程目录