超完整，讲解单片机的BootLoader

对于一个复杂的单片机项目来说，有一个 BootLoader（以下简称BL）是非常重要的。它可以使得你的应用程序代码维护和升级更加便捷。

本篇文章，带你了解为什么要设计 Bootloader，以及如何设计 Bootloader。争取做到知其然、知其所以然。

通过对 BL 进行详细的讲解，希望让大家可以体会到它的重要性。

1、烧录方式的更新迭代

古老的烧录方式

单片机诞生于20世纪80年代，以 51 为代表开始广泛应用于工业控制、家电等很多行业中。起初对于单片机的烧录，也就是将可执行的程序写入到其内部的ROM中，不是一件容易的事情，而且成本不低，因为需要依赖于专门的烧录设备。由于受到半导体技术与工艺的限制，对于ROM的烧写大多需要高压。这种境况一直持续到2000年左右，如图所示。

ISP与ICP烧录方式

随着低压电可擦写ROM的成熟，单片机开始集成可通过数字电平直接读写的存储介质。

其最大的优势在于可实现在系统或在电路直接烧录程序，而无需像以前一样把单片机芯片从电路中拿出来，放到编程器上，这种烧录方式就是 ISP(In System Programming) 或 ICP(In Circuit Programming)，如图所示。

有人问过这样一个问题：“ISP和ICP我都听说过，都说是可以在电路板上直接烧录程序，而无需拿下芯片，那ISP和ICP有什么区别？”

从广义上来说，两者没有区别，平时我们把其意义混淆也毫无问题。非要刨根问底的话，那可以这样来理解：

ISP要求单片机中驻留有专门的程序，用以与上位机进行通信，接收固件数据并烧录到自身的ROM中，很显然ISP的单片机是需要可运行的，即要具备基本的最小系统电路(时钟和复位)。

而 ICP 可以理解为 MCU 就是一块可供外部读写的存储电路，它不需要预置任何程序，也不需要单片机芯片处于可运行的状态。

支持 ISP 或 ICP 的芯片，以AT89S51最为经典，当时从 AT89C51 换成 S51，多少人因此不再依赖烧录器而大呼爽哉。这种并口下载线非常流行，如图3.3，网上还有各种ISP小软件，可以说它降低了很多人入门单片机的门槛，让单片机变得喜闻乐见。一台电脑、一个S51最小系统板、一条并口ISP下载线，齐了！

更方便的ISP烧录方式

串口ISP

后来我们发现带有并口的电脑越来越少。那是在2005年前后，STC单片机开始大量出现，在功能上其实与S51相差无几，甚至比同期的一些高端51单片机还要逊色。但是它凭借一个优势让人们对它爱不释手，进一步降低了单片机的学习门槛。

这个优势就是--串口ISP，这是真正意义上的 ISP，如图所示。

再后来，9针串口都很少见了，只有USB。这促使一个烧录和调试神器炙手可热 -- USB TTL串口。这下232转换芯片省掉了，直接通过USB进行烧录。这种方式造福了无数的单片机学习者和工程师。

多年来，在串口与单片机的交互上，我动了很多脑筋，这也是我乐于开发 Bootloader 的一个原因。我希望“USB串口在手，一切全有！”

STC 并不是第一个使用串口 ISP 烧录程序的，但它是最成功和最深入人心的。与之同期的很多单片机，包括时至今日仍然应用最广泛的 STM32 全系列也都支持了串口 ISP，它成为了一种标配的、非常普遍的程序烧录手段。

各种USB ISP

串口ISP固然方便，但是下载速度是它的硬伤，当固件体积比较大的时候，比如一些大型嵌入式项目的固件动辄几百K，甚至几M，再用串口ISP就未免太慢了。所以一些单片机配有专门的USB ISP下载器。以下列举几种比较主流单片机及其USB ISP下载器。

1) AVR

AVR 单片机曾经盛极一时，但经历了 2016 年的缺芯风波之后，加之 STM32 的冲击，开始变得一蹶不振，鲜有人用了。与之配套的USB ISP下载器非常多样，有些是官方发布的，更多的是爱好者开源项目的成果，如图所示。

2) C8051F

3) MSP430

我们会发现，一个具体良好生态的主流单片机，一定有配套的高效便捷的烧录下载工具。可见一种好的烧录方式，对单片机开发是多么重要。

