1、以往简单的实现
以前自己也做了IAP升级，但是以往的流程是
应用层选择程序进行串口升级
- 串口接收完毕后存放到指定分区后断电
- 断电，判断是否有升级标记位
- 不升级就跳转到正常运行区，升级就开始复制数据到运行区
- 跳转前检查是否有运行成功标记位，有的话才跳转
- 没有运行成功标记位则报错，提示单片机启动失败
- 跳转运行成功，赋值成功标记位
- 跳转失败程序已经跑飞，也恢复不了，只能关机从2开始再次执行
这里面的缺点就是对于数据没有保护
网上看了一下，主要看这篇博客OTA远程升级固件安全验证流程，
2、添加加密算法
准备工作就是windows先生成密钥对，下位机存储公钥数据
添加以后的流程大概就是：
- 上位机对升级文件进行计算生成哈希值
- 上位机对生成的哈希值进行加密生成数字签名
- 上位机执行升级命令，将发送数字签名和升级文件
- 下位机接收完成后存储重启
- 重启以后先检查标记位，查看是否有升级命令
- 有升级则取出公钥进行验签，通过则跳转，不通过继续执行之前的代码
- 无升级就进行运行区的内容计算校验，查看是否存在存储损坏，某一个bit跳变的情况
- 一切正常则跳转，跳转后设置程序当前运行区和启动状态
在启动过程中，上下位机需要建立及时的通讯机制以及报错机制，在出现问题时帮助其他工程师排除问题
3、具体实现
Flash分了五个区，
- bootloader，
- App1，
- App2
- publickey
- config
每次假设运行区在App1，接收的升级数据就存放在App2中，相关的数字签名就存放在Config区，验签所需要的公钥存储在publickey区
因为跟项目相关就不贴代码了，但是把代码的执行流程说一下
3.1、上电启动，执行时钟和外设初始化
3.2、进入while循环，等待上位机程序启动成功
3.3、收到上位机启动成功后程序开始运行命令
3.4、开始运行，先查看上次的启动状态标记位是否正常启动
3.4.1、未正常启动，查看未启动成功次数，
- 如果超过三次就停止跳转，等待重新升级，同时上报错误
- 未超过三次则继续跳转到上次的启动区域
3.4.2、如果是启动成功，则判断config区是否有升级标记位更新
假设此时App1有升级标记位，则进行数据验签，
- 通过则跳转到App1的地址运行，同时记录当前的运行区域，更改标记位，当前App1的Flash内容的校验和存储进Config区，避免遇到内存损坏
- 未通过则上报错误，询问上位机是等待升级还是重新运行上一个区域，等待上位机返回
3.5、跳转前将启动状态标记位改为异常，等到正常的App启动以后改为正常，等待App启动
3.6、App启动成功
在bootloader里面最好每一个功能步骤都向上位机发送一个状态位