网关控制器BootLoader系统设计

孙 瑞， 徐建国， 马 伟， 杨玉柱

(上海采埃孚转向系统有限公司, 上海 201821)

在某款车用网关控制器的开发过程中，为了方便实现网关控制器的实车调试和程序更新，需要设计出一种通过CAN总线即可刷写应用程序的软件.CAN(Controller Area Network)总线是一种主流的车用现场总线，具备标准化的通信格式，其信号传输的实时性、可靠性和准确性等优点使其获得汽车行业内的广泛认可.因此，CAN总线成为本文设计BootLoader系统的首选通信介质.在CAN总线协议与S19文件协议的基础上，本文又引入了一个自定义的通信协议，以实现BootLoader与上位机之间的命令和状态传递.该BootLoader系统简单、可靠，无需应用程序本身做任何适应性更改，因此同样适用于以XET256为平台的其他控制器开发项目.

1 BootLoader设计思路

Bootloader称为系统的引导加载程序，是系统加电或复位后执行的第一段代码[1]，其主要作用是实现应用程序的更新以及引导应用程序的执行.基于这一基本思路，在设计BootLoader时首先要考虑的问题是BootLoader与应用程序在Flash中应如何划分，以保证二者所占用的存储空间不能相互冲突.其次，控制器上电后，应该首先执行BootLoader，由BootLoader决定是进行程序的更新还是进入应用程序执行.然后，在控制器上电后，BootLoader开始执行时，应以操作员即上位机的指令为判断依据，来控制程序执行的方向.在应用程序刷写过程中，还应对上位机的命令及命令执行情况进行反馈，以使操作员明确应用程序是否成功更新.最后，BootLoader应能够根据规定好的协议，将通过CAN总线接收到的应用程序数据准确地写入.

2 Flash与RAM划分

2.1 PRM中P-Flash与RAM划分

设计BootLoader时需充分考虑对ECU存储器的分配[2]，在飞思卡尔编译器CodeWarrior中，程序和数据存储空间的划分工作是在prm文件中完成的.以关键字SEGMENTS和END为标志.Flash存储空间的关键字为READ_ONLY.

XET256中P-Flash地址范围为0x4000～0xFFFF[3].其中，0xFF0F～0xFFFF为中断向量区，0xFF00～0xFF0E为Flash配置区，主要用于P-Flash写保护等功能.剩下的地址范围0x4000～0xFEFF开放给用户，用于存储用户程序代码.受限于16位寻址能力，P-Flash被分为非分页区(unpagedFlash)和分页区(paged Flash).非分页区(0x4000～0x7FFF与0xC000～0xFFFF)可直接用16位地址寻址.而分页区(0x8000～0xBFFF)则必须用24位地址寻址.

为了给网关控制器应用程序提供更多的代码空间，以及便于实现BootLoader写保护等目的，将BootLoader程序安排在从0xFEFF开始往上数的一段区域，其大小可根据具体代码量调整，本文将其定义为3.75K，即地址范围为0xF000～0xFEFF.

在对P-Flash擦除与写入操作的时候，不允许同时对其进行读取，否则可能导致Flash的损坏[4].本着这一原则，对Flash的擦除、写入以及CAN中断信号的处理代码，应复制到RAM中运行.这一功能可通过关键字RELOCATE_TO实现.因此，在划分Flash的同时也应对RAM进行划分，以实现这一功能.定义RAM的关键字为READ_WRITE.P-Flash与RAM的实际划分如图1和图2所示.

图1 P-Flash划分图

图2 RAM划分图

2.2 全局地址表示方式

如前所述，非分页区Flash的地址唯一，可直接采用16位逻辑地址进行寻址.但0x8000～0xBFFF这一分页区共由14页组成，具体寻址到哪一页取决于PPAGE寄存器.其地址变为了8位页地址加16位具体地址，即24位地址.如PPAGE寄存器的默认值为0xFE，则逻辑地址0xFE_8000表示0xFE这一页的0x8000地址.