不论是串口 ISP 还是各种专用的 ISP 下载器，都有一些共同的弊端。

1、依赖于专门的上位机或下载器硬件，不能作到统型；

2、下载器价格仍然比较高，尤其是原厂的，这也是为什么有些单片机催生出很多第三方的下载器，比如 AVR；

3、下载的时候通常需要附加额外的操作，比如STC要重新上电、STM32需要设置BOOT引脚电平等等。这些额外的操作都增加了烧录的复杂性。尤其是在产品形态下要去重新烧录程序，比如嵌入式升级，就要打开外壳，或将附加信号引出到壳外。这都是非常不高效，不友好的作法。

如果有一种烧录方法，对于任何一种单片机：

1、通信方式统一（比如一律都用串口)）；

2、提供一个友好的操作界面（比如命令行方式）；

3、高效快速，没有附加操作，最好一键自动化烧录；

4、另外再增加一些嵌入式固件管理的功能（比如固件版本管理）。

这一定会让我们事半功倍。Bootloader 就能实现上述的这一切！

关于Bootloader

Bootloader的基本形态

直接看图

可以看到BL就是一段存储在ROM中的程序，它主要实现4个功能：

1、通过某种途径获取要烧录的固件数据；

2、将固件数据写入到ROM的APP区中；

3、跳转到APP区运行，将烧录进去的用户程序引导起来；

4、在此过程中，提供必要而友好的人机交互界面。

这么说可能不好理解，我们还是通过实例来进行讲解。

Bootloader的两个设计实例

下面的两个实例，用于说明BL的实际应用形态，不涉及具体的实现细节，旨在让大家了解 BL 实际是如何运行的。

带Shell命令行的串口BL

基本的操作逻辑如下：

1、通过超级终端、SecureCRT 或 Xshell 之类的串口终端输入命令 program；

2、BL 接收到命令后，开始等待接收固件文件数据；

3、串口终端通过某种文件数据传输协议（例如  X/Y/Zmodem协议）将固件数据传给BL；

4、BL 将固件数据写入到 ROM 的 APP 区中；

5、BL 将 APP 区中的程序引导运行起来。

更具体的示意如图所示。

这里把操作逻辑说得很简单，实际实现起来却并不容易，我们放在后面去细究其具体实现。

插SD卡即烧录的BL

基本的操作逻辑如下：

1、将待烧录的固件拷贝到SD卡中；

2、将SD卡插入到卡槽中；

3、BL 检测到 SD 卡插入，搜索卡中 BIN 文件；

4、将 BIN 文件数据读出写入到 ROM 的 APP 区中；

5、BL 将 APP 区中的程序引导运行起来。

如图所示。

通过这两个设计实例，大家应该已经了解BL是什么了吧。有没有感受到 BL 是比 ISP 烧录器更通用、更灵活、更友好、功能更强大的固件烧录和管理手段呢？

有人可能知道 Linux 下的 Uboot，它就是一个强大的 BL，它提供非常强大的刷机（烧录操作系统镜像）的功能以及完备而灵活的Shell界面，如图所示。其实我们电脑的BIOS也是一种广义的BL。

那如何实现一个BL呢？别急，要实现BL是需要满足一些基本要求的。

BL实现的要点

首先要说，并不是任何一个单片机都可以实现BL的，要满足几个要点。

芯片体系架构要支持

来看图

我们知道单片机程序的最开头是中断向量表，包含了程序栈顶地址以及Reset程序入口，通过它才能把程序运行起来。很显然在从BL向APP跳转的时候，APP程序必须有自己的中断向量，并且而且单片机体系架构上要允许中断向量表的重定向。

传统51单片机的中断向量表只允许放到ROM开头，而不能有偏移量，所以传统51单片机是不能支持BL的。

有人要问“你这不是自相矛盾吗？你前面说STC的51单片机是支持串口ISP的，那它应该内置有ISP程序，我理解它应该和BL是一个道理。”

没错，它内置的 ISP 程序就是一种 BL。STC 之所以可以实现 BL 功能，是因为宏晶半导体公司对它的硬件架构进行了改进，请看图

可以看到，STC51 单片机多出了一块专门存放 BL 的 ROM，称为 BOOTROM。

