实现"通过串口升级嵌入式目标板软件"功能的一些心得体会

嵌入式平台 ARM7 AT91FR40162 串口升级
  最近由于项目需要，在AT91FR40162平台上实现了通过串口传输目标板二进制可执行文件并更新固化到储存执行代码的片内ROM中。在这之前，我进入公司以来，这个平台上，通过仿真器把程序下载到目标板是更新目标板固化程序的唯一途径。随着对嵌入式系统的逐步了解，我认识到存在不通过仿真器升级程序的方法：我们日常使用的嵌入式设备，如有线电视机顶盒，可以通过电视线升级软件，如路由器，可以通过网线升级软件，诸如此类，理论上有数据传输的通路就可以实现目标板软件升级。上网翻了下AT91FR40162的资料，不知道现在还有多少人用这块arm7...还好找到几年前的一些文档资料，Q&A，还有ATMEL免费提供的上位机软件ATMEL Host loader，但传说中配合使用的AT91 Flash Uploader却没找到。结合某已离职大牛遗留下没人再用的代码，还有其他平台的经验，终于在这个平台实现了串口升级。当中的一些学习心得和经验体会写下来作个记录并分享。
  首先简要总结串口升级的原理。在我们的目标板里，这块ARM上电复位并执行memory remap之后，0地址映射到片内RAM，0x400000映射到FLASH ROM。由于片内RAM为256k，FLASH ROM为2M，目标板的执行代码储存在FLASH ROM，运行时大部分在FLASH ROM执行，只有少部分对速度要求高的映射到片内RAM。实现软件串口升级的基本思路，就是编写实现接收串口数据并把数据转存至FLASH ROM功能的代码，将其用仿真器下载至目标板，并保持以后每次软件串口升级之后FLASH ROM都保持有这样功能的代码。
  接着就具体不同的需求来分析不同的实现方案。我之前在另一个DSP平台实现过串口升级，方法是目标板的日常运行代码里有串口升级的模块，当收到串口升级命令之后，按照预定的流程把二进制可执行文件数据从串口接收下来，储存在RAM里，在确认无误后，再刷写固化入FLASH ROM中。这个方案的要点是，负责串口升级的模块代码，特别是负责把数据刷写入FLASH ROM以及之后操作的相关执行代码和访问到的常量，必须加载到RAM里，以免升级FLASH ROM后代码位置改变而不能执行；此外RAM要提供一个大的缓冲区，用作储存二进制可执行文件数据。我分析过这次ARM7平台的代码量在100k多一点，也就是二进制可执行文件大小100多k，需要加载到RAM的代码和变量数据之和小于100k，这样256k的RAM刚好能满足要求。就这样，参照离职大牛的代码，了解这块ARM的FLASH操作之后，移植DSP平台的串口升级模块代码，便实现了软件串口升级的功能。我认为这方案特点是：一，对内存的使用量比较多，比较适合RAM相对较充足的情况；二，运行的时候随时升级，但存在风险：一旦在写FLASH的过程中掉电，或者刷入了不含串口升级功能的代码，之后就只能接仿真器刷了；三，编码简单，移植方便。然而，虽然目前我这个项目的代码量还不多，但如果以后要增加功能，势必会增加代码大小和内存使用量，那时候使用这方案就不合适了，因而我必须思考其他实现方案。
  既然内存不充裕，那我就减少升级代码缓冲区的大小，例如设置一个固定的FLASH ROM页面大小，刚好是FLASH进行清除操作的最小单元；这样填满了这个缓冲区，就进行写FLASH操作，写好继续接收。现在我常用的串口波特率最高是115200bps，就是说每秒最多传14400字节，假如刷写一个页面的FLASH ROM需要x个毫秒，从串口驱动的接收缓冲区拷数据到升级代码缓冲区需要y毫秒，那么串口驱动的接收缓冲区必须大于14.4(x+y)个字节，才能避免丢失串口数。我没有查资料和做准确测试，这x+y估计在100以下。所以，相对于方案一，这个方案节省了大量内存，从原来的100多k减少到一个页面4k，而且还不需要限制代码量的大小，只要FLASH ROM装得下；不过，风险大大增加：方案一在串口传输的过程中如果掉电，只是升级失败，旧程序还在，而这方案如果在那时候掉电，新程序还没完全刷好，那又得接仿真器重刷了。一般FLASH ROM的重刷只需不到一秒，但100k的数据传输需要好几秒，为了避免这一风险的增加，我想到在FLASH ROM上做备份。例如现在FLASH ROM有2M字节这么多，假如我现在的代码翻十几倍，还可以多放1个相同的镜