1. 引言：上电那一刻，代码在哪里

我做过几年嵌入式开发，被新人问得最多的一句话就是：“代码明明烧进去了，为什么上电就是跑不起来？”这背后其实藏着一整套完整的启动链路——ROM Code、Bootloader与启动代码的协同交接。搞明白这段流程，比背一百遍芯片手册都管用。

这篇文章我想把这部分彻底讲透。无论你用的是STM32、ESP32这类ARM Cortex-M单片机，还是i.MX、全志、瑞芯微这类Cortex-A应用处理器，只要吃透这套思路，换平台也只是细节差异。适合刚入行的嵌入式开发、准备自己做Bootloader移植、或者正在被启动失败bug折磨的工程师参考。我会从片上ROM怎么运行讲起，一直讲到应用代码的main函数是如何被层层接力调起来的。

先说一句题外话。很多朋友上来就查“为什么串口没输出”，甚至怀疑是晶振坏了——但真正的问题往往出在上电后的前几十毫秒里。如果你连启动流程都摸不清，排查起来就跟没头苍蝇一样。所以这篇文章的重点不只是“流程是什么”，更会讲清楚“为什么这样设计”以及“出了事怎么查”。

2. 一条链路，三个角色：先看清楚活是谁干的

2.1 从复位到main，中间隔着多少层交接

嵌入式系统上电后的执行路径，可以简单概括成一句话：芯片内部的固化代码先跑起来，再把控制权交给用户可烧写的Bootloader，最后由Bootloader把应用代码拉起来。这中间每一棒都不能掉，每一棒都有各自的职责边界。

以常见的ARM Cortex-M处理器为例，CPU复位后第一条指令肯定不是用户代码，而是一段出厂就固化在芯片内部的ROM Code。这段ROM Code会去读取启动引脚的电平状态（BOOT0/BOOT1），判断该从哪个介质启动——是内部Flash、系统存储器还是SRAM。然后它按照约定地址跳过去，把后续执行权交给对应的程序。

这里特别要澄清一个容易混淆的点：很多人以为“Bootloader就是启动代码”，其实不是。Bootloader是一个独立的、可被用户替换或升级的程序，它负责更复杂的初始化与镜像搬运；而“启动代码”通常指应用工程里的那段汇编启动文件（比如startup_stm32f103xe.s），它负责处理器从复位入口到C语言main函数之间的那段“过渡”。ROM Code、Bootloader、启动代码，三者是递进关系，各自解决不同阶段的问题。

2.2 为什么非要分成多级启动，一步到位不行吗

这个问题我问过不少同事，很多人一时答不上来。核心原因有两个：一是芯片内部SRAM太小，放不下完整的Boot程序；二是片外DDR、Flash控制器的初始化需要额外代码，而这些代码本身又需要一个存放和运行的环境。

打个比方。ROM Code就像一个酒店前台，它只知道怎么把你领到大堂——固定路线、固定动作，代码量极小。Bootloader则是礼宾部，负责帮你办入住、带你去房间，它可以换、可以升级。启动代码才是你房间里的那张床，是你真正要躺下的地方。如果把酒店前台直接改成全流程服务，那前台的工程量就太大了，而且酒店（芯片厂商）一旦建好就不能改——所以ROM Code必须保持精简，把活儿拆给后面的人。

所以你会看到，Cortex-A平台上普遍是四级启动：ROM Code → SPL（Secondary Program Loader）→ U-Boot → 内核/应用；Cortex-M简单些，通常是ROM Code（系统存储器）→ 自定义Bootloader → 应用。层数越少越直接，但代价是灵活性低，二者平衡而已。

3. ROM Code：芯片出厂就写死的第一段代码

3.1 ROM Code到底干了件什么事

ROM Code是芯片流片时固化在只读存储器里的一段微小程序，用户没法改、也删不掉。它的本质是一个自带驱动的最小加载器。以STM32F1系列为例，芯片上电后CPU从0x00000000取指，由于设置了BOOT引脚的映射关系，这个地址会被重映射到0x0010 0000的System Memory区域，也就是ROM Code所在的位置。重新映射这个动作不需要软件参与，是芯片硬件自动完成的。

ROM Code干的事情主要有这么几件：

1. 初始化最基本的时钟（通常只是芯片内部HSI，不会去碰外部晶振）；
2. 配置启动引脚对应的启动介质选择逻辑；
3. 使能对应的通信接口（USB、UART、SPI、SDIO等，视芯片而定）；
4. 从一个约定起始地址读取代码，校验无误后跳转过去。

看到没有，ROM Code的设计原则就是“能懒则懒”。它不会去初始化DDR，不会去挂文件系统，更不会去读以太网。一切需要额外上下文的操作，都不适合放在这里。它的存在意义，仅仅是让系统有一个“绝对可靠的起点”。