网上有一位叫 shaoziyang 的网友为 AVR 单片机写了一个 BL，还配套开发了一款叫 AVRUBD 的上位机，如图。（AVRUBD是很有用的，它可以让我们实现隔空烧录），实现了AVR单片机的串口烧录，让很多人摆脱了对USBISP之类ISP下载器的依赖（虽然ISP下载器已经很方便了，但它毕竟还需要银子嘛）。

AVR 在硬件架构上与 STC51 是一个套路，如图所示。

通过配置AVR的熔丝位可以控制复位入口地址以及BOOT区的大小和开始地址，如图所示。

讲到这里，有人会说：“那有没有一种单片机，程序放在ROM的任何位置都可以运行起来，也就是中断向量表可以重定位？”

当然有，这种单片机还很多，其中最典型的就是 STM32。它的程序之所以可以放之各地皆可运行，是因为在它的 NVIC 控制器中提供了中断向量表偏移量的相关配置，这个后面我们再详细说。

ROM 要支持 IAP

这也是需要单片机硬件支持的。很好理解，在 BL 获取到固件数据之后，需要将它写入到 ROM 的 APP 区中，所以说单片机需要支持 IAP 操作，所谓 IAP 就是 In Application Programming，即在应用烧录。也就是在程序运行过程中，可以对自身ROM进行擦除和编程操作。

大家仔细想想是不是这样？似乎支持串口ISP的单片机都支持IAP功能。STC还把这一功能包装成了它的一大特色，可以用内部ROM来充当EEPROM的功能，可以在运行时记录一些掉电不丢失的参数信息。

STM32 的 ROM 擦写在配套的固件库(标准库或HAL库)中已经有实现，大家可以参考或直接使用。

APP程序的配套修改

为了让BL可以顺利的将APP程序引导运行起来，APP 程序在开发的时候需要配合BL作出相应的修改。最重要的就是 APP 程序的开始地址（即中断向量表的开始地址）以及对中断控制器的相应配置。

对于51、AVR这类单片机APP程序不用修改，具体原因大家应该明白。这里主要对 STM32 APP程序如何修改进行详细讲解。

我们依然是结合实例，请看图所示。

假设我们所使用的 STM32 的 ROM 总大小为 128KB，BL程序的体积是16K，APP程序紧邻BL，那么APP区的开始地址为0X08004000，也就是APP程序的中断向量表偏移地址为0X4000。

如果我们使用MDK作为开发环境的话，需要修改这里，如图所示。

而如果我们使用的是 gcc 的话，则需要对 link.ld 链接文件进行修改，如图3.18。

然后我们还需要对NVIC的中断向量表相关参数进行配置，主要是中断向量表的偏移量，如下代码。

#define VECT_TAB_OFFSET 0x4000

OK，经过修改后的程序，我们把它放到 ROM 的 0X08004000 开始地址上，然后再让BL跳转到这个地址，我们的程序就能运行起来了。

有人又会问：“BL中的跳转代码怎么写？”别急，这是我们要讲的下一个要点。

BL中的跳转代码

跳转代码是 BL 要点中的关键，直接关系到 APP 程序能否正常运行，如图

我直接给出 STM32 的 jump_app 函数代码。

typedef void (*iapfun)(void);

iapfun jump2app; 

void MSR_MSP(u32 addr)
{
  __ASM volatile('MSR MSP, r0');    //set Main Stack value*
  __ASM volatile('BX r14');*
}


void load_app(u32 appxaddr)
{
  if(((*(vu32*)appxaddr)&0x2FFE0000)==0x20000000)//**检查栈顶地址合法*
  {

    //**用户代码区第二个字为程序开始地址(**复位地址)
    jump2app=(iapfun)\*(vu32\*)(appxaddr+4);

    //**初始化APP**堆栈指针(**用户代码区的第一个字用于存放栈顶地址)
    MSR_MSP(*(vu32*)appxaddr);  

    jump2app();   //**跳转到APP.
  }
}

这段代码大家自行研究，如果展开讲就属于赘述了。

到这里BL相关的要点就介绍完了，大家应该有能力去完成一个简单的BL了。基于 STM32 设计的一个小实验，大家有兴趣可以小试牛刀一下，如图

我们将 BL 程序用 Jlink 烧录到 0X08000000 位置，而把 APP 程序烧录到 0X08002000 开始位置，然后复位，如果串口打印了 hello world 或流水灯亮起来了，就说明我们的 BL 成功了。

把Bootloader玩出花