由于存在以上地址表示方式的不同(16位与24位)，在对Flash进行擦写时，如果直接采用逻辑地址，不仅关系复杂，而且容易出错.而采用全局地址，可使表示方式单一，容易寻址.所谓全局地址是由页寄存器PPAGE的值以及逻辑地址按一定关系组成的24位地址.这种表示方式使得Flash存储单元的地址线性且唯一，便于操作.逻辑地址转换为全局地址的关系式为

GA=0x400000|((((dword)(PA))<<14)|

(LA&0x3FFF))

(1)

式中，LA表示逻辑地址，PA表示PPAGE寄存器值，GA表示全局地址.当逻辑地址位于0x4000～0x7FFF时，PA的值为0xFD；当逻辑地址位于0xC000～0xFFFF时，PA的值为0xFF；当逻辑地址位于分页区时，PA的值取决于具体页，默认值为0xFE.

采用全局地址后，Flash在全局地址表示方式下的划分如图3所示.由于划分Flash时只需关注分界线，因此，在prm文件中，依然采用逻辑地址进行划分.从图3可以看出，XET256的256K Flash是由不连续的两个Block(0/1)组成的，每一个Block为128K.

图3 全局地址表示下的Flash划分

3 中断地址分配

飞思卡尔16位单片机在复位后总是从优先级最高的中断向量地址0xFFFE处取第一条执行指令[4].因此，BootLoader可执行代码的首地址应安排在此处，以保证上电后BootLoader的首先执行.这可以通过在prm文件中定义VECTOR 0来实现，即将VECTOR 0定义为BootLoader程序的入口地址.然而，网关应用程序在编写时也会对VECTOR 0进行定义，以实现在单片机上电后直接执行应用程序的目的.由于存在这一中断资源冲突，因此，BootLoader在刷写时需要对网关应用程序的中断向量表进行重新分配.

默认情况下，XET256的中断向量表位于0xFF0F～0xFFFF区间[3].这一特性是由中断向量基址寄存器IVBR在上电后总是默认为0xFF所确定的.一条可执行的中断向量地址是由基址(IVBR寄存器的值)加偏移组成的.如复位中断向量地址0xFFFE，即表示IVBR的值为0xFF，该中断向量的偏移为0xFE.在一款特定的单片机中，任一硬件中断向量相对于基址的偏移总是确定的.因此，通过改变IVBR寄存器的值，即可实现中断向量表的更改.本文设计的BootLoader在引导进入应用程序之前将应用程序中断向量表基址IVBR更改为0xEF，即经过BootLoader重新分配后，应用程序中断向量表位于0xEF0F～0xEFFF.在刷写应用程序时，若BootLoader检测到地址为0xFF0F～0xFFFF的代码数据，则将其地址更改为0xEF0F～0xEFFF，然后在新的地址上将数据写入.由于存在这一安排，应用程序非中断向量代码的存储不得位于0xEF0F以下，这也是本文设计的BootLoader对应用程序的唯一要求.

在对P-Flash进行擦除与写入的过程中，所使用的硬件资源CAN通道依然在进行正常工作，当其接收到有效数据后，即可使单片机自行进入中断处理服务.单片机将从所选CAN通道的中断服务地址处读取CAN中断服务代码的首地址.如前所述，P-Flash在擦除过程中不允许对其进行读取，因此，这种由CAN通道中断所导致的操作应加以避免.本设计采取的解决方案是BootLoader进入刷写程序后，在擦除与写入P-Flash之前将中断向量表更改至RAM中.本文将IVBR更改为0x3F，即在BootLoader执行刷写程序时，实际中断向量表为0x3F00～0x3FF0.

4 应用程序更新

4.1 通信协议

为实现BootLoader与上位机之间的命令和状态传输，本文在标准的CAN协议基础上，定义了一套简单的通信协议.该协议中所使用的命令和状态均以报文ID表示，即每一个ID代表一个特定的命令或状态.根据本文所涉及项目的相关要求，刷写过程中使用的报文ID不能与整车网络中其他节点用到的ID相同，因此本协议报文ID的选择范围为0x500～0x5FF.具体选择报文ID及协议见表1.

表1通信协议表

4.2 应用程序更新流程

