BootLoader协议说明及性能分析

BootLoader协议说明及性能分析

BootLoader协议说明
HEX格式文件说明
Hex文件是Intel公司提出的按地址排列的数据信息格式,数据宽度为字节,所有数据使用16进制数字表示，并且以ASCII码的形式，按行记录数据，下图为VCU当前工程代码的HEX文件局部截图：

如上图所示，HEX文件每一行均以“:”开头，表明记录的开始，“：”之后,每至少2个字符表示一组16进制数据，格式形如:BBAAAATTHHHH…HHHCC。
 BB – 16进制，表示此行数据长度字节数，表示HH的数目
 AAAA – 16进制，表示数据记录的起始地址，若此行是数据记录，则表示偏移地址，其它无意义。
 TT – 16进制，表示记录类型
00-代表本行是数据记录
01-代表HEX文件结束;
02-标识扩展段地址记录，表明后面所有数据地址+段地址左移4位
03-开始段地址记录：开始段地址记录
04-标识扩展线性地址记录，表明后面所有数据地址+线性地址左移16位，将该地址<<16 后作为基地址。并且表示在下一个04类型行出现之前都要使用该地址作为基地址.
05-开始线性地址记录：开始线性地址记录，开始线性地址记录其实就是main函数入口地址
 HH…HH – 16进制，低字节/高字节 结合数据，高字节在后；注意，若是偏移地址则都是2字节，高字节在前，低字节在后
 CC – 16进制，校验码，除冒号和自身以外的其他字节数据加起来模除256的余数的补码，如上图第一行，其校验码为01+~（02+00+00+04+01+00）= F9。具体计算过程为：（02+00+00+04+01+00）加和为0x07，模除256后，商0余0x07，0x07补码为0xF9。




BootLoader协议描述
本次调试所编写的BootLoader，交互命令共6个：

1. 进入BootLoader
2. 重启
3. 下载
4. 下载结束
5. 检查BootLoader程序
6. 擦除Flash
   每个命令使用CAN报文的第一字节作为标识，以上5个命令对应的命令CAN报文及下位机反馈报文如下表所示：
   
   下载流程分为：握手、擦除、下载、下载结束三部分。
   握手阶段：上位机需要依次发送EntryBootloader、Reset、CheckBootloader三个命令以保证当前下位机正在BootLoader程序中，三个命令都检查到反馈，则握手完成。 
   擦除阶段：上位机需要发送Erase命令擦除用户Flash空间，此过程大约需要2S左右，擦除完成后，下位机上传反馈报文，则擦除阶段完成。
   下载阶段：下载阶段的数据报文以数据包的形式发送，当前BootLoader设定为每256个数据字节为一个数据包。因为每帧CAN报文第一字节为数据标识符0x02，每帧有效数据仅7字节，因此，一个数据包共需37帧发送完成，且第37帧仅有4个有效数据字节。数据包结构设计为：1帧首帧+37帧数据帧+1帧尾校验帧。
