基于CANoe的ECUBootLoader上位机
基于CANoe的BootLoader上位机
session下载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()中调⽤，根据需要可制作⾯板来丰富功能，在此不做赘述。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。