基于基于CAN总线的总线的Bootloader设计与实现设计与实现
使用BDM工具下载或升级应用程序,不仅麻烦而且稳定性也不高。采用在线更新的方法,设计并实现了一种基
于CAN总线的Bootloader。介绍车载网络通信与诊断服务的实现、Bootloader的设计以及其在车载控制单元的实
现,并在此基础上,提出最小Bootloader的概念,可以有效提高程序的灵活性。实验结果证明,Bootloader能正
确引导加载程序的运行,准确方便地实现应用程序的下载和更新,在软件开发和测试过程中能够极大地提高工
作效率,而且Bootloader的稳定性也很高。还能将网络层和UDS诊断服务部分方便地移植到其他芯片上,为后
序的软件开发与测试提供了方便。
摘 摘 要要: 使用BDM工具下载或升级应用程序,不仅麻烦而且稳定性也不高。采用
关键词关键词:
0 引言引言
为了避免在更新程序的过程中拆除ECU,通过串行总线、SD卡或USB口以及相应的通信协议,将应用程序更新到单片机
中[1]。在更新过程中,系统不免受到外界干扰和软件故障等影响,因此可靠性成为Bootloader开发工作中首要考虑的因素。同
时,Bootloader也存在软件升级的问题,现行的方案并不完善。为此,本文提出最小Bootloader以保证程序的灵活性,为了应
对程序更新出错的意外状况,提出Stay-In-Boot的概念,增强程序的稳定性。
1 Bootloader部分部分
1.1 Bootloader原理原理
Bootloader的主要工作是初始化硬件设备、分配内存映射等,构建良好的软硬件程序,并决定升级应用程序还是继续运行
原有的应用程序[2]。如果升级应用程序,则擦除原有程序数据并通过CAN网络把更新的程序下载到Flash中,再拷贝到RAM中
运行;如果继续运行原有的应用程序,则把Flash中的应用程序数据拷贝到RAM里,程序跳转到地址0x4000(仅针对
S12G192而言)处运行。
1.2 S12G192单片机的内存空间单片机的内存空间
S12系列单片机支持两种寻址方式:局部地址寻址和全局地址寻址。只有在对Flash进行操作时才会有全局地址的概念,
对RAM和EEPROM进行操作时使用局部地址就可以了。
Bootloader应该放在受保护的Flash中,但不是所有Flash都可以设置保护,所以一般放置在0xc000~0xfeff区间内。
2 ISO15765协议协议[3]
按协议内容和体系结构实现来进行划分,ISO15765协议共分为4层,分别是应用层、网络层、数据链路层和物理层。应
用层诊断协议设计应遵循ISO14229-1或ISO15765-3,应用层规定了具体诊断服务的服务标识符(SID)及后面所携带的参数
格式与内容。应用层数据经过网络层实现数据的传输、打包、解包,数据传输时以单帧和多帧的方式按ISO15765-2进行传
输。数据经数据链路层时应按ISO 11898-1转化为有效的CAN数据帧,最后经物理层实现与另一节点的通信。被诊断电子控制
单元(Electronic Control Unit,ECU)收到请求报文后,再按协议体系结构进行逐层解析。
3 基于基于ISO15765的的Bootloader设计与实现设计与实现
单片机中的Bootloader程序必须设计得尽量小,因为ECU中有限的Flash容量是由应用程序和Bootloader程序共同占用
的。本文将Bootloader分为8大部分,如图1所示。下面详细介绍框图内各个组件的设计与实现。
3.1 CAN Driver的设计与实现的设计与实现
CAN驱动完成CAN的底层配置,包括CAN初始化,CAN的发送和接收函数。CAN初始化又分为关看门狗、屏蔽所有中
断、初始化PLL和时钟等[4]。
3.2 ISO15765协议的实现协议的实现
ISO15765协议的实现主要包括udsDiag.c、udsDiag.h、udsNWL.c和udsNWL.h 4个文件的配制。udsDiag.c和udsDiag.h
用于提供诊断服务[5],udsNWL.c和udsNWL.h用于提供网络传输服务。udsNWL.c中最重要的是从网络层发送和接收数据的
两个函数。udsDiag.c对每个服务进行响应。
评论4
最新资源