3.2 BOOT引脚、fuse位与启动介质的选择

启动介质的选择在不同芯片上差异很大，但思路是一致的。Cortex-M芯片通常用引脚电平，比如STM32的BOOT0/BOOT1组合；Cortex-A芯片往往是芯片内部的eFuse寄存器或者OTP区域，出厂时或首次烧录时确定。

我整理了一个常见的启动介质选择对照表，方便你参考：

这里有一个容易被忽略的点：ROM Code跳转之前，会把手头已经初始化的外设状态以某种形式传递下去吗？复杂平台会通过参数结构体传递，简单平台则一概不管，全凭Bootloader重新初始化。所以在设计自己的Bootloader时，千万不要假定“ROM Code已经帮我把串口配好了”，那是靠不住的。

3.3 ROM Code的安全校验与签名机制

这几年芯片安全问题越来越被重视，ROM Code里通常还会内置一道签名或者CRC校验。签名校验的意义在于：只有经过授权的镜像才允许继续执行。对于一些防抄板、防篡改的场景，这个特性特别有用。

我见过一个做电表的朋友，他们产品的固件里就做了多重校验：第一道是ROM Code校验Bootloader的签名，第二道是Bootloader校验应用固件的CRC。一旦校验失败就直接进入死循环或者跳回工厂模式，绝不给非法镜像任何执行机会。这个思路值得借鉴——尤其是做IAP升级的产品，一定要考虑升级包在传输过程中被破坏或篡改的情形。

4. Bootloader：承上启下的“搬运工”与“管家”

4.1 Bootloader到底“初始化”了什么东西

Bootloader和ROM Code最大的区别在于：它是一个可替换的程序，通常存放在外部Flash或系统保留区，厂商不会帮你管理它。它承担的工作就复杂多了。

拿嵌入式Linux里最常见的U-Boot举例，它的启动过程分为两个阶段：

第一阶段是汇编代码，主要干三件事：设置CPU模式、初始化异常向量表、建立页表（MMU）。这一阶段代码量极小，目的是让CPU处于一个可控状态。

第二阶段是C语言代码，这一阶段才开始真正干“重活”：初始化DDR控制器、配置时钟树（PLL分频倍频）、初始化串口、网卡、Flash控制器，然后通过某种介质加载内核镜像。对MCU来说，Bootloader虽然没有U-Boot这么庞大，但基本逻辑是相通的——先把外设初始化好，再把应用镜像从存储介质里读出来，搬运到运行地址，跳转执行。

所以你在网上搜索“bootloader开发”时，看到的绝大多数教程都会聚焦在两件事上：一是外设驱动初始化，二是跳转逻辑的实现。这两件事做好了，Bootloader就算成功了一大半。

4.2 镜像从哪来：Flash、SD卡还是OTA网络包

Bootloader加载镜像的方式可以分成三类：

第一类是最常见的本地加载：直接从外部Flash或内部Flash的某个分区读取镜像。单片机做IAP升级时用的就是这种方式，Bootloader判断升级标志，如果置位就执行擦除和写入操作，否则直接跳旧版本。这里有个细节：擦写内部Flash时需要关闭全局中断，并且确保代码执行在RAM中，否则擦写过程中一有中断请求就卡死。

第二类是SD卡加载：很多开发板的U-Boot可以从SD卡读取内核镜像，方便调试。这类Bootloader需要额外实现FAT/exFAT文件系统驱动，读SD卡的扇区只是基础，解析文件系统才是大头。我自己写过一个轻量级FAT16读取器，专门加载log和配置文件，说实话，解析目录项、处理长文件名这些细节挺繁琐，但写一次能用很多年。

第三类是OTA网络加载：Bootloader通过以太网或Wi-Fi接收升级包，然后写入指定分区。这种场景下，Bootloader的体积会明显膨胀，因为它要自包含网络协议栈，比如LwIP精简版。所以很多产品会采用A/B分区方案：当前版本在A槽运行，升级包写入B槽，校验成功后切换启动槽位。这样即使升级中途失败，系统也能回滚到A槽，不会变砖。

4.3 U-Boot、MCUBoot、自研Bootloader到底怎么选

选Bootloader方案，我的建议是先看芯片平台，再看产品需求，最后看团队维护能力。

U-Boot适合Cortex-A/Linux生态，优点是对大量开发板都有现成支持，驱动丰富，调试工具多；缺点是代码量巨大、配置复杂，除非你经常接触Linux启动链，否则入门有一定门槛。

MCUBoot是开源社区里适合MCU的Bootloader，由Juul Labs贡献，支持Zephyr、MyNewt等RTOS，签名校验、固件升级、回滚这些功能都已经实现，适合不想从零造轮子的团队。缺点是它对Flash分区的管理有自己的一套约定，你得先理解它的image header格式。

