嵌入式固件工程化：启动流程、故障定位与OTA实战解析-开发者社区

1. 从裸机思维到工程化思维：为什么你需要拆透这三件事

嵌入式固件这行，干到一定阶段，你会发现真正的分水岭不是你会不会调外设、能不能跑通 RTOS，而是面对一个“跑不起来”或者“跑起来但偶发异常”的系统，你能不能在一个合理的时间窗口内，给出有依据的判断。我做了十多年固件，带过不少初中级工程师，大家普遍存在两个断层：第一，对启动流程的理解停留在“复位后从 main 开始”，但对启动前的每一段代码、每一个寄存器的意义没有系统认知；第二，遇到故障只会“加日志—复现—猜原因”，缺少一套可复现、可追溯的定位方法论；第三，做过 OTA 的不少，但多数是“能跑就行”，离“工程化”还差着十万八千里。

所以我一直想写这么一套连载，把启动流程、故障定位、OTA 升级这三块串成一条线来讲。这三件事听起来各自独立，实际上底层逻辑高度统一——都是对系统生命周期和资源状态的管理。启动流程是系统从无到有的诞生过程，故障定位是在异常状态下逆向还原系统的行为轨迹，OTA 则是系统在运行中完成自我更新的能力。把这三件事拆透，你的固件开发水平会有一个质变。

这篇付费专栏的上篇，我已经把启动流程的框架搭了出来，并在文末留了几道思考题。这篇连载更新，我先把上篇的思考题完整解析补上，然后顺着读者的反馈，把故障定位方法论和 OTA 工程化实战这两块内容继续往下延展，做一个相对完整的输出。

先说清楚，这篇文章适合谁。如果你刚入门嵌入式、还在调 LED 和串口，那可以先收藏，等你有过一两个量产项目的经验再回来看。如果你已经独立负责过至少一个 MCU 或 SoC 项目的固件开发，正感觉自己的知识和经验是零散的、点状的，想把这些点串成体系，那这篇文章就是写给你的。

2. 启动流程深度拆解：从复位向量到 main 函数之间到底发生了什么

2.1 硬件复位后的第一行代码：向量表与启动文件

很多人在学习阶段，对启动流程的认知止步于“启动文件是汇编写的，里面把栈指针初始化一下，然后跳进 main”。但如果你去做真正的产品开发，尤其是涉及产线烧录、低温启动、异常复位这类场景，对启动过程的深度理解会直接决定你排查问题的速度。

CPU 复位之后，做的第一件事其实非常机械：从复位向量地址取出第一条指令的地址，然后跳过去执行。对 Cortex-M 内核来说，复位后从0x00000000读取初始栈指针 MSP，从0x00000004读取复位向量，这也是为什么startup_xxx.s文件里第一个DCD指令后面跟的必须是栈顶地址，第二个DCD后面跟的才是 Reset_Handler。这里有一个特别容易忽略的细节：向量表第一项是栈顶地址，不是代码地址。这意味着，如果栈顶地址配置错误，系统复位后会在执行第一条指令之前就直接触发 HardFault——我见过不止一个项目，在移植到新芯片时出现“一上电就死”的诡异问题，最终查出来是链接脚本里_estack符号指向的 RAM 地址和芯片实际的 RAM 末地址差了 4 个字节。

从复位向量进入 Reset_Handler 之后，固件要做的事情按顺序大致分为这么几类：

复制.data段：把初始化值从 Flash 拷贝到 RAM。
清零.bss段：把未初始化全局变量所在的 RAM 区域全部写成 0。
配置系统时钟：从默认的内部 RC 振荡器切换到外部高速晶振或 PLL，把 CPU 主频提上去。
初始化堆栈环境，调用__libc_init_array（或等价函数）完成 C 运行时环境初始化。
调用main()。

