APP就是平时写的单片机上的应用程序，而BootLoader本质上和APP一样，也是平时写的应用程序。BootLoader只不过是拥有从外部接收数据，更新Flash（也就是APP），跳转至APP功能的特殊APP罢了。

以STM32F103为例，如果没有BootLoader，flash分布就如下图左半部分。如果有BootLoader，就如下图右半部分，将flash分为两部分（这里举例用0x800 4000做分界线），存储了两个应用程序（BootLoader和APP）

从外部接收数据，更新Flash，普通的APP也会有这样的需求。不常见的也就是从BootLoader跳转到APP这个功能了。STM32 单片机启动流程中介绍了单片机上电后的启动流程，其实也就主要干了两件事：

然后单片机执行复位中断服务函数，在复位中断服务函数中设置中断向量表的偏移地址，准备C环境，最后跳转到main()函数。同理，从Bootloader跳到APP也需要干这两件事情，只不过上电时是单片机自动加载的MSP和PC，而从Bootloader跳到APP则需要我们编写函数进行跳转。

下面是STM32 跳转到APP的具体函数，在BootLoader函数中调用即可跳转到APP_ADDR，如果该地址存放了APP的bin文件则会运行APP的复位中断服务函数（一定要记得在APP中修改中断向量表偏移地址，如APP中不修改则默认使用BootLoader的中断向量表，APP中发生中断时就会去查BootLoader的中断向量表，从而调用BootLoader的中断服务函数），进而运行APP的main()函数。同理，APP跳转到BootLoader，修改跳转地址 APP_ADDR 为BootLoader地址（这里为0x8000000）即可实现.

单片机升级的原理大致是：收到升级指令——>MCU复位或者跳转到Boot程序区——>擦除对应的Flash区域——>获取APP数据——>写入FLASH数据——>校验——>跳转到APP应用程序区

单APP方案将Flash分成了三个部分，Boot+APP+Config，Boot负责更新APP；APP实现程序的主要功能；Config区域主要是存放APP是否完整的标志位，协助Boot判断是否要跳转到APP。单APP有个明显的缺点：开始升级时就将原来的APP擦除了，如果升级中断则会一直停留在BootLoader，直至APP升级完成。

双APP方案将Flash分成了四个部分，Boot+APP1+APP2+Config，Boot负责更新APP；APP1实现程序的主要功能；APP2相当于缓冲区，Boot升级APP时，会将接收到的APP数据包写入APP2，当APP数据包全部接收完毕，再将APP2搬运到APP1，这样就避免了单APP方案，升级中断一直停留在BootLoader的尴尬； Config区域主要是存放APP1是否需要升级的标志位，协助Boot判断是否要将APP2的内容搬运至APP1。

STM32自举具体信息可以去官网查看手册AN2606 如果BOOT0为高电平，复位后将从系统存储器自举（系统存储区存放着系统bootLoader，出厂时，官方固化在单片机中的一段代码，用户无法修改的。在STM32中，常用的串口下载，DFU就是系统bootLoad中的功能）

使用系统bootLoader需要在复位时调整BOOT0管脚的电平，使用起来还是比较麻烦的。系统BootLoader也是FLash中的一段程序，只不过是官方烧录的不可修改的，我们可以利用前面说的跳转到APP的方法跳转到系统BootLoader，这样就可以不修改BOOT0管脚电平，直接进入系统BootLoader，利用系统BootLoader的下载功能下载更新程序。

在手册中的闪存章节，找到系统BootLoader的起始地址0x1FFF F000，将APP_ADDR宏定义改为系统BootLoader地址即可跳转到系统BootLoader

从APP跳转到系统BootLoader后，利用STM32CubeProgrammer工具更新程序