2.12 控制DTC设置(0x85)——暂停症状记录

刷写固件时为什么DTC会“假发病”

你马上要给ECU刷入新固件了。你已经进了编程会话(0x10 0x02)、关了通信(0x28 0x01 0x03)、解锁了高级安全(0x27)——一切就绪。

但刷写期间，Flash被逐块擦除和重写。这个过程中ECU的电源管理进入特殊模式——CPU全速运行、所有低功耗外设关闭、电压调节器高频工作——传感器读取可能出现瞬时异常。你的进气温度传感器可能在刷写期间读回了一个超低值——因为它所在的模拟前端在Flash编程时被瞬间干扰了一下。

ECU的DEM监控周期如果仍然运行，就会捕捉到这个“读数异常“——然后写入一个P0113（进气温度传感器电路高电压）。等刷写完毕——仪表盘亮了黄色的Check Engine灯。

但这不是真实故障。它只是刷写过程中的电气噪声。你什么都没做错——刷写固件本身在你的车间里是正常的操作——却污染了ECU的DTC记录。

不过，很多ECU在进入编程会话后会自动停用DEM监控——应用层代码停止运行，传感器诊断也随之暂停。这种情况下DTC不会误报，0x85也不是必需的。但对于那些DEM仍在运行的ECU（例如某些硬件级诊断监控器独立于应用层运行），或者OEM的刷写规范明确要求的情况下——0x85就是一道必要防护。

设计追问：为什么不自动暂停

如果你看过Arctic Core的0x10会话控制实现——切换会话时会自动调用DspResetDiagnosticActivityOnSessionChange——它关闭IO控制、周期DID、事件响应、通信控制通道。为什么不自动停DTC？

答案是：因为切换到编程会话不总意味着马上刷写。OTA的场景里——ECU可能先进入编程会话、等待安全密钥验证（0x27）、等待远程服务器的下载授权签收——这会经过几秒甚至几十秒——而这期间如果发动机仍怠速运行（比如某些ECU允许在编程会话下怠速、但不能在行驶中刷写）——DTC的检测仍在生效是必要的（因为怠速期间的故障可能是真实故障）。

0x85的存在就是为了让这个时间窗可以精确控制——诊断仪自己在准备开始刷写的前一刻发0x85暂停DTC，在刷写完成后立即恢复。DSL/DSP不做预设假设。

核心洞察：0x85的设计哲学是：不要把时机强加于协议——让诊断仪决定该在什么时候暂停。这避免了“一刀切自动暂停“带来的漏检真实故障的风险。

两种子功能——关与开

请求只有两个字节：0x85 0x01 或 0x85 0x02。SubFunction的bit6-0为子功能码，bit7仍为suppressPosRsp标志位。

正响应同样简短：0xC5 0x01 或 0xC5 0x02——SID+0x40回声子功能。

当DTC记录被off之后——ECU内部的DEM监控周期继续运行（传感器读数被正常采集、诊断算法正常执行、故障条件正常评估）——但检测结果的DTC状态位不更新。可以说——DEM仍在“看“但不再“记“。

状态的自动恢复——让你无法忘掉恢复

off状态不是永久的。它会在以下条件下自动回到on：

1. 手动恢复：诊断仪发0x85 0x01——最明确的恢复方式
2. 会话切换：从编程会话切到默认或扩展会话时自动恢复——这是AUTOSAR DCM的默认行为
3. ECU Reset：hardReset/keyOffOnReset/softReset后默认恢复——因为电源循环后所有寄存器重启

不存在“永久off“——因为如果存在永久off，某次刷写后忘了手动恢复，接着车主的驾驶循环再也没有DTC记录——排放监控失效——法律风险极大。自动恢复是闭环安全机制——保证最坏情况最多只是一个驾驶循环后恢复正常。

一次完整的刷写全流程

诊断仪 → ECU:  0x10 0x02                   // 进入编程会话
ECU → 诊断仪:   0x50 0x02 0x0032 0x00FA     // 确认编程会话, P2=50ms, P2*=2500ms

诊断仪 → ECU:  0x27 0x01                   // 解锁安全等级1
ECU → 诊断仪:   0x67 0x01 0xA3D45F12       // 返回种子
诊断仪 → ECU:  0x27 0x02 0xKEYDATA         // 发送密钥
ECU → 诊断仪:   0x67 0x02                   // 解锁成功

诊断仪 → ECU:  0x85 0x02                   // 暂停DTC记录 ← 关键步骤
ECU → 诊断仪:   0xC5 0x02                   // DTC记录已暂停

诊断仪 → ECU:  0x34 0x00 0x44 0x00040000...// 请求下载
ECU → 诊断仪:   0x74 0x20 0x00C8            // 允许, 最大块=200字节

诊断仪 → ECU:  0x36 0x01 [200字节固件]     // TransferData #1
ECU → 诊断仪:   0x76 0x01                   // 确认块1

诊断仪 → ECU:  0x36 0x02 [200字节]         // TransferData #2
... (循环所有块直到传输完成) ...

诊断仪 → ECU:  0x37                        // 传输终止
ECU → 诊断仪:   0x77                        // 传输完成, 固件校验OK

诊断仪 → ECU:  0x85 0x01                   // 恢复DTC记录 ← 立即恢复
ECU → 诊断仪:   0xC5 0x01                   // DTC记录恢复

诊断仪 → ECU:  0x11 0x01                   // ECU硬复位
ECU → 诊断仪:   0x51 0x01                   // 确认即将复位 → ECU复位

注意——0x85 0x02必须在0x34下载请求之前发，0x85 0x01在0x37传输终止之后、0x11复位之前发。这个顺序保证了整个刷写窗口期间的DTC记录被屏蔽——从第一个下载块到最后一个块完毕。

核心洞察：0x85是UDS中最短的“保护性“服务——它只有两个字节。对于DEM在编程会话中仍在运行的ECU，它是刷写流程的必要防护——防止电气噪声污染DTC记录。对于DEM已自动停止的ECU，它是一道可选的冗余保险。多数OEM的刷写规范要求显式执行0x85，不是技术必要，而是流程上的统一约定。

和0x14 清除DTC的辨析——两个维度的正交

它们不重叠——它们是诊断时间线上的两个独立的阶段：清过去的记录（修好之后），暂停未来的记录（刷写过程中）。

本篇小结

1. 0x85是DTC记录的开关——on恢复记录(0x01)、off暂停记录(0x02)。
2. 刷写期间是否需要暂停DTC记录取决于ECU实现——如果编程会话中DEM自动停止则不需要0x85；如果DEM仍在运行，0x85可防止Flash编程的电气噪声产生虚假DTC。
3. off状态是临时的——会话切换、ECU复位、手动恢复三种方式都会使状态回到on——这是“永远不能忘掉恢复“的安全设计。
4. 0x85和0x14是正交的两个服务——一个暂停新纪录、一个清除已存在的记录——它们共同构成了DTC全生命周期的管理闭环。
5. 刷写序列中0x85的位置有严格顺序——在0x34之前发、0x37之后恢复——这是刷写脚本经验中的固定规则。

【下集预告】：症状控制住了——现在该开始治疗了。不是简单的改一个参数、贴一个值——而是一系列程序化的诊断操作：ABS泵自检、ADAS摄像头重新标定、电池组电芯平衡。这些多步骤、跨多秒的操作需要一个新的SID来调度——0x31 RoutineControl。