基于TCP的STM32 IAP bootloader初步设计

基于TCP的STM32 IAP bootloader初步设计

Daniel_USTB  2015-8-22夜

 

            好久没有写东西，前段时间发生了不少事情，现在终于能静下心来。停下脚步望望曾经的自己，一路走来，对技术的坚持是多么的可贵。人的时间是有限的，作为一个嵌入式工程师，对新技术的热爱和好奇心将产生前进的驱动力。至于可以达到怎样的高度，全看个人的执行力和自我约束，兴趣常常是最好的导向。

        最近研究了下IAP bootloader的实现方法,这在产品设计中是非常有用的。所谓IAP就是在线应用编程，可以用于远程程序升级。比如我们设计了一个产品，使用较为复杂的工艺被封装在精美的外壳中，或者被用于偏远的场景，如果在使用过程中需要修改程序，使用烧写器烧写是非常麻烦的，费时费力。真正的工业产品几乎都会有自己的bootloader。

       其实，实现自己的bootloader在原理上并不复杂，就是通过MCU的接口把外部新的程序文件烧写到其内部的flash中，然后去运行新程序。以前怎么也没想过如何在同一个flash里面运行毫无关系的两个程序，bootloader就可以实现。其核心跳转代码就只有三行：

     app_program = (void(*)())((*(__IO uint32_t*)(ApplicationAddress+4)));

     __set_MSP(*(__IO uint32_t*) ApplicationAddress);//初始化堆栈指针

     app_program();//跳转到app程序去执行

     其中ApplicationAddress，是应用程序在flash中存储的地址，ApplicationAddress+4就是复位中断向量地址，因为程序最开始都是去执行复位中断函数的。在这之前，先用一张图说明下stm32的正常启动过程。下图很好的说明了arm的启动过程，以及程序在flash中的存储方式：

 

     对于这个启动过程，我相信图上画的已经很明白了，也可以在很多文档中看到，我就不再赘述了。当然这个是bootloader的运行方式，现在我们还有一个app程序，放在了flash的另外一个区域。使用上述三行代码可以实现跳转，如下图所示：

 

     其中下面的那部分就是APP的存储结构以及运行过程。其过程也不再赘述。有了这个思路作为指导，就可以完成我自己的bootloader了。

     之所以选择TCP的升级方式，我觉得一是升级速度快，二是利用了原设备现有的网口，比较方便，在现有uIP协议栈的基础上实现一个TCP Server，用于接收上位机发来的二进制文件。涉及到数据交互，就要选择相应的交互协议，用的比较多的是1K—Xmodem协议。由于这是一个初级版本，以简单起见先用分包发送的方式实现，稍后在使用1K—Xmodem协议，再做诸多改进。这个简单的思路是，在点击下载程序后，先于bootloader进行握手，成功后使用上网机软件将APP BIN文件读入，然后分成1024大小的数据包发送给bootloader，每发完一个包，bootloader就写入flash，这样只占用1K的内存，即使对一个小型stm32芯片也可以实现，而不是一次性读到内部的ram后再编程flash。

     基于这个思路我做了一些实验，出现了一些问题。

     问题1，arm收到上位机下发一个数据包后马上写入flash，再返回ack，读写flash会占用较长的时间，造成上位机发送超时，引起重发。

     其实，完全可以arm收到一个数据包后立即应答，之后在下个数据包发来之前写入flash中去。

     问题二、把一包1024字节的数据写入flash后，我定义的很多全局变量被莫名奇妙的编程了FF，导致了程序运行错误。

     我想了两个晚上都不知原因。后来看flash函数才发现，原来flash是按块进行读写的，写入数据前先要整个数据块读出来，而这个函数声明了一个一块大小的局部数组，居然有2048这么大！大家都知道局部数组是放在内存的栈上的，而stm32在启动文件中定义的栈只有1K大小！在存储一包1024大小的数据到flash时栈过小，造成泄露，覆盖了分配在堆上的全局变量！把启动文件中栈大小改为Stack_Size      EQU     0x00002000，一共为8192字节，可以解决上述问题。

     这样，我的BIN文件就可以存入flash中去了，我定义的首地址为0x08010000,也就是给bootloader留出了64KBytes的空间，我的bootloader编译完一共26K，足够了。

     可以我又遇到了第三个问题：写完后居然不能执行！我通过jlink把flash中0x08010000地址上的数据读出与BIN文件对比，发现有些数据是错的！

    

                                       通过jlink烧写的app程序        通过上位机少进去的程序

     原来，是上位机打开BIN文件的方式不对。上位机软件使用C#编写，打开BIN文件起先使用的是StreamReader，后来查到应该使用BinaryReader。原来StreamReader是按照asc码的定义来解析，如果没有对应的asc码，就会出现乱码，而造成了某些字节的错位。读取文件改为BinaryReader方法就可以了，看看这几天的成果吧。

 

      下一步计划：使用X-Modem协议实现数据的交互，添加异常处理机制，保证数据传输的可靠性，以及bootloader的稳定性。