这几步里，时钟配置对新手而言是最容易出问题的。原因是，芯片上电默认通常是内部低速时钟，跑得稳但慢；一旦你切换到外部晶振，又分了 PLL 倍频，任何一个环节（晶振没焊好、负载电容不对、PLL 参数越界）都可能导致系统卡死在时钟切换的等待循环里。而这种卡死往往没有任何输出，因为串口也还没初始化。

注意：如果你在移植过程中遇到“烧录后第一次复位能跑、按一下复位键就死机”的现象，优先怀疑时钟配置里的 PLL 锁定超时逻辑——很多 HAL 库的HAL_RCC_ClockConfig会做超时等待，但早期某些版本的启动文件里对时钟失败没有做容错处理，直接就跳进 HardFault 了。

2.2 MCU 与 SoC 启动流程的关键差异：从裸奔到带“引导加载程序（Bootloader）”

这个差异我觉得是上篇里最值得展开的地方，因为它在根上决定了你的调试策略。MCU（比如 STM32、GD32、NXP 的 Kinetis 系列）和 SoC（比如全志、瑞芯微、树莓派的 BCM 系列）都有一个“启动”的概念，但规模和灵活性差了一个数量级。

对 MCU 来说，启动介质非常直接，要么是内部 Flash，要么是外部 SPI Flash，要么是串行下载。以 STM32 为例，BOOT0/BOOT1 引脚的电平组合决定了从主 Flash、系统存储器（内置 Bootloader）还是 SRAM 启动。这个设计是为了方便工厂烧录和 ISP 升级。但要注意，一旦你量产烧录完成，这两个引脚应该固定拉到确定的电平，否则产线上一块板子因为贴片不良出现浮空，所有板子都可能出现“上电进不了应用”的批量性灾难。

而对 SoC 来说，它内部通常没有可供应用直接运行的 Flash，启动过程被拆分成“多级引导”的方式。典型的流程是：BootROM（芯片出厂固化的只读代码）→ SPL（Secondary Program Loader，通常由 U-Boot 构建）→ U-Boot → 内核 / 应用固件。BootROM 做的事情非常少，基本就是把初始化存储控制器的代码从固定的启动介质（SD 卡、eMMC、SPI NOR/NAND）里加载到内部 SRAM，然后跳转执行。

多级引导带来的工程问题是：你没法像调试 MCU 那样只关注一个向量表，而是要关注每一级跳转的条件和校验方式。我做过一个基于 SoC 的项目，遇到的现象是“偶尔启动不了”，而且只在低温环境下出现。查到最后，问题是 SPL 阶段的 DDR 训练参数在低温边界情况下不稳定，U-Boot 在读取 DDR 时数据出错，但又没有在 SPL 阶段做 CRC 校验，于是随机性地加载了错误数据。这类问题如果在 MCU 体系里，大概率不会出现，因为 MCU 的 Flash 读取有严格的时序保证，很少需要软件参与 DDR 初始化。

把这两类启动流程放进同一篇文章里，我想强调的不是哪个更复杂，而是两种系统对“启动可靠性”的评估维度不同。MCU 关注的是时钟、复位、向量表这些基础要素；SoC 还要关注每一级引导的握手协议、DDR 初始化时序、介质读取可靠性。理解了这一层，你在选型和技术方案评估阶段，就能比别人多想一步。

2.3 RT-Thread 启动初始化流程：从汇编到 C 的世界

上篇发布后，后台有不少读者追问 RT-Thread 的启动流程，这里我补一段。RT-Thread 作为一个以“组件化”和“设备驱动框架”见长的 RTOS，它的启动流程在传统启动文件的基础上扩展了两层：一是内核对象初始化，二是自动初始化机制。

RT-Thread 的启动大致走这条链路：

复位向量进入Reset_Handler，完成和裸机一样的.data拷贝、.bss清零。
调用SystemInit（在board.c或clock.c中实现），完成系统时钟初始化。
进入 C 世界，调用rtthread_startup（在components.c中实现），这个函数承担了 RTOS 内核所有核心模块的初始化工作。
依次完成：rt_hw_board_init（板级硬件初始化）、rt_system_heap_init（堆初始化）、rt_init_thread（创建初始化线程）、rt_scheduler_init（调度器初始化）、rt_application_init（创建 main 线程）。
启动调度器rt_system_scheduler_start。

