工作多年,常常觉得自己遇到的问题及解决办法,时间稍长,就容易遗忘,且没地方查。再者,经常看别人的文章,受益匪浅,自己也有些经验,却从来没有分享出来,深感惭愧。工作忙不是好借口,今日开始开博,不为别的,只为记录、备忘,以及解决其他人可能遇到的相同问题顺利找到解决办法。
问题:
stm32f103ret6上做的IAP,仿真调试阶段没有遇到过问题,外场使用就发现不能跳转到app,且不同板子、不同isp等都可能出现这种问题
解决:
直觉上是有规律的,一直找规律,经过一天试验、跟踪、bin代码对比,终于发现bin的最后一部分代码没有成功写入flash。
进一步分析iap的bootloader程序,果然最后不够整页的代码写入时指针不对,在已写入的区域,由于有代码且没擦除,不会执行编程操作,对已写入的部分没有影响,但是最后一部分程序丢失,当app启动运行时pc指针0xFFFFFFFF,进入硬件异常,修正指针后正常。其实增加写入代码验证会更利于debug。
附加问题:
1、bootloader、app是采用flash_loader_demo_v2.8.0,分两次写入flash
2、使用mcu isp可以使用网上的一个批处理文件合并之后,下载,也能运行
copy /b .\bootloader.hex+.\app.hex *-hb.hex
效果就是把app.hex拷贝到bootloader后面,写入*-hb.hex。
分别试验2个软件,得出结论:
1、mcu isp是整片擦除,flash_loader是可选
2、mcu isp不验证hex结束,文件内容全部写入flash,flash_loader到第一个hex结束行即停止
so,
目前mcu isp只能烧写*-hb.hex能正常运行,单独烧写一个文件会擦除整个片子内容,在烧写这个文件,对iap来说运行不了。
flash_loader要灵活的多,但是烧写不了*-hb.hex,因为第一个文件结束行能被检测到,不在执行第二个文件的烧写。
度娘hex的格式,其实把bootloader.hex的最后一行去掉,把app.hex拷贝到后面即可,这样两个烧写软件都能够使用。
附hex文件格式说明:
用记事本打开hex,内容是一行一行的,且以冒号开头,16进制:
第一个字节:本行数据长度
第二个字节和第三个字节:本行代码写入flash的相对地址
第四个字节:数据类型
'00' Data Rrecord:用来记录数据,HEX文件的大部分记录都是数据记录
'01' End of File Record: 用来标识文件结束,放在文件的最后,标识HEX文件的结尾
'02' Extended Segment Address Record: 用来标识扩展段地址的记录
'03' Start Segment Address Record:开始段地址记录
'04' Extended Linear Address Record: 用来标识扩展线性地址的记录
'05' Start Linear Address Record:开始线性地址记录
最后一个字节:校验码,0x100-所有的字节加起来的最后一个字节
例:
:020000040800F2 第一行
:1000000050FA002009010008490800084B080008C0 第二行
02 本行数据0x02个字节
0000 相对地址0x0000
04 表示数据内容是扩展地址,绝对地址的高16位
0800 编程地址的高字节,左移16位即0x0800 0000构成了基地址
F2 校验码,02+00+00+04+08+00=0x0E 0x100-0x0E=0xF2
:04000005080030EDD2
:00000001FF 最后一行
倒数第二行
05 表示main的入口地址,080030ED
最后一行
01 表示hex文件结束
『本文转载自网络,版权归原作者所有,如有侵权请联系删除』