在系统上电后，BootLoader将初始化堆栈、配置系统时钟，并初始化所选CAN通道.当CAN通道正常工作后，BootLoader将等待20ms，如果在这段时间内接收到上位机进入刷写程序的指令或检测到应用程序不存在，则执行应用程序更新操作；否则，跳转至应用程序执行.如直接跳转至应用程序执行，则应首先配置中断寄存器基址，然后，将单片机指针更改为应用程序复位向量地址，本文设计为0xEFFE.采用这一策略无需应用程序配合，但要求操作员如需更新应用程序，则应在系统上电前将上位机启动，以保证BootLoader能接收到相应指令.BootLoader工作流程如图4所示.

图4 BootLoader工作流程图

若执行应用程序更新操作，首先应配置P-Flash时钟，使其工作频率为用户手册推荐的0.8～1.05MHz[3]，这可以通过设置FCLKDIV寄存器的值来实现.P-Flash的时钟源为外部晶振，本文所选的外部晶振频率为16MHz，查用户手册将FCLKDIV寄存器的值设置为0x0F.然后，将P-Flash中定义好的BootLoader擦/写/中断处理代码拷贝至RAM中划分好的区间0x3D00～0x3EFF处.接着，将中断向量表配置到RAM中.当所有BootLoader更新应用程序所需的环境都准备好后，就可以对P-Flash进行擦除与写入操作.应用程序更新操作流程图如图5所示.

图5 应用程序更新流程图

4.3 应用程序擦除

应用程序擦除代码存储在P-Flash中，在执行时拷贝到RAM中执行.XET256支持将P-Flash以Sector(每个Sector的大小为1K)和Block为单位进行擦除.对于Block1(0x78_0000～0x79_FFFF)可按Block为单位整体擦除.而对于Block0应只擦除属于应用程序的部分，即0x7E_0000～0x7F_EFFF的区间，此处应以Sector为单位进行擦除.擦除过程如图6所示，首先等待其它Flash命令执行完毕，然后清除Flash状态寄存器中的故障码，之后即可通过配置Flash控制寄存器FCCOB的值来选择擦除命令与擦除区域.

图6 应用程序擦除操作

Flash控制寄存器FCCOB由6个字组成，通过选择寄存器FCCOBIX可分别对6个字进行配置[3].其中，FCCOB第1个字的高8位代表具体Flash命令，如0x09表示执行按Block擦除命令；0x0A表示执行按Sector擦除命令；0x06表示写Flash命令.FCCOB第1个字的低8位代表全局地址的高8位.FCCOB第2个字表示全局地址的低16位.FCCOB的第3到第6个字则用于存放需要写入的数据，擦除操作时不需要，但执行写入操作时需要.Flash控制寄存器配置好后，即可通过将Flash状态寄存器的最高位写1来执行FCCOB中存储的命令和数据.之后，利用Flash状态寄存器来判断操作是否成功执行完毕.

4.4 应用程序写入

BootLoader成功将P-Flash擦除后，即向上位机发送成功擦除信号，通知上位机发送新的应用程序数据.上位机传输给BootLoader的数据格式采用S19文件协议，而且每一个地址或数据等信息均以字符的形式发送.

4.4.1 S19协议解析

S19文件是飞思卡尔推荐使用的标准程序下载文件，该文件格式由记录类型、记录长度、存储地址、代码数据和校验码5个部分组成[5].S19文件的每一行总是以“S”开始，其后的一位数字表示该行记录的类型.如S0表示该行记录为说明性信息，非程序数据；S1表示该行记录为程序数据且地址为16位地址，S2则表示该行记录为程序数据且地址为24位地址；S9表示该行为整个S19文件的结束行.由于本文在擦、写时采用全局地址，所以经式(1)转化后的S19文件只包括S0、S2和S9.记录类型之后的一个字节表示其后该行记录所包含的字节长度.紧接着的3个字节表示目标地址，之后是写入目标地址的数据.最后一个字节为该行记录的校验码，校验码加代表信息长度、目标地址、写入目标地址数据的所有字节的和为0xFF.

BootLoader通过CAN中断接收到ID为0x50F的S19数据帧后，会将数据依次存入指定缓存中，然后周期性地对缓存数据进行组织和解析.由于上位机发过来的数据全部为字符的形式，因此，首先应将字符转化为16进制数，然后整理成以字节为单位的有效数据.如在解析信息长度时，应连续读取两个字符，将其分别转化为16进制数后，第1个数左移4位加第2个数，这样即可整理为一个有效的字节数据.

