2、STM32基础回顾：STM32系列分类、存储器映射、Flash与RAM结构、启动模式（BOOT0/BOOT1）及启动流程

在深入Bootloader与IAP（In-Application Programming，应用内编程）固件升级之前，必须先夯实STM32的底层硬件与启动机制。Bootloader的本质是一段在CPU复位后最先执行的代码，它的行为完全受芯片的存储器映射、Flash/RAM布局以及BOOT引脚电平的约束。如果对这些基础概念理解不透彻，后续编写跳转函数、规划APP起始地址、处理中断向量表重映射时，极易出现“死机”或“跳转失败”的疑难问题。本章将系统梳理STM32的家族谱系、存储器架构、启动模式选择以及完整的复位启动流程，为后续实现IAP升级建立坚实的知识底座。

上图展示了STM32在IAP场景下的核心存储布局与启动路径。左侧为Cortex-M3/M4内核的标准存储器映射，右侧则对应Bootloader与APP分区后的实际运行视图。理解这张图的关键在于：CPU始终从0x00000000地址取向量表，而该地址在物理上被映射到不同的存储介质（Flash、RAM或系统ROM），具体映射到哪一块，由BOOT0和BOOT1引脚的电平状态决定。

2.1 STM32系列分类与选型要点

STM32家族庞大，不同系列在Flash容量、RAM大小、外设资源以及内核性能上差异显著。从Bootloader开发的角度，我们最关心的是Flash扇区大小、RAM起始地址以及是否支持硬件双Bank特性。

2.2 存储器映射详解：Flash与RAM的地址布局

STM32的存储器映射是固定的，由芯片设计时决定。Cortex-M内核通过统一的地址空间访问所有外设和存储介质。对于Bootloader开发，以下三个区域最为关键：

• 主Flash（0x08000000起）：存放代码和只读数据。CPU通过I-Code总线取指，通过D-Code总线访问字面量。Flash的读取速度慢于CPU主频，因此需要配置等待周期（Flash Latency）。
• SRAM（0x20000000起）：存放变量、堆栈。CPU通过System总线访问。SRAM的起始地址存放的是初始栈顶指针（MSP），这是复位后CPU执行的第一条指令前必须加载的值。
• 系统存储器（0x1FFF0000起）：出厂固化的ROM Bootloader，支持USART、SPI、USB等接口下载程序。这是芯片出厂时的“救砖”通道。

在IAP设计中，Flash被划分为两个逻辑区域：Bootloader区（通常占前16KB-64KB）和APP区（剩余空间）。APP区的起始地址必须满足扇区对齐要求。例如，若Flash扇区大小为16KB，则APP起始地址应为0x08004000、0x08008000等，而不能是0x08005000。

// 以STM32F407VG为例，Flash 1MB，扇区大小分布：
// 扇区0: 0x08000000 - 0x08003FFF (16KB)
// 扇区1: 0x08004000 - 0x08007FFF (16KB)
// 扇区2: 0x08008000 - 0x0800BFFF (16KB)
// 扇区3: 0x0800C000 - 0x0800FFFF (16KB)
// 扇区4: 0x08010000 - 0x0801FFFF (64KB)
// 扇区5: 0x08020000 - 0x0803FFFF (128KB)
// 扇区6: 0x08040000 - 0x0807FFFF (128KB)
// 若Bootloader占用扇区0-3（共64KB），则APP起始地址为0x08010000

2.3 启动模式（BOOT0/BOOT1）与启动流程

STM32的启动模式由BOOT0和BOOT1引脚的电平状态决定。不同系列引脚数量略有差异，但逻辑一致。以STM32F4为例：

复位后，CPU的硬件逻辑会执行以下步骤：

1. 根据BOOT引脚状态，将对应存储介质的起始地址映射到0x00000000别名区。
2. 从0x00000000处读取初始栈顶指针（MSP），加载到SP寄存器。
3. 从0x00000004处读取复位向量，加载到PC寄存器。
4. 跳转到复位向量指向的地址，开始执行启动代码（startup_xxx.s）。

2.4 实战场景：从Bootloader跳转到APP的完整流程

假设我们使用STM32F407，Bootloader位于0x08000000-0x0800FFFF（64KB），APP位于0x08010000。跳转函数的核心代码如下：

typedef void (*pFunction)(void);
#define APP_ADDRESS 0x08010000

void JumpToApp(void)
{
    uint32_t app_msp = *(volatile uint32_t *)APP_ADDRESS;
    uint32_t app_reset = *(volatile uint32_t *)(APP_ADDRESS + 4);
    pFunction app_main;
    
    // 1. 检查栈顶地址是否合法（应在RAM范围内）
    if ((app_msp & 0xFFF00000) != 0x20000000)
    {
        Error_Handler(); // 栈顶非法，说明APP区无有效程序
    }
    
    // 2. 关闭全局中断，避免跳转过程中被中断打断
    __disable_irq();
    
    // 3. 设置中断向量表偏移（仅Cortex-M3/M4支持VTOR）
    SCB->VTOR = APP_ADDRESS;
    
    // 4. 重新设置主栈指针
    __set_MSP(app_msp);
    
    // 5. 跳转到APP复位向量
    app_main = (pFunction)app_reset;
    app_main();
    
    // 6. 正常情况下不会执行到这里
    while(1);
}

这段代码看似简单，但实际工程中常遇到以下问题：

• 外设状态未清理：Bootloader中使能过的外设（如USART、DMA）在跳转前未复位，导致APP初始化时冲突。解决方法是跳转前调用HAL_RCC_DeInit()和HAL_DeInit()。
• 中断标志残留：跳转前未清除挂起的中断标志，APP开启中断后立即触发异常。应在__disable_irq()后执行NVIC_ClearPendingIRQ()。
• Flash等待周期不匹配：APP若修改了主频，但Flash等待周期未同步更新，会导致取指错误。APP启动代码中应重新配置FLASH_ACR寄存器。

2.5 常见误区与总结复盘

在Bootloader开发中，以下误区最容易导致项目延期或产品故障：