STM32固件升级之基础知识（一）

这里以KEIL开发环境和STM32F407为例。

上电时单片机首先进入复位中断 Reset_Handler，即汇编文件的复位中断处理函数。

并且有一个中断向量表默认存在于flash地址开始处。

为什么说是默认的呢？这是因为如果没有特殊要求我们一般很少回去修改中断向量表。实际上这个中断向量表是可以更改的。如果我们更改了中断向量表，在执行新的程序时，必须在地址开始处建立一个新的中断向量表,因为复位后,程序默认(硬件决定的)从flash开始的第一个字读取栈指针,第二字就是复位中断的入口,并根据该指针最终进入复位函数中执行相应的函数。如果修改中断向量表之后的新程序没有对应的中断向量表程序是无法启动的。

那么既然前面说可以重新设定中断向量表的位置，那必然有一个寄存器记录着这张表的位置，这就是 VTOR 寄存器。从《Cortex-M3 权威指南》可以看该寄存器的介绍：

并且向量表的偏移量有如下要求：

64*4 是因为一个表项为 4 字节。更具体的关于更改向量表的信息查看《Cortex-M3 权威指南》。

在复位处理函数中有进入 SystemInit 函数执行，在函数里有一个设置中断向量表的位置的语句。

VECT_TAB_OFFSET 默认情况下就是 0。因为这是官方库函数，并且上电之后必定进入复位中断函数处理，因此必定会执行重新定位向量表的操作。因此只要修改宏定义就可以重新定位向量表。

先准备两个程序，一个为 bootloader，用于更新程序，一个为 APP，即固件程序。

首先确定 BootLoader 为上电最先执行的函数，需要通过下载器下载，而 APP 则可以通过有线（spi、i2c、usart、usb）、无线（Bluetooth、WiFi）等各种方式下载，只要能够正确传输数据即可。

因为两个程序中只能有一个程序正在运行，所以可以共用 RAM。所以这个时候对一些变量就有必要进行初始化，以防 APP 程序使用的 RAM 空间存在之前的数据。上电之后，因为硬件问题（可能是 VTOR 寄存器断电不保存数据吧），导致单片机自动从中断向量表 1 中寻找复位中断处理函数，此时必然最终会进入BootLoader 程序中执行。因为向量表第一个字（32 字节）存放的地址就是 BootLoader 程序编译出来的中断处理函数地址。所以在这个程序一般就是初始化传输方式，然后在一定时间里判断是否需要更新固件，需要则将更新固件并跳转到第二个复位中断函数中执行，而如果超时则自动跳转到第二个复位中断函数中执行。

一般更新固件的文件类型为 bin 文件，文件可以直接拷贝到 flash 中并且执行。那么 bin 文件应该是怎样的呢？在MDK中的"Options for target"选项卡中找到User这个选择,在After Build/Rebuild的选择窗口中，勾选"Run#1"在相对应的对话栏中写入$K\ARM\ARMCC\bin\fromelf.exe --bin --output=@L.bin !L可以在当前项目目录下生成bin文件。生成的APP程序文件如下所示。

和普通程序的生成没多大区别，都是编译器编译得到的目标的程序。但是我们要如何让编译将程序放在该放的地址呢，即在得到这个 bin 文件之后，当从向量表的第二字获取的地址刚好指向了 Reset_Handler 函数呢？即这里面存放的地址应该是绝对地址。可以通过设置KEIL即可:

上面设置为 0x8001000，这样在编译过程中就会将整个程序的开始放在 0x8001000，并且其他函数地址也会根据该地址自动确定地址，而变量和栈等数据则存放在 0x20000000 开始处（和 BootLoader 一样，所以它们其实是共用 RAM），这样程序才能正确执行。但是 BootLoader 怎么找到 APP 的第一个函数的地址并进入执行呢？就是从接收到的 bin 文件里找。之前说过程序的开始处就是一张向量表（编译器自动处理的），也就是这个程序的向量表开始就在 0x8001000，而 bin 文件可以直接看成一个 flash 空间，程序应该放在 0x8001000，在 bin 文件就是在文件的开始处，这样就能找到栈顶指针和复位中断处理函数了。有点绕，看示意图（数字无意义）：

但是 BootLoader 虽然找到了 APP 程序的复位向量地址，并且整个 APP 程序拷贝到 0x08001000 开始处了，BootLoader 程序可以通过跳转语句调到复位中断处理函数执行，并且能从向量表出得到栈顶位置，并且其他函数地址也由编译器确定了，执行应该是没问题的。但是一旦中断来了，根据 stm32 的中断机制，肯定会从中断向量表中找地址，而找中断向量表是通过 VTOR 来定位的，而在跳转后虽然进入了复位中断处理函数，并进入了 SystemInit()中执行，也执行了重新设置 VTOR 寄存器的操作，但是你的 VECT_TAB_OFFSET 还是 0……这样一旦中断发生，通过 VTOR 定位又跑到 BootLoader 的向量表去执行处理程序了。所以在进入 APP 函数后，需要重新定位我们新的向量表，只需要修改 VECT_TAB_OFFSET 即可，而这个偏移量有限制……，而且这个偏移量其实也就是给 BootLoader 程序预留的空间，所以在这里 VECT_TAB_OFFSET 设置为 0x1000，符合限制条件，并且这个偏移量应该大于 BootLoader 程序的总大小，这样就 OK 了。跳转到复位中断处理函数之前，必须重新设置栈顶位置，虽然是共用 RAM，但毕竟 BootLoader 程序编译下的 RAM 分配和 APP 程序编译下的 RAM 分配可能是不同的，需要重新确定栈顶位置。

总结：
1、BootLoader 两个功能，一个是通过标志是否需要更新 APP，如果需要则接收并将其烧写到指定地址的 flash 空间中，并从该地址中获取栈顶指针和 Reset_Handler 指针，并跳转到该函数执行；
2、APP 程序需要让编译器将程序存放在指定地址空间里，并重新定位中断向量表的位置。
3、每次上电复位之后程序都会直接从 BootLoader 的 Reset_Handler 函数执行，而不是从 APP 中执行。
4、这个地址有两个限制：BootLoader 程序大小和向量表地址限制，必须两者都符合要求。