Stm8sIAPBootloader设计Word格式文档下载.docx
- 文档编号:21065360
- 上传时间:2023-01-27
- 格式:DOCX
- 页数:18
- 大小:1.15MB
Stm8sIAPBootloader设计Word格式文档下载.docx
《Stm8sIAPBootloader设计Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《Stm8sIAPBootloader设计Word格式文档下载.docx(18页珍藏版)》请在冰豆网上搜索。
一般来说,嵌入式产品的软件都会分为两部分,第一部分为Bootloader,第二部分为主程序(MainAPP),它们存放在flash的不同区域。
Bootloader是上电或者复位以后先执行的,通过它,我们可以初始化硬件设备、建立内存空间的映射图,检测程序的完整性,判断是否需要从Bootloader跳转到APP或者更新APP。
而主程序呢,则是真正用来实现产品面向客户的功能的。
通常呢,在Bootloader会实现一种或者一种以上的IAP方式,可能是UART,SPI,CAN或者Ethernet等。
本次例程呢,就是设计一个Bootloader,允许用户用电脑的串口+超级终端实现烧录功能
2.程序流程设计
秉承软件开发好习惯,coding前先想好思路,设计好流程框图,coding时才能事半功倍哦。
此次Bootloader程序主要分为三个模式:
1.升级模式Upgrademode:
对硬件初始化完成以后,率先检测这个模式,进入该模式的条件为,检测到升级程序的命令,否则进入下一个模式的检测。
在这个模式下,LED指示灯闪烁速率最快,为50ms
2.正常模式NormalMode:
这个模式主要作用为检测主程序是否有效,如果有效则进行程序跳转进入主程序,否则进行下一个模式的检测。
这边建议在主程序控制LED指示灯以其他的频率(例如500ms或者1s)闪烁,以示区别。
3.等待模式WaitMode:
如果上述两种模式都不满足,则停留在这个模式。
这个模式主要作用为循环检测串口数据,如果有收到数据则进行解析,满足升级模式的进入条件则转到升级模式。
该模式下,LED指示灯闪烁速率为200ms。
程序流程框图如下:
2.1.正常模式
从之前的程序流程图可以看出,我们已经将stm8s的flash分为了Bootloader和MainAPP,所以如果没有接到烧录指令且MainAPP的flash区域已经有了正常的程序,那么bootloader就跳转到MainAPP执行。
那么怎么判断MainAPP已经有了程序了呢?
这边我提供一个比较简单方法。
我们可以在MainAPP的代码中,把某串特定的字符通过伪指令放入特定的地址,那么Bootloader只要读取该地址与预先规定好的字符是否一致。
一致的话则认为MainAPP存在。
本次实践,我在MainAPP中将“XLXWW”字符放入flash的0x9180地址中。
当然如果对安全性要求更高的话,我们还可以定义更复杂的方式。
业内比较通用的方式是除了刚才提到的方法,还会加上将整个MainAPP的flash的值进行checksum校验等。
2.2.升级模式
升级指令会在在两种情况下收到:
1.芯片内部只有bootloader
2.芯片有bootloader和MainAPP,且当前程序跑在MainAPP。
这种情况下,我们在跳转会Bootloader前需要先将这个信息写入EEPROM,bootloader才知道需要升级程序
下面定义了升级模式过程中的步骤:
1.如果之前未初始化UART,则首先初始化UART的配置;
2.上位机(PC)通过串口发送询问请求,包括系统型号,程序版本等信息,Bootloader根据自己的信息回复,如果上位机认为匹配成功,则进行下一步
3.上位机根据烧录文件的信息,发送开始烧录请求,请求包中包含了需要擦除的地址段。
Bootloader根据上位机的请求,擦除对应地址的flash,成功后回复ok
4.上位机分段将flash的Data传送给你Bootloader,Bootloader将数据依次写入Flash空间
5.所有数据烧写完成后,上位机开始请求验证flash数据是否被正确写入。
此时Bootloader分段读取flash数据,发送给上位机,上位机收到数据后与原始烧录文件的数据做对比,如果完全一致,则整个烧录过程结束,如果有不一致,则提示用户是否重新烧录。
2.3.等待模式
等待模式,其实就是由于MainAPP不存在或者不完整,程序一直待在booloader.在while循环里面,一直查询是否有收到串口数据。
如果有则进行解析,并根据解析后的指令是进入升级模式还是丢弃这些不满足期望的数据。
3.前期准备
3.1.编译器是怎么生成烧录文件的
简单讲,编译器就是将“一种语言(通常为高级语言)”翻译为“另一种语言(通常为低级语言)”的程序。
一个现代编译器的主要工作流程:
源代码(sourcecode)→预处理器(preprocessor)→编译器(compiler)→目标代码(objectcode)→链接器(Linker)→可执行程序(executables).
以IAR为例,编译可以细分为三个阶段:
1.源文件解析
IAR中有C/C++和汇编编译器,会根据实际项目中的源文件类型,翻译为中间目标文件.这些文件具备特殊格式,可重定位,作为第二步链接器的输入文件。
2.链接
第一步生成的目标文件,只是一个中间产物,需要通过链接器进行链接,生成烧录文件。
既然要链接,我们首先必须得有链接配置文件。
Stm8s链接配置文件是.icf文件,默认情况下只要我们在工程设置中选取了device,编译器会自动找寻到对应的.icf作为配置文件。
所以之前的课程中,并没有提及。
但是在此次课程中,由于我们需要将flash分为两个部分,因此需要我们对自带的.icf进行适当的修改。
详见3.2.
与此同时,链接器也可以生成其他文件,比较有参考意义的有.map文件。
在.map文件里面我们可以详细的查看flash空间用了多少,一些全局变量和函数被分配到了flash的什么区域。
3.链接以后
链接器生成的一些文件,可以根据需要进一步转换为其他文件,例如给IAR的调试器,方便我们进行调试.或者调用其他外部转换器,转为其他我们所想要格式的烧录文件。
3.2.如何将Bootloader和MainAPP放入特定flash段
LINK链接器是按照用户在ICF文件中的规定来放置sections的,所以理解ICF文件的内容尤其重要。
一个标准的ICF文件可包括下面这些内容:
-可编址的存储空间(memory)
-不同的存储器地址区域(region)
-不同的地址块(block)
-Section的初始化与否
-Section在存储空间中的放置
默认情况下IAR根据Device类别自动选取对应的icf文件,也可以根据需要选定自己写的icf文件,设置方法如下:
OptionLinker,选取自定义文件
所以我们需要分别为bootloader和mainAPP准备icf文件,里面定义的flash地址需要错开,RAM空间可以共用。
下面是两个文件的部分对比,详细的内容请参见bootloader和mainAPP工程下的Linker文件夹。
3.3.MainAPP和Bootloader间的切换和识别
3.3.1.MainAPPBooloader
MainAPP切换到Bootloader的情形为,MainAPP接收到烧录命令,需要跳转到Bootloader,然后由bootloader擦除MainAPP的flash空间。
所以这里存在两个问题:
1.MainAPP如何跳转到Bootloader
2.Bootloader怎么分辨是从MainAPP跳入的,而不是系统硬复位
对于第一个问题,简单的来说,就是收到烧录指令后,我们人为地让程序进入Bootloader的flash首地址存储的地址中去。
Bootloader中的flash开头存放的是中断向量表,PC跳到首地址以后,CPU会先取2个地址,第一个是栈顶地址,第二个是复位异常地址,然后执行复位初始化函数以后,转入执行bootloader的main函数。
如此便开始执行bootloader。
第二问题,我们在ifc文件中定义一段RAM空间,属性为不需要初始化。
正常来说,只要发生复位,不管是硬复位还是软复位,那么RAM区域都会初始化为0(跳入Main函数前的汇编代码中)。
但是如果我们在icf文件中设定为不需要初始化,那么则会跳过这段区域的初始化。
所以在跳转之前,我们将这片RAM区更新为某个特定的值,那么Bootloader开始阶段,以此判断即可。
icf
程序
3.3.2.BooloaderMainAPP
类似的,所以这里也存在两个问题:
1.Bootloader如何跳转到MainAPP
2.Bootloader怎么分辨flash中已经有MainAPP
第一个问题与3.3.1描述的类似,不再重复。
第二个问题也需要利用icf文件。
教程里面用的方法是,在flash地址最末尾预留出一小段,存放特定的字符串。
之所以放在末尾,是因为这段地址最后更新,如果能检测到,说明之前的地址已经烧录了MainAPP。
3.4.如何解析烧录文件
有了前面的准备,我们可以准备工程并且通过工程配置生成IntelHex格式烧录文件。
IntelHEX文件是遵循IntelHEX文件格式的ASCII文本文件。
在IntelHEX文件的每一行都包含了一个HEX记录。
这些记录是由一些代表机器语言代码和常量的16进制数据组成的。
IntelHEX文件常用来传输要存储在ROM或者EPROM中的程序和数据。
每个记录包含5个域,它们按以下格式排列:
StartCode每个IntelHEX记录都由冒号开头
Bytecount是数据长度域,它代表记录当中数据字节的数量
Address是地址域,它代表记录当中数据的起始地址
Recordtype是代表HEX记录类型的域,它可能是以下数据当中的一个:
00-数据记录
01-文件结束记录
02-扩展段地址记录
03-开始段地址记录
04-扩展线性地址记录
05-开始线性地址记录
Data是数据域,一个记录可以有许多数据字节.记录当中数据字节的数量必须和数据长度域中指定的数字相符
Checksum是校验和域,它表示这个记录的校验和.校验和的计算是通过将记录当中所有十六进制编码数字对的值相加,以256为模进行以下补足。
下图是我们此次例程生成的hex文件截图,大家可以对照着看看:
通过上面的说明,我们就可以设计程序在接收到串口数据以后进行解析。
需要注意的是,IntelHex是ASCII文本文件,在烧录前需要转下格式。
举个例子,同样表示0x12,ASCII会将1和2分别拆分为字符“1”和“2”进行传送,所以接收端要将其重新整合为0x12。
3.5.如何利用超级终端发送烧录文件
超级终端估计大家平时比较少用到,我们可以认为它就是一个特殊版本的串口工具。
之所以本次使用它,是因为这个软件有发送文本文件的功能,并且可以设置行延迟,即每发送完一行数据以后,可以根据设定延迟xms后再发送下一行。
如此Bootloader就有时间去处理数据了。
当然,如果大家学有余力且懂得MFC或者VB编程的话,可以自己写个上位机。
使用步骤如下:
-新建连接,名称随便。
我习惯以串口号+波特率方式进行命名:
-选择你的串口号
-设置波特率等。
注意:
数据流控制记得选无:
-然后继续配置属性,行延迟这里设定为200ms,其实也可以选择快一点。
但是为了验证烧录是否正确,stm8s程序加入了测试指令,每烧录一行数据,也会向超级终端回发flash数据,这个需要200ms才能确保不被打断。
-一切就绪就可以选择实际的文本文件发送数据给开发板了
另外为了让stm8s知道什么时候开始擦除以及烧录结束,我们需要给hex文件做个小改动。
我们规定,如果stm8s收到字符串“flash”表示烧录开始,需要擦除MainAPPflash空间;
如果收到字符串“end”,则表示烧录结束,可以reset了。
4.工程介绍
为了验证烧录是否ok,此次课程有三个工程,一个自然是bootloader,LED每100ms闪烁以此,一个是以500ms闪烁的MainAPP,第三个是以2s闪烁的MainAPP。
大家就可以明确地感受是否正常烧录进去对应的MainAPP了。
Bootloader主程序示意图如下所示:
MainAPP主程序示意图:
具体细节可以查看代码,都有很详细的注释了,详细大家都能看懂。
5.问题汇总和后续改进
注意事项和总结:
1.Stm8s虽然支持中断向量表重映射,但是bootloader和APP似乎一次只能有一个能使能中断,用远跳转的方式会有问题。
有兴趣的可以深入研究下。
例程的bootloader有使用中断,MainAPP并没有开启中断。
2.超级终端发送文本没有内置任何握手协议,它只管按行发送数据,如果发送过程中异常,发送和接收方无法自动重发;
3.例程使用的是stm8s103,flash空间才8k。
单单bootloader就用去了差不多5k了。
也是因为这个原因和上位机的限制,最初我们定义的升级模式的行为逻辑并没有完全实现,如下图,红色框图的步骤我们并不具备。
如果大家后续有在其他更大flash容量的芯片使用bootloader的需求,可以参考本次例程进行进一步完善。
如有其它问题,欢迎咨询。
源码可以加入qq交流群索取:
478737279.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Stm8sIAPBootloader 设计