在对S19文件进行解析时，首先判断接收到的第一个字节是否为'S'以及第二个字节是否为'0'、'2'或'9'，如果不符合则舍弃该条信息.若符合则开始对信息长度、地址、数据和校验码的解析，然后按照S19协议对校验码进行校验，如果校验结果为有效则将目标地址、写入目标地址的数据放到相应的缓存中.至此，一条S19信息被成功解析.

4.4.2 P-Flash数据写入

当一条有效的S19信息被接收并成功解析后，还应对该信息做进一步判断.如果接收的是S9或接收过程中有错误，则直接退出数据写入程序；如果是S0，则予以忽略；如果是S2，则按照解析出的目标地址，将程序数据写入.

在数据写入之前，应对目标地址进行判断.若目标地址位于中断向量区，则首先按第3节所述对其进行更改，然后再执行数据写入程序；若目标地址不位于中断向量区，但超出了第2节所规定的应用程序区域，则拒绝执行写入程序.

Codewarrior编译器生成的S19文件连续地址之差为32的整数倍，即每一条S19信息涵盖32个字节的P-Flash数据信息，即使转化成全局地址后，这一规则依然不变.FCCOB寄存器中有4个字，即8个字节用于存放程序数据.因此，每一条S19信息中的数据可以分4次写入，每一次的写入方法如4.3所述.

5 上位机设计

BootLoader系统中的上位机基于Labview开发，其基本工作原理是：首先读取S19文件，然后按行将S19文件中的十六进制数转换为相应的字符串数组，并补以行结束符.整合好的字符串数组会以8个字符为一组通过PEAK CAN工具转成CAN信号发送给网关控制器(最后一次不足8个的字符串发送实际字符长度).

由于本文设计的BootLoader系统无需应用程序做适应性更改，因此，上位机必须在跳转到应用程序之前启动.上位机启动后即向网关控制器发送握手指令，若后者没有反馈，上位机将连续10s发送该指令.这一策略要求操作员应在启动上位机后10s内将网关控制器上电或复位.若BootLoader接收到握手指令，并成功进行反馈，上位机将退出握手环节，并进入等待刷写环节.握手成功后，BootLoader将自行进入环境配置及擦除P-Flash过程，擦除成功后将向上位机发送擦除成功信号.上位机接收到该信号即退出等待，逐条发送S19文件.BootLoader接收并解析S19文件，写入成功后向上位机发送写入成功信号.若上位机在发送完最后一条S19信息后一段时间内没有接收到写入成功信号，则默认为本次程序更新失败.程序更新成功后，需操作员手动复位网关控制器，从而执行新的应用程序.整个操作过程及系统状态均会在上位机中实时显示.BootLoader系统上位机工作流程如图7所示.

图7 BootLoader系统上位机工作流程

6 结束语

本文设计的BootLoader系统几乎无需应用程序做任何适应性更改，因此可直接在其他以XET256为平台的产品上运行.试验证明，该系统操作方便、实现简单、运行可靠，能够正确地实现网关应用程序更新，从而大大方便了网关控制器的实车调试，加快了项目进度.

[1] 王伏，张忠能，杭勇.基于CAN总线的电控单元程序引导加载功能开发[J].微型电脑应用,2011，27(2):30-32.

[2] 奚英泽，于健楠，徐凤.基于飞思卡尔MPC5634M单片机的Bootloader设计[C]//中国汽车工程学会.2013中国汽车工程学会年会论文集.北京:中国学术期刊电子出版社,2013:566-569.

[3] Freescale.MC9S12XEP100RMV1(1.25)[M/OL].(2013-02)[2014-03-28]. http://www.freescale.com/files/microcontrollers/doc/data sheet/MC9S12XEP100RMV1.pdf.

[4] 罗峰，孙泽昌.汽车CAN总线系统原理、设计与应用[M].北京:电子工业出版社,2010.

[5] 张夕杰，李清政，王乔.MPC5534单片机在线程序更新系统研制[J].国外电子测量技术,2013(12):49-52.