文章详细介绍了在STM32F767ZGT6硬件平台上，使用HAL库和KEIL5开发环境中实现固件的In-ApplicationProgramming(IAP)。IAP通过RS232等接口更新程序，避免使用下载器。文中提到了两种IAP实现方式，分别是APP接收和BOOT接收新程序，并分析了它们的优缺点。此外，还阐述了从HEX到BIN的转换方法，以及APP和BOOT在接收、存储和跳转新程序时的代码实现和设置。同时，文章强调了中断管理、CRC校验和中断初始化等关键点，以确保程序安全更新。
硬件平台：STM32F767ZGT6，这个差别不大，用了STM32CUBE+freeRTOS，这个也没啥太大差别。
软件平台：KEIL5
使用库：使用的CUBE的HAL库
1.理论知识
1）IAP方法
IAP一般指的就是不使用官方下载器（如STLINK/ULINK/JLINK等），而是借助RS232、RS485、CAN、以太网、USB等等接口来实现程序的编写，具体采用哪种接口对于IAP过程来说没什么区别。
IAP程序一般包括bootloader程序（这个轻易不改的）和app程序（一般改这个），而下载逻辑有两种：
一般新程序的接收代码都是放到APP中，APP接收验证完毕后把新程序存到新程序缓存flash区域，然后软件复位，然后再由boot程序把新程序数据提取到RAM，然后覆盖到正常程序的FALSH区域，然后跳转。。
但是也可以由BOOT直接接收并存储新程序，流程是：APP收到新程序下载申请后写个FLASH标志然后软件复位到boot，boot查询到FALSH更新标志位后发出允许发送程序的握手指令，然后开始接收数据到RAM，接收完毕并校验后直接覆盖到正常程序的FALSH区域，然后跳转。。
两种方式差异如下：
| BOOT接收 | APP接收 | |
| RAM占用 | 不占用APP中RAM | 需要定义RAM来接收APP数据 |
| FLASH占用 | FLASH不需要缓存程序区，节省FLASH | 需要把FLASH分为3部分：boot+正常APP区+缓存APP区 |
| 允许APP大小 | 原则上等于整个FLASH区域减去boot大小 | 小于整个FLASH的一半 |
| 接收新程序数据时其他程序能否正常执行 |
最低0.47元/天 解锁文章
扫一扫
1261
到【灌水乐园】发言
