实现STM32的空中升级OTA

鸣涧

实现STM32的空中升级OTA

前一段利用空闲时间折腾物联网，实现了远程温度数据和电压数据的获取，以及远程点灯，突发奇想，既然都是远程操作，那干脆软件升级也远程算了，因为软件无论是日常维护还是功能的添加，升级是必不可少的，远程图的就是一个方便，所以这个功能还是值得研究的。

在介绍OTA之间，先来认识一下有线通讯情况下的程序下载原理以及它的实现过程。

1. STM32的IAP技术介绍

目前，Cortex-M3的程序烧录方式可以分为三种：ICP，ISP，IAP。

1.1 ICP(In-Circuit Programming)

在电路中编程。使用厂家配套的软件或仿真器进行程序烧录，目前主流的有JTAG接口和SWD接口，常用的烧录工具为J-Link、ST-Link等。

在程序开发阶段，通常在连接下载器的情况下直接使用编程软件进行程序下载调试。

在MDK软件中可以选择不同的下载器。

1.2 ISP(In-System Programing)

在系统中编程。以STM32为例，其内置了一段Bootloader程序，可以通过更改BOOT引脚电平来运行这段程序，再通过ISP编程工具将程序下载进去。下载完毕之后，再更改BOOT至正常状态，使得MCU运行所下载的程序。

正点原子的STM32开发板中专门设计了一个单片机自动复位及设置Boot引脚电平状态的电路，便于程序下载。

1.3 IAP(In-Application Programming)

在应用中编程。IAP可以使用微控制器支持的任一种通信接口（如I/O端口、USB、CAN、UART、I2C、SPI等）下载程序或数据到FLASH中。IAP允许用户在程序运行时重新烧写FLASH中的内容。但需要注意，IAP要求至少有一部分程序（Bootloader）已经使用ICP或ISP烧到FLASH中。

无论是ICP技术还是ISP技术，都需要连接下载线，设置跳线帽等操作。一般来说，产品的电路板都会密封在外壳中，在这时若要使用ICP或ISP的方式对程序进行更新，则必然要拆装外壳，如果产品的数量比较多，将花费很多不必要的时间。

采用IAP编程技术，可以在一定程度上避免上述的情况。一般情况下，产品的外壳都会留有通信接口，若能通过这种通信方式对程序进行升级，则可以省去拆装的麻烦。在此基础上，若引入远距离或无线数据传输方案，更可以实现远程编程或无线编程。

某种微控制器支持IAP技术的首要前提是其必须是基于可重复编程闪存的微控制器。

STM32微控制器带有可编程的内置闪存，同时STM32拥有在数量上和种类上都非常丰富的外设通信接口，因此在STM32上实现IAP技术是完全可行的。

2. IAP方案设计

IAP技术的核心在于BootLoader程序的设计，这段程序预先烧录在单片机中，正常的APP程序可以使用BootLoader程序中的IAP功能写入，也可以两部分代码一起写入，以后需要程序更新时通过IAP进行代码更新。每次板卡上电都会首先执行BootLoader程序，在程序内判断进行固件升级还是跳转到正常的APP程序。

是否进行固件升级的判断可以从硬件和软件两个方面进行考虑。

硬件实现：通过拨码开关、跳线帽等方式设定单片机某一引脚电平状态，程序通过读取引脚电平判断是否需要升级。此种方式需要接触板卡进行操作，当板卡被封闭在外壳中或安装于不便于操作位置时很难实现。

软件实现-1：软件内设定一标志位（变量），通过判断标志位状态判断是否需要升级。该标志位状态掉电不能改变，故需要存储在外部EEPROM或单片机内部FLASH中。若存储在外部EEPROM，则需要增加额外的电路；若存储在单片机内部FLASH，由于FLASH每次写入都需要擦除一整页，会造成资源浪费。

软件实现-2：单片机每次上电首先进入BootLoader程序，在BootLoader中等待一定时间，若上位机软件在该时间段内发起通讯，则停留在BootLoader程序中等待固件升级；若该时间段内无通讯，则跳转到正常的APP程序。该方式每次上电都要等待一定时间，需要考虑是否可以接受。

在IAP过程中，单片机通过特定的通讯方式从上位机软件接收程序数据，并执行FLASH擦写操作对APP部分的程序进行更新。

