基于STM32的串口环形队列IAP调试

  IAP很常见了，我这里主要是记录一下我所使用的方法，调试也花了两天时间。我所用的型号是F103C8T6，这个片子估计是目前性价比最高的了，所以平时也都是用的这个。这个，也有小道说有后置隐藏的64K，也就是说其实是有128K，我一直也没有测试，有空测测，有大神这样说，估计是可以的。这里重点记录一下我写的IAP思路和代码和具体细节和遇到坑的地方。先大体的概述一下，最后贴上我认为重点的代码。

  在概述之前先要解决一个问题，那就是sram空间和flash空间的问题，sram只有20K，flash有64k。

  1）最常见的就是自己写上位机软件，通过分包发送，期间还能加入加密算法，校验等等。

  2）使用环形队列，简单点说就是个环形数组，一边接收上位机数据，一边往flash里面写。

  这里条件限制就采用第二种方法。所以即使是分给A和B的25K空间的flash空间，sram只有20K也是不能一次接收完所有的bin数据的，这里我只开辟了一个1K的BUF，使用尾插法写入，我的测试应用程序都在5-6K，用这样的办法能够在9600波特率下测试稳定，也试过57600的勉强可以的，115200就不行了。

  1、把64K的flash空间分成了4个部分，第一部分是BootLoader，第二部分是程序A（APP1），第三部分是程序B（APP2），第四部分是用来存储一些变量和标记的。下面是空间的分配情况。BootLoader程序能用来更新程序A，而程序A又更新程序B，程序B可以更新程序A。最开始的时候想的是程序A、B都带更新了干嘛还多此一举，其实这个Bootloader还是需要的。如果之后程序A、B和FLAG三部分，假设一种情况，在程序B中更新程序A中遇上问题，复位后直接成砖，因为程序A在其实地址，上电直接运行程序A，而程序A现在出问题了，那就没招了。所以加上BootLoader情况下，不管怎么样BootLoader的程序是不会错的，因为更新不会更新BootLoader，计时更新出错了，还能进入BootLoader重新更新应用程序。我见也有另外一种设计方法的，就是应用程序只有一个程序A，把程序B区域的flash当作缓存用，重启的时候判断B区域有没有更新程序，有的话就把B拷贝到A，然后擦除B，我感觉这样其实也一样，反正不管怎么样这部分空间是必须要预留出来的。

  这里在keil中配置的只有起始地址和大小，并没结束地址，我这里也就不详细计算了。总体就是这样的。

  BootLoader的任务有两个，一是在串口中断接收BIN的数据和主循环内判断以及更新APP1的程序，二是在在程序开始的时候判断有没有可用的用户程序进而跳转到用户程序（程序A或者程序B）。

  系统上电首先肯定是执行BootLoader程序的，因为它的起始地址就是0x08000000，首先是初始化，然后判断按键是否手动升级程序，按键按下了就把FLAG部分的APP标记写成0xFFFF（这里用的宏定义方式），再执行执行App_Check()，否则就直接执行App_Check()。

  App_Check函数是来判断程序A和程序B的，最开始BootLoader是用swd方式下载的，下载的时候全片擦除，所以会执行主循环的Update_Check函数。此时串口打印出“等待接收APP1的BIN”，这样一个时间段发送APP1的BIN过去，等接受完了，会写在FLAG区域写个0xAAAA，代表程序A写入了，下次启动可以执行程序A。

  这两个都是用户程序，这两个程序都带有更新程序功能，我这里用作测试的A和B程序大体都差不多，不同的地方就是程序A接收的BIN用来更新程序B，程序B接收的BIN用来更新A，还有就是中断向量表便宜不同以及打印输出不同。

  这里其实只是用来存储2个变量，一个是程序运行标记，一个是接收到的程序长度，程序标记还有点把子用，程序长度其实要不要都无所谓。

  最值得一说的就是更新部分，最开始程序没有加入擦除flash，遇到的情况就是下载完BootLoader后发送app1没问题，在app1中更新App2也没问题，然后app2再更新app1就出问题了。直观的结果就是循环队列溢出，缘由是app2在更新app1前没有去擦除app1所在的flash，所以在写的时候就要去擦除，这样就写的很慢，然而串口接收是不停的收，所以就是写不过来。