自研Bootloader的好处是体积可以控制得很小，逻辑完全透明，出了bug容易排查；坏处是每个平台都要重新适配，尤其在处理Flash驱动、加密校验、Flash磨损均衡这些层面，细节非常多。

我个人的原则是：产品处于快速迭代期，选MCUBoot这类成熟方案；如果对固件体积、启动时间有极致要求，再考虑自研。别什么都想自己写，也别什么都依赖现成方案，要在可控和灵活之间找平衡。

5. 启动代码：应用接管CPU后的“第一口气”

5.1 中断向量表为什么必须放在最前面，栈指针为什么在首位

Bootloader完成跳转后，CPU到达的真正“应用入口”就是启动代码。ARM Cortex-M系列的启动文件里最显眼的就是中断向量表。这张表本质上是一组地址数组，每一项对应一个中断或异常的处理函数入口。它的第一项存放的是初始栈指针（MSP），第二项存放的是复位处理函数（Reset_Handler）地址。

为什么栈指针非得放在第一个？因为Cortex-M处理器复位后，硬件会直接从向量表起始地址读取MSP和PC值。这是CPU设计者定下的规矩，不是软件约定可以随便改的。如果你把向量表放在0x0800 0000，那么该地址处的第一个4字节必须是栈顶地址，第二个4字节才是复位函数地址。一旦放错顺序，启动就会跑飞到莫名其妙的地方。

在实际项目中，这个向量表的首地址由链接脚本决定。比如STM32的链接脚本会规定FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K，而启动文件里的__initial_sp符号会被放在向量表最前面。修改了Flash起始地址后，记得同时修改中断向量表的偏移，否则程序虽然能编译通过，但上电一定起不来。

5.2 从Reset_Handler到main函数，启动文件替你干了多少事

很多人对启动文件的印象就是“编译器自动生成的模板”，平时压根不打开看。实际上，从复位到main之间，启动文件干了四件大事：

第一步，把主栈指针设置为向量表第一项的值。别嫌这一步简单，没有正确的栈，任何函数调用都会当场崩掉。

第二步，调用SystemInit函数。这个函数通常由芯片厂商的固件库提供，作用是配置系统时钟。比如把外部高速晶振（HSE）启动起来，配置PLL锁相环，把系统主频拉到芯片最高标称值。一个典型的错误是：忘记配置Flash等待周期，结果把主频提上去后程序周期性地跑飞。

第三步，拷贝.data段到RAM，清零.bss段。.data段是已初始化的全局变量，.bss段是未初始化的全局变量。拷贝和清零都是启动代码必须做的，不然你在main里面给全局变量初值就会失效。这里有个坑：如果拷贝地址和RAM的物理地址不连续，链接脚本的__ram_start和__ram_end符号配置错误，会导致变量区覆盖了栈区，程序表现为“有时正常、有时莫名复位”。

第四步，调用__main（Cortex-A/M的C库启动函数）或者直接跳转到main。如果用的是GCC环境，启动文件通常会调用_start，再由C运行时完成标准库的初始化，最后才进入main。

你需要记住的核心结论是：启动代码不是可有可无的模板，它决定了C语言环境是否就绪。如果main之前出了问题，你连printf都看不到输出，因为标准输出和串口重定向本身就在main之后的用户代码里。

5.3 启动代码的若干反直觉错误

我想列举一些自己在实际调试中碰到过的启动阶段问题，每一个都是血泪教训：

第一，中断来了没人处理。复位后的处理器默认全局中断是关闭的，但如果你在SystemInit或者早期初始化里就开启了某个外设中断，而此时中断处理函数还没被正确链接进向量表，一旦中断触发，系统会跳进HardFault。

第二，栈太小导致启动崩溃。有些芯片默认中断栈只有几百字节，如果启动阶段就调用了较深的函数链，比如文件系统挂载、长字符串拼接，栈很容易溢出。溢出后的表现五花八门，最典型的是变量被莫名改写、程序跳进HardFault。

第三，data段拷贝被优化掉了。编译优化等级开高后，如果链接脚本描述有误，编译器可能认为某些内存操作是“无用操作”而删掉。我曾经在ARM GCC的O2优化下遇到过全局变量初值全丢失的诡异现象，最后发现是链接脚本里的VMA/LMA地址配置错误，导致拷贝源和目标重合了。

6. 三者的交接协议：跳转时的各种细节与避坑清单

6.1 Bootloader跳转应用前，必须做对这几件事

很多人写Bootloader时跳得特别干脆，一条函数指针调用就完事，结果应用就是跑不起来。其实跳转前的准备工作，比跳转本身重要得多。我梳理了一份我每次都会检查的清单：

