STM32 BOOT与APP程序跳转：从内存规划到中断向量表重映射的完整指南

STM32BOOTAPP

于 2026-07-31 07:03:05 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 从一次固件升级失败说起：为什么需要程序跳转？

最近在调试一个基于STM32F103的项目，遇到了一个典型的现场升级难题。设备已经部署，我需要通过串口给它的应用程序（APP）推送一个新版本的固件。按照常规思路，我写了一个简单的IAP（In Application Programming）程序，接收数据并写入Flash。一切看似顺利，新固件下载完成，校验也通过了。但当我触发重启，期待设备以新程序运行时，它却“砖”了——要么卡死在启动阶段，要么运行行为异常，仿佛还在执行旧程序。

经过一番痛苦的排查，问题根源并非Flash写入错误，而是程序跳转的逻辑有瑕疵。我错误地理解了中断向量表重映射的时机，也没有处理好关键外设的复位，导致新程序虽然“躺”在Flash里，但MCU的“大脑”却找不到正确的入口，或者带着旧程序的状态进入了新世界，结果自然是崩溃。

这次经历让我意识到，STM32上实现BOOT与APP的跳转，远不是简单调用一个函数指针那么简单。它涉及到内存布局的精确规划、启动流程的深刻理解，以及运行时状态的干净切换。这不仅是实现OTA（空中升级）、双备份等高级功能的基础，更是嵌入式开发者从“写单个程序”到“设计可维护固件架构”必须跨越的一道坎。今天，我就结合这次踩坑和后续的成功实践，把STM32上BOOT与APP程序跳转的核心原理、实现步骤，以及那些容易忽略却至关重要的“注意问题”彻底讲透。

2. 内存地图规划：为BOOT和APP划清“地盘”

程序跳转的前提，是BOOT程序和APP程序在物理存储上井水不犯河水。你不能让APP覆盖了BOOT的代码，也不能让BOOT的变量区侵占了APP的地盘。这一切都始于链接脚本（Linker Script）中对内存布局的精确规划。

2.1 理解STM32的Flash与RAM结构

以常见的STM32F103C8T6为例，它拥有64KB的Flash和20KB的RAM。Flash用于存储程序代码和常量，RAM用于存放变量、堆栈等运行时数据。我们的目标是将这块Flash分成两个独立的部分。

一个典型的分区方案如下：

BOOT区：占用Flash起始部分，例如从0x0800 0000到0x0800 3FFF，共16KB。这个区域存放引导程序，负责系统初始化、固件更新逻辑以及最终的跳转。
APP区：紧接着BOOT区之后，例如从0x0800 4000开始，到0x0800 FFFF结束（假设APP用掉剩下的48KB）。这个区域存放我们的主应用程序。
参数区：有时我们还需要一小块区域（如Flash的最后一页）来存储升级标志、APP版本号、CRC校验值等参数。这有助于BOOT程序判断是否需要以及如何跳转。

注意：分区大小不是固定的。你需要根据BOOT程序的实际大小（加上余量）和APP的预期大小来调整。务必在项目初期就估算好，并留出足够的余量（通常建议BOOT区预留比编译结果大50%-100%的空间）。

2.2 在Keil MDK中配置分散加载文件

对于使用Keil MDK的开发者，配置内存布局主要通过修改工程的“Options for Target”中的设置。

BOOT工程配置：
- 打开“Target”选项卡，在“IROM1”中，将起始地址设置为0x08000000，大小设置为0x4000（即16KB）。这告诉链接器，BOOT程序必须放在这个区域。
- “IRAM1”的配置通常保持不变（如0x20000000, 0x5000），因为BOOT和APP在运行时共用同一块RAM，但需要小心处理堆栈和全局变量的冲突，我们后面会讲。
APP工程配置：
- 同样在“Target”选项卡，将“IROM1”的起始地址修改为APP区的起始地址，例如0x08004000，大小设置为剩余空间，如0xC000（48KB）。
- 这是最关键的一步，确保APP的代码被链接到正确的Flash位置。