上面我所讲的都是BL最基础的一些内容，是我们实现BL所必须了解的。BL真正的亮点在于多种多样的固件数据获取方式。

BL的实现与延伸（串口传输固件）

前面我讲到过两个BL应用的实例，一个是串口传输固件文件，一个是SD卡拷贝固件文件。它们是在实际工程中经常被用到的两种BL形式。

这里着重对前一个实例的实现细节进行讲解剖析，因为它非常具有典型意义，如图

这个流程图提出了3个问题：

• 串口通信协议是如何实现的？
• 为什么获取到上位机传来的固件数据，不是直接写入到APP区，而是先暂存，还要校验？

• 对固件数据是如何实现校验的？

第一个问题，串口通信协议以及文件传输实现的相关内容略显繁杂，在以后的文章会专门进行讲解。

第二个问题：经过串口传输最终由单片机接收到的固件数据是可能出现差错的，而有错误的固件冒然直接写入到APP区，是一定运行不起来的。所以，我们要对数据各帧进行暂存，等全部传输完成后，对其进行整体校验，以保证固件数据的绝对正确。

针对第三个问题，我们要着重探讨一下。

一个文件从发送方传输到接收方，如何确定它是否存在错误？

通常的做法在文件中加入校验码，接收方对数据按照相同的校验码计算方法计算得到校验码，将之与文件中的校验码进行对比，一致则说明传输无误，如图。

上图是对固件文件的补齐以及追加校验码的示意。

为什么要对文件补齐？嵌入式程序经过交叉编译生成的可烧录文件，比如 BIN，多数情况下都不是128、256、512或1024的整数倍。这就会导致在传输的时候，最后一帧数据的长度不足整帧，就会产生一个数据尾巴。

取整补齐是解决数据尾巴最直接的方法。这一操作是在上位机上完成的，通常是编写一个小软件来实现。这个小软件同时会将校验码追加到固件文件末尾。这个校验码可以使用校验和（Checksum）或者 CRC，一般是 16 位或 32 位，如图，通过一个小软件实现对固件文件补齐和添加校验码。

又有人会问：“要把整个固件暂存下来，再作校验，那得需要额外的存储空间吧，外扩ROM（FlashROM或EEPROM）？”

是的。如果想节省成本，我们也可以不暂存，传输时直接烧写到APP区。这是有风险的，但是一般来说问题不大（STC和STM32的串口ISP其实也都是实时烧写，并不暂存）。

因为在传输的过程中，传输协议对数据的正确性是有一定保障的，它会对每一帧数据进行校验，失败的话会有重传，连续失败可能会直接终止传输。所以说，一般只要传输能够完成，基本上数据正确性不会有问题。

但是，仍然建议对固件进行整体校验，在成本允许的情况下适当扩大ROM容量。同时，固件暂存还有一个另外的好处，在APP区中的固件受到损坏的时候，比如固件意外丢失或IAP时不小心擦除了APP区，此时我们还可以从暂存固件恢复回来（完备的BL会包含固件恢复的功能）。

其实也不必非要外扩ROM，如果固件体积比较小的话，我们可以把单片机的片上ROM砍成两半来用，用后一半来作固件暂存。将片上ROM划分为3部分：

我们将片上ROM划分为3部分，分别用于存储 BL、APP 固件以及暂存固件。比如我们使用 STM32F103RBT6，它一共有128KB 的 ROM，可以划分为 16K/56K/56K。

有些产品对成本极为敏感。我就有过这样的开发经历，当时使用的单片机是 STM32F103C8T6，片上ROM总容量为64K，固件大小为48K，BL为12K。在通过BL进行固件烧写时根本没有多余的ROM进行固件暂存。我使用了一招“狗尾续貂”，如图

我无意中了解到 STM32F103C8T6 与 RBT6 的晶元是同一个。只是因为有些芯片后 64KB 的ROM性能不佳或有瑕疵，而被限制使用了。我实际测试了一下，确实如此。

但是后 64K ROM 的使用是有前提的，也就是需要事先对其好坏进行验证。如果是好的，则暂存校验，再写入APP区；而如果是坏的，那么就直接在固件传输时实时写入APP区（这个办法我屡试不爽，还没有发现后64K有坏的）。

以上振南所介绍的是一种“骚操作”，根本上还是有一定的风险的，ST 官方有声明过，对后 64K ROM 的质量不作保证，所以还是要慎用。

