解决AN2295不能烧写部分S19文件的方法（转）

好好先森

转一篇，原作者：FSL_FAE_ConstYu

问题提出：
在当前的AN2295中，有客户反馈使用GUI只能烧写部分S19文件，而同样的配置，修改代码后，生成的S19文件烧写却不成功，如下图，总是出现程序烧写98%左右后，编程失败。




问题分析：
分析前后两个S19文件发现，添加代码前后S19的长度出现变化，能正常下载的S19的都是4字节对齐的。于是结合AN2295的MCU端程序代码，可以看到如下红色代码，其强制性的将S19文件进行了4字节截断，从而导致了最后的不满4个字节数据被丢弃，于是出现了编程错误。
case BOOT_CMD_WRITE:
          ReadAddress();
          length = UART_GetChar();          // Read length
          ………
          // Load the data to write
          for(i = 0;i<length; i++)
          {
            write_buffer =  UART_GetChar();
        ………
          }
          length >>= 2;    // divide by four
          …………         
          if(FLASH_PROGRAM(address.complete, (LWord*)write_buffer, length))
          {           
            SendResultCRC(1);
            break;
          }

问题解决：
针对这个问题有两种解决方式，
1. 强制修改工程生成的S19文件补充0xFF，使之4字节对齐，修改前后对比如下图。




2. 在AN2295代码中将未4字节对齐的最后一帧数据，使用0xFF填充，使之4字节对齐。需要在bootload.c函数中，添加如下图红色方框中代码。




总结：
对于很多新用户来说，遇到这个问题，会不确定是上位机PC端GUI代码的问题还是下位机MCU的问题，而且调试时需要GUI和MCU配合起来，特别是如何判断最后一帧数据的长度，所以比较难定位问题。但一旦找到问题点，就比较好修改了。推荐使用第二种修改方法，能帮助用户对AN2295代码的执行流程有比较深入的了解。

延伸：
如下截图，在当前AN2295代码中决定是否执行APP的条件是指定的跳转首地址是不是0xFFFFFFF。而如果在更新过程中出现中断，由于首地址已经不是0xFFFFFFFF，在重启后，程序依然会执行不完整的APP代码，从而有可能产生意外的结果。这种情况，在一些对安全性要求比较高的应用场合需要特别注意，有必要的话，用户可以修改这个判别条件，做特别的优化处理。
目前两个可行的办法是：
1. 使用特定的Flash地址存放bootloader更新完成标志，并以该标志作为进入APP的判断标准；
2. 修改GUI传送的烧写MCU的S19文件的顺序，从后向前烧写Flash sector，如果更新过程中出现中断，首地址来不及更新，将会是默认的0xFFFFFFF，从而可使用该条件作为判断是否在重启后进入APP的标准。

我知道答案 目前已有2人回答

阅读全文

雨轩-367816

学习了，顶一个

autoyoung

也可以自己做个上位机呀！