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

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

---ConstYu 20151105

问题提出：在当前的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

{

write_buffer[i] = UART_GetChar();

………

}

length >>= 2; // divide by four

…………

if(FLASH_PROGRAM(https://www.sodocs.net/doc/d59140328.html,plete, (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的标准。