CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)

  • 前言
  • Panel界面
  • 控件使用
  • 文件解析
  • 下载流程

————————————————

前言

请输入公众号:总线网络。关注我,获取汽车网络开发及测试方面资料,更新干货!
应朋友问题:之前已看过CANOE用报告形式设计bootloader自动化测试(地址https://blog.csdn.net/qq_36407982/article/details/107610153)。那我要是没CANOE岂不是刷不了,那能否用CANalyzer及CANOE创建Network Node的方法来设计bootloader?两者有什么不同?
我:不同之处太多了,前者可列详细步骤函数,有延时函数,可以出报告;后者没有。相信很多朋友做这个都觉得比较难,难的不是正常刷写,而是各种逆向刷写很麻烦,话不多说,且看下文。

Panel界面

CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)_第1张图片
FBL panel界面图示

控件使用

如上图所示,我们放置CheckBox控件来选择项目,打印出id值及版本号读取(可重新输入);放置两个 Path Dialog 来获取Driver和App路径,此路径是存在于盘下的任何一个路径;再通过File Number确定文件个数(>=1),最后通过Button(start)开始刷写。至于CAPL Output View控件则是我们进行输出提示语,进度条是每个文件刷写的进度。由于个人习惯原因,所以绑定控件值全部弄的系统变量而没做环境变量。好了,话不多说,正文开始!

文件解析

第一步还是老操作,文件解析!
刷写文件常见的三种:S19/HEX/BIN,本文不对BIN文件做解析,没难点。
通过文件路径后缀名识别出是哪种文件类型,再将之用于代码判断。因为文件类型不同,解析方式不同。这里简单说明下文件类型。
在这里插入图片描述
文件类型判断

S19文件解析:

S1 10 2000 00 00 00 00 00 00 00 00 00 00 00 00 10 BF
如上数据:

  1. S1:文件地址字节数为1+1=2个,最常见还有S2、S3以此类推;
  2. 10:表示10后面的所有数据个数是0x10个字节,即为16个字节;
  3. 2000:文件地址0x2000
  4. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01:数据
  5. BF:checksum值 BF = 0XFF - (0X10 +0X20 + 00 …+0X10),注意,这个值最终结果只能是一个字节的数。
HEX文件解析:

:020000020FFBF2
:021000000001EC
如上数据:
6. ::HEX开头
7. 02:0x02个字节数据,即为2个数据
8. 0000:地址0x0000
9. 02:数据类型:(1)0x00:下载的数据
(2)0x01:读取文件结束标志
(3)0x02:扩展段地址记录,例上0xFFB<<4等于0xFFB0是为段文件初始地址再加上0x1000等于0x10FB0。(相当于左移4位再加上下一行的地址即为新的擦除地址值)
(4)0x03:开始段地址记录
(5)0x04:扩展线性地址记录,相当于把0xFFB<<16再加上初始地址0x1000
(6)0x05:开始线性地址 记录
10. F2:checksum值 F2 = 0X100 -(0X02+0X10+…+0XFB),注意,这个值最终结果只能是一个字节的数。
代码:
在这里插入图片描述
在这里插入图片描述
解析函数接口代码
在这里插入图片描述
通过解析函数fileGetStringSZ代码来对文件进行彻底的解析并存到driver或者app的buff中。最后在下载数据里直接导入此buff。

下载流程

由于没有测试步骤函数及延时函数,那么就需要我们自己做一个定时器来做延时,步骤也要在定时器里实现
CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)_第2张图片
这里设置了预编程、编程中、后编程步骤及已下载文件个数<文件个数,否,就stop()。

一. 预编程

在进行下载的时候,一般会有一个预编程,在进入编程模式之前会进行对DID读取,28和85服务使用。有些客户甚至会要求31服务预编程条件检测。
在这里插入图片描述

二. 编程模式

进入到编程模式后,一般会对DID进行写入,比如指纹,日期等,写入格式均有要求。
CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)_第3张图片
写入数据如图示

三. driver下载

对driver下载,一般是直接下载,34-36-37.下载完之后会进行31CRC校验或者在37进行CRC校验。
在这里插入图片描述
driver下载流程图

四.app下载

一般app下载会涉及到多文件/多段下载。
在这里插入图片描述
多段下载解析代码如图示
利用for循环将Tempi(段)和二位数组将数据存入buff中,就可以得出app的二维数组数据。
CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)_第4张图片
多段下载解析代码如图示
利用段落判断(g_TxData.paragraph_n <= g_AppData.paragraph)判断得出结论是否循环当前步骤。
利用(g_File.completed_number < g_File.number)判断得出结论是否循环当前步骤。
利用

if(g_File.pathchange_flag == FALSE)
{
STEP = paragraph_step_start;
}

来确定是否添加新的文件,这都需要判断。设置全局变量。
当第一次加载文件后并进行下载成功时,会自动判断此时下载成功文件个数是否等于填入的应该下载的文件个数值,利用if(文件个数>完成刷写文件个数?),通过暂停(g_File.pathchange_flag == FALSE)在panel界面加载剩下的文件(自动识别加载与否)来进行下一步的解析并反复走下载流程(擦除地址、请求下载、下载、停止下载、CRC校验、一致性检验)达到多文件下载的目的。
CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)_第5张图片
延时定时器图

五. 复位

当所有文件下载完成并完成一致性校验,会进行一次复位看是否能够回到APP状态中。

六. 逆向测试

逆向测试:对测试进行故障测试(获得想要的故障,例如返回期望NRC)。
这里介绍常见的逆向测试
在这里插入图片描述
逆向测试如图示

七. 补充说明

对于传输层输送数据时,一般是在on message下完成,但是有些硬件不支持即时传输,必须考虑传输数据的stmin时间及每一个请求数据的响应时间间隔,所以此法行不通。
我在定时器里传输数据,在通过定时器对每一帧数据都进行一个可编辑延时,达到真正灵活下载。
在这里插入图片描述
帧数据延时图

请输入公众号:总线网络。关注我,获取汽车网络开发及测试方面资料,更新干货!
分享总线开发知识
分享CAN/CANFDLIN/ETH等网络资料
分享CANoe/TSMaster/PCAN等设备工具使用
分享UDS/NM/Bootloader测试用例等
一起来学习,进步,交流吧!
CANalyzer及CANOE使用二:基于UDS的Panel界面及使用Capl编写BootLoader自动化刷写流程(多文件or多段下载)_第6张图片

你可能感兴趣的:(canalyzer,canoe脚本capl,bootloader,自动化,运维)