第1章 UDS刷写概述

1、UDS刷写概述：什么是UDS刷写、刷写流程总览、刷写中的关键服务

大家好，我是你们的讲师。今天咱们正式开始聊UDS刷写。说实话，这个主题我讲了不下几十遍了，但每次讲都觉得有新东西可以挖。你想想看，一辆车从产线下来，到4S店做保养，再到远程升级，背后都离不开UDS刷写这套机制。

那什么是UDS刷写呢？说白了，就是通过UDS协议，把新的软件或数据写到ECU的存储器里。我习惯把它比作「给ECU做换脑手术」——旧的程序取出来，新的装进去，还得保证手术过程中不能出任何差错。

核心定义：UDS刷写是指基于ISO 14229标准，利用诊断服务实现对ECU非易失性存储器（如Flash）的编程操作。它不仅仅是写数据，更是一套完整的状态机管理流程。

嗯，这里要注意，刷写不是一上来就写数据的。它有一套严格的流程，我把它分成三个阶段：

我在项目中遇到过好几次，有人跳过预编程直接写数据，结果ECU直接变砖。你想想看，刷写过程中如果CAN总线突然被其他报文干扰，那后果不堪设想。所以流程一个都不能少。

刷写过程中会用到多个UDS服务，我挑最重要的7个来讲。这些服务就像工具箱里的扳手、螺丝刀，各有各的用途。

我的小技巧：实际项目中，0x10和0x27往往是连着用的。先切会话，再解锁，顺序不能乱。我曾经见过有人先发0x27再发0x10，结果ECU直接返回NRC 0x7F——服务不支持。嗯，顺序真的很重要。

刷写的第一步，就是把ECU从默认会话切换到编程会话。为什么？因为默认会话下很多刷写相关的服务是被禁用的。我习惯用0x10 0x02来请求编程会话，ECU会回复一串支持的扩展会话列表。

说白了就是「对暗号」。ECU会给你一个种子（Seed），你算出一个密钥（Key）发回去。算法通常是自定义的，每家OEM都不一样。我在做项目时遇到过一种情况：种子每次都不一样，但密钥算法里有个固定偏移量，找出来就通了。

这个服务用来写一些刷写前的配置参数。比如刷写指纹、硬件版本号等。我个人习惯在刷写前先写一个「刷写开始标记」，万一刷到一半断电了，下次上电时ECU能知道上次刷写没完成。

例程控制是个大杀器。刷写中主要用它来做两件事：擦除Flash和校验完整性。比如0x31 0x01 0xFF00表示启动擦除例程。你想想看，擦除操作是不可逆的，所以一定要确保条件都满足了再发。

警告：0x31擦除例程一旦启动，ECU可能会有一段时间不响应任何请求。我曾经遇到过擦除大块Flash时，ECU卡了将近5秒才回复。这时候千万别急着重发请求，否则可能把ECU搞死。建议在工具端设置合理的超时时间，比如10秒。

这三个服务是刷写的核心。流程是这样的：

这里有个坑：0x36的块大小不是随便定的。我建议根据CAN帧的有效载荷来算，标准CAN是8字节，CAN FD是64字节。块大小最好是这个值的整数倍，否则ECU处理起来会多很多边界判断。

刷写完成后，发一个0x11 0x01让ECU硬复位。新程序就跑起来了。嗯，这里要注意，复位后ECU会回到默认会话，如果你还想继续诊断，得重新发0x10切会话。

总结一下：UDS刷写不是简单的「写数据」，而是一套严谨的状态机管理。从会话切换、安全解锁，到擦除、写入、校验，再到复位，每一步都有对应的服务。我做了这么多年，最大的体会就是：流程规范比技术本身更重要。严格按照规范来，刷写出错的概率会大大降低。

好了，这一章就讲到这里。下一章我们会深入聊0x10诊断会话控制的具体实现细节，包括会话切换的时序要求和常见错误码处理。到时候见。