一种BootLoader的管理方法

文档序号:8445431阅读:300来源:国知局
一种BootLoader的管理方法
【技术领域】
[0001]本发明涉及一种BootLoader的管理方法,尤其涉及一种利用车辆上通用的CAN总线,实时更新加载应用代码的BootLoader的管理方法,属于新能源汽车整车控制系统软件领域。
【背景技术】
[0002]如今,BootLoader广泛应用于汽车控制系统,是一种在不借助调试仿真器的前提下,利用如SC1、SP1、CAN等通信媒介,引导处理器并加载应用软件的引导程序,其作用类似于PC机中的B1S。
[0003]现有的BootLoader能够在不拆卸控制器的情况下实现对应用代码的加载,这给现场开发人员与远程开发人员的交互提供了便利,保证了源代码的隐秘性,并对部件的布置和隐藏提供了便利。
[0004]但是现有的BootLoader还存在诸多问题,具体问题如下:1.当需要优化BootLoader自身引导功能时,需要通过TBDML等方式重新加载BootFlash,这样就需要对控制器进行拆卸,甚至对整车电气系统布局进行破坏,并且同时需要专业的技术人员借助专门的设备进行现场调试操作,整个过程非常复杂和麻烦;2.当对AppFlash进行加载更新的时候,需要同时考虑对BootFlash进行加载更新;3.在车辆运行过程中,若需要对BootFlash进行加载更新,但由于个人操作的不注意,整车可能带着高压电运行,在程序的加载进行中,有可能对高压线束以及相关零部件造成影响;4.在带有BootLoader功能的新能源车辆控制器的Flash中,由于同时存在BootFlash和AppFlash,对于初次装上车辆控制器的试验车辆,在整车某部件出现异常却毫不知情而导致应用代码无法运行的情况下,无法获知此时程序是否已经加载应用代码;5.在BootLoader加载代码的过程中,由于使用不当或者意外掉电等情况的发生,容易导致加载异常而导致控制器失效。

【发明内容】

[0005]本发明的目的在于:针对上述现有技术存在的问题,提出一种BootLoader的管理方法,本发明能够真正实现控制器免拆卸,使用固定CAN通道,通过该固定CAN通道,能够实现AppFlash加载BootFlash以及BootFlash加载AppFlash,实现两种代码更新模式的无缝对接和跳转。
[0006]为了达到以上目的,本发明一种BootLoader的管理方法,其特征在于,该方法包括配置Flash存储空间、自定义指令流程、更新加载AppFlash和BootFlash、以及定位运行模式。
[0007]进一步地,所述配置Flash存储空间包括将Flash存储空间划分为如下区域:区域一为寄存器配置区、E印rom存储区,寄存器配置区负责硬件平台的初始化,Eeprom区负责系统故障码的存储;区域二为内存区,用于存储参数变量以及标定参数的镜像映射;区域三为应用代码AppFlash区,包含JumpFlash区、标定常量区、中断向量区、中断代码区以及默认常规应用代码区;区域四为BootFlash区,包含启动代码、中断向量,中断代码;区域五系统默认复位向量区,其指向BootFlash的首地址。
[0008]进一步地,所述自定义指令流程包括自定义的控制命令帧和应答响应帧;所述控制命令帧包括连接、烧写和断开命令帧,所述应答响应帧包括命令应答肯定响应和擦除、烧写完成肯定响应。
[0009]所述BootFlash加载更新AppFlash的方法步骤如下:
Stepl:设置BootFlash、AppFlash和JumpFlash的地址范围,以及对应的中断向量区和中断代码区;
Step2:系统上电,开始初始化配置,系统从复位向量区指定的起始地址处开始执行,默认的是上电后从BootFlash的起始地址处执行,代码初始化中断向量区以及初始化寄存器配置;初始化配置完成之后,系统判断JumpFlash对应的有效数据是否为AppFlash首地址,同时AppFlash具有有效代码,若条件满足,跳转AppFlash运行,进入应用代码模式;否则,自动在默认的BootFlash运行,即进入BootLoader模式;以JumpFlash处的有效地址作为条件判断之一,用于防止系统掉电后的判断条件无效,另一方面强调跳转AppFlash的可靠性,另一判断条件则用于判断AppFlash是否含有代码,防止误跳转;
Step3:上位机发送连接指令给下位机,让下位机为实现代码加载做准备;
在进行加载代码时,上位机与下位机的交互应该按照自定义的命令帧与应答帧的流程进行,命令帧ByteO为自定义的Cmd,第二个字节Byte2为命令计数Ctr,每发送一帧命令,命令计数Ctr加I,直到255后重新置I,初始命令帧的Ctr=I,命令帧的Byte6=Byte7=0XFF ;连接命令帧ByteO为自定义的Cmd=OxOl ;
Step4:下位机成功获取连接命令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功;命令肯定应答ByteO=OxOO,并且Bytel=Ctr与命令帧一致,Byte6=Byte7=0xFF ;E⑶接收到连接命令后,检测对应的AppFlash是否擦除完成,若否,擦除AppFlash空间,为下一步AppFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step5:当AppFlash和JumpFlash擦除成功的前提下,E⑶向上位机响应擦除完成应答;擦除完成肯定应答ByteO=OxOO,并且Bytel=Ctr与命令帧一致;其余字节为O ;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载命令,下载命令 ByteO (Cmd) =0x22,Byte2:Byte4=ProgramAddress (烧写地址),Byte5=CRC (检验码),Byte6:Byte7=0XFF ;
Step6:下位机成功获取下载命令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;命令肯定应答Byte0=0x00,并且Bytel=Ctr与命令帧一致,Byte6=Byte7=0xFF ;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后ECU回复烧写完成应答并执行下次可执行文件烧写进程;
所述可执行文件是由基于Freescale S12系列平台的控制代码生成的S19格式可执行文件;S19文件内每一行数据包含格式、地址信息、校验码和烧写数据;所述Step6的具体步骤如下:
Step6-1:上位机通过对可执行文件进行逐行解析发送,下位机逐行烧写;
St印6-2:上位机发送一帧报文,下位机判断报文是否满足下载命令帧格式,若满足,获取命令报文中地址信息和校验码,为获取下面的烧写数据信息做准备,发送烧写肯定响应;同时下位机发送肯定响应给上位机;
St印6-3:在相应下载命令帧的基础上,下位机ECU接收来自上位机的烧写数据帧;上位机通过识别获取ASCII值OxOD (回车符)判定是否已经到达一行数据的最后一个字节,从而为发送下一行数据做准备;在接收一行S19文件后,通过计算当前数据检验码与接收的校验码作比较,保证数据传输的可靠性;
Step6-4:若校验码配对成功,下位机根据获取的地址信息,将接收到的数据烧写到对应的地址中;烧写成功之后,向上位机发送烧写肯定响应数据帧;其肯定应答ByteO=OxOO,并且Bytel=Ctr与命令帧一致,Byte6=Byte7=0xFF ;参考图5 ;
Step6-5:在烧写一行可执行文件成功后,进入下一行文件的烧写工作,进程转入St印6-1 ;整个执行文件烧写成功之后。转而回到St印7执行。
[0010]Step7:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,E⑶回复断开肯定应答信号,并向JumpFlash烧写AppFlash首地址。
[0011]所述AppFlash加载更新BootFlash以及重新更新AppFlash的方法步骤如下:
St印8:系统跳转到AppFla
当前第1页1 2 3 4 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1