• 关闭全局中断（包括定时器、DMA、外设产生的各种中断）；
• 禁用SysTick定时器，并清除SysTick的中断挂起标志；
• 将当前使用的外设恢复到复位状态，避免残留配置干扰应用；
• 重新定位向量表。Cortex-M使用SCB->VTOR指向新的向量表地址；Cortex-A则需要在MMU/页表中映射新地址；
• 如果要跑RTOS，还需要考虑是否关闭MMU和缓存，或者在跳转前做一次cache clean；
• 确认跳转地址是按4字节对齐的合法地址，并且没有超过Flash容量边界。

其中向量表重定位是最容易被遗忘的一步。如果你在Bootloader里把向量表设成了Bootloader自身的起始地址，然后直接跳到应用，中断会产生，却跳回Bootloader的向量表去取处理函数——结果就是异常处理逻辑和行为完全错乱。这种问题排查起来特别迷惑，建议在Bootloader里加上启动打印，明确打印出即将跳转的地址和向量表偏移值，可以有效定位。

6.2 启动失败排查：从“完全没反应”到“反复复位”

排查启动问题，一定要按照“从底层到上层”的顺序来，千万别一上来就怀疑应用代码逻辑。

第一优先级是电源和时钟。上电后用示波器同时测量电源轨和复位引脚，确认复位释放时间是否满足芯片要求。很多板子上电“没反应”，其实是POR（上电复位）时间不足，或者电源毛刺导致反复复位。

第二优先级是启动介质配置。检查BOOT引脚、eFuse设置是否正确。尤其是从外部Flash启动时，如果Flash芯片没有焊接好，或者引脚虚焊，ROM Code根本没法定址到有效程序，自然串口一句打印都没有。

第三优先级是串口打印。Bootloader里从一开始就初始化调试串口，并打印一条起始日志。如果连起始日志都没有，问题大概率出在ROM Code阶段或者Bootloader早期初始化阶段；如果有起始日志但没有后续日志，问题就出在中间某一步的时钟或DDR配置上。

第四优先级是看门狗。有些应用里看门狗一旦开启，喂狗不及时就会复位。如果你的应用代码很长、初始化很久，而Bootloader跳转前没有喂一下狗或者清零相关的看门狗状态，上位机看到的可能就是“系统反复重启”。

6.3 链接脚本、OTA分区与版本兼容的几个坑

最后聊几个工程化层面的问题。

链接脚本是启动流程的“隐藏角色”。你写的每一个符号地址，比如_estack、__bss_start__、__etext，最终都会影响启动代码的执行。改启动代码时，一定要同步看链接脚本，确保内存布局一致。我见过有人只改了Flash起始地址，却没动向量表偏移，结果应用程序一进中断就死循环，差不多是最典型的低级错误。

OTA升级时更要小心分区兼容性。新老版本的Bootloader对分区的编号、起始地址、大小定义必须保持一致。如果新版本Bootloader把应用分区地址从0x08010000改成了0x08020000，而旧版本OTA包的目标地址还在0x08010000，升级后系统就会跳转到错误地址而死机。

有一个经验分享给你：在Bootloader和应用的代码里，都增加一个固定的“启动信息结构体”，放在Flash保留区域，记录当前启动次数、上次启动结果、固件版本号。每次启动时先读这个结构体，再决定是直接启动还是升级。这样不管你的启动流程怎么改，关键信息都有据可查，排查问题会轻松很多。

7. 我在实际调试中的几点体会

代码写多了，你会发现启动流程其实是整块嵌入式系统里最考验“全局观”的部分。它不是某一个函数的优化问题，而是从芯片硬件、固化代码、可移植程序到应用工程的完整链路。任何一个环节脱节，都可能导致神秘的启动失败。

我个人受到的教训是：永远不要在“没验证过的最小系统”上直接调试复杂启动流程。新板子到手，第一件事永远是写上电点灯、串口打印这类最小启动测试。确认时钟、复位、Flash读取都正常后，再一步步加Bootloader和应用代码。别急着烧完整的镜像，否则出了问题你根本分不清是哪一级的问题。

另一个体会是：多用启动阶段的日志输出，把交接过程用文字“看见”。不管是ROM Code阶段的ISP命令，还是Bootloader里的跳转地址打印，又或者是启动文件里临时加的GPIO翻转标记，都能在关键时刻帮你缩小排查范围。

最后想提醒一点：ROM Code和Bootloader的资料，官方手册和数据手册里写得比较分散，你花点时间把它们串起来读一遍，建立自己的“启动时序图”，后续做任何平台的移植都会事半功倍。启动流程这个东西，搞懂了一次，换芯片只是换皮不换骨。