10米之内隔空烧录

这个“隔空烧录”源于我的一个 IoT 项目，它是对空调的外机进行工况监测。大家知道，空调外机的安装那可不是一般人能干的，它要不就在楼顶，要不就在悬窗上。这给硬件升级嵌入式程序带来很大的困难。

所以，我实现了“隔空烧录”的功能，其实它就是串口BL应用的一个延伸，如图所示，通过蓝牙串口模块实现“隔空烧录”。

“隔空烧录确实牛，但是总要抱着一个电脑，这不太方便吧。”确实是！还记得前面我提过的AVRUBD通信协议吗？它的上位机软件是有手机版的。这样我们只要有手机，就能“隔空烧录”了，如图，手机连接蓝牙串口模块实现“手机隔空烧录”。

“哪个APP？快告诉我名字”，别急，蓝牙串口助手安卓版，下图是正在传输固件的界面。

AVRUBD其实是对 Xmodem 协议的改进，这个我们放在专门的文章进行详细讲解。

BL的分散烧录

我们知道BL的核心功能其实就是程序烧录。那你有没有遇到过比较复杂的情况，如图所示，一个系统（产品）中有多个部件需要烧录固件。

这种情况是有可能遇到的。主 MCU+CPLD+通信协处理器+采集协处理器就是典型的复杂系统架构。这种产品在批量生产阶段，烧录程序是非常繁琐的。首先需要维护多个固件，再就是需要一个个给每一个部件进行烧写，烧写方式可能还不尽相同。所以我引入了一个机制，叫“BL的分散烧录”。

首先，我们将所有的固件拼装成一个大固件(依次数据拼接)，并将这个大固件预先批量烧录到外扩 ROM 中，比如spiFlash；再将主MCU预先烧录好BL；然后进行SMT焊接。

PCBA生产出来之后，只要一上测试工装(首次上电)，BL会去外扩ROM中读取大固件，并从中分离出各个小固件，分别以相应的接口烧录到各个部件中去。配合工装的测试命令，直接进行自检。

这样做，批量化生产是非常高效的。当然，这个 BL 开发起来也会有一定难度，最大问题可能还是各个部件烧录接口的实现（有些部件的烧录协议是比较复杂的，比如 STM32 的 SWD 或者 ESP8266 的 SLIP）。

BL没有最好的，只有最适合自己的。通常来说，我们并不会把BL设计得非常复杂，原则上它应该尽量短小精炼，以便为APP区节省出更多的ROM空间。毕竟不能喧宾夺主，APP才是产品的主角。

不走寻常路的BL

Bootpatcher

我来问大家一个问题：“Bootloader在 ROM 中的位置一定是在 APP 区前面吗？”很显然不是，AVR 就是最好的例子。那如果我们限定是 STM32 呢？似乎是的。上电复位一定是从0X08000000位置开始运行的，而且BL一定是先于APP运行的。

在某些特殊的情况下，如果 APP 必须要放在0X08000000位置上的话，请问还有办法实现BL串口烧录吗？要知道APP在运行的时候，是不能 IAP 自己的程序存储器的（就是自己能自己擦出重新烧录新固件）。请看图，BL位于APP之后称之为Bootpatcher。

APP运行时，想要重新烧录自身，它可以直接跳转到后面的BL上，BL运行起来之后开始接收固件文件，暂存校验OK之后，将固件写入到前面的APP区。然后跳转到 0X08000000，或者直接重启。这样新的APP就运行起来了。

这个位于 APP 后面的 BL，我们称之为 Bootpatcher（意为启动补丁）。但是这种作法是有风险的，一旦 APP 区烧录失败，那产品就变砖了。所以这种方法一般不用。

APP反烧BL

前面我们都是在讲BL烧录APP，那如果BL需要升级怎么办呢？用 JLINK。不错，不过有更直接的方法，如图，APP烧录BL区。

这是一种逆向思维，我们在 APP 程序中也实现接收固件文件，暂存校验，然后将其烧录到 BL 区。这种作法与Bootpatcher 同理，也是有一定风险的，但一般都没有问题。

最后

OK，本系列文章对BL进行了详尽的剖析讲解，应该做到了深入浅出，包含基本的原理，以及实例的实现，还有一些知识的扩展。希望能够对大家产生启发，在实际的工作中将这些知识付诸实践。

作者/来源：一起学嵌入式