这里比较有意思的是第 4 步里的自动初始化机制，也就是INIT_BOARD_EXPORT、INIT_APP_EXPORT这些宏做的“编译段”魔法。它的原理并不神秘：链接脚本里定义了若干个以.rti_fn开头的段，INIT_*_EXPORT宏本质上是把函数指针放到这些段里，启动时通过遍历段内数据来调用所有注册过的初始化函数。这相当于给驱动和应用模块提供了一套“按优先级自动加载”的机制，省掉了手动逐个调用的繁琐。

但从工程角度，这个机制有一个隐含的坑：所有INIT_*_EXPORT注册的函数，默认都被认为是非阻塞且不会失败的。如果某个驱动的初始化函数里写了死循环等待或者长时间阻塞，整个系统启动就会被卡住，而且你在日志里看到的还只是“初始化到 XX 模块”的上一句，问题模块可能连日志都没来得及打。我在实战中处理过一个类似问题，板子偶发启动卡死，排查了很久，最后发现是某个传感器驱动在INIT_APP_EXPORT阶段里做了一次 I2C 通信，而 I2C 控制器此时尚未完全就绪，驱动层在等待总线空闲标志时超时机制写错了，导致死等。

所以如果你是 RT-Thread 的重度用户，我建议你养成一个习惯：每个驱动初始化函数里至少要保证有超时退出路径，且要在入口和出口各加一段调试日志。这个习惯可以帮你省下大量后续的启动问题排查时间。

3. 故障定位方法论：从“瞎猜”到“有章法地逼近真相”

3.1 首先要建立一套故障信息采集机制

故障定位最大的障碍，不是问题本身有多难，而是信息不够。很多产品在开发阶段调试还好，一旦进入量产和现场运行阶段，故障就变得“不可复现”，这时候你手里只有用户的一句话——“板子死机了”。你根本没法现场看寄存器、没法接调试器，所以你要做的事，是在设计阶段就预留好故障信息的采集和上报通道。

我做过的量产项目里，固化故障信息采集的做法基本是三板斧：

保留一段独立的 RAM 区域（不被bss清零影响），专门存放复位原因、故障发生时 PC 指针、LR 寄存器、关键寄存器快照。
利用芯片自带的复位标志寄存器（如 STM32 的RCC_CSR）记录上一次复位类型：上电复位、看门狗复位、引脚复位、软件复位、低功耗复位。
将以上信息和运行日志一起写入外部 Flash 或片上 Flash 的专用分区，方便下次启动时通过串口或远程方式导出。

这套机制的底层逻辑是：你无法预知故障长什么样，所以你要做的是把“犯罪现场”尽可能完整地保留下来。不要等到出了问题再想怎么加日志，那会先复现几天，然后才能开始真正的排查。

另外要提一下 HardFault 处理。Cortex-M 内核遇到 HardFault 时，硬件会把现场压栈，但如果你没有实现HardFault_Handler的现场解析逻辑，那调试器里看到的只是“停在 HardFault 中断”，无从判断是从哪儿跳进来的。通用的做法是在 HardFault 中断里先通过 MSP/PSP 判断当前使用的是哪个栈指针，然后从栈帧里解析出 R0-R3、R12、LR、PC 和 xPSR，并把这些信息连同BFAR、MMFAR等辅助寄存器一起保存。代码本身不复杂，网上有很多现成实现，核心是你要理解为什么从栈里能拿到这些东西——因为硬件在进入异常时自动完成了八寄存器压栈。这个知识点我在上篇里重点讲过，思考题也有一道涉及，后面会给出解析。

3.2 二分法与最小系统复现：现场排查的两种高效手段

排查故障的时候，我强烈建议不要“大撒网”。信息越多的排查，越容易让你陷入“看啥都像嫌疑犯”的泥潭。我的习惯是先做两类操作：二分裁剪和环境最小化。

