4、通信控制（0x28服务）：通信模式控制、应用报文与诊断报文的隔离、刷写时的通信管理
各位工程师朋友，咱们接着聊刷写流程。前面几章我们把诊断会话、安全访问都捋了一遍，今天要聊的这个0x28服务——通信控制，说实话，在刷写场景里它是个「隐形功臣」。很多人刷写失败，回头查日志，发现不是数据传错了，而是通信模式没管好。
0x28服务，说白了就是ECU的通信开关。它能控制ECU要不要发报文，要不要收报文，收哪种报文。在刷写这种敏感操作里，这个服务至关重要。
4.1 通信控制到底在控制什么？
先看它的核心能力。0x28服务可以控制三类通信：
- 应用报文：比如CAN总线上的车速、转速、温度这些周期性报文
- 诊断报文：就是我们正在用的UDS请求/响应
- 网络管理报文：比如CAN的NM报文，用于网络休眠唤醒
控制方式有三种：
- 使能：允许发送/接收
- 禁用：禁止发送/接收
- 不改变：保持当前状态
嗯，这里要注意，0x28服务不是简单地「关掉所有通信」，而是精细到每个通信类型。我个人习惯把它的控制模式整理成一张表：
| 子功能 | 含义 | 刷写时常用场景 |
|---|---|---|
| 0x00 | 启用Rx和Tx（恢复通信） | 刷写完成后恢复 |
| 0x01 | 禁用Rx和Tx（完全静默） | 极少用，太粗暴 |
| 0x02 | 启用Rx，禁用Tx | ECU只收不发，防止干扰总线 |
| 0x03 | 禁用Rx，启用Tx | ECU只发不收，用于某些测试 |
| 0x04 | 启用诊断报文和网络管理报文，禁用应用报文 | 刷写核心模式 |
重点来了：刷写时最常用的子功能是0x04。它只禁用应用报文，保留诊断报文和网络管理报文。这样ECU还能正常响应我们的刷写请求，但不会往总线上乱发车速、转速这些无关数据。
4.2 应用报文与诊断报文的隔离
为什么刷写时要隔离应用报文？我举个例子你就明白了。
有一次我在实验室刷写一个网关ECU，刷到一半，突然总线负载率飙升到90%。查了半天，原来是ECU一边在刷写，一边还在发CAN报文。刷写数据包和正常报文在总线上打架，结果刷写超时失败。
你想想看，刷写时ECU的Flash正在被擦写，CPU资源本来就紧张。如果还要处理应用报文的发送和接收，很容易出问题。更严重的是，如果应用报文里包含安全相关的数据（比如刹车信号），刷写过程中万一发了错误数据，后果不堪设想。
所以，刷写前必须做两件事：
- 发送0x28服务，子功能0x04，禁用应用报文
- 确认ECU回复了肯定响应，再开始刷写
刷写完成后，再发送0x28服务，子功能0x00，恢复所有通信。
我的经验：有些ECU在刷写完成后，应用报文不会自动恢复。你必须在刷写流程的最后一步手动发送0x28 0x00。我曾经遇到过一台ECU，刷完后忘了恢复通信，结果整车下电后，ECU一直处于静默状态，客户以为ECU坏了。其实只是通信没打开。
4.3 刷写时的通信管理流程
好了，我们来看一个完整的刷写通信管理流程。我把它分成三个阶段：
阶段一：刷写前——隔离
// 伪代码示例
1. 进入扩展会话 (0x10 0x03)
2. 安全访问解锁 (0x27)
3. 发送 0x28 0x04 // 禁用应用报文，保留诊断报文
4. 检查响应：肯定响应 (0x68 0x04)
5. 开始刷写... 这里有个细节：发送0x28服务后，ECU应该立即停止发送应用报文。但有些ECU实现得不好，会有延迟。我建议你在发送0x28后，等100ms再开始刷写，给ECU一点处理时间。
阶段二：刷写中——保持
刷写过程中，ECU只响应诊断请求。这时候要注意：
- 不要发送非诊断报文
- 如果刷写时间很长（比如几分钟），可以定期发送TesterPresent（0x3E服务）保持会话
- 有些ECU在刷写期间会自动忽略应用报文，但为了保险，还是建议显式控制
阶段三：刷写后——恢复
// 伪代码示例
1. 刷写完成，校验通过
2. 发送 0x28 0x00 // 启用所有通信
3. 检查响应：肯定响应 (0x68 0x00)
4. 发送 0x11 0x01 // 硬件复位，让ECU重新初始化
5. 等待ECU重启完成警告：千万不要在刷写过程中断电或断开CAN总线。如果0x28服务发送后ECU进入了静默模式，但刷写还没完成就断开了连接，ECU可能一直处于「只收不发」的状态。这时候你连诊断仪都连不上它，只能通过硬线复位或者断电重启。
4.4 避坑指南
做刷写这么多年，我在0x28服务上踩过的坑不少。分享几个典型的：
- 坑一：忘记恢复通信。我曾经有一次刷完ECU，直接发了复位指令，忘了先恢复通信。结果ECU复位后，应用报文一直没恢复。后来查代码才发现，0x28服务设置的状态在复位后不会自动清除，需要显式恢复。
- 坑二：子功能用错。有同事用了0x01（完全禁用Rx和Tx），结果ECU连诊断请求都不响应了。刷写工具直接超时，还以为ECU坏了。其实只是通信被完全关闭了。
- 坑三：时序问题。有些ECU对0x28服务的响应时间有要求。比如必须在收到请求后10ms内停止发送应用报文。如果ECU实现得慢，总线上的其他节点可能会收到错误数据。
嗯，最后总结一句：0x28服务看似简单，但它是刷写流程的「交通警察」。管好了，刷写顺顺利利；管不好，各种奇怪问题都来了。我个人建议，在刷写工具的测试用例里，一定要把0x28服务的正反测试都覆盖到，特别是边界情况。
下一章我们聊0x31服务——例程控制，这是刷写中用来执行擦除、校验等操作的关键服务。到时候见。