#  bootForHC32F460

**Repository Path**: GKoSon/bootForHC32F460

## Basic Information

- **Project Name**:  bootForHC32F460
- **Description**: https://gitee.com/GKoSon/ioboard 的boot.bin
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-02-12
- **Last Updated**: 2026-05-11

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# HC32F460 IAP Bootloader

## 项目简介

本项目是华大半导体HC32F460系列MCU的bootloader(该分支master是差分升级版本)

## 快速上手

请务必先理解分支FULL全量方案的代码  再阅读本分支差分升级方案

纵观全局需要的工具:APP工程 + 上位机 + 通讯协议 + BOOT工程 + 二合一脚本 + 修饰头冠以40字节的脚本

差分升级和全量升级的区别其实<BOOT工程>和<修饰头冠以40字节的脚本> auto脚本 不一样 仅此而已

因为其他都是文件传输文件烧录 和算法没有关系的！
![1778462958434](images/README/1778462958434.png)
40个字节的定义如上
全量只需要告诉BOOT文件的大小filesize即可  因为它的算法就是百分百一比一的拷贝
差分除了需要filesize用于校验传输可靠  还需要告诉BOOT旧文件的大小oldAppOnMcuFileSize+差分包的大小diffFileSize这样才可以算出新固件  额外我主动打包newFileSize是去MCU做判定是否一致的！

差分的实现:https://gitee.com/GKoSon/firmware-release-assistant/blob/master/bin/Debug/head40ZipForOta.c
全量的实现:https://gitee.com/GKoSon/ioboard/blob/FULL/TOOLS/packBinForOta.c

请重点注意上面说的区别

## OTA全量方案流程

MCU的固件是在FLASH执行的

###STEP1 编译出boot.bin   编译出appV1.bin
###STEP2 调用auto.bat亦即调用两个脚本 其一 merge.c完成boot+CFG+appV1=all.bin方便JLINK一次性烧写 其二 再次编译APP工程输出appV2.bin 脚本packBinForOta.c完成appV2.bin前面追加40个字节变成appForOta.bin
此时MCU内部FLASH如下
![1778382189544](images/README/1778382189544.png)
###STEP3 上位机走文件传输协议和app通讯 把appForOta.bin烧录到MCU的备份区域
此时MCU内部FLASH如下
![1778382579917](images/README/1778382579917.png)
###STEP4 MCU判定固件可靠 就把appForOta.bin前面的40个字节拷贝到CFG区域 然后复位
此时MCU内部FLASH如下
![1778382722335](images/README/1778382722335.png)
###STEP5 MCU复位走到BOOT 此时BOOT读到CFG区域有数据就执行"神奇工作" 然后清除CFG区域的数据 然后再次复位
###STEP6 MCU复位走到BOOT 此时BOOT读到CFG区域无数据就直接JUMP到APP区域![1778382778446](images/README/1778382778446.png)
在全量升级方案中 这个"神奇工作"就是全量拷贝ota_copy_file() 因为上位机发给MCU的是全量可执行的固件
![1778382527562](images/README/1778382527562.png)
示意图如下 这是非常安全非常可靠的 即使中途掉电也可以再次上电的时候重写拷贝

在差分升级(原地更新)方案中 这个"神奇工作"就是解压差分还原 因为上位机发给MCU的是新固件和旧固件的差分包的压缩包
对比如下 这是有风险的 因为算法是依靠旧固件和差分包还原出来新固件再及时覆盖到原始固件地址的 一旦中途掉电就变砖头 因为即使再次上电原来旧固件被篡改了 无法算出新固件了

## OTA差分方案流程

###STEP1 编译出boot.bin   编译出appV1.bin
###STEP2.1 调用auto.bat亦即调用一个脚本 其一 merge.c完成boot+CFG+appV1=all.bin方便JLINK一次性烧写
此时MCU内部FLASH如下

###STEP2.2  再次编译APP工程输出appV2.bin 使用上位机 传入 appV1.bin+appV2.bin就会输出差分包+差分包的压缩包+差分包的压缩包再冠以40个字节头的zipForOta.bin

###STEP3 上位机走文件传输协议和app通讯 把zipForOta.bin烧录到MCU的备份区域
###STEP4 MCU判定固件可靠 就把zipForOta.bin前面的40个字节拷贝到CFG区域 然后复位
###STEP5 MCU复位走到BOOT 此时BOOT读到CFG区域有数据就执行"神奇工作" 然后清除CFG区域的数据 然后再次复位
###STEP6 MCU复位走到BOOT 此时BOOT读到CFG区域无数据就直接JUMP到APP区域

在全量升级方案中 这个"神奇工作"就是全量拷贝ota_copy_file() 因为上位机发给MCU的是全量可执行的固件
示意图如下 这是非常安全非常可靠的 即使中途掉电也可以再次上电的时候重写拷贝

在差分升级(原地更新)方案中 这个"神奇工作"就是解压差分还原 因为上位机发给MCU的是新固件和旧固件的差分包的压缩包
对比如下 这是有风险的 因为算法是依靠旧固件和差分包还原出来新固件再及时覆盖到原始固件地址的 一旦中途掉电就变砖头 因为即使再次上电原来旧固件被篡改了 无法算出新固件了

![1778382870025](images/README/1778382870025.png)

解决办法:
不要原地更新 而是先利用上位机发的包+旧固件算出新固件记录好 最后安安静静执行全文件拷贝(代码很容易写 但是浪费flash 可能需要外挂NORFLASH来额外记录)

![1778383043953](images/README/1778383043953.png)

## 主要特性

- **IAP引导功能**：支持跳转到应用程序执行
- **OTA差分升级**：支持增量（patch）和全量固件升级
- **通信接口**：支持串口通信，用于接收固件数据
- **安全校验**：集成MD5和CRC校验，确保固件完整性
- **Flash操作**：支持扇区擦除、读写操作
- **压缩支持**：集成hpatch_lite和tuz解压库，支持压缩固件包

## 硬件要求

- HC32F460系列开发板
- 串口调试工具（USB转TTL模块）
- J-Link或DAP调试器（用于程序烧录）

## 软件架构

```
MDK/
├── iap_boot.uvprojx        # Keil工程文件
├── startup_hc32f460.s      # 启动文件
└── config/
    ├── debug_init.ini      # 调试初始化配置
    ├── release_init.ini    # 发行初始化配置
    └── linker/
        ├── HC32F460xC.sct  # 512KB Flash链接脚本
        └── HC32F460xE.sct  # 1024KB Flash链接脚本

source/
├── main.c/h               # 主程序入口
├── com.c/h                # 串口通信驱动
├── flash.c/h              # Flash操作驱动
├── md5.c/h                # MD5校验算法
├── mydiffPort.c/h         # 本人抽象的唯一函数接口!重点关注 方便移植
├── hpatch_lite.c/h        # 差分压缩库
├── tuz_dec.c/h            # 数据解压库
├── tuz_hpbridge.c/h       # 桥接模块
├── hc32f4xx_conf.h        # 芯片配置头文件
└── hpatch_lite_*.h        # 相关头文件
```