二分法很好理解——如果是软件时序类问题，在两个可疑模块之间插入一个“观测点”（可以是翻转一个 GPIO 或者往串口扔一个特定字符），然后观察故障是出现在观测点之前还是之后，以此缩小范围。这个思路在硬件定位上同样适用：先用示波器量关键节点，沿着信号路径的中间点测，判断信号有没有送到后半段。本质上，这是在把“状态空间”减半。

环境最小化的意思是，把系统裁剪到“能复现问题的最简配置”。举个真实案例：某产品在现场出现偶发死机，代码量很大，无法判断是哪个任务导致的。我们在实验室尝试复现，先把外设全部关闭、只保留核心任务和串口日志，问题依旧出现。然后逐步关掉任务，最终发现只要把某个通信任务屏蔽，死机就不再出现。顺藤摸瓜，最后定位到该任务使用的 DMA 缓冲区存在栈越界写入。这个问题的排查如果没有“裁剪”这一步，你在完整系统里根本不会有那么干净的复现条件。

提示：在裁剪系统时，一定要保证“故障现象”仍然存在。一旦裁剪后问题消失，说明你动到的正是问题所在或触发条件，这本身就是一个重要信息。如果裁剪后问题依然在，那就继续沿着二分法缩小区间。不要贪快，一次只动一个变量。

3.3 日志分级与环形缓冲区的工程落地

日志是嵌入式系统最朴素的调试手段，但很多项目的日志方案做得一塌糊涂：要么日志太多把系统时序拖垮，要么日志太关键的信息没有打印，要么日志直接写在 Flash 里导致 Flash 提前写坏。我分享一下经验值。

日志分级是必须的，建议至少在 DEBUG、INFO、WARN、ERROR 四级基础上，再去考虑是否需要 TRACE 级别。开发阶段可以在编译开关控制下全量输出，量产固件则只保留 WARN 级别以上的输出，但要在代码里保留调试日志的“编译单元”，而不是满屏#if 0。更好的做法是用printf的重定向或者宏定义在编译期裁剪。

环形缓冲区则是日志落盘的核心实现方式。因为嵌入式系统里，串口输出本身是慢速设备，如果每条日志都直接同步发送，会阻塞业务逻辑。工程上常见的方案是：日志统一写入内存环形缓冲区，后台由一个低优先级任务负责把缓冲区数据刷到串口或 Flash。这个缓冲区的大小要根据日志产生速率和刷出速率来平衡，我一般按“系统满负荷运行时，每秒钟能容纳 3-5 秒的日志”这个标准来估算。比如每秒产生 2KB 日志，缓冲区至少做 8KB，留出余量。

环形缓冲区还有一个容易踩坑的点是“读指针追写指针”的问题。如果读者速度长期落后于写者，旧数据会被覆盖。对故障定位而言，你要的往往不是最新数据，而是故障发生前的那一段数据，所以更合理的策略是“故障冻结”——检测到异常时立刻停止写入，保留故障前最后一段日志。实现起来就是一个标志位的事，但带来的排查价值巨大。

4. OTA 升级工程化实战：从烧录器依赖中解脱出来的完整方案

4.1 OTA 不是“把新固件写进 Flash”那么简单

业内有个共识，OTA 的难点不在“能不能升级”，而在“升级失败了怎么办”“升级到一半断电了怎么办”“升级后设备变砖了怎么救”。这三个问题不解决，OTA 就只能算个 Demo，不能叫工程化。

先说架构。OTA 系统的核心是 Bootloader + 双分区（A/B 分区）方案。Bootloader 负责三件事：校验固件完整性、决定启动哪个分区、必要时执行固件搬运。双分区的思路是：固件运行区（A 区）和新固件下载区（B 区）彼此独立，升级时把新固件完整写入 B 区，校验通过后切换启动标志，下次复位从 B 区启动。一旦 B 区启动失败，Bootloader 回退到 A 区，设备不至于变砖。

