接着以前的文章华大MCU(四)：HC32F460串口IAP升级

现在其实几乎所有的iap实现都大同小异，只是有的做了很多安全的机制和更多的功能，本文只介绍最基本的方案。

说实话华大HC32是我心目中的mcu，它并不是仿照stm32，而是引入很多在mcu领域很少见的东西。我最喜欢的是两点：

但是就是它的与众不同导致你可能不能像GD32那样快速的熟悉它。所以我针对我写IAP进行一次总结，希望对还在坑中的人有帮助。

先说废话，这些虽然是废话，但有很多细节，小细节最容易翻车，希望认真读完。

首先，我们都知道串口的传输虽然有奇偶检验，可以检查错误，但是对于通信来讲，上位机向mcu串口传输，当串口收到错误数据，也只能抛弃，上位机根本不知道mcu的情况，对于重要的数据这将是致命的。因此产品的iap升级都不会直接用串口直接分包下发(隐患太大)，而是通过一种发送应答机制(常见的使用CRC错误侦测方法)来完成bin文件传输，这类的协议很多，甚至可以自己写一套自己的协议(原理不难)，现实中有很多开源的这种协议。而现实中最常见的用于串口传输的协议就是XModem，YModem，ZModem。

利用这些的传输协议，可以不用开发上位机的，因为有很多软件自带这些协议，如XShell，SecureCRT等。同时这些协议比较健壮，所以推荐直接使用现成的协议就完了，方便。这三种协议网上有大量的教程，本文对于它的原理就不赘述了。

我曾写过两套HC32F460芯片的BootLoader，核心原理都是一样的，上位机将app的bin文件发送到串口，串口接收上位机数据，写到mcu的flash内，下载完后，在跳转到app中执行。区别在于一个是开机检测一个引脚，当引脚为高就代表升级，串口会进入接收app的bin文件模式，当收完自动跳转到app执行，另外一个是开机读取串口数据，若在3s内(tim实现的)收到升级指令(其实就是一段字符串)，就进入接bin状态，接收完跳到app执行。若未收到升级指令，超时则直接跳到app执行。

本次介绍倒计时实现BootLoader的方案，正好介绍一下定时器的使用。有几个注意事项一定要提前了解：

我认为两个程序的iram的地址是可以重叠的，但是为了方便懒得验证了，(sram大，不在乎)。

模板：我是直接在stm32的官网的iap的demo改的。这样我就省的再去移植YModem了。

这个stm32的模板我会直接传到csdn上。下载链接

根据HC32F460的数据手册，还有我们在编译app所选择的flash地址，可以声明下面这些宏：

mcu的时钟的配置请参考我另一篇文章华大MCU(二)：HC32f460启动过程和时钟分析，在这里直接默认系统时钟为200M。

在程序跳转到app前要失能定时器，并清除定时器资源：

串口接收数据的几个函数的实现：

上层通过函数

来不间断的扫描串口的值，并将串口的值存在key中。不建议用中断来接收串口数据，若真的必要用串口接收，那么请参考我另一篇文章 华大MCU(三)：HC32F460实现串口dma发送和中断接收。

在程序跳转到app前要失能串口，并清除串口资源：

首先要操作flash，当然先解锁使能

下面是Ymodem协议将数据向flash写入，这个函数来自官方stm32的iap的demo，我连注释都没改，而是直接将stm32的擦除flash和写flash换成了hc32的。

这时候一定要注意，因为每种单片机的flash的页容量不同，而且每次擦除的最小单位也不同，因此部分逻辑要修改。

因为Ymodem协议导致buf只有1024个字节，而hc32f460的最小擦除是8k字节，写的时候4个字节写一次。因此修改如下：

我相信来看这个文章的人都用过stm32的，这是经典的iap跳转app的程序，只是要注意检查栈地址是否合法的时候要根据自己所选择的那块iram。

其实我们重点要验证两个方面：

首先写一个最简单的华大mcu程序，比如说led闪烁(用while加delay堵塞实现，别用定时器)，不要调用mcu的其他资源，防止和BootLoader资源冲突导致误判，将flash的链接脚本flash位置改到启动地址0x00；让它就做一个普通程序，烧录到hc32,确定能够正常运行来保证app程序没有问题，led别闪的太快，因为我们通过闪的快慢可以分析直接运行和iap跳转会不会导致时钟剧烈变化(我就偶然发现HC32F460会超频，后面会讲)。

然后对照数据手册，给它找个新flash位置，编译生成HEX文件备用，同时利用工具在生成bin文件备用。

编写一个BootLoader文件，测试它可以运行，不死机，生成HEX文件。

将BootLoader的HEX和app的HEX合并成一个HEX，若不知道方法，请参考我的另一篇文章将两个HEX文件合并成一个HEX文件。

将新生成的HEX文件用J-LINK下载到mcu中，在不触发iap升级情况下，看看app能否执行，来验证链接脚本的时候flash和sram设置的地址有没有问题，bootloader的跳转那段程序是否有问题。

BootLoader启动，将bin发给它，然后看下载的bin的app能否运行，来验证bootloader的下载保存那部分代码没有问题。

观察有boot和没有boot的app程序的led闪烁情况，来确定时钟配置没发生问题(一般时钟出问题都会时钟变化很大，所以看led就可以看出来)。

按正常情况，你现在已经完成了HC32F460的iap的完整过程，但是我在测试的时候发现了非常怪异的问题。

​ 开始的时候我用一个led闪烁作为了app程序，结果发现当从bootloader跳转过来后，发现led的闪烁变快了(快了非常多，肉眼可见)，后来经过测是分析，我认为是时钟变快导致的，也就是app运行发生了超频。

后来我不断检查发现：

至于配置外部时钟的方法我另外的文章有讲：华大MCU(二)：HC32f460启动过程和时钟分析

我认为发生的问题的原因是，在app启动的汇编程序调用内部时钟初始化，应该是有寄存器没初始化到，把本来外部配置好的时钟树搞乱了。解决办法我认为有3个，第一种是对照时钟树，把app汇编里面那个初始化时钟函数给补全了，第二种简单粗暴，把app汇编里面那个初始化时钟函数给改成调用外部时钟函数。第三种就是若在bootloader里面初始化外部200M时钟，就在app里面再初始化一遍时钟就不会发生这件事，但是这种可能有隐患。