IAP过程中传输的数据文件一般为后缀名为bin的文件，该文件内容与正常烧录进FLASH中的数据内容一致，便于程序升级。但是MDK软件并不能直接生成bin文件，需要进行一些配置。

fromelf.exe  --bin -o ..\OBJ\TIMER.bin ..\OBJ\TIMER.axf  //“TIMER”需要改成自己程序的名字

由于我把fromelf.exe所在目录添加到了环境变量，所以可以直接这样写。如未添加环境变量，则需要写清楚详细路径，该文件一般在MDK软件的安装目录下(D:\Keil_v5\ARM\ARMCC\bin)。

配置完成重新编译之后即可生成bin文件（OBJ目录）。

2.1 FLASH空间划分

BootLoader程序和APP 程序存放在 STM32 FLASH 的不同地址范围，一般从最低地址区开始存放 BootLoader，紧跟其后的就是 APP 程序。在FLASH足够大的情况下，还可以分配多个APP程序区域，便于恢复默认程序或者执行多段功能不同的程序。

不同型号STM32 FLASH大小，在进行FLASH空间划分之前，首先需要了解一下不同型号STM32单片机的FLASH大小。

对于不同容量的STM32F1系列产品，其FLASH页大小是不同的，具体的容量划分规则如下：

小容量产品：FLASH容量在16K至32K字节之间的STM32F101xx、STM32F102xx和STM32F103xx微控制器。

中容量产品：FLASH容量在64K至128K字节之间的STM32F101xx、STM32F102xx和STM32F103xx微控制器。

大容量产品：FLASH容量在256K至512K字 节之间的STM32F101xx和STM32F103xx微控制器。

对于小容量和中容量的产品，其页大小为1K，对于大容量产品，其页大小为2K。

2.2查看程序占用空间大小

在进行FLASH空间划分时，必须知道编写的程序占用FLASH空间大小。用MDK软件进行工程编译之后会生成一个.map文件，在该文件末尾可找到程序需要占用的FLASH空间。

在实际设计过程中，主要是确定BootLoader程序占用空间，便于确定APP程序的起始地址。

在这时候可以先编写部分BootLoader程序，再通过map文件查看当前占用空间，从而预估BootLoader程序最终会占用的空间大小。

在实际空间分配过程中，可以稍微大一点，以便于后续对BootLoader的功能扩展。

在MDK软件配置项中，可以对程序的起始位置以及大小进行设置。

对于BootLoader程序来说，只需要设置其Size，该值可根据刚才map文件中的值进行预估。

2.3 APP程序中需要做的配置项

BootLoader程序按照正常的程序编写即可。而APP程序由于其下载位置与默认程序下载位置不同，故需要做一些特殊的配置。

首先是APP 程序起始地址设置

起始位置即去除BootLoader程序之后剩余空间的首地址。一般设定为某一页的首地址，因为FLASH写入之前必须进行页擦除。

Size = FLASH原始大小 - 偏移量（0x8000），我使用的是STM32F103ZET6，FLASH大小为512K。

接着设置中断向量表的偏移量，在主函数起始位置添加：

SCB->VTOR = FLASH_BASE | 0x8000; //0x8000即BootLoader大小（偏移量）

2.4 IAP程序实现

IAP（BootLoader）编程关键技术

通信：

选用何种通信方式：串口、CAN、以太网......

通信协议：数据分发、帧头帧尾校验

配套上位机

Flash擦写

Flash写入流程

1 解锁

void FLASH_Unlock(void)                //解锁

2 擦除

//页擦除

FLASH_Status FLASH_ErasePage(uint32_t Page_Address);

//整片擦除

FLASH_Status FLASH_EraseAllPages(void);

3 写入

//半字写入

FLASH_Status FLASH_ProgramHalfWord(uint32_t Address, uint16_t Data);

//全字写入

FLASH_Status FLASH_ProgramWord(uint32_t Address, uint32_t Data);

4 上锁

void FLASH_Lock(void);

APP跳转

2.5 IAP升级的不足与展望

1.目前的IAP模式只能实现有线传输，不能够进行空中升级；

2.目前数据为一次性整包传输，接收到的数据存储在数组里，占用单片机RAM空间，而单片机的RAM是有限的。以STM32F103ZET6为例，RAM大小仅为64KB。若APP程序所需大于这个值，则此方法不能使用。

3.直接传输数据包的方式可靠性低，如果数据传输过程中出错无法判断。