基于canoe 新建一个lin工程_基于CANoe的BootLoader上位机

基于CANoe的BootLoader上位机

2019年国庆，闲来无事，写下大致流程。。。

汽车ECU的基于UDS的刷写流程大致相同，基本如下：

扩展会话10 03—28 03 03禁止收发APP报文及NM报文—85 02停止记录DTC—编程会话—安全访问—写入刷件日期—写入诊断仪序列号—请求下载—开始下载—下载完成—检查内存0202—擦除内存FF00—请求APP下载—开始下载—下载完成—检查内存—程序依赖性检查FF01—复位—打开APP及NM收发—DTC使能—进入默认会话—清除DTC

上位机的作用在于向ECU发送请求，ECU作为回应。

重点在于如何读取.S19，.HEX或.BIN文件，并在34服务中将其下载，协调发送与接收的数据包及发送时间，CANoe的Capl语言类似于C，首先设定文件的路径，将app及drive文件放在该路径下，打开文件函数为：OpenFileRead(文件名，读取方式)，并有返回值来体现文件是否打开成功。读取文件的函数为fileGetBinaryBlock(存放的数组名，文件大小，OpenFileRead返回值)，当读取完毕之后应计算CRC值，以便之后校验内存使用。文件的打开和读取就是这两个函数。

下来说一说数据包的发送和接收。

用HEXview可以打开.S19，.HEX或.BIN文件，其中.S19文件可以体现下载的起始地址及数据字节大小，但是.S19文件格式相比BIN文件较复杂，况且三种格式可以相互转化，一般选取.BIN文件来解析比较方便。

扩展会话10 03—28 03 03禁止收发APP报文及NM报文—85 02停止记录DTC—编程会话—安全访问—写入刷件日期—写入诊断仪序列号

以上服务比较简单，安全访问的算法各不相同，2E服务要写入的内容也不尽相同，只需要写简单的函数，在主函数中调用即可。如：

Void session_control(byte session_mode)

{

gTxDataBuffer[0] = 0x10;

gTxDataBuffer[1] = session_mode;

CanTpSendData(ghandle, gTxDataBuffer,2);

}

上边的gHandle是在定义发送端的TP层参数时的返回值，

long ghandle;
ghandle = CanTpCreateConnection( 0); // Normal mode

这些相关的函数在帮助文档OSEK TP » Functions » Function Overview路径下，在Capl中使用需要调用OSEK TP.DLL数据库

34服务是下载的请求，34是SID，后面一个字节说明文件是否加密等等，再后面一个字节，高四位说明起始地址占得字节数，低四位说明字节大小占得字节数，后面字节分别对应起始地址和字节大小，如34 00 44 00 0E 00 00 00 00 0A 00 其中00 0E 00 00为起始地址占4字节，00 00 0A 00是数据字节大小。

34服务的响应 74，将会带回36服务每一包允许发送多少个字节，通过这个数据可以计算出36一共将发多少包数据，并可得出是否存在不完整的包及不完整的包有多少字节。

重点是36服务的处理，36是SID，后面一个字节代表第几包数据，CAPL中的函数

void CanTp_ReceptionInd(long connHandle, byte data[])

void CanTp_ReceptionInd( long connHandle, byte data[])
{
write( "Received %d byte on connection %d: [%02x] ..."
, elcount( data), connHandle, data[0]);
}

存放接收到的数据，也就是ECU发出来的数据，在这个函数下可处理譬如ECU返回的种子，36服务的正响应，等等。当36服务每发送一包数据，ECU返回76 0x?，所以在这个函数下可以嵌套发送其余的数据。

在发送时每包数据时，可加一帧诊断仪在线以保持会话。

发送完毕之后发送37请求

检查内存时将计算得出的CRC添加到31 02 02的para中即可，期待获得正响应，则下载完整。

36的下载过程中，需要添加一定的延时testwaitfortimeout();

代码是在CANoe的test module中实现的，除CAPL的内置函数之外所有的自建函数均在MainTest()中调用，根据需要可制作面板来丰富功能，在此不做赘述。