有一个不依赖双分区的简化方案是“先擦后写同一分区”，通过把固件下载到外部存储或用“备份区”的方式在 Bootloader 里搬移。但在成本和安全性之间做取舍，我还是推荐把双分区作为默认首选。尤其是现在的 MCU 越来越多自带较大 Flash（1MB 甚至 2MB），双分区的空间成本已经不像十年前那么不可接受。

4.2 固件差分包与断点续传：两个省流量的关键技术

如果产品需要通过蜂窝网络或低带宽网络升级，全量固件会吃掉大量流量，这时候差分升级就有价值了。差分升级的原理是：在生成固件的 PC 端，用 bsdiff 或类似工具对比旧版本和新版本的二进制，生成一个“差分包”；设备端拿到差分包后，结合本地旧固件做逆向还原，得到新固件。

这么说可能有点抽象，我用个生活类比：你的旧手机里已经有一份系统，新系统本质上只改动了其中一小部分文件。与其把整个系统重新下载一遍，不如只下载“改动清单+改动内容”，在本地把新系统拼出来。差分包往往只有全量包的十分之一甚至更小，对低带宽、高资费的场景帮助极大。

但差分包也带来两个问题：第一，设备端需要有足够 RAM 或临时存储来存放“还原中间态”；第二，如果旧固件被破坏（比如 Flash 个别位翻转），还原过程会失败。所以工程上建议的策略是：流量敏感且可靠性要求高的场景，用差分+校验双重机制；普通 WiFi 场景，直接全量包加断点续传就够了。不要过度设计。

断点续传在嵌入式的落地方式是：下载固件包时，按固定大小（比如 4KB）分块记录“已接收块位图”，设备重启后，根据位图跳过已经收到的块，只请求缺失块。这个方案要求服务器端支持 Range 请求或者自定义协议中的分段拉取，但协议实现并不复杂，关键在于设备端的位图要持久化到 Flash，否则重启后之前下载的内容就白干了。

4.3 升级过程中的安全校验与异常回滚机制

OTA 工程化绕不开安全。如果固件在传输过程中被篡改或者根本不完整，设备升级后就可能变砖。至少要做的有三道校验：

传输层完整性：下载完成后，计算整个固件的 CRC32 或 SHA-256 哈希，与服务器下发的哈希值比对。
固件签名验证：用非对称加密算法（如 RSA 或 ECDSA）验证固件签名，防伪。这一步在 Bootloader 里做，防止攻击者直接伪造固件包。
应用层自检：Bootloader 在跳转前检查应用固件头部魔法字（magic number）和版本号，确认分区内容看起来像可执行固件。

回滚机制则依赖于 A/B 分区里记录的“启动计数”。Bootloader 在每次引导应用时，把启动计数器加一；应用正常启动并跑过一定时间后，上报“运行正常”，Bootloader 才把这个计数器清零。如果计数器累计到阈值仍未清零，Bootloader 判定新固件状态异常，自动回滚到旧分区。这个机制不复杂，但它是 OTA“工程化”和“Demo”之间最直观的分界线。

4.4 量产环境下的 OTA 策略：灰度发布与升级窗口

最后再补充一个偏策略的维度。OTA 升级不只是技术问题，它还是产品运营问题。全量推送新固件，一旦固件有隐蔽 bug，影响面可能非常大。所以工程上普遍采用灰度发布：先推送给一小部分设备（比如 5%），观察一两天，确认崩溃率、在线率正常后，再逐步扩大到 10%、30%、100%。这个策略在很多物联网平台上已经是基础能力，但如果你的产品自建 OTA 服务，就要在协议设计阶段就把“批次号”“升级策略”这些字段留好，而不是等上线后再打补丁。

