简介这份资源面向汽车电子诊断开发初学者与嵌入式工程师提供基于UDS协议的ECU升级刷写上位机参考代码帮助读者理解诊断会话控制、安全访问、数据传输与错误处理等核心流程并借助CAN总线完成与ECU的通信交互。压缩包共49个文件约2.07MB以22张png截图、15篇md笔记、6个cpp源文件与4个头文件为主辅以少量jpg与txt涵盖环境搭建、交叉编译、SocketCAN、pthread与动态库等模块目录按Part1、Part2与DiagboxSRC分层组织便于按主题检索。目前已有5774人学习下载适合需要动手实践UDS刷写逻辑的开发者参考。读者可从中获取上位机框架、通信会话管理、文件传输与编程算法适配思路以及测试调试与排错方法为构建自有诊断刷写工具提供可复用的代码基础与学习路径。1. 从一次刷写失败说起这套 UDS 诊断 ECU 升级上位机代码到底能干什么去年帮一个做车载电子的朋友排查问题他们的产线刷写工具在写 Application 分区时偶发校验失败换了两台电脑、三根 CAN 线都没定位到原因。最后发现是上位机在 RequestDownload 之后没有严格按 blockSequenceCounter 递增发送 TransferDataECU 端超时后直接回了负响应。这件事让我意识到一套靠谱的 UDS 刷写上位机参考代码价值不在于界面多好看而在于它把 ISO 14229 里那些容易踩坑的时序、计数器、状态机都老老实实实现了一遍。这份 UDS 诊断 ECU 升级刷写上位机参考代码面向的就是需要自己搭一套刷写工具、或者想搞懂 UDS 刷写完整链路的开发者。它覆盖了从 10 03 进入扩展会话、27 安全访问、34/36/37 传输数据到 31 例程校验、11 复位这一整条刷写流程适合做 ECU 产线刷写、售后诊断工具、或者 Bootloader 联调的团队拿来当起点。如果你正在找一份能直接跑、又能改的 UDS 升级刷写参考实现这份代码值得先跑通再动手改。2. 技术选型与整体架构为什么是分层状态机而不是一把梭2.1 上位机侧的技术栈取舍拿到一份刷写上位机代码第一件事是看它怎么组织通信层和业务层。这份参考代码走的是典型的「CAN 驱动 ISO-TP 传输 UDS 服务 刷写流程」四层结构。底层用 CAN 适配器常见做法是 PCAN、Kvaser 或周立功的二次封装库中间用 ISO 15765-2 做多帧拆包上面才是 UDS 服务层和刷写状态机。为什么强调分层因为刷写过程中最怕的就是把「发一帧 CAN」和「发一条 UDS 请求」混在一起写。一旦混了超时重传、流控帧处理、连续帧序号这些逻辑就会散落在业务代码里改一个参数要动三四个文件。分层之后换一个 CAN 盒子只需要改驱动适配层UDS 服务层和刷写流程完全不用动。# 通信层抽象不同 CAN 适配器实现同一套接口 class CanDriverBase: def open(self, channel, bitrate): ... def send(self, can_id, data): ... def recv(self, timeout_ms): ... class IsoTpLayer: ISO 15765-2 传输层负责单帧/首帧/连续帧/流控帧 def __init__(self, driver, tx_id, rx_id): self.driver driver self.tx_id tx_id self.rx_id rx_id self.block_size 0 # 流控帧里的 BS self.st_min 0 # 流控帧里的 STmin def send_uds(self, payload: bytes): # 大于 7 字节走多帧首帧 连续帧 if len(payload) 7: self.driver.send(self.tx_id, bytes([len(payload)]) payload) else: self._send_multi_frame(payload)这段代码里block_size和st_min是从 ECU 回的流控帧里解析出来的不是写死的。很多自己写的刷写工具翻车就翻在这里——把 BS 固定成 0表示不再发流控帧结果 ECU 其实要求每发 N 帧就等一次流控发快了直接丢帧。参数说明tx_id是上位机发给 ECU 的功能/物理寻址 IDrx_id是 ECU 回给上位机的 ID刷写场景一般用物理寻址避免多个 ECU 同时响应。2.2 刷写流程的状态机设计刷写不是一条直线中间任何一步 NRC负响应都可能需要回退或重试。这份代码把整个刷写过程拆成了一个显式状态机每个状态对应一个 UDS 服务或一个等待条件。from enum import Enum, auto class FlashState(Enum): IDLE auto() SESSION_EXT auto() # 10 03 SECURITY_ACCESS auto() # 27 01 / 27 02 ROUTINE_PRE auto() # 31 01 FF00 预编程 DOWNLOAD auto() # 34 RequestDownload TRANSFER auto() # 36 TransferData TRANSFER_EXIT auto() # 37 RequestTransferExit CHECK_DEPENDENCY auto() # 31 01 FF01 依赖检查 ERASE auto() # 31 01 FF00 擦除 CHECK_MEMORY auto() # 31 01 0202 校验 RESET auto() # 11 01 class FlashStateMachine: def __init__(self, uds_client): self.uds uds_client self.state FlashState.IDLE self.block_seq 0 # blockSequenceCounter从 1 开始 def step(self): if self.state FlashState.SESSION_EXT: resp self.uds.send([0x10, 0x03]) if resp and resp[0] 0x50: self.state FlashState.SECURITY_ACCESS else: raise FlashError(进入扩展会话失败, resp) # ... 其余状态迁移状态机的核心价值在于每个状态只关心「发什么请求、期望什么响应、失败怎么处理」。block_seq是 TransferData 的块计数器从 1 开始每发一块加 1溢出后回绕到 0注意不是 1。这个细节在 ISO 14229 里有明确定义但手写代码时极容易写成从 0 开始或者溢出后回 1ECU 会直接回 0x73wrongBlockSequenceCounter。2.3 目录结构一览参考代码的目录组织大致如下方便你按模块定位目录/文件职责drivers/CAN 适配器封装PCAN、Kvaser、ZLG 各一个文件isotp/ISO 15765-2 传输层单帧/多帧/流控uds/UDS 服务封装10/11/14/19/27/28/31/34/36/37/3E/85flash/刷写状态机、S19/HEX 解析、分块策略config/ECU 描述文件含 CAN ID、安全算法 DLL 路径、Flash 驱动地址ui/上位机界面PyQt 或 WinForms视版本而定tests/针对 ISO-TP 和 UDS 层的单元测试这个结构的好处是你要换安全算法只动config/里指向的 DLL要换刷写文件格式只动flash/里的解析器要换 CAN 盒子只动drivers/。各层之间通过接口耦合不是通过具体实现耦合。3. 核心模块拆解从 10 03 到 11 01 的完整链路3.1 会话与安全访问27 服务的种子密钥逻辑刷写的第一步是进扩展会话10 03第二步是安全访问27 01 请求种子27 02 发送密钥。安全算法通常由 ECU 供应商以 DLL 形式提供上位机通过 ctypes 或 JNA 调用。import ctypes class SecurityAccess: def __init__(self, dll_path): self.dll ctypes.CDLL(dll_path) # 常见导出函数GenerateKey(seed, seed_len, key, key_len) self.dll.GenerateKey.argtypes [ ctypes.POINTER(ctypes.c_ubyte), ctypes.c_int, ctypes.POINTER(ctypes.c_ubyte), ctypes.POINTER(ctypes.c_int) ] def request_seed(self, uds): resp uds.send([0x27, 0x01]) if resp[0] ! 0x67: raise FlashError(请求种子失败, resp) return resp[2:] # 跳过 67 01 def send_key(self, uds, seed): key_buf (ctypes.c_ubyte * 16)() key_len ctypes.c_int(16) seed_buf (ctypes.c_ubyte * len(seed))(*seed) self.dll.GenerateKey(seed_buf, len(seed), key_buf, ctypes.byref(key_len)) key bytes(key_buf[:key_len.value]) resp uds.send([0x27, 0x02] list(key)) if resp[0] ! 0x67: raise FlashError(安全访问被拒, resp)这里有个血泪经验种子长度和密钥长度不一定相等有的 ECU 种子 4 字节、密钥 8 字节有的反过来。GenerateKey的签名里key_len是入参出参调用前要设成缓冲区大小调用后才是实际密钥长度。如果直接按种子长度去截密钥大概率会得到一个 NRC 0x35invalidKey。3.2 34/36/37 传输分块大小与超时怎么定RequestDownload34里要带上 memoryAddress 和 memorySizeECU 返回 maxNumberOfBlockLength这个值决定了你每块 TransferData 最多能带多少字节。def request_download(self, uds, address, size): # 34 服务dataFormatIdentifier addressAndLengthFormatIdentifier # 常见做法0x00 表示不压缩不加密0x44 表示 4 字节地址 4 字节长度 req [0x34, 0x00, 0x44] req list(address.to_bytes(4, big)) req list(size.to_bytes(4, big)) resp uds.send(req) if resp[0] ! 0x74: raise FlashError(RequestDownload 失败, resp) # 响应格式74 lengthFormatIdentifier maxNumberOfBlockLength max_len int.from_bytes(resp[2:], big) return max_len def transfer_data(self, uds, data, max_block_len): # max_block_len 包含 SID blockSequenceCounter所以实际数据要减 2 chunk_size max_block_len - 2 offset 0 self.block_seq 1 while offset len(data): chunk data[offset:offset chunk_size] req [0x36, self.block_seq] list(chunk) resp uds.send(req, timeout_ms2000) if resp[0] ! 0x76: raise FlashError(fTransferData 失败 seq{self.block_seq}, resp) self.block_seq (self.block_seq 1) 0xFF if self.block_seq 0: self.block_seq 1 # 回绕到 1不是 0 offset len(chunk)参数说明max_block_len是 ECU 告诉你的单块最大长度包含 SID 和 blockSequenceCounter 两个字节所以实际数据块要减 2。timeout_ms在擦除和写入 Flash 时通常要放大到 2000ms 以上因为 ECU 内部擦写一个扇区可能耗时几百毫秒。如果你用默认的 100ms 超时会看到大量超时重传最后刷写失败但不知道卡在哪。3.3 31 例程控制擦除、校验、依赖检查的顺序31 服务在刷写里承担了三个关键例程预编程FF00、擦除FF00 带不同参数、校验0202。顺序不能乱擦除必须在 RequestDownload 之前校验必须在 TransferExit 之后。def routine_control(self, uds, routine_id, sub_func, paramsNone): req [0x31, sub_func] list(routine_id.to_bytes(2, big)) if params: req list(params) resp uds.send(req, timeout_ms5000) # 擦除例程耗时长 if resp[0] ! 0x71: raise FlashError(f例程 {routine_id:#06x} 失败, resp) return resp[3:] # 跳过 71 sub_func routine_id # 典型调用顺序 routine_control(uds, 0xFF00, 0x01) # 预编程 routine_control(uds, 0xFF00, 0x01, [0x00]) # 擦除参数视 ECU 而定 # ... 34/36/37 ... routine_control(uds, 0xFF01, 0x01) # 依赖检查 routine_control(uds, 0x0202, 0x01) # 校验注意擦除例程的响应时间可能长达数秒timeout_ms要设够。有的 ECU 在擦除期间会周期性发 0x7F 31 01responsePending上位机需要正确处理这种「请稍等」的响应而不是当成失败。这份代码在 ISO-TP 层做了 0x7F 的透传UDS 层再判断是否继续等待。3.4 S19/HEX 文件解析与地址对齐刷写文件通常是 Motorola S-record 或 Intel HEX 格式。解析时要处理地址不连续、数据段之间有空洞的情况。def parse_s19(file_path): segments [] # [(address, data), ...] with open(file_path, r) as f: for line in f: line line.strip() if not line.startswith(S): continue rec_type line[1] if rec_type 3: # S34 字节地址 byte_count int(line[2:4], 16) address int(line[4:12], 16) data bytes.fromhex(line[12:12 (byte_count - 5) * 2]) segments.append((address, data)) # 合并连续段按地址排序 segments.sort(keylambda x: x[0]) return segments解析完之后要做地址对齐Flash 写入通常要求按页对齐比如 8 字节或 16 字节如果某段数据长度不是页大小的整数倍需要补齐 0xFF。补齐的字节在后续校验时会被 ECU 忽略还是参与计算取决于 ECU 的校验算法这一点要跟 ECU 供应商确认不能想当然。4. 跑起来环境搭建与第一次刷写4.1 依赖安装与 CAN 驱动配置参考代码的 Python 版本依赖通常在requirements.txt里核心是python-can、cantools可选用于 DBC 解析、pyserial如果走串口转 CAN。pip install python-can cantools pyserial # 如果用的是 PCAN还需要装 PCAN-Basic 驱动 # 如果用的是周立功装 ZLG 的 CAN 驱动和 Python 封装CAN 驱动配置是新手最容易卡住的地方。以 PCAN 为例python-can的配置里要指定interfacepcan、channelPCAN_USBBUS1、bitrate500000。如果can.Bus()初始化报错先确认驱动装没装、盒子插没插、通道号对不对。常见做法是先用厂商自带的工具发一帧确认硬件通路没问题再跑上位机代码。4.2 配置文件怎么填config/下的 ECU 描述文件一般包含这些字段字段说明示例tx_id上位机发送 ID0x7A0rx_idECU 响应 ID0x7A8bitrateCAN 波特率500000security_dll安全算法 DLL 路径./sec/seed_key.dllflash_driverFlash 驱动地址0x40000000app_startApplication 起始地址0x8000app_sizeApplication 大小0x3F000填错tx_id/rx_id的表现是发出去的请求没有任何响应或者收到的是别的 ECU 的响应。用 CAN 分析仪抓一下报文就能确认。app_start和app_size填错的话RequestDownload 可能成功但校验会失败因为写到了错误的地址。4.3 第一次刷写的完整命令序列跑通第一次刷写建议按下面的顺序手动发一遍确认每一步都有正确响应再让状态机自动跑。# 假设用 python-can 的 cansend 工具做手动验证 # 1. 进扩展会话 cansend can0 7A0#021003 # 期望7A8#06500300 32 01 F4 P250ms, P2*5000ms # 2. 请求种子 cansend can0 7A0#022701 # 期望7A8#066701 种子 # 3. 发密钥假设密钥是 11223344 cansend can0 7A0#06270211223344 # 期望7A8#026702 # 4. 预编程 cansend can0 7A0#043101FF00 # 期望7A8#067101FF00 可选参数每一步的响应都要看 SID 是不是请求 SID 0x40是的话说明肯定响应不是的话看 NRC 码。0x78 表示 responsePending继续等0x33 表示安全访问被拒0x31 表示请求超出范围0x72 表示编程失败。把这些 NRC 码整理成一张表贴在工位上排查效率会高很多。5. 避坑与排查刷写失败时先看这五个地方5.1 现象TransferData 发到一半 ECU 不再响应原因blockSequenceCounter 回绕逻辑写错或者流控帧的 BS/STmin 没按 ECU 要求处理。有的 ECU 要求每发 8 帧就等一次流控上位机如果一口气发完ECU 缓冲区溢出后直接丢帧。解决在 ISO-TP 层严格按流控帧的 BS 值控制发送节奏BS0 表示不再发流控帧BSN 表示每 N 帧等一次。STmin 是连续帧之间的最小间隔单位可能是毫秒或微秒要看流控帧里的编码。5.2 现象安全访问一直返回 0x35原因密钥算错了。要么是种子长度和密钥长度搞混要么是 DLL 调用时参数类型不对比如把 unsigned char* 传成了 char*要么是字节序问题。解决先用已知的种子-密钥对单独测 DLL确认 DLL 本身没问题。再检查上位机传给 DLL 的种子是不是完整的、有没有被截断。字节序方面有的算法要求种子按小端传入有的要求大端这个只能看 ECU 供应商的文档。5.3 现象擦除例程超时但 ECU 其实在擦原因擦除 Flash 扇区耗时可能超过默认的 P2 超时ECU 会先回 0x7F 31 01responsePending擦完再回 0x71。上位机如果没处理 0x7F会直接报超时。解决在 UDS 层判断响应字节如果是 0x7F 且 NRC 是 0x78就继续等待直到收到最终响应或达到 P2* 超时。P2* 通常比 P2 大很多比如 P250ms、P2*5000ms。5.4 现象校验例程返回失败但数据看着写进去了原因校验算法不匹配。ECU 可能用 CRC32、累加和、或者自定义算法。上位机如果按 CRC32 算ECU 按累加和算结果肯定对不上。解决找 ECU 供应商要校验算法的说明或者用已知正确的刷写文件反推算法。有的 ECU 在 Bootloader 里提供了读校验值的例程可以先读出来跟上位机算的对比。5.5 现象刷完复位后 ECU 不启动原因Application 的入口地址或中断向量表没配对或者刷写时漏掉了某个必须写入的配置区。解决确认刷写文件是否完整有没有漏掉 Bootloader 要求的配置段。复位后如果 ECU 不响应可能需要重新进 Bootloader 模式通常靠硬件引脚或特定的 CAN 报文触发再刷一遍。6. 二次开发把这套代码改成你自己的刷写工具拿到这份参考代码之后最常改的三个地方是安全算法、刷写文件格式、以及刷写流程的定制。安全算法方面如果你的 ECU 用的是标准算法比如某些通用 Bootloader 的固定算法可以直接在 Python 里实现不用调 DLL。如果是自定义算法保持 DLL 调用方式只换 DLL 路径就行。我一般会在config/里加一个security_type字段支持dll和builtin两种模式方便切换。刷写文件格式方面除了 S19 和 HEX有的项目用 bin 文件加地址偏移。这时候只需要在flash/下加一个parse_bin(file_path, base_address)函数返回同样的[(address, data)]结构上层状态机完全不用动。这就是分层的好处。刷写流程定制方面有的 ECU 要求在 RequestDownload 之前先写一个特定的配置字或者在校验之后读一下某个 DID 确认版本。这些都可以在状态机里插入新的状态或者在现有状态的前后加 hook。我习惯把每个状态的处理函数写成可注册的这样不同项目可以复用同一套状态机框架只替换差异部分。# 可注册的状态处理器方便不同项目定制 class FlashStateMachine: def __init__(self, uds_client): self.handlers {} self.register(FlashState.SESSION_EXT, self._handle_session_ext) # ... def register(self, state, handler): self.handlers[state] handler def _handle_session_ext(self): resp self.uds.send([0x10, 0x03]) if resp[0] ! 0x50: raise FlashError(进入扩展会话失败, resp) return FlashState.SECURITY_ACCESS验证改造是否成功最直接的方法是拿一个已知能刷成功的 ECU 和刷写文件跑一遍完整流程对比改造前后的 CAN 报文。如果报文序列一致说明改造没有引入行为差异。如果报文有差异逐帧对比看差异出现在哪个状态再定位到对应的处理函数。从那以后我每次改刷写流程都强制走一遍「抓报文 对比 再刷一次」的闭环不靠肉眼 review 代码。希望这份参考代码和上面的拆解能帮你少走几个我当年踩过的坑。本文还有配套的精品资源点击获取 UDS诊断ECU升级刷写上位机参考代码：从10 03到11 01完整链路与避坑指南
简介这份资源面向汽车电子诊断开发初学者与嵌入式工程师提供基于UDS协议的ECU升级刷写上位机参考代码帮助读者理解诊断会话控制、安全访问、数据传输与错误处理等核心流程并借助CAN总线完成与ECU的通信交互。压缩包共49个文件约2.07MB以22张png截图、15篇md笔记、6个cpp源文件与4个头文件为主辅以少量jpg与txt涵盖环境搭建、交叉编译、SocketCAN、pthread与动态库等模块目录按Part1、Part2与DiagboxSRC分层组织便于按主题检索。目前已有5774人学习下载适合需要动手实践UDS刷写逻辑的开发者参考。读者可从中获取上位机框架、通信会话管理、文件传输与编程算法适配思路以及测试调试与排错方法为构建自有诊断刷写工具提供可复用的代码基础与学习路径。1. 从一次刷写失败说起这套 UDS 诊断 ECU 升级上位机代码到底能干什么去年帮一个做车载电子的朋友排查问题他们的产线刷写工具在写 Application 分区时偶发校验失败换了两台电脑、三根 CAN 线都没定位到原因。最后发现是上位机在 RequestDownload 之后没有严格按 blockSequenceCounter 递增发送 TransferDataECU 端超时后直接回了负响应。这件事让我意识到一套靠谱的 UDS 刷写上位机参考代码价值不在于界面多好看而在于它把 ISO 14229 里那些容易踩坑的时序、计数器、状态机都老老实实实现了一遍。这份 UDS 诊断 ECU 升级刷写上位机参考代码面向的就是需要自己搭一套刷写工具、或者想搞懂 UDS 刷写完整链路的开发者。它覆盖了从 10 03 进入扩展会话、27 安全访问、34/36/37 传输数据到 31 例程校验、11 复位这一整条刷写流程适合做 ECU 产线刷写、售后诊断工具、或者 Bootloader 联调的团队拿来当起点。如果你正在找一份能直接跑、又能改的 UDS 升级刷写参考实现这份代码值得先跑通再动手改。2. 技术选型与整体架构为什么是分层状态机而不是一把梭2.1 上位机侧的技术栈取舍拿到一份刷写上位机代码第一件事是看它怎么组织通信层和业务层。这份参考代码走的是典型的「CAN 驱动 ISO-TP 传输 UDS 服务 刷写流程」四层结构。底层用 CAN 适配器常见做法是 PCAN、Kvaser 或周立功的二次封装库中间用 ISO 15765-2 做多帧拆包上面才是 UDS 服务层和刷写状态机。为什么强调分层因为刷写过程中最怕的就是把「发一帧 CAN」和「发一条 UDS 请求」混在一起写。一旦混了超时重传、流控帧处理、连续帧序号这些逻辑就会散落在业务代码里改一个参数要动三四个文件。分层之后换一个 CAN 盒子只需要改驱动适配层UDS 服务层和刷写流程完全不用动。# 通信层抽象不同 CAN 适配器实现同一套接口 class CanDriverBase: def open(self, channel, bitrate): ... def send(self, can_id, data): ... def recv(self, timeout_ms): ... class IsoTpLayer: ISO 15765-2 传输层负责单帧/首帧/连续帧/流控帧 def __init__(self, driver, tx_id, rx_id): self.driver driver self.tx_id tx_id self.rx_id rx_id self.block_size 0 # 流控帧里的 BS self.st_min 0 # 流控帧里的 STmin def send_uds(self, payload: bytes): # 大于 7 字节走多帧首帧 连续帧 if len(payload) 7: self.driver.send(self.tx_id, bytes([len(payload)]) payload) else: self._send_multi_frame(payload)这段代码里block_size和st_min是从 ECU 回的流控帧里解析出来的不是写死的。很多自己写的刷写工具翻车就翻在这里——把 BS 固定成 0表示不再发流控帧结果 ECU 其实要求每发 N 帧就等一次流控发快了直接丢帧。参数说明tx_id是上位机发给 ECU 的功能/物理寻址 IDrx_id是 ECU 回给上位机的 ID刷写场景一般用物理寻址避免多个 ECU 同时响应。2.2 刷写流程的状态机设计刷写不是一条直线中间任何一步 NRC负响应都可能需要回退或重试。这份代码把整个刷写过程拆成了一个显式状态机每个状态对应一个 UDS 服务或一个等待条件。from enum import Enum, auto class FlashState(Enum): IDLE auto() SESSION_EXT auto() # 10 03 SECURITY_ACCESS auto() # 27 01 / 27 02 ROUTINE_PRE auto() # 31 01 FF00 预编程 DOWNLOAD auto() # 34 RequestDownload TRANSFER auto() # 36 TransferData TRANSFER_EXIT auto() # 37 RequestTransferExit CHECK_DEPENDENCY auto() # 31 01 FF01 依赖检查 ERASE auto() # 31 01 FF00 擦除 CHECK_MEMORY auto() # 31 01 0202 校验 RESET auto() # 11 01 class FlashStateMachine: def __init__(self, uds_client): self.uds uds_client self.state FlashState.IDLE self.block_seq 0 # blockSequenceCounter从 1 开始 def step(self): if self.state FlashState.SESSION_EXT: resp self.uds.send([0x10, 0x03]) if resp and resp[0] 0x50: self.state FlashState.SECURITY_ACCESS else: raise FlashError(进入扩展会话失败, resp) # ... 其余状态迁移状态机的核心价值在于每个状态只关心「发什么请求、期望什么响应、失败怎么处理」。block_seq是 TransferData 的块计数器从 1 开始每发一块加 1溢出后回绕到 0注意不是 1。这个细节在 ISO 14229 里有明确定义但手写代码时极容易写成从 0 开始或者溢出后回 1ECU 会直接回 0x73wrongBlockSequenceCounter。2.3 目录结构一览参考代码的目录组织大致如下方便你按模块定位目录/文件职责drivers/CAN 适配器封装PCAN、Kvaser、ZLG 各一个文件isotp/ISO 15765-2 传输层单帧/多帧/流控uds/UDS 服务封装10/11/14/19/27/28/31/34/36/37/3E/85flash/刷写状态机、S19/HEX 解析、分块策略config/ECU 描述文件含 CAN ID、安全算法 DLL 路径、Flash 驱动地址ui/上位机界面PyQt 或 WinForms视版本而定tests/针对 ISO-TP 和 UDS 层的单元测试这个结构的好处是你要换安全算法只动config/里指向的 DLL要换刷写文件格式只动flash/里的解析器要换 CAN 盒子只动drivers/。各层之间通过接口耦合不是通过具体实现耦合。3. 核心模块拆解从 10 03 到 11 01 的完整链路3.1 会话与安全访问27 服务的种子密钥逻辑刷写的第一步是进扩展会话10 03第二步是安全访问27 01 请求种子27 02 发送密钥。安全算法通常由 ECU 供应商以 DLL 形式提供上位机通过 ctypes 或 JNA 调用。import ctypes class SecurityAccess: def __init__(self, dll_path): self.dll ctypes.CDLL(dll_path) # 常见导出函数GenerateKey(seed, seed_len, key, key_len) self.dll.GenerateKey.argtypes [ ctypes.POINTER(ctypes.c_ubyte), ctypes.c_int, ctypes.POINTER(ctypes.c_ubyte), ctypes.POINTER(ctypes.c_int) ] def request_seed(self, uds): resp uds.send([0x27, 0x01]) if resp[0] ! 0x67: raise FlashError(请求种子失败, resp) return resp[2:] # 跳过 67 01 def send_key(self, uds, seed): key_buf (ctypes.c_ubyte * 16)() key_len ctypes.c_int(16) seed_buf (ctypes.c_ubyte * len(seed))(*seed) self.dll.GenerateKey(seed_buf, len(seed), key_buf, ctypes.byref(key_len)) key bytes(key_buf[:key_len.value]) resp uds.send([0x27, 0x02] list(key)) if resp[0] ! 0x67: raise FlashError(安全访问被拒, resp)这里有个血泪经验种子长度和密钥长度不一定相等有的 ECU 种子 4 字节、密钥 8 字节有的反过来。GenerateKey的签名里key_len是入参出参调用前要设成缓冲区大小调用后才是实际密钥长度。如果直接按种子长度去截密钥大概率会得到一个 NRC 0x35invalidKey。3.2 34/36/37 传输分块大小与超时怎么定RequestDownload34里要带上 memoryAddress 和 memorySizeECU 返回 maxNumberOfBlockLength这个值决定了你每块 TransferData 最多能带多少字节。def request_download(self, uds, address, size): # 34 服务dataFormatIdentifier addressAndLengthFormatIdentifier # 常见做法0x00 表示不压缩不加密0x44 表示 4 字节地址 4 字节长度 req [0x34, 0x00, 0x44] req list(address.to_bytes(4, big)) req list(size.to_bytes(4, big)) resp uds.send(req) if resp[0] ! 0x74: raise FlashError(RequestDownload 失败, resp) # 响应格式74 lengthFormatIdentifier maxNumberOfBlockLength max_len int.from_bytes(resp[2:], big) return max_len def transfer_data(self, uds, data, max_block_len): # max_block_len 包含 SID blockSequenceCounter所以实际数据要减 2 chunk_size max_block_len - 2 offset 0 self.block_seq 1 while offset len(data): chunk data[offset:offset chunk_size] req [0x36, self.block_seq] list(chunk) resp uds.send(req, timeout_ms2000) if resp[0] ! 0x76: raise FlashError(fTransferData 失败 seq{self.block_seq}, resp) self.block_seq (self.block_seq 1) 0xFF if self.block_seq 0: self.block_seq 1 # 回绕到 1不是 0 offset len(chunk)参数说明max_block_len是 ECU 告诉你的单块最大长度包含 SID 和 blockSequenceCounter 两个字节所以实际数据块要减 2。timeout_ms在擦除和写入 Flash 时通常要放大到 2000ms 以上因为 ECU 内部擦写一个扇区可能耗时几百毫秒。如果你用默认的 100ms 超时会看到大量超时重传最后刷写失败但不知道卡在哪。3.3 31 例程控制擦除、校验、依赖检查的顺序31 服务在刷写里承担了三个关键例程预编程FF00、擦除FF00 带不同参数、校验0202。顺序不能乱擦除必须在 RequestDownload 之前校验必须在 TransferExit 之后。def routine_control(self, uds, routine_id, sub_func, paramsNone): req [0x31, sub_func] list(routine_id.to_bytes(2, big)) if params: req list(params) resp uds.send(req, timeout_ms5000) # 擦除例程耗时长 if resp[0] ! 0x71: raise FlashError(f例程 {routine_id:#06x} 失败, resp) return resp[3:] # 跳过 71 sub_func routine_id # 典型调用顺序 routine_control(uds, 0xFF00, 0x01) # 预编程 routine_control(uds, 0xFF00, 0x01, [0x00]) # 擦除参数视 ECU 而定 # ... 34/36/37 ... routine_control(uds, 0xFF01, 0x01) # 依赖检查 routine_control(uds, 0x0202, 0x01) # 校验注意擦除例程的响应时间可能长达数秒timeout_ms要设够。有的 ECU 在擦除期间会周期性发 0x7F 31 01responsePending上位机需要正确处理这种「请稍等」的响应而不是当成失败。这份代码在 ISO-TP 层做了 0x7F 的透传UDS 层再判断是否继续等待。3.4 S19/HEX 文件解析与地址对齐刷写文件通常是 Motorola S-record 或 Intel HEX 格式。解析时要处理地址不连续、数据段之间有空洞的情况。def parse_s19(file_path): segments [] # [(address, data), ...] with open(file_path, r) as f: for line in f: line line.strip() if not line.startswith(S): continue rec_type line[1] if rec_type 3: # S34 字节地址 byte_count int(line[2:4], 16) address int(line[4:12], 16) data bytes.fromhex(line[12:12 (byte_count - 5) * 2]) segments.append((address, data)) # 合并连续段按地址排序 segments.sort(keylambda x: x[0]) return segments解析完之后要做地址对齐Flash 写入通常要求按页对齐比如 8 字节或 16 字节如果某段数据长度不是页大小的整数倍需要补齐 0xFF。补齐的字节在后续校验时会被 ECU 忽略还是参与计算取决于 ECU 的校验算法这一点要跟 ECU 供应商确认不能想当然。4. 跑起来环境搭建与第一次刷写4.1 依赖安装与 CAN 驱动配置参考代码的 Python 版本依赖通常在requirements.txt里核心是python-can、cantools可选用于 DBC 解析、pyserial如果走串口转 CAN。pip install python-can cantools pyserial # 如果用的是 PCAN还需要装 PCAN-Basic 驱动 # 如果用的是周立功装 ZLG 的 CAN 驱动和 Python 封装CAN 驱动配置是新手最容易卡住的地方。以 PCAN 为例python-can的配置里要指定interfacepcan、channelPCAN_USBBUS1、bitrate500000。如果can.Bus()初始化报错先确认驱动装没装、盒子插没插、通道号对不对。常见做法是先用厂商自带的工具发一帧确认硬件通路没问题再跑上位机代码。4.2 配置文件怎么填config/下的 ECU 描述文件一般包含这些字段字段说明示例tx_id上位机发送 ID0x7A0rx_idECU 响应 ID0x7A8bitrateCAN 波特率500000security_dll安全算法 DLL 路径./sec/seed_key.dllflash_driverFlash 驱动地址0x40000000app_startApplication 起始地址0x8000app_sizeApplication 大小0x3F000填错tx_id/rx_id的表现是发出去的请求没有任何响应或者收到的是别的 ECU 的响应。用 CAN 分析仪抓一下报文就能确认。app_start和app_size填错的话RequestDownload 可能成功但校验会失败因为写到了错误的地址。4.3 第一次刷写的完整命令序列跑通第一次刷写建议按下面的顺序手动发一遍确认每一步都有正确响应再让状态机自动跑。# 假设用 python-can 的 cansend 工具做手动验证 # 1. 进扩展会话 cansend can0 7A0#021003 # 期望7A8#06500300 32 01 F4 P250ms, P2*5000ms # 2. 请求种子 cansend can0 7A0#022701 # 期望7A8#066701 种子 # 3. 发密钥假设密钥是 11223344 cansend can0 7A0#06270211223344 # 期望7A8#026702 # 4. 预编程 cansend can0 7A0#043101FF00 # 期望7A8#067101FF00 可选参数每一步的响应都要看 SID 是不是请求 SID 0x40是的话说明肯定响应不是的话看 NRC 码。0x78 表示 responsePending继续等0x33 表示安全访问被拒0x31 表示请求超出范围0x72 表示编程失败。把这些 NRC 码整理成一张表贴在工位上排查效率会高很多。5. 避坑与排查刷写失败时先看这五个地方5.1 现象TransferData 发到一半 ECU 不再响应原因blockSequenceCounter 回绕逻辑写错或者流控帧的 BS/STmin 没按 ECU 要求处理。有的 ECU 要求每发 8 帧就等一次流控上位机如果一口气发完ECU 缓冲区溢出后直接丢帧。解决在 ISO-TP 层严格按流控帧的 BS 值控制发送节奏BS0 表示不再发流控帧BSN 表示每 N 帧等一次。STmin 是连续帧之间的最小间隔单位可能是毫秒或微秒要看流控帧里的编码。5.2 现象安全访问一直返回 0x35原因密钥算错了。要么是种子长度和密钥长度搞混要么是 DLL 调用时参数类型不对比如把 unsigned char* 传成了 char*要么是字节序问题。解决先用已知的种子-密钥对单独测 DLL确认 DLL 本身没问题。再检查上位机传给 DLL 的种子是不是完整的、有没有被截断。字节序方面有的算法要求种子按小端传入有的要求大端这个只能看 ECU 供应商的文档。5.3 现象擦除例程超时但 ECU 其实在擦原因擦除 Flash 扇区耗时可能超过默认的 P2 超时ECU 会先回 0x7F 31 01responsePending擦完再回 0x71。上位机如果没处理 0x7F会直接报超时。解决在 UDS 层判断响应字节如果是 0x7F 且 NRC 是 0x78就继续等待直到收到最终响应或达到 P2* 超时。P2* 通常比 P2 大很多比如 P250ms、P2*5000ms。5.4 现象校验例程返回失败但数据看着写进去了原因校验算法不匹配。ECU 可能用 CRC32、累加和、或者自定义算法。上位机如果按 CRC32 算ECU 按累加和算结果肯定对不上。解决找 ECU 供应商要校验算法的说明或者用已知正确的刷写文件反推算法。有的 ECU 在 Bootloader 里提供了读校验值的例程可以先读出来跟上位机算的对比。5.5 现象刷完复位后 ECU 不启动原因Application 的入口地址或中断向量表没配对或者刷写时漏掉了某个必须写入的配置区。解决确认刷写文件是否完整有没有漏掉 Bootloader 要求的配置段。复位后如果 ECU 不响应可能需要重新进 Bootloader 模式通常靠硬件引脚或特定的 CAN 报文触发再刷一遍。6. 二次开发把这套代码改成你自己的刷写工具拿到这份参考代码之后最常改的三个地方是安全算法、刷写文件格式、以及刷写流程的定制。安全算法方面如果你的 ECU 用的是标准算法比如某些通用 Bootloader 的固定算法可以直接在 Python 里实现不用调 DLL。如果是自定义算法保持 DLL 调用方式只换 DLL 路径就行。我一般会在config/里加一个security_type字段支持dll和builtin两种模式方便切换。刷写文件格式方面除了 S19 和 HEX有的项目用 bin 文件加地址偏移。这时候只需要在flash/下加一个parse_bin(file_path, base_address)函数返回同样的[(address, data)]结构上层状态机完全不用动。这就是分层的好处。刷写流程定制方面有的 ECU 要求在 RequestDownload 之前先写一个特定的配置字或者在校验之后读一下某个 DID 确认版本。这些都可以在状态机里插入新的状态或者在现有状态的前后加 hook。我习惯把每个状态的处理函数写成可注册的这样不同项目可以复用同一套状态机框架只替换差异部分。# 可注册的状态处理器方便不同项目定制 class FlashStateMachine: def __init__(self, uds_client): self.handlers {} self.register(FlashState.SESSION_EXT, self._handle_session_ext) # ... def register(self, state, handler): self.handlers[state] handler def _handle_session_ext(self): resp self.uds.send([0x10, 0x03]) if resp[0] ! 0x50: raise FlashError(进入扩展会话失败, resp) return FlashState.SECURITY_ACCESS验证改造是否成功最直接的方法是拿一个已知能刷成功的 ECU 和刷写文件跑一遍完整流程对比改造前后的 CAN 报文。如果报文序列一致说明改造没有引入行为差异。如果报文有差异逐帧对比看差异出现在哪个状态再定位到对应的处理函数。从那以后我每次改刷写流程都强制走一遍「抓报文 对比 再刷一次」的闭环不靠肉眼 review 代码。希望这份参考代码和上面的拆解能帮你少走几个我当年踩过的坑。本文还有配套的精品资源点击获取