CN104765632A - 一种BootLoader的管理方法 - Google Patents
一种BootLoader的管理方法 Download PDFInfo
- Publication number
- CN104765632A CN104765632A CN201510176703.4A CN201510176703A CN104765632A CN 104765632 A CN104765632 A CN 104765632A CN 201510176703 A CN201510176703 A CN 201510176703A CN 104765632 A CN104765632 A CN 104765632A
- Authority
- CN
- China
- Prior art keywords
- programming
- appflash
- code
- bootflash
- bootloader
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
本发明公开了一种BootLoader的管理方法,该方法包括配置Flash存储空间、自定义指令流程、更新加载AppFlash和BootFlash、以及定位运行模式;本发明能够真正实现免拆卸,本发明的代码加载接口使用固定CAN通道,通过该固定CAN通道,能够实现应用代码AppFlash中加载启动代码BootFlash以及启动代码BootFlash中加载应用代码AppFlash,实现两种代码更新模式的无缝对接和跳转;同时利用该固定CAN通道可实现除了BootLoader模式以外的其它多种模式复用,包括标定、诊断、自测试、调试、监控等,提高了硬件的资源利用效率。
Description
技术领域
本发明涉及一种BootLoader的管理方法,尤其涉及一种利用车辆上通用的CAN总线,实时更新加载应用代码的BootLoader的管理方法,属于新能源汽车整车控制系统软件领域。
背景技术
如今,BootLoader广泛应用于汽车控制系统,是一种在不借助调试仿真器的前提下,利用如SCI、SPI、CAN等通信媒介,引导处理器并加载应用软件的引导程序,其作用类似于PC机中的BIOS。
现有的BootLoader能够在不拆卸控制器的情况下实现对应用代码的加载,这给现场开发人员与远程开发人员的交互提供了便利,保证了源代码的隐秘性,并对部件的布置和隐藏提供了便利。
但是现有的BootLoader还存在诸多问题,具体问题如下:1.当需要优化BootLoader自身引导功能时,需要通过TBDML等方式重新加载BootFlash,这样就需要对控制器进行拆卸,甚至对整车电气系统布局进行破坏,并且同时需要专业的技术人员借助专门的设备进行现场调试操作,整个过程非常复杂和麻烦;2.当对AppFlash进行加载更新的时候,需要同时考虑对BootFlash进行加载更新;3.在车辆运行过程中,若需要对BootFlash进行加载更新,但由于个人操作的不注意,整车可能带着高压电运行,在程序的加载进行中,有可能对高压线束以及相关零部件造成影响;4.在带有BootLoader功能的新能源车辆控制器的Flash中,由于同时存在BootFlash和AppFlash,对于初次装上车辆控制器的试验车辆,在整车某部件出现异常却毫不知情而导致应用代码无法运行的情况下,无法获知此时程序是否已经加载应用代码;5.在BootLoader加载代码的过程中,由于使用不当或者意外掉电等情况的发生,容易导致加载异常而导致控制器失效。
发明内容
本发明的目的在于:针对上述现有技术存在的问题,提出一种BootLoader的管理方法,本发明能够真正实现控制器免拆卸,使用固定CAN通道,通过该固定CAN通道,能够实现AppFlash加载BootFlash以及BootFlash加载AppFlash,实现两种代码更新模式的无缝对接和跳转。
为了达到以上目的,本发明一种BootLoader的管理方法,其特征在于,该方法包括配置Flash存储空间、自定义指令流程、更新加载AppFlash和BootFlash、以及定位运行模式。
进一步地,所述配置Flash存储空间包括将Flash存储空间划分为如下区域:区域一为寄存器配置区、Eeprom存储区,寄存器配置区负责硬件平台的初始化,Eeprom区负责系统故障码的存储;区域二为内存区,用于存储参数变量以及标定参数的镜像映射;区域三为应用代码AppFlash区,包含JumpFlash区、标定常量区、中断向量区、中断代码区以及默认常规应用代码区;区域四为BootFlash区,包含启动代码、中断向量,中断代码;区域五系统默认复位向量区,其指向BootFlash的首地址。
进一步地,所述自定义指令流程包括自定义的控制命令帧和应答响应帧;所述控制命令帧包括连接、烧写和断开命令帧,所述应答响应帧包括命令应答肯定响应和擦除、烧写完成肯定响应。
所述BootFlash加载更新AppFlash的方法步骤如下:
Step1:设置BootFlash、AppFlash和JumpFlash的地址范围,以及对应的中断向量区和中断代码区;
Step2:系统上电,开始初始化配置,系统从复位向量区指定的起始地址处开始执行,默认的是上电后从BootFlash的起始地址处执行,代码初始化中断向量区以及初始化寄存器配置;初始化配置完成之后,系统判断JumpFlash对应的有效数据是否为AppFlash首地址,同时AppFlash具有有效代码,若条件满足,跳转AppFlash运行,进入应用代码模式;否则,自动在默认的BootFlash运行,即进入BootLoader模式;以JumpFlash处的有效地址作为条件判断之一,用于防止系统掉电后的判断条件无效,另一方面强调跳转AppFlash的可靠性,另一判断条件则用于判断AppFlash是否含有代码,防止误跳转;
Step3:上位机发送连接指令给下位机,让下位机为实现代码加载做准备;
在进行加载代码时,上位机与下位机的交互应该按照自定义的命令帧与应答帧的流程进行,命令帧Byte0为自定义的Cmd,第二个字节Byte2为命令计数Ctr,每发送一帧命令,命令计数Ctr加1,直到255后重新置1,初始命令帧的Ctr=1,命令帧的Byte6=Byte7=0xFF;连接命令帧Byte0为自定义的Cmd=0x01;
Step4:下位机成功获取连接命令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功;命令肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致,Byte6=Byte7=0xFF;ECU接收到连接命令后,检测对应的AppFlash是否擦除完成,若否,擦除AppFlash空间,为下一步AppFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step5:当AppFlash和JumpFlash擦除成功的前提下,ECU向上位机响应擦除完成应答;擦除完成肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致;其余字节为0;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载命令,下载命令Byte0(Cmd)=0x22,Byte2:Byte4=ProgramAddress(烧写地址),Byte5=CRC(检验码),Byte6:Byte7=0XFF;
Step6:下位机成功获取下载命令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;命令肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致,Byte6=Byte7=0xFF;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后ECU回复烧写完成应答并执行下次可执行文件烧写进程;
所述可执行文件是由基于Freescale S12系列平台的控制代码生成的S19格式可执行文件;S19文件内每一行数据包含格式、地址信息、校验码和烧写数据;所述Step6的具体步骤如下:
Step6-1:上位机通过对可执行文件进行逐行解析发送,下位机逐行烧写;
Step6-2:上位机发送一帧报文,下位机判断报文是否满足下载命令帧格式,若满足,获取命令报文中地址信息和校验码,为获取下面的烧写数据信息做准备,发送烧写肯定响应;同时下位机发送肯定响应给上位机;
Step6-3:在相应下载命令帧的基础上,下位机ECU接收来自上位机的烧写数据帧;上位机通过识别获取ASCII值0x0D(回车符)判定是否已经到达一行数据的最后一个字节,从而为发送下一行数据做准备;在接收一行S19文件后,通过计算当前数据检验码与接收的校验码作比较,保证数据传输的可靠性;
Step6-4:若校验码配对成功,下位机根据获取的地址信息,将接收到的数据烧写到对应的地址中;烧写成功之后,向上位机发送烧写肯定响应数据帧;其肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致,Byte6=Byte7=0xFF;参考图5;
Step6-5:在烧写一行可执行文件成功后,进入下一行文件的烧写工作,进程转入Step6-1;整个执行文件烧写成功之后。转而回到Step7执行。
Step7:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,ECU回复断开肯定应答信号,并向JumpFlash烧写AppFlash首地址。
所述AppFlash加载更新BootFlash以及重新更新AppFlash的方法步骤如下:
Step8:系统跳转到AppFlash运行,AppFlash代码初始段设置其对应的中断向量寄存器;
Step9:在应用代码模式运行中,若检测到应用代码更新指令,则对JumpFlash区进行擦除操作,擦除成功后,软件复位重新运行,进入BootLoader模式;
Step10:在应用代码模式运行中,若检测到BootLoader更新指令,则继续检测下位机是否收到连接指令,当下位机成功获取连接指令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功; ECU接收到连接指令后,检测对应的BootFlash是否擦除完成,若否,擦除BootFlash空间,为下一步BootFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step11:当BootFlash和JumpFlash擦除成功的前提下,ECU向上位机响应擦除完成应答;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载指令;
Step12:下位机成功获取下载指令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后,ECU回复烧写完成应答并执行下次可执行文件烧写进程;
Step13:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,ECU回复断开肯定应答信号,并擦除JumpFlash跳转标识段;
Step14:JumpFlash擦除成功后,软件复位重新运行;
Step15:系统重新在BootFlash运行,进入BootLoader模式。
进一步地,所述BootFlash和AppFlash之间的相互加载更新使用固定的CAN通道,利用该通道可实现除了BootLoader模式以外的其它多种模式复用,包括标定、诊断、自测试、调试和监控模式。
进一步地,所述定位运行模式的方法为:连接CAN收发器,发送任一标定、诊断、自测试、调试、和监控的命令帧,若握手成功,系统运行在应用代码模式,若握手失败,系统运行在BootLoader模式。
进一步地,所述执行擦除和烧写操作时,禁止一切中断事件的发生;在首次加载应用代码时,当出现异常事件的发生,例如:断电,一旦上电,系统跳转至启动代码执行。
进一步地,所有代码的加载更新应在车辆停止,高压掉电的情况下执行。
本发明的突出效果是:
本发明能够真正实现免拆卸,使用固定CAN通道,通过该固定CAN通道,能够实现AppFlash加载BootFlash以及BootFlash加载AppFlash,实现两种代码更新模式的无缝对接和跳转;同时利用该固定CAN通道可实现除了BootLoader模式以外的其它多种模式复用,包括标定、诊断、自测试、调试、监控等,提高了硬件的资源利用效率;本发明通过指令特定的指令帧报文和应答报文,能够实现运行模式的快速定位,只需连接CAN收发器,发送任一标定、诊断、自测试、调试、和监控的命令帧,若握手成功,系统运行在应用代码模式,若握手失败,系统运行在BootLoader模式,同时本发明中BootLoader编译成电控单元镜像文件烧入指定Flash中,保证了默认中断向量处的指定地址,为后续从其指定地址处判断执行代码的运行模式提供依据;本发明能够兼容多种CAN通信平台,通过制定多指令帧来防止启动的BootLoader出现异常而导致控制器失效;本发明能够自动定位烧写地址、配置跳转模式和优化资源配置,具有工作效率高、可靠性和可兼容性高的特点;本发明自定义指令帧,实现加载流程,灵活性强、流程更加简化,一方面防止了某个特定的协议对加载进程的约束,同时可以兼顾其他上位机的CAN硬件平台;自定义的控制指令帧和应答响应帧为整个BootLoader功能的执行进程提供保证,不需要额外的时间等待来保证上一步的执行,只需判断响应应答来执行流程步骤,从而降低了对上位机硬件平台选型的局限性,缩小了成本。
附图说明
下面结合附图对本发明作进一步的说明。
图1为本发明控制器存储空间分配图。
图2为本发明BootFlash加载更新AppFlash的流程图。
图3为本发明AppFlash加载更新BootFlash以及重新更新AppFlash的流程图。
图4为本发明控制系统加载可执行文件的流程图。
图5为本发明实行加载流程的指令帧和应答响应格式帧。
具体实施方式
本发明BootLoader的管理方法,是一种基于Freescale S12系列硬件为平台,以依维柯新能源客车为载体,实现车辆控制器代码的BootLoader管理方法。
本发明BootLoader的管理方法,包括配置Flash存储空间、自定义指令流程、更新加载AppFlash和BootFlash、以及定位运行模式。
如图1所示,所述配置Flash存储空间包括将Flash存储空间划分为如下区域:区域一为寄存器配置区、Eeprom存储区,寄存器配置区负责硬件平台的初始化,Eeprom区负责系统故障码的存储;区域二为内存区,用于存储参数变量以及标定参数的镜像映射;区域三为应用代码AppFlash区,包含JumpFlash区、标定常量区、中断向量区、中断代码区以及默认常规应用代码区;区域四为BootFlash区,包含启动代码、中断向量,中断代码;区域五系统默认复位向量区,其指向BootFlash的首地址。
如图5所示,所述自定义指令流程包括自定义的控制命令帧和应答响应帧;所述控制命令帧包括连接、烧写和断开命令帧,所述应答响应帧包括命令应答肯定响应和擦除、烧写完成肯定响应。
如图2所示, BootFlash加载更新AppFlash的方法步骤如下:
Step1:设置BootFlash、AppFlash和JumpFlash的地址范围,以及对应的中断向量区和中断代码区;
Step2:系统上电,开始初始化配置,系统从复位向量区指定的起始地址处开始执行,默认的是上电后从BootFlash的起始地址处执行,代码初始化中断向量区以及初始化寄存器配置;初始化配置完成之后,系统判断JumpFlash对应的有效数据是否为AppFlash首地址,同时AppFlash具有有效代码,若条件满足,跳转AppFlash运行,进入应用代码模式;否则,自动在默认的BootFlash运行,即进入BootLoader模式;以JumpFlash处的有效地址作为条件判断之一,用于防止系统掉电后的判断条件无效,另一方面强调跳转AppFlash的可靠性,另一判断条件则用于判断AppFlash是否含有代码,防止误跳转;
Step3:上位机发送连接指令给下位机,让下位机为实现代码加载做准备;在进行加载代码时,上位机与下位机的交互应该按照自定义的命令帧与应答帧的流程进行,命令帧Byte0为自定义的Cmd,第二个字节Byte2为命令计数Ctr,每发送一帧命令,命令计数Ctr加1,直到255后重新置1,初始命令帧的Ctr=1,命令帧的Byte6=Byte7=0xFF;连接命令帧Byte0为自定义的Cmd=0x01;
Step4:下位机成功获取连接命令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功;命令肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致,Byte6=Byte7=0xFF;ECU接收到连接命令后,检测对应的AppFlash是否擦除完成,若否,擦除AppFlash空间,为下一步AppFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step5:当AppFlash和JumpFlash擦除成功的前提下,ECU向上位机响应擦除完成应答;擦除完成肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致;其余字节为0;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载命令,下载命令Byte0(Cmd)=0x22,Byte2:Byte4=ProgramAddress(烧写地址),Byte5=CRC(检验码),Byte6:Byte7=0XFF;
Step6:下位机成功获取下载命令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;命令肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致,Byte6=Byte7=0xFF;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后ECU回复烧写完成应答并执行下次可执行文件烧写进程;
本发明的可执行文件是由基于Freescale S12系列平台的控制代码生成的S19格式可执行文件;S19文件内每一行数据包含格式、地址信息、校验码和烧写数据;如图4所示,所述Step6的具体步骤如下:
Step6-1:上位机通过对可执行文件进行逐行解析发送,下位机逐行烧写;
Step6-2:上位机发送一帧报文,下位机判断报文是否满足下载命令帧格式,若满足,获取命令报文中地址信息和校验码,为获取下面的烧写数据信息做准备,发送烧写肯定响应;同时下位机发送肯定响应给上位机;
Step6-3:在相应下载命令帧的基础上,下位机ECU接收来自上位机的烧写数据帧;上位机通过识别获取ASCII值0x0D(回车符)判定是否已经到达一行数据的最后一个字节,从而为发送下一行数据做准备;在接收一行S19文件后,通过计算当前数据检验码与接收的校验码作比较,保证数据传输的可靠性;
Step6-4:若校验码配对成功,下位机根据获取的地址信息,将接收到的数据烧写到对应的地址中;烧写成功之后,向上位机发送烧写肯定响应数据帧;其肯定应答Byte0=0x00,并且Byte1=Ctr与命令帧一致,Byte6=Byte7=0xFF,参考图5;
Step6-5:在烧写一行可执行文件成功后,进入下一行文件的烧写工作,进程转入Step6-1;整个执行文件烧写成功之后。转而回到Step7执行。
Step7:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,ECU回复断开肯定应答信号,并向JumpFlash烧写AppFlash首地址。
如图3所示,AppFlash加载更新BootFlash以及重新更新AppFlash的方法步骤如下:
Step8:系统跳转到AppFlash运行,AppFlash代码初始段设置其对应的中断向量寄存器;
Step9:在应用代码模式运行中,若检测到应用代码更新指令,则对JumpFlash区进行擦除操作,擦除成功后,软件复位重新运行,进入BootLoader模式;
Step10:在应用代码模式运行中,若检测到BootLoader更新指令,则继续检测下位机是否收到连接指令,当下位机成功获取连接指令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功; ECU接收到连接指令后,检测对应的BootFlash是否擦除完成,若否,擦除BootFlash空间,为下一步BootFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step11:当BootFlash和JumpFlash擦除成功的前提下,ECU向上位机响应擦除完成应答;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载指令;
Step12:下位机成功获取下载指令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后,ECU回复烧写完成应答并执行下次可执行文件烧写进程;
Step13:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,ECU回复断开肯定应答信号,并擦除JumpFlash跳转标识段;
Step14:JumpFlash擦除成功后,软件复位重新运行;
Step15:系统重新在BootFlash运行,进入BootLoader模式。
本发明所述BootFlash和AppFlash之间的相互加载更新使用固定的CAN通道,利用该通道可实现除了BootLoader模式以外的其它多种模式复用,包括标定、诊断、自测试、调试和监控模式。所述定位运行模式的方法为:连接CAN收发器,发送任一标定、诊断、自测试、调试、和监控的命令帧,若握手成功,系统运行在应用代码模式,若握手失败,系统运行在BootLoader模式。所述执行擦除和烧写操作时,禁止一切中断事件的发生;在首次加载应用代码时,当出现异常事件的发生,例如:断电,一旦上电,系统跳转至启动代码执行。所有代码的加载更新应在车辆停止,高压掉电的情况下执行。
本发明在加载进程有序运行过程当中,若出现掉电或复位等异常情况,只要JumpFlash段条件无效,系统仍在BootFlash中运行。在对Flash进行操作时,通过禁止中断和实时监测Flash状态,防止对Flash的操作失效,若Flash操作失效,程序不进行跳转,程序重新执行一次代码加载。在跳转AppFlash条件有效时,无需掉电复位,直接进行Jump到AppFlash的首地址。若需要更新BootFlash,在应用代码中,通过识别更新BootFlash的命令帧,应用代码进入到更新BootFlash模式,整车控制器不受高压影响,强行掉高压电,通过自定义加载流程,完成对BootLoader功能的更新,更新过程当中,监测到断开指令,执行对JumpFlash的烧写,程序执行软复位,跳转至BootFlash段运行,为重新加载应用程序做准备。AppFlash和BootFlash有对应的中断向量,在各自代码程序块的初始化起始段,重新定义各自对应的中断向量寄存器。
本发明能够真正实现免拆卸,本发明使用固定CAN通道,通过该固定CAN通道,能够实现AppFlash加载BootFlash以及BootFlash加载AppFlash,实现两种代码更新模式的无缝对接和跳转;同时利用该固定CAN通道可实现除了BootLoader模式以外的其它多种模式复用,包括标定、诊断、自测试、调试、监控等,提高了硬件的资源利用效率;本发明通过指令特定的指令帧报文和应答报文,能够实现运行模式的快速定位,只需连接CAN收发器,发送任一标定、诊断、自测试、调试、和监控的命令帧,若握手成功,系统运行在应用代码模式,若握手失败,系统运行在BootLoader模式,同时本发明中BootLoader编译成电控单元镜像文件烧入指定Flash中,保证了默认中断向量处的指定地址,为后续从其指定地址处判断执行代码的运行模式提供依据;本发明能够兼容多种CAN通信平台,通过制定多指令帧来防止启动的BootLoader出现异常而导致控制器失效;本发明能够自动定位烧写地址、配置跳转模式和优化资源配置,具有工作效率高、可靠性和可兼容性高的特点。
本发明自定义指令帧,实现加载流程,灵活性强、流程更加简化,一方面防止了某个特定的协议对加载进程的约束,同时可以兼顾其他上位机的CAN硬件平台;自定义的控制指令帧和应答响应帧为整个BootLoader功能的执行进程提供保证,不需要额外的时间等待来保证上一步的执行,只需判断响应应答来执行流程步骤,从而降低了对上位机硬件平台选型的局限性,缩小了成本。整车在测试过程当中,往往有数据获取(从CAN总线获取)和代码更新的需求,为了保证相关测试人员人手有一套总线测试和代码更新的设备,需要选择成本低的测试和代码加载工具。同时为了兼顾多种CAN硬件平台,避免CAN收发工具只能用于总线测试这单一功能使用,减少开发成本,因此自制定协议。
除上述实施例外,本发明还可以有其他实施方式。凡采用等同替换或等效变换形成的技术方案,均落在本发明要求的保护范围。
Claims (10)
1.一种BootLoader的管理方法,其特征在于:该方法包括配置Flash存储空间、自定义指令流程、加载更新AppFlash和BootFlash、以及定位运行模式。
2.根据权利要求1所述的一种BootLoader的管理方法,其特征在于:所述配置Flash存储空间包括将Flash存储空间划分为如下区域:区域一为寄存器配置区、Eeprom存储区,寄存器配置区负责硬件平台的初始化,Eeprom区负责系统故障码的存储;区域二为内存区,用于存储参数变量以及标定参数的镜像映射;区域三为应用代码AppFlash区,包含JumpFlash区、标定常量区、中断向量区、中断代码区以及默认常规应用代码区;区域四为BootFlash区,包含启动代码、中断向量,中断代码;区域五系统默认复位向量区,其指向BootFlash的首地址。
3.根据权利要求1所述的一种BootLoader的管理方法,其特征在于:所述自定义指令流程包括自定义的控制命令帧和应答响应帧;所述控制命令帧包括连接、烧写和断开命令帧,所述应答响应帧包括命令应答肯定响应和擦除、烧写完成肯定响应。
4.根据权利要求1所述的一种BootLoader的管理方法,其特征在于:所述BootFlash加载更新AppFlash的方法步骤如下:
Step1:设置BootFlash、AppFlash和JumpFlash的地址范围,以及对应的中断向量区和中断代码区;
Step2:系统上电,开始初始化配置,系统从复位向量区指定的起始地址处开始执行,默认的是上电后从BootFlash的起始地址处执行,代码初始化中断向量区以及初始化寄存器配置;初始化配置完成之后,系统判断JumpFlash对应的有效数据是否为AppFlash首地址,同时AppFlash具有有效代码,若条件满足,跳转AppFlash运行,进入应用代码模式;否则,自动在默认的BootFlash运行,即进入BootLoader模式;
Step3:上位机发送连接指令给下位机,让下位机为实现代码加载做准备;
Step4:下位机成功获取连接命令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功;ECU接收到连接命令后,检测对应的AppFlash是否擦除完成,若否,擦除AppFlash空间,为下一步AppFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step5:当AppFlash和JumpFlash擦除成功的前提下,ECU向上位机响应擦除完成应答;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载命令;
Step6:下位机成功获取下载命令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后ECU回复烧写完成应答并执行下次可执行文件烧写进程;
Step7:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,ECU回复断开肯定应答信号,并向JumpFlash烧写AppFlash首地址。
5.根据权利要求4所述的一种BootLoader的管理方法,其特征在于:所述可执行文件是由基于Freescale S12系列平台的控制代码生成的S19格式可执行文件;S19文件内每一行数据包含格式、地址信息、校验码和烧写数据;所述Step6的具体步骤如下:
Step6-1:上位机通过对可执行文件进行逐行解析发送,下位机逐行烧写;
Step6-2:上位机发送一帧报文,下位机判断报文是否满足下载命令帧格式,若满足,获取命令报文中地址信息和校验码,为获取下面的烧写数据信息做准备,发送烧写肯定响应;同时下位机发送肯定响应给上位机;
Step6-3:在相应下载命令帧的基础上,下位机ECU接收来自上位机的烧写数据帧;上位机通过识别获取ASCII值0x0D,判定是否已经到达一行数据的最后一个字节,从而为发送下一行数据做准备;在接收一行S19文件后,通过计算当前数据检验码与接收的校验码作比较,保证数据传输的可靠性;
Step6-4:若校验码配对成功,下位机根据获取的地址信息,将接收到的数据烧写到对应的地址中;烧写成功之后,向上位机发送烧写肯定响应数据帧;
Step6-5:在烧写一行可执行文件成功后,进入下一行文件的烧写工作,进程转入Step6-1;整个执行文件烧写成功之后,转而回到Step7执行。
6.根据权利要求1所述的一种BootLoader的管理方法,其特征在于:所述AppFlash加载更新BootFlash以及重新更新AppFlash的方法步骤如下:
Step8:系统跳转到AppFlash运行,AppFlash代码初始段设置其对应的中断向量寄存器;
Step9:在应用代码模式运行中,若检测到应用代码更新指令,则对JumpFlash区进行擦除操作,擦除成功后,软件复位重新运行,进入BootLoader模式;
Step10:在应用代码模式运行中,若检测到BootLoader更新指令,则继续检测下位机是否收到连接指令,当下位机成功获取连接指令后,ECU回复肯定应答响应,使上位机监测到ECU与其握手成功; ECU接收到连接指令后,检测对应的BootFlash是否擦除完成,若否,擦除BootFlash空间,为下一步BootFlash的程序烧写做准备;同时擦除JumpFlash条件空间,为识别后面的断开指令时,烧写JumpFlash空间做准备;
Step11:当BootFlash和JumpFlash擦除成功的前提下,ECU向上位机响应擦除完成应答;在上位机获取连接肯定应答和擦除完成肯定应答双重条件下,发送程序下载指令;
Step12:下位机成功获取下载指令后,ECU回复肯定应答响应,当上位机监测到下载肯定应答响应后,发送可执行文件烧写数据帧;下位机接收到可执行文件烧写数据帧后执行当次烧写进程,当次烧写完成后,ECU回复烧写完成应答并执行下次可执行文件烧写进程;
Step13:当可执行文件烧写完成后,上位机发断开指令,下位机接收到断开指令后,ECU回复断开肯定应答信号,并擦除JumpFlash跳转标识段;
Step14:JumpFlash擦除成功后,软件复位重新运行;
Step15:系统重新在BootFlash运行,进入BootLoader模式。
7.根据权利要求5或6所述的一种BootLoader的管理方法,其特征在于:所有代码的加载更新应在车辆停止,高压掉电的情况下执行。
8.根据权利要求5或6所述的一种BootLoader的管理方法,其特征在于:所述BootFlash和AppFlash之间的相互加载更新使用固定的CAN通道,利用该通道可实现除了BootLoader模式以外的其它多种模式复用,包括标定、诊断、自测试、调试和监控模式。
9.根据权利要求5或6所述的一种BootLoader的管理方法,其特征在于:所述执行擦除和烧写操作时,禁止一切中断事件的发生;在首次加载应用代码时,当出现异常事件的发生,例如:断电,一旦上电,系统跳转至启动代码执行。
10.根据权利要求1所述的一种BootLoader的管理方法,其特征在于:所述定位运行模式的方法为:连接CAN收发器,发送任一标定、诊断、自测试、调试、和监控的命令帧,若握手成功,系统运行在应用代码模式,若握手失败,系统运行在BootLoader模式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510176703.4A CN104765632A (zh) | 2015-04-15 | 2015-04-15 | 一种BootLoader的管理方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510176703.4A CN104765632A (zh) | 2015-04-15 | 2015-04-15 | 一种BootLoader的管理方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104765632A true CN104765632A (zh) | 2015-07-08 |
Family
ID=53647480
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510176703.4A Pending CN104765632A (zh) | 2015-04-15 | 2015-04-15 | 一种BootLoader的管理方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104765632A (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105159188A (zh) * | 2015-08-14 | 2015-12-16 | 广州智维电子科技有限公司 | 一种新能源整车异构网络仿真器及控制方法 |
CN105204896A (zh) * | 2015-09-08 | 2015-12-30 | 江苏绿扬电子仪器集团有限公司 | 一种数字存储示波器的BootLoader设计方法 |
CN107678792A (zh) * | 2017-09-06 | 2018-02-09 | 中国航空工业集团公司西安飞行自动控制研究所 | 一种基于can总线的多余度目标机在线加载方法 |
CN108228198A (zh) * | 2016-12-22 | 2018-06-29 | 比亚迪股份有限公司 | 烧写方法及装置 |
CN108427569A (zh) * | 2018-06-07 | 2018-08-21 | 合肥美菱股份有限公司 | 一种家用电冰箱在线升级控制程序的方法 |
CN108664256A (zh) * | 2017-03-28 | 2018-10-16 | 宁德时代新能源科技股份有限公司 | 系统的固件更新方法、装置和电池管理系统 |
CN111814139A (zh) * | 2020-07-02 | 2020-10-23 | 深圳市法拉第电驱动有限公司 | 汽车电机控制器程序安全加载系统及方法 |
CN112015456A (zh) * | 2019-05-31 | 2020-12-01 | 河南森源电动汽车有限公司 | 一种BootLoader程序更新方法 |
CN112859809A (zh) * | 2021-01-11 | 2021-05-28 | 上海星融汽车科技有限公司 | 车辆ecu刷写方法、系统及车辆诊断设备的下位机 |
CN113342385A (zh) * | 2021-04-29 | 2021-09-03 | 博格思众(常州)空调系统有限公司 | 软件升级方法及装置、空调控制面板 |
-
2015
- 2015-04-15 CN CN201510176703.4A patent/CN104765632A/zh active Pending
Non-Patent Citations (2)
Title |
---|
吴成加: ""基于CAN Bootloader的电动汽车远程数据更新系统设计"", 《客车技术与研究》 * |
张博等: ""一种Freescale单片机基于CAN的Bootloader的实现"", 《第十一届河南省汽车工程科技学术研讨会》 * |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105159188A (zh) * | 2015-08-14 | 2015-12-16 | 广州智维电子科技有限公司 | 一种新能源整车异构网络仿真器及控制方法 |
CN105204896A (zh) * | 2015-09-08 | 2015-12-30 | 江苏绿扬电子仪器集团有限公司 | 一种数字存储示波器的BootLoader设计方法 |
CN108228198A (zh) * | 2016-12-22 | 2018-06-29 | 比亚迪股份有限公司 | 烧写方法及装置 |
CN108228198B (zh) * | 2016-12-22 | 2021-01-01 | 比亚迪股份有限公司 | 烧写方法及装置 |
CN108664256A (zh) * | 2017-03-28 | 2018-10-16 | 宁德时代新能源科技股份有限公司 | 系统的固件更新方法、装置和电池管理系统 |
CN107678792A (zh) * | 2017-09-06 | 2018-02-09 | 中国航空工业集团公司西安飞行自动控制研究所 | 一种基于can总线的多余度目标机在线加载方法 |
CN108427569A (zh) * | 2018-06-07 | 2018-08-21 | 合肥美菱股份有限公司 | 一种家用电冰箱在线升级控制程序的方法 |
CN112015456A (zh) * | 2019-05-31 | 2020-12-01 | 河南森源电动汽车有限公司 | 一种BootLoader程序更新方法 |
CN111814139A (zh) * | 2020-07-02 | 2020-10-23 | 深圳市法拉第电驱动有限公司 | 汽车电机控制器程序安全加载系统及方法 |
CN112859809A (zh) * | 2021-01-11 | 2021-05-28 | 上海星融汽车科技有限公司 | 车辆ecu刷写方法、系统及车辆诊断设备的下位机 |
CN113342385A (zh) * | 2021-04-29 | 2021-09-03 | 博格思众(常州)空调系统有限公司 | 软件升级方法及装置、空调控制面板 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104765632A (zh) | 一种BootLoader的管理方法 | |
EP1360592B1 (en) | Configurable measuring apparatus | |
CN103748569B (zh) | Usb设备的无驱动操作的系统和方法 | |
CN101615128B (zh) | 一种单片机在线升级的方法及装置 | |
CN101989212A (zh) | 提供用于启动刀片服务器的虚拟机管理程序的方法和装置 | |
CN104149717A (zh) | 一种用于整车控制的远程无干扰更新系统和方法 | |
CN103092642B (zh) | 用于更新电能计量装置的固件的设备、系统和方法 | |
KR20100063474A (ko) | Fota 서비스 제공 방법 및 그 시스템 | |
WO2017035236A1 (en) | Programming and debugging electronic devices using a near field communications device | |
CN112333278A (zh) | 智能设备升级方法、系统及智能设备 | |
CN101344853A (zh) | 用于空中编程的系统和方法 | |
CN116243996A (zh) | 业务的运行切换方法、装置、存储介质及电子装置 | |
CN113360175A (zh) | 车辆控制器的应用更新方法及车辆控制器 | |
CN113535202B (zh) | 充电桩的升级方法、升级装置以及充电桩系统 | |
CN116755749A (zh) | 板载mcu的升级方法、板载mcu、板卡及信息处理系统 | |
CN110377303A (zh) | 基于备用存储区方式升级程序的方法及其设备 | |
CN115878144A (zh) | 一种终端设备程序升级系统及方法 | |
CN211427090U (zh) | 微控制单元设备 | |
CN113220324B (zh) | 一种cpld远程更新的方法、系统及介质 | |
CN116225541A (zh) | 一种带内cpu与带外管理bmc通信的方法及通信系统 | |
EP4361798A1 (en) | Method for updating electronic control unit (ecu), ecu, and terminal | |
CN112596764B (zh) | 一种基于NB-IoT远程升级的物联网监测方法和装置 | |
CN114327536A (zh) | 一种服务器运维方法、装置、设备及存储介质 | |
CN115102855A (zh) | 智能水表嵌入式软件在线升级方法及系统 | |
CN110851160A (zh) | 一种嵌入式装置及其程序升级方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
EXSB | Decision made by sipo to initiate substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20150708 |
|
RJ01 | Rejection of invention patent application after publication |