今天研究了一下gd32单片机串口OTA升级的事情。我感觉ota的唯一好处就是不用调试器就可以下载（更新）单片机应用程序。(但是需要232串口，OTA程序我是使用stlink下载的！！)

可能有些同学要问，32的单片机本身就支持串口下载，为啥还要搞这一出呢？单片机的串口下载需要boot0这个引脚的设置，但有一些可能性，比如：万一用户不想开盖呢？第二，可能硬件在做的时候并没有考虑串口升级的事情呢？这时就不得不考虑用这个ota的办法了。

是啊，事情不是总是顺意啦，硬件不能解决的，软件有办法解决那也行啊。

一、已经具备的环境：

1.硬件：gd32f103vbt6 单片机，（128Kflash），boot0，boot1被强制拉了电平，不方便改变。同时也没有设计自动下载电路。总之就是硬件不支持串口下载更新程序！！！

2.keil5.29

3.单片机原应用程序。（能正常运行的，但是没有OTA的功能，需要使用OTA升级的单片机程序）

4.到网上找一个OTA的单片机程序。

二、步骤

2.1 基本步骤可以参考网络上的OTA部分。

2.2 一些不太清晰的地方，做一些说明。（可能也不全对，请指正）

2.2.1 如果要实现OTA，就需要增加一个单片机程序（是一个独立的工程），这个程序我们可以称之为bootloader（随便取吧）。我自己的代码是gd32的标准库，使用其他库的话，需要稍微调整一下，提供给大家。https://github.com/zhaozhi0810/gd32f103-OTA-uart.git

2.2.2 还有一个程序就是在OTA之前的一个单片机应用程序，就是原单片机程序。

三、OTA程序

3.1 ota 的基本思路

3.1.1 单片机上电后，启动OTA，初始化串口，systick，一个led，从串口读取字符（200ms），我的程序设置的是ctrl+c的值（3），读取到了则进入下载模式，否则直接启动单片机应用程序。

3.1.2 led做了一个闪烁400ms翻转一次，比单片机应用程序快。这里可以体现出程序的阶段。

3.1.3 串口没有使用中断了。

3.1.4 使用Ymodem的方式收发文件，需要secCRT或者类似软件的支持。

3.1.5 设置中irom的起始位置不需要改变，保持为0x8000000. 大小最好在12K以内（偏移值为0x3000）。如果OTA的程序比较大，建议修改偏移值

3.1.6 0x800，0000~0x800，2fff,总共12K字节，用于保存OTA的程序，0x800，3000之后的空间用于保存单片机的应用程序。这个数值已经在OTA程序中写死了，如果需要修改，则要注意。

3.1.7 注意单片机flash的页大小，和flash总大小，我现在的单片机是128K，页大小是1K。内部读写flash的时候用到了这些参数。

        flash 容量 1-128k的页都是1k

        flash 容量128k - 512K的页都是2k页

        flash 容量512K以上的页，前512k是在bank0，为2k页，之后的在bank1，为4K页。

这个比较重要，单片机每次需要按页擦除。

3.1.8 按数字1进入下载模式，出现ccc的打印

 3.1.9 secCRT 发送文件，弹出对话框，选择单片机的bin文件（如何转成bin，在下文中描述了）

 3.1.10 发送结束，提示没有错误。

 3.1.11 可以选择重新上电重启，也可以选择数字3，启动应用程序。

3.1.12 上传文件没有测试

3.2 ota程序我是使用stlink下载的！！！单片机的bin文件则不能用keil直接下载了！！

 

四、原单片机程序

4.1 原工程中需要修改的地方，设置好之后需要重新编译

4.1.1 设置中irom的起始位置：（图中是0x8003000，表示偏移了12K）

4.1.2 main函数的起始位置需要修改中断向量表的位置（与偏移的地址一致）

 

 如果没有这个函数，可以自己实现

4.2  还需要增加一个命令，将axf转成bin文件，ota下载只需要bin文件

 

fromelf --bin -o ./output/@L.bin ./Objects/@L.axf 

注意在工程中增加一个output的目录。fromelf是keil自带的程序，不需要特别指定路径

重新编译即可生成最新的bin文件了。

4.3 使用OTA之后的弊端：

4.3.1 不能使用keil的下载按钮进行程序下载了！！！

4.3.2 不能使用keil进行程序在线调试了！！！

4.3.3 单片机的应用程序需要生成bin，才能使用串口下载。

五、关于一些思考

5.1 我能不能分成两个app区域，只更新其中一个app，ota程序选择最新的单片机程序运行？

5.1.1我看了一下单片机的bin文件是28K左右，我的flash有128K，去掉12K（用于ota）还有116K，分成两半还有58K，从空间来看，是可以分为两个区域。

5.1.2 空间上没问题，但是程序上有问题，单片机的应用程序的链接地址和实际运行的地址有偏差，比如链接地址设置为0x800，3000.这个地址在app1的区域是正常能跑的，但是app2的区域（实际运行地址是0x8011800，而链接地址是0x8003000），很明显不同，这时候会导致程序跑飞，实际app2还是跑不起来。

5.1.3 对不同app区域修改irom的值，可以解决这个问题，升级app1，我就要设置irom的地址为0x8003000，升级app2，就要修改irom的起始地址为0x8011800，这样生成不同的app文件，提供给客户，并且我提供给客户（升级程序）的时候，还要考虑他是升级app1和app2，简直麻烦透了，容易出错，要是升级错了，简直就乱套了。所以前提必须是不管升级app1还是app2，都只能用同一个app.bin文件去升级，升级后，单片机确实就是运行最新的程序。

5.1.3 这里考虑位置无关代码，然而我还没有很多时间来研究这个东西，只要能够做到位置无关，似乎可以解决这个问题？？？

5.1.4 我看到网上的解决办法，app2当成备份区，并不能运行，ota下载的时候，先下载到app2区域，下载成功后，下次ota启动的时候，就把app2的内容搬到app1来。这种方法可能本身是考虑下载过程出错的情况，下载不成功，这是可以防止的，但是我觉得意义不大，我下载不成功，还可以再下载一次啊。搬运的那一次，我觉得浪费了我的启动时间，万一我对启动时间特别敏感呢？

5.15 再研究吧，肯定还有优化的空间。

5.2 能否直接在单片机应用程序升级呢？

5.2.1 理论这样是不行的，单片机本身在运行，然后你却擦除了那里的flash，这样运行的程序就出错了呀。下载过程中，单片机就跑飞了，升级肯定就失败了。

5.2.2 如果有两个app，并且都能正常运行，app1 运行的时候，升级app2的区域，app2运行的时候升级app1的区域，这样应该是可行的，但是目前做两个app区域，并且能够都可执行，似乎还有点困难。