升级窗口同样重要。对无人值守的设备，升级时机选得不对，会影响用户使用。比如智能门锁，你最好别在用户频繁出入的时间段推送升级；对工业设备，可能需要在设备空闲时升级，并在升级前记录当前业务状态，升级完成后恢复现场。这些听上去像是产品经理的事，但固件工程师如果在 OTA 架构设计时不考虑这些复杂度，后续产品迭代会被动挨打。

5. 上篇课后思考题完整解析

5.1 题目一：为什么复位向量表里的第一项是栈顶地址，而不是代码入口地址？

这个问题的答案要回到 ARM Cortex-M 内核的异常处理机制。Cortex-M 系列在复位后，处理器会从向量表偏移0x00处加载初始栈指针（MSP），从偏移0x04处加载复位向量（也就是 Reset_Handler 的地址）。处理器这样做，是为了能够在进入用户代码之前，就有一套完整可用的栈。

你可以设想一下：如果向量表第一项不是栈顶地址，CPU 在跳进 Reset_Handler 后，C 函数调用所需要的压栈操作就没有支撑，那启动代码就得先用汇编指令手动初始化栈，然后再跳 C 世界——多绕一步。Cortex-M 的设计直接把“让 C 世界尽快跑起来”这件事做进了硬件，你只需要在链接脚本里把栈顶地址正确地放在向量表的起始位置即可。

这个设计的另一个好处是：任何异常发生时的硬件自动压栈，都可以无脑使用当前栈指针，不需要软件临时切栈。这一点和很多其他架构（比如 ARM7/ARM9 系列的 SVC 模式切换要手动改栈指针）相比，提高了异常处理的可靠性。理解这层含义后，你再去看启动文件，就不会只觉得它是一堆“奇怪的 DCD”。

我理解的“深挖”是：这道题其实是在考察你有没有把自己代入处理器的视角。CPU 不关心你的业务代码长什么样，它只关心“第一条指令在哪里”“栈在哪里”。这两件事在复位瞬间必须同时成立，所以硬件设计者才把栈顶地址安排为系统的第一项。

5.2 题目二：系统上电后 .bss 段如果不清零，会发生什么问题？为什么不清零的后果有时比 .data 段错误更隐蔽？

.bss段存放的是未初始化的全局/静态变量，C 标准规定它们默认值为 0。如果启动代码没有清零.bss段，这些变量的初始值是随机的——取决于 RAM 上电后的物理状态。这会导致的问题很典型：一个变量在第一次运行时碰巧是 0，程序跑得一切正常；但复位后第二次运行，变量变成 0x5A，程序就走进了完全不同的分支。

你说它“比 .data 段错误更隐蔽”，关键就在“不确定性”四个字。.data段拷贝错误通常是确定的，比如源地址或目标地址错了，程序一跑必然异常，复现容易；但.bss不清零的错误是“概率性”的，因为变量的初始值取决于 RAM 里的残留数据，而这个残留数据又从芯片型号、温度、上电时序这些因素里变化。一次上电能跑，两次上电也可能跑，但十次里可能有一次偶发异常。这种故障，如果在没有良好信息采集机制的系统里，可能会耗费工程师好几天时间。

所以，我在项目里不仅会在启动文件里保证.bss清零，还会额外在链接脚本里把.bss段按 4 字节对齐，并在清零循环中使用 32 位写入而不是逐字节写入。这一点在意代码效率的 MCU 上尤其重要，某些启动文件里用LDRB/STRB逐个字节清零，在大 RAM 芯片上会白白浪费几百毫秒，对启动时间敏感的产品不可接受。

5.3 题目三：RT-Thread 的自动初始化机制和传统手动调用初始化函数相比，优势是什么？劣势又是什么？

自动初始化机制（INIT_*_EXPORT）的核心优势是解耦。传统手动调用方式是：driver_a_init(); driver_b_init(); app_init();，每加一个驱动就要进主函数去追加一行调用，而且顺序必须人肉维护，非常容易出错。自动初始化机制把顺序控制交给编译器链接顺序和优先级数字，你新增一个模块时只需要在文件里补一个宏，不需要动其它代码。

