STM32 空中升级之IAP升级

STM32 空中升级之IAP升级

 

                                                     撰写人:张婷婷  更新时间:2019.07.30

目录

1.软件设计思想... 2

2. BootLoader的设计... 3

3.APP的设计... 5

3.1 APP程序入口地址和大小修改... 5

3.2中断向量表地址偏移... 5

3.3 收到固件更新命令执行软复位... 6

3.4将编译生成的.axf转换生成对应的.bin文件... 6

4.实验验证... 6

 

 

 

 

1. 软件设计思想

STM32 要想实现固件空中升级, 就必须借助外部可以无线接收数据的模块, 比如WiFi模块去接收固件包.bin文件然后再由WiFi模块经串口传送给STM32, 利用STM32的IAP将此bin文件写入flash, 最后运行bin文件才算间接完成了空中固件升级.

所以此时STM32需要两段程序区,一段是等待接收WiFi模块bin文件称做BootLoader的程序区, 另一段是用户实际代码运行区称做APP程序区.

这两段代码区可以设计成上电先运行BootLoader去检测是否有新的固件包需要升级,设置一个超时等待时间,在此期间如果有固件包传送,经检查后如果无误则可进行写入更新,超时无固件或者写入成功后就可以转到APP程序区运行.

然后在APP运行期间和WiFi模块约定一条固件包升级协议,在准备固件升级之前先发送此条命令告诉APP程序接下来要进行固件升级,此时APP需要利用软复位将代码执行地址拉到入口地址0x8000000也就是BootLoader处开始运行接收固件包.这样就可以实现任意期间均允许进行程序固件包升级.接下来详细介绍如何设计这两段程序.

 

 

 

2. BootLoader的设计

BootLoader的魔术棒的配置和平时程序工程的配置没有什么不同(下图2_2程序大小可以选择不修改),主要是内部程序,这里我们需要实现以下这三点主要功能:

 

1. 串口接收WiFi数据包;
2. 将接收到的固件包数据写入flash指定位置;
3. 跳转到指定flash地址运行代码.

 

此次以STM32F407VET6为例,该MCU flash 大小为512K(0x80000) ,我们分配BootLoader程序入口地址为0x8000000大小64K(0x10000),剩下的作为APP程序区.我这里BootLoader实际不到5K.

 

图 2_1 BootLoader编译大小

 

图2_2 BootLoader 程序大小修改

图2_3 BootLoader main主程序

其中实现需求1的usart.c,实现需求2.3的stmflash.c和iap.c可参考正点原子F4的例程:串口IAP实验,这里不作贴图了.

3.APP的设计

APP的设计比BootLoader的设计要复杂一些,在你想要实现的代码工程上增加一些支持IAP串口升级的修改即可,主要也就是以下这四点:

 

1. APP程序入口地址和大小修改;
2. 中断向量表地址偏移;
3. 收到固件更新命令执行软复位;
4. 将编译生成的.axf转换生成对应的.bin文件.

3.1 APP程序入口地址和大小修改

正常情况下,程序的入口地址是0x8000000,大小是0x80000(512K).但是上面的BootLoader程序已经占用了一部分内存,为了后面软复位能正确回到BootLoader处运行,所以我们上面设计了BootLoader入口地址为0x8000000,所以APP入口地址就顺推到0x8010000,大小为0x70000.

 

3.2中断向量表地址偏移

由于修改了入口地址,所以中断向量表的地址也要顺着偏移相同的偏移量,这里只需要在程序开始处添加一句偏移即可.

3.3 收到固件更新命令执行软复位

添加固件更新命令主要是为了满足任意期间均允许升级的需求, 因为MCU不可能一直停在BootLoader处等待固件包更新消息, 所以正常情况应该是MCU运行APP程序, 而WiFi模块在接收到可升级的固件包之后先发送一条约好的命令告诉APP程序接下来要进行固件升级,此时APP需要利用软复位将执行地址复位到入口地址0x8000000也就是BootLoader处开始运行接收固件包.而BootLoader写完固件包之后就会跳转运行新APP.这样也就实现了任意期间均允许进行程序固件包升级.下图是软复位代码:

 

 

3.4将编译生成的.axf转换生成对应的.bin文件

平时我们用keil下载编译生成的都是.axf文件,进行固件升级是需要发送.bin文件, 所以这里需要将.axf文件转换生成.bin文件, keil有自带的转换工具在keil安装的目录下的D:\Keil5\ARM\ARMCC\bin \fromelf.exe所以这里直接使用这个转换工具,这里我们可以配置APP程序在每次编译之后都将其.axf文件转换生成同名.bin文件并存放在相同文件下.实际配置方法如下图:

 

 

由上图RUN#1处的路径:

D:\Keil5\ARM\ARMCC\bin\fromelf.exe --bin -o ..\OBJ\CommonDecivs.bin ..\OBJ\CommonDecivs.axf

可以看出此次我们的APP程序工程名为CommonDecivs且存放在工程文件向上退一层的OBJ文件夹中,这里我们利用D:\Keil5\ARM\ARMCC\bin\fromelf.exe这个keil自带的转换工具将这个CommonDecivs.axf转换生成CommonDecivs.bin且存放在其同名文件夹下.

4.实验验证

先下载BootLoader程序,也可以一起下载BootLoader和APP程序,后面使用ST_Link或者其他工具单独下载这两段程序中的一方均不会影响另一方,因为烧录写入的地址彼此互不干扰 . 这里我们利用串口助手模拟WiFi端发送.bin文件.

 

 

接下来就是打开串口查看日志验证结果,这里我们可以看到在倒数105秒的时候我们发送了APP程序文件,程序文件大小为16K,经过验证之后成功写入flash 并在写完之后程序转到APP程序区运行.