简称: “ControlDTCSetting”,控制诊断故障代码设置
功能: 该服务用于停止或重启ECU诊断故障代码状态位的更新
控制类型的定义如下表:
01: 当ECU接受到子功能参数为开的控制诊断故障代码设置请求时,ECU应暂停诊断故障代码状态位的任何更新(即冻结当前数值),直到功能被重新使能。
02 :当ECU接收到子功能参数为关的控制诊断故障代码服务请求, 或进入不支持控制诊断故障代码设置服务的会话(如:会话层时序参数超时进入默认会话、电控单元复位等),诊断故障代码状态位信息应重新开始更新。
注: 如果接收到测试工具发送的清除诊断信息( $14)服务, 0x85服务应不妨碍ECU诊断故障代码状态位的重置。
那么问题来了,该服务用在何处呢?
解答:和0x28通信控制服务很相似,主要用于FBL刷新ECU程序时候用到,FBL(Flash Bootload)主要是诊断仪与ECU节点之间通过CAN总线将需要更新的程序刷写进芯片之中。为了避免在刷新程序时由于CAN总线拥堵导致无法完成刷新任务的情况,我们会在刷新程序之前先调用0x28通信控制服务关闭该ECU节点的收发报文功能和0x85服务禁止DTC更新记录功能,这样针对该刷新任务就独占了ECU节点的CAN总线
~ ~ 我的总线我做主!无敌的我又迷路了。
DTCSettingType :01 开启 02 关闭
请求报文: 85 01
请求报文: 85 02
解析报文log:
10 03 : 进入Extend会话模式
50 03 00 32 01 F4: 成功切换会话(00 32 01 F4 不必纠结,是两个诊断时间参数)
85 02: 请求停止DTC设置功能
C5 02: 完成停止DTC设置功能
14 FF FF FF FF: 请求清除DTC数据
54: 完成清除DTC数据(注:如果接收到测试工具发送的清除诊断信息服务, 0x85服务不妨碍ECU诊断故障代码状态位的重置。)
19 02 09: 读取满足DTC状态掩码09的DTC故障码
59 02 09: 正响应且无当前正在发生的故障
11 01: 请求ECU复位
51 01: 完成ECU复位
此时,我们制造写满足掩码09的故障码。
19 02 09: 读取满足DTC状态掩码09的DTC故障码
59 02 09 92 00 1C 09 92 01 1C 09…: 满足条件的DTC有 0x92001C和0x92011C(ECU复位时,诊断故障代码状态位信息应重新更新)
1)正响应
参见CANoe图中的框
2)否定响应
支持的否定响应如下,一般工作上根据整车厂给的诊断输入文档来选择要支持的NRC码。
博主平日项目中支持NRC如下:
NRC12: Sub-Function不支持(请求数据 85 FF。而你请求的子功能FF根本找不到啊,规范里也没有FF子服务,ECU收到你这条报文,无法识别subfunc,因此回复该NRC)
NRC13: 请求报文数据长度有误(正确请求数据85 01 有2个字节。而你请求的是85 01 00有3个字节,ECU收到你这条报文,无法理解,因此回复该NRC)
NRC22: 请求条件不满足
(一般整车厂会告诉你NRC22的满足条件,例如:车速>3km/h,电源过欠压时候,请求服务,ECU便回复该NRC)
NRC7F: 当前诊断会话下不支持该服务(正常情况下,0x85服务支持的会话有 编程会话和外部扩展会话)
0x85服务在实际运用中主要体现在ECU更新刷写程序时候才会使用到!
下一章 0x3E握手服务见!