对于模块特别多的系统（RT-Thread 生态下，一个完整系统有几十上百个组件和驱动），这种解耦能显著降低集成成本。这也是 RT-Thread 能支持大量中间件和板卡支持包的原因之一——它们不需要各自去改别人的文件，只需要保证自己的文件里有一个正确优先级的导出宏。

劣势方面，首当其冲的是可读性与可追踪性下降。你在代码里很难一眼看到“初始化顺序到底是怎么排列的”，必须链接后查看 map 文件或者反汇编。第二是调试困难，因为初始化函数是编译器自动遍历调用的，断点设置和单步跟踪都比较反直觉；第三个劣势是安全性，很多初始化函数被假定是无阻塞且不会失败的，但实际上硬件初始化经常会遇到外设未就绪、总线上拉冲突等异常，一旦初始化函数内部没有良好的超时和错误处理，系统启动就会“莫名其妙地卡死”，前面章节也提到过这个坑。

所以我要强调：自动初始化机制是“好工具”，但不是“万能药”。用它的前提是每个初始化函数必须健壮，必须可失败、可超时、可记录日志，否则机制的便捷性会反过来成为排查问题的阻碍。这也是我把这道题放进课后思考题的原因——它考察的不是你对 RT-Thread 宏的熟悉程度，而是工具和工程复杂性之间的取舍。

5.4 题目四：设计 OTA 时，为什么需要同时做差分升级和整包升级？两者能互相替代吗？

差分和整包不是替代关系，而是互补关系。差分升级的价值在省流量，但它依赖于“设备本地已经有一份和差分基准一致的旧固件”。如果设备里当前的固件版本与生成差分包时的基准版本不一致，差分包根本没法还原；哪怕只差了一个编译开关配置，二进制也可能差距巨大。

另一个问题是，差分升级的还原过程对设备端的计算和存储都有额外要求。某些低端 MCU 的主频和 RAM 都不足以快速完成逆向还原，如果强行做差分，升级时间反而比下载整包更长，得不偿失。

所以工程实践中的通常做法是“两套并行”：正常迭代用差分包，空间小、下载快，适合批量升级；某些特殊场景（比如跨版本升级、固件损坏恢复、远古版本直接跳到最新版）用整包，主打可靠兼容。在 OTA 服务器的策略上，可以设计成“优先下发差分包，客户端发现无法还原时自动请求整包”，这是业界比较成熟的降级策略，你甚至可以把它当成一种“服务端能力探测”的手段。

5.5 题目五：Bootloader 跳转应用时，为什么通常要求全局关闭中断，并在跳转前复位外设状态？

这道题考的是对系统状态切换的深度理解。Bootloader 和应用程序是两个独立的固件镜像，它们各自都有中断向量表和中断处理函数。如果 Bootloader 跳转前没有关闭中断，那么跳转后的第一条指令有可能被一个“还在排队”的中断打断。问题是，这个中断的中断服务函数地址是从 Bootloader 的向量表里取的，而跳转后程序正在执行的却是应用代码，两边状态错乱，结果只能是 HardFault 或更神秘的异常。

同理，外设也需要复位。Bootloader 里初始化过的 DMA、定时器、UART 等外设，如果带着运行中的状态直接交给应用，应用无法确定它们的寄存器现场。比如 DMA 正在搬运数据，Bootloader 直接跳走了，那 DMA 可能会继续读写未知的内存区域。更安全的做法是：跳转前把用过的外设恢复默认值，必要时调用系统复位函数（如NVIC_SystemReset）让芯片在干净状态下重新执行启动流程，由应用自己的启动代码重新初始化一切。

我在实际项目里的做法比较保守：Bootloader 在完成固件校验和分区选择后，会把用到的外设全部反初始化，关闭全局中断，设置好新的 MSP，然后通过一个函数指针跳转。跳转后，应用启动文件会重新完成SystemInit和向量表重定位，确保应用运行在一个全新的状态中。这套流程我用了很多年，没出过跳转相关的生产事故。