关于BootLoader(Ymodem协议)遇到的BUG

省流：

1.Flash 地址固定位置出现写入错误。

 2.BootLoader导致APP全局变量被更改。

近期需要做一款产品的OTA，采用了串口升级方式做OTA，发现了一个BUG。升级后有一段Flash地址变成了 FF FF FF FF FF  FF FF FF。百思不得其解~~

一开始以为是APP问题，但是程序找来找去都没找到BUG。------>>>>初步排除。

后来以为是Ymodem协议发送问题，也找了好几个小程序发Ymodem协议，经测试，Ymodem协议发送没有问题。------>>>>>>>>排除

现在唯一的可能就是这BootLoader有问题了！！！！！光这几个测试搞了很久。

接下来就是逐帧排查！！！

偶然间，发现这个判断句有点怪怪的，为啥要-8，会不会-8造成了这个结果？

然后点进去一看，好家伙，就是它!!!!!!! 

 翻阅了单片机的资料

0X0800AFFF-8=0X800AFF7

好家伙这不就是我开始写FFFFFFFFFFFFFFFF的地址嘛？

原来如此，该if判断语句并没有把0X0800AFFF这个地址算进去，而是只算到了0X800AFF7，故前面的数据都是对的，只有该位置是错的。

后来把该地址改为

这样就可以正常运行了，falsh地址也一样了，哎，还是看代码不仔细。

以为已经完成了，但是又发现一个BUG ，APP的全局变量被更改了。 

dbug_aa=1????

但是我APP初始化是0啊！！！！ 

一开始以为是OTA升级造成的原因，后来经排查，发现并不是，而是一开始正常运行就有问题，既然APP程序没问题，那就只有BootLoader程序有问题。

经排查，

 

tickCnt的地址怎么和dug_aa的地址一样？？？

经排查

 原来是这里定义的全局变量进行了++的情况，把这个删除后，运行程序就没有问题了，但是如果其他全局变量也有问题呢？？？

这引发了我的思考。

后来经过我师傅提点，关闭总中断（BootLoader需要），其他中断会被挂起，并不会失能。所以出现了+1的情况。所以保险一点，的解决方法：

先关闭所有外设，再关闭总中断！！！

先关闭所有外设，再关闭总中断！！！

先关闭所有外设，再关闭总中断！！！

 经测试，OTA程序就能正常运行。

PS：如果觉得麻烦，也可以在APP内重新初始化所有全局变量，也可以达到一样的效果（前提你能保证记得住所有全局变量初始化的值）。

讲的不足之处还望各位大佬指点一二。