7. 首帧：前5字节为固定内容：0x02 0xAA 0x55 0xFA 0xAF，剩余3字节为经过简化后的地址：真实数据地址- 0x800000，此处减去0x800000的原因是为了保证地址长度为24位，能使用首帧的剩余3字节发完。
8. 数据帧：前36帧的数据帧结构为0x02+7字节数据，第37帧最后的3字节加入了固定的校验内容（0xAA 0x55 0xA5），表明此帧为最后一个数据帧。
9. 尾帧：主要是用来校验数据包，前5字节为固定内容：0x02 0xAF 0XFA 0X55 0XAA，第6字节为校验和，其值为所有39帧数据字节加和后的值，取其低8位字节作为校验。
   若下位机检查到首帧标识正确，尾帧标识正确，数据包帧数为39，且校验和无误，则将调用Flash驱动将256字节烧录进Flash，并向上位机反馈0x92的下载反馈报文，上位机在接收到下载反馈报文后，可开始发送下一个256字节数据包。
   下载结束阶段：在完成所有数据包的传输后，上位机发送DataEnd命令结束BootLoader，并将收到命令反馈。
   BootLoader性能分析
   上一部分介绍了HEX文件的结构以及本阶段BootLoader的下载流程，下面将针对BootLoader的性能作简要分析。
   调试结果
   衡量Bootloader有效性的指标为下载速度，本阶段的BootLoader
   所要求的下载速率为4Min/MB，目前版本BootLoader实际速率为2.5Min/MB，调试过程中使用1.6MB的整车控制策略HEX文件进行下载试验，下载共耗时4分钟。
   下载速率上限分析
   依照当前的下载协议，以256字节为一个数据包进行烧录下载，速率虽然满足第一阶段要求，但最终下载速率的目标设置需要结合理论分析以及实际测试得到，首先对500K波特率下的总线速率的是否会是下载速率瓶颈作如下分析：
   500K波特率下，理论下载速度为500K bit/s,而CAN总线协议本身限制，每个标准帧最大将传输108bit数据，但仅有64bit为有效数据，此时，下载速率将有协议损耗，500K bit * 64/108 = 296296 bit/s，将单位从bit转换为KB得：296296 /8/1024 = 36KB/S。依据此速率进行计算，下载1MB数据需要1024KB / 36KB = 28s。与此同时，因为HEX文件大小并不代表真实得下载数据量，因其用ASCII码表示数据，因此，真实数据量大小约为HEX文件大小的三分之一，因此，28s/MB的真实下载速率若使用HEX文件大小作为参考，速度可进一步提升至10S/MB。
   以上的理论计算结果的前提为CAN总线为100%负载下，且为单向传输，无交互损耗的情况下得到。而真实下载情况总，CAN负载率达不到100%，下载协议导致CAN数据域的利用率减小，最主要的时间损耗则是在交互等待，这个等待时间无法避免，因为每个数据包的烧写需要时间，只有一个数据包烧录完成，下一个数据包才可继续发送。
   若以当前的下载速度反推交互损耗，有如下计算过程：
   本阶段下载协议的39帧共312字节中，其中有56字节为协议损耗，则协议的传输效率为0.82。1.6MB的HEX文件，经查，其真实数据量约为583KB，因为有协议损耗，传输等效数据量约为583KB/0.82=710KB，使用上文中的理论速度计算其下载时间，约为：710KB/36KB/S = 20s，真实下载耗时240s，可得：交互总耗时220s，下载710KB数据所需发送的数据包个数为：710*1024/256=2840个，则可算出，每个数据包的交互耗时为：220s/2840 = 77ms。
   由以上计算分析，要优化下载速度，可采用增大数据包大小，减小交互损耗的方法：若将数据包大小扩大到4倍（1024字节一个数据包），交互损耗减小为：55s，总下载时长约为20s+55s = 75s，HEX下载速率为1.28Min/MB;若将数据包大小扩大到16倍（4096字节一个数据包），下载时长将减小到：20s+14s=34s，HEX下载速率为21S/MB。
   以上内容仅为计算分析，真实效果待试验。
   可靠性分析
   由上文分析可知，扩大数据包大小将有效减少数据交互损耗时间，从而加快加载速度。但是，有效性的提升必将导致可靠性的下降，因此，下面将对当前BootLoader协议的可靠性进行分析。
   数据包加大带来的影响：
10. 数据包的加大将影响到首帧尾帧的误判概率，可能导致下载失败。
11. 数据包加大导致反馈时间变长，数据量增多将导致参数误码的可能性增大。
    尽管数据包的增大将增大以上错误产生的可能性，但由于下载协议本身为双层嵌套，物理层由CAN总线协议保证数据包总每一帧的正确性（出错可检查出来）：
     CAN本身使用差分信号传输，信号稳定
     CAN协议本身带有CRC校验，其检错率可达99.9%以上，此处参考论文：CRC编码与检错性能分析。
    私有协议中有对首帧的校验、尾帧的校验，数据包的Checksum校验、接收帧数校验。这其中任何一项出错，都将被识别，从而保证不会将错误的程序下载到VCU中。
    综上，CAN协议本身保证了数据包中每一帧的正确性，下载协议保证了数据包的正确性。最终，双层协议保证了BootLoader烧写的可靠性。以上内容的计算与验证复杂，此处虽然无法给出理论计算作为参考，但是CAN总线本身是经过汽车行业多年验证的可靠传输协议，再加上应用层的双重保障，由此，我们可以乐观的尝试将增大数据包作为提升下载速率的手段，并用到后一阶段的UDS下载当中。