1. 从一次刷写失败说起：为什么BootLoader值得单独拎出来讲
前阵子帮一个做域控制器的朋友排查问题，他们的一款车身控制器在产线刷写时偶发“刷到一半卡死、重启后应用起不来”的情况。日志抓下来一看，UDS的RequestDownload已经返回了正响应，TransferData也传了几十帧，结果在最后一帧校验时ECU直接复位，再上电就停在BootLoader里出不来。折腾了两天才定位到：SBL（Secondary BootLoader）在擦写App区时没有对Flash驱动做分页对齐，跨页写入触发了写保护。
这个案例很典型。汽车ECU BootLoader升级这件事，表面上看就是“把新固件灌进去”，但真正落到工程上，它牵扯到PBL/SBL两级引导的架构设计、UDS诊断服务的时序配合、Flash驱动的擦写策略、刷写鲁棒性（掉电、通信中断、校验失败）的处理，以及产线/OTA两种场景下的差异化需求。我做了几年车载诊断和刷写工具链，踩过的坑基本都集中在这些“看不见”的地方。
这篇文章面向的是刚接触ECU刷写的嵌入式工程师、诊断协议开发者、以及需要自己搭刷写工具链的测试人员。我会把PBL/SBL的分工、UDS刷写服务的完整交互、Flash操作的关键细节、以及实际调试中遇到的典型问题，按我自己的理解从头捋一遍。不堆术语，尽量说人话，能直接抄的配置和代码我会给出来。看完你应该能独立设计一套可用的刷写流程，并且知道哪些地方最容易翻车。
2. PBL与SBL：两级引导到底在分工什么
2.1 为什么不能只有一个BootLoader
很多人第一反应是：ECU上电后先跑BootLoader，BootLoader负责判断要不要刷App、刷完跳App，不就完了？为什么还要分PBL和SBL两级？
核心原因在于**“不可变”和“可升级”的矛盾**。PBL（Primary BootLoader）通常烧在芯片的启动扇区或者受保护区域，出厂后基本不动，它的职责极其单一：初始化最基础的时钟和Flash控制器，然后去校验SBL的完整性，校验通过就跳过去。SBL（Secondary BootLoader）才是真正干刷写活的那个，它包含完整的UDS诊断栈、Flash驱动、校验算法，是可以被升级的。
这么设计的好处有三个。第一，PBL体积极小，通常几KB到十几KB，烧在受保护区域，几乎不可能被刷坏，保证了“变砖”后还有救。第二，SBL可以独立升级，当刷写协议要改、要支持新的Flash型号、要加新的校验算法时，只升级SBL即可，不用动PBL。第三，职责分离让验证更简单，PBL只需要验证SBL的CRC，SBL只需要验证App的CRC，每一级的验证逻辑都很清晰。
我见过一些低成本方案把PBL和SBL合并成一个，省Flash空间。短期没问题，但一旦这个合并的BootLoader本身有bug需要修复，就只能返厂用调试器重新烧，产线和售后的成本会非常高。所以只要Flash空间允许，我强烈建议保留两级结构。
2.2 PBL的启动流程与跳转条件
PBL的启动逻辑可以用一句话概括：先看有没有刷写请求，没有就校验SBL并跳转，有就停在PBL等待。但实际实现里，这个“刷写请求”的判断有很多讲究。
常见的判断依据有这么几种：
- App有效性标志：在Flash固定地址放一个魔数（比如
0x5A5A5A5A），App刷写成功后由SBL写入。PBL上电读这个标志，有效就跳App，无效就停在BootLoader。 - 刷写请求标志：由诊断服务或外部引脚触发，置位后PBL知道要进入刷写模式。
- SBL有效性校验：对SBL区域做CRC或哈希校验，通过才跳转。
这里有个容易忽略的点：PBL跳转到SBL之前，必须把中断向量表重映射。Cortex-M系列芯片上电默认从0x00000000取向量表，如果SBL烧在0x08004000，那PBL在跳转前要设置SCB->VTOR = 0x08004000，否则SBL里的中断会跳到PBL的向量表去，直接跑飞。这个坑我见过至少三次，每次都是“跳过去就HardFault”，查半天才发现是VTOR没设。
/* PBL跳转到SBL的典型实现 */ typedef void (*pFunction)(void); pFunction JumpToSBL; uint32_t sblAddr = 0x08004000; /* 检查SBL栈顶是否合法 */ if (((*(uint32_t*)sblAddr) & 0x2FFE0000) == 0x20000000) { /* 设置向量表偏移 */ SCB->VTOR = sblAddr; /* 取SBL复位向量 */ JumpToSBL = (pFunction)(*(uint32_t*)(sblAddr + 4)); /* 设置主栈指针 */ __set_MSP(*(uint32_t*)sblAddr); JumpToSBL(); }注意：跳转前一定要关掉所有外设中断和SysTick，否则跳过去之后残留的中断会立刻触发，而此时向量表还没完全生效，容易出问题。
2.3 SBL的职责边界与设计取舍
SBL是刷写的主力，它要干的事包括：初始化通信外设（CAN/CAN-FD/以太网）、跑UDS诊断服务、驱动Flash擦写、做完整性校验、最后跳转到App。听起来很多，但每一项都有取舍。
通信外设的选择直接影响刷写速度。传统CAN 500kbps下，一帧8字节，刷1MB的App大概要十几分钟，产线根本受不了。所以现在新一点的ECU基本都上CAN-FD（2Mbps数据段）或者车载以太网（100Mbps），刷写时间能压到几十秒甚至几秒。如果你们还在用普通CAN刷大固件，建议优先评估升级到CAN-FD的可行性。
Flash驱动的实现是SBL里最需要小心的部分。不同厂商的Flash（内部Flash、外部QSPI Flash、eMMC）擦写粒度不同，有的是1KB一页，有的是4KB一扇区。SBL必须知道当前写入地址是否跨页，跨页时要先擦下一页再写。我前面提到的那个案例，就是SBL的Flash驱动没做跨页判断，TransferData传过来的数据块正好跨在两页之间，写到第二页时因为没擦除直接写，触发了写保护复位。
校验算法的选择也有讲究。CRC32速度快、实现简单，但碰撞概率比SHA-256高。对于安全等级要求高的ECU（比如涉及功能安全的），建议用SHA-256或者至少CRC32加长度校验。校验的时机一般是所有数据传输完成后，由SBL对App区做一次全量校验，校验通过才写有效性标志。
2.4 PBL/SBL/App的Flash布局规划
Flash布局是刷写方案的地基，规划不好后面全是坑。我一般按下面的原则来分：
| 区域 | 典型大小 | 说明 |
|---|---|---|
| PBL区 | 16KB~32KB | 受保护，出厂后不升级 |
| SBL区 | 64KB~128KB | 可升级，含UDS栈和Flash驱动 |
| App区 | 剩余空间 | 应用代码，可升级 |
| 配置区 | 4KB~8KB | 存有效性标志、刷写计数、版本号 |
| 备份区（可选） | 与App区等大 | 用于A/B分区升级 |
配置区的位置很关键，它不能被App的擦写操作误伤。我通常把配置区放在App区之后，并且在SBL的Flash驱动里把配置区地址列为“保护地址”，擦写时直接跳过。另外，配置区最好做双备份，写的时候先写备份再写主份，读的时候两份都读、取有效的那个，防止写配置时掉电导致标志丢失。
3. UDS刷写服务：从会话切换到最终校验的完整交互
3.1 UDS刷写涉及的核心服务梳理
UDS（Unified Diagnostic Services，ISO 14229）里跟刷写相关的服务就那么几个，但每个的细节都能卡人。我先把它们列出来，然后逐个说坑。
0x10DiagnosticSessionControl：切换到编程会话（0x02）0x27SecurityAccess：安全访问，解锁刷写权限0x85ControlDTCSetting：关闭DTC记录0x28CommunicationControl：关闭非诊断通信0x31RoutineControl：擦除内存、校验完整性0x34RequestDownload：请求下载，协商数据格式0x36TransferData：传输数据块0x37RequestTransferExit：退出传输0x11ECUReset：复位ECU
整个刷写流程就是这些服务按顺序组合起来。顺序不能乱，比如没切到编程会话就发0x34，ECU会直接回0x7F 0x34 0x7E（服务不支持于当前会话）。我见过有人调试时图省事，跳过0x27直接发0x34，结果一直收到否定响应，查了半天以为是协议栈问题，其实是安全访问没做。
3.2 会话切换与安全访问的时序陷阱
0x10 0x02切到编程会话后，ECU通常会启动一个S3定时器（一般5秒），如果5秒内没有收到任何诊断请求，ECU会自动退回默认会话。这意味着你在刷写过程中如果因为擦除Flash耗时太长（比如擦一整块Flash要3秒），中间没有及时发请求，会话就掉了，后面的0x36全部会被拒绝。
解决办法有两个：一是把擦除操作放在0x31例程里，ECU在执行例程时会自己喂S3定时器；二是刷写工具在等待期间周期性发送0x3E TesterPresent保持会话。我一般两个都做，双保险。
安全访问0x27的坑主要在种子和密钥的算法上。0x27 0x01请求种子，ECU返回一个随机数；工具用约定的算法算出密钥，通过0x27 0x02发回去。算法是OEM和供应商约定的，常见的有固定密钥、种子异或、AES加密等。调试阶段如果算法对不上，会连续收到0x27的否定响应，连续错几次后ECU会锁定一段时间（一般是10秒），这时候别急着一直重试，等锁定时间过了再试。
实操心得：安全访问的种子每次请求都应该不同（ECU用真随机数或伪随机数生成器）。如果发现每次种子都一样，说明ECU的随机数生成有问题，这在功能安全审计时会被挑出来，建议尽早修复。
3.3 RequestDownload与TransferData的参数协商
0x34 RequestDownload是刷写里信息量最大的一个服务。它的请求格式是：
0x34 [dataFormatIdentifier] [addressAndLengthFormatIdentifier] [memoryAddress] [memorySize]dataFormatIdentifier一般填0x00，表示不压缩不加密。如果固件是压缩的，这里填压缩算法标识，ECU收到后要解压。addressAndLengthFormatIdentifier的高4位表示memorySize占几个字节，低4位表示memoryAddress占几个字节。比如0x44表示地址4字节、长度4字节。
ECU的肯定响应里会带一个maxNumberOfBlockLength，告诉工具“你每次0x36最多能发多少字节”。这个值取决于ECU的接收缓冲区大小和诊断栈的配置。工具必须遵守这个限制，发超了ECU会回0x7F 0x36 0x13（长度错误）。
# 解析RequestDownload正响应的maxNumberOfBlockLength def parse_download_response(resp): # resp[0] = 0x74 (0x34 + 0x40) # resp[1] = lengthFormatIdentifier # resp[2:2+lengthFormatIdentifier] = maxNumberOfBlockLength length_fmt = resp[1] max_block_len = int.from_bytes(resp[2:2+length_fmt], 'big') return max_block_len0x36 TransferData的请求格式是0x36 [blockSequenceCounter] [data]。blockSequenceCounter从0x01开始，每发一帧加1，到0xFF后回绕到0x00。这个计数器是ECU用来检测丢帧和重复帧的，工具必须严格递增。我见过有人图省事一直填0x01，结果ECU在第二帧就回了0x7F 0x36 0x73（块序号错误）。
3.4 RoutineControl在擦除与校验中的用法
0x31 RoutineControl有三个子功能：0x01启动例程、0x02停止例程、0x03请求例程结果。刷写里主要用0x01来触发擦除和校验。
擦除例程的请求一般长这样：0x31 0x01 [routineIdentifier] [memoryAddress] [memorySize]。routineIdentifier是OEM定义的，比如0xFF00表示擦除、0xFF01表示校验。ECU收到后开始擦除，擦除时间取决于Flash型号和擦除范围，可能几百毫秒到几秒。工具在发完擦除请求后要等ECU的响应，如果超时了不要立刻重发，先发0x3E保持会话，再等一会儿。
校验例程通常在0x37 RequestTransferExit之后调用，ECU对刚写入的App区做CRC或哈希校验，把结果通过0x31的响应返回。工具拿到校验结果后跟本地计算的对比，一致才算刷写成功。
注意：有些ECU的擦除例程是异步的，发完
0x31 0x01后ECU立刻回正响应，但实际擦除还在后台进行。这时候如果马上发0x34请求下载，ECU可能因为Flash还在忙而拒绝。稳妥的做法是发完擦除后轮询0x31 0x03查询例程状态，直到返回“已完成”。
3.5 刷写完成后的复位与App有效性确认
所有数据传完、校验通过后，工具发0x11 0x01（硬复位）让ECU重启。ECU重启后PBL会检查App有效性标志，标志有效就跳App。工具在复位后应该等待一段时间（一般2~5秒），然后重新建立诊断连接，读取App的版本号（0x22读DID）确认新固件已经生效。
这里有个细节：复位后ECU可能不会立刻响应诊断请求，因为App初始化需要时间。工具的重连逻辑要有重试机制，比如每隔500ms发一次0x3E，连续3次没响应就再等1秒重试，总共重试5次。如果5次都失败，说明App可能没起来，需要回退到BootLoader重新刷。
4. Flash擦写与数据完整性：刷写鲁棒性的核心
4.1 Flash擦写粒度与对齐处理
Flash的物理特性决定了它只能“先擦后写”，而且擦除的最小单位（扇区/页）通常远大于写入的最小单位（字/半字）。比如某款内部Flash扇区是2KB，但可以按4字节写入。SBL在收到0x36的数据后，不能直接往目标地址写，必须先判断这个地址所在的扇区是否已经擦除过。
我的做法是在SBL里维护一个**“已擦除扇区位图”**。擦除例程执行时，把要擦除的扇区在位图里标记为已擦除。0x36写入时，先查位图，如果目标扇区没擦过，先擦再写，然后更新位图。这样既避免了重复擦除（擦除很耗时），又保证了不会往没擦的扇区写。
/* 简化的扇区擦除检查逻辑 */ #define SECTOR_SIZE 2048 #define FLASH_BASE 0x08010000 #define SECTOR_COUNT 128 static uint8_t erased_bitmap[SECTOR_COUNT / 8]; int flash_write(uint32_t addr, uint8_t *data, uint32_t len) { while (len > 0) { uint32_t sector = (addr - FLASH_BASE) / SECTOR_SIZE; if (!(erased_bitmap[sector/8] & (1 << (sector%8)))) { if (flash_erase_sector(FLASH_BASE + sector*SECTOR_SIZE) != OK) return -1; erased_bitmap[sector/8] |= (1 << (sector%8)); } /* 按写入粒度写数据 */ uint32_t write_len = min(len, SECTOR_SIZE - ((addr - FLASH_BASE) % SECTOR_SIZE)); if (flash_program(addr, data, write_len) != OK) return -1; addr += write_len; data += write_len; len -= write_len; } return 0; }跨页写入是另一个高频坑。假设扇区2KB，当前地址在扇区末尾还剩100字节，但0x36传过来200字节，那后100字节就落到下一个扇区了。如果下一个扇区没擦，直接写就会失败。上面的代码通过write_len的计算自动处理了跨页，每次只写到扇区边界，下一轮循环再处理新扇区。
4.2 掉电与通信中断的恢复策略
刷写过程中掉电或者通信线被拔，是最考验方案鲁棒性的场景。理想情况下，重新上电后ECU应该停在BootLoader，等待工具重新发起刷写。要做到这一点，关键是App有效性标志的写入时机。
我的做法是：在刷写开始前，SBL先把App有效性标志清除（写无效值）。这样即使刷到一半掉电，重启后PBL发现标志无效，就会停在BootLoader。等所有数据传完、校验通过后，SBL再写入有效标志。这样保证了“要么完整刷完，要么停在BootLoader”，不会出现“刷了一半但标志还有效，PBL跳到一个残缺的App”的情况。
通信中断的恢复稍微复杂一点。如果工具和ECU之间的连接断了，ECU的S3定时器超时后会退回默认会话，刷写状态丢失。工具重新连接后需要从0x10 0x02重新开始整个流程。为了提高效率，有些方案支持断点续传：SBL记录已经成功写入的地址范围，工具重连后查询这个范围，从断点继续传。但断点续传的实现复杂度高，而且如果断点记录本身写坏了，反而会出问题。我一般建议产线刷写用有线连接保证稳定，OTA场景才考虑断点续传。
4.3 CRC校验与哈希校验的选型对比
校验算法选型要看安全等级和性能要求。我整理了一个对比表：
| 算法 | 计算速度 | 碰撞概率 | 适用场景 |
|---|---|---|---|
| 累加和 | 极快 | 高 | 对安全无要求的内部调试 |
| CRC16 | 快 | 中 | 低安全等级ECU |
| CRC32 | 较快 | 低 | 一般刷写场景 |
| SHA-256 | 慢 | 极低 | 功能安全相关ECU |
CRC32在大多数刷写场景下够用，计算1MB数据大概几十毫秒。SHA-256慢一些，1MB可能要几百毫秒到一秒，但对于功能安全ECU（比如刹车、转向）是必须的。选型时还要考虑ECU的算力，低端MCU跑SHA-256可能力不从心，这时候可以用硬件加密模块加速。
校验的另一个细节是校验范围。要校验的是整个App区，包括可能存在的填充字节。如果App实际大小小于分配的App区，填充字节也要参与校验，否则工具和ECU的校验范围不一致，结果永远对不上。我一般让SBL在擦除App区时把整个区域擦成0xFF，校验时按整个App区大小算，这样工具端也按同样大小算，就不会有歧义。
4.4 双分区（A/B）升级的取舍
A/B分区升级是指Flash里存两份App，一份运行、一份备份。升级时往备份区刷，刷完校验通过后切换启动标志，下次重启跑新固件。如果新固件有问题，可以快速回退到旧固件。
A/B分区的优点是升级过程不影响当前运行，而且回退方便。缺点是Flash空间翻倍，对于Flash紧张的ECU不现实。我的建议是：如果Flash空间充足（比如有外部Flash），且对可用性要求高（比如OTA场景），上A/B分区；如果Flash紧张且是产线刷写（刷写时ECU本来就不运行），单分区就够了。
A/B分区的实现关键在启动标志的管理。通常用一个独立的配置区存“当前活动分区”和“待激活分区”。SBL刷完备份区后，把“待激活分区”指向备份区，然后复位。PBL启动时读配置区，决定跳哪个分区。如果新分区启动失败（比如连续复位几次），PBL自动切回旧分区。这个“连续复位计数”的逻辑要小心，别让正常的复位（比如看门狗复位）被误判为启动失败。
5. 实操全流程：从零搭建一套可用的刷写方案
5.1 工具链选型与最小系统搭建
搭建刷写方案，工具链分三块：ECU端的SBL、PC端的刷写工具、两者之间的通信硬件。
ECU端的SBL我一般用C语言写，基于芯片厂商的HAL库。UDS协议栈可以自己实现（服务不多，几百行代码），也可以用现成的（比如开源的isotp+uds库）。自己实现的好处是可控、体积小，坏处是要处理ISO-TP的分帧重组，比较繁琐。如果团队有现成的诊断栈，直接复用最省事。
PC端的刷写工具，Python是首选，因为python-can、udsoncan这些库很成熟。udsoncan封装了UDS服务的请求响应，python-can负责底层CAN通信。用这两个库，一个基本的刷写脚本几十行就能写出来。
import can import udsoncan from udsoncan.connections import PythonIsoTpConnection from udsoncan.client import Client import isotp # 配置CAN和ISO-TP can_bus = can.interface.Bus(channel='can0', bustype='socketcan', bitrate=500000) tp_addr = isotp.Address(isotp.AddressingMode.Normal_11bits, txid=0x7E0, rxid=0x7E8) stack = isotp.CanStack(bus=can_bus, address=tp_addr) conn = PythonIsoTpConnection(stack) # 建立UDS客户端 with Client(conn, request_timeout=5) as client: client.change_session(0x02) # 编程会话 client.unlock_security_access(0x01) # 安全访问 # ... 后续刷写流程通信硬件方面，产线用Vector的VN系列或者PCAN，调试用便宜的USB-CAN分析仪也行。关键是波特率要匹配，CAN-FD还要配置数据段波特率。我见过有人用500kbps的硬件去刷CAN-FD的ECU，怎么都通不上，换了硬件就好了。
5.2 刷写脚本的关键步骤拆解
一个完整的刷写脚本，我一般按下面的顺序组织：
- 建立连接：初始化CAN和ISO-TP，发
0x3E确认ECU在线。 - 切编程会话：
0x10 0x02，等正响应。 - 安全访问：
0x27 0x01取种子，算密钥，0x27 0x02发送。 - 关闭DTC和通信：
0x85 0x02、0x28 0x03 0x01。 - 擦除App区：
0x31 0x01 0xFF00加地址长度。 - 请求下载：
0x34 0x00 0x44加地址长度，解析maxNumberOfBlockLength。 - 传输数据：循环发
0x36，每帧带递增的块序号。 - 退出传输：
0x37。 - 校验：
0x31 0x01 0xFF01，对比校验结果。 - 复位：
0x11 0x01。 - 重连确认：等待后重连，读版本号确认。
每一步都要检查响应码，收到否定响应就打印出来并终止。否定响应码的含义可以查ISO 14229标准，常见的0x13是长度错误、0x22是条件不满足、0x31是请求超出范围、0x33是安全访问被拒、0x7E是服务不支持于当前会话、0x7F是服务不支持于当前会话（子功能不支持）。
def flash_ecu(firmware_path): with open(firmware_path, 'rb') as f: firmware = f.read() with Client(conn, request_timeout=5) as client: client.change_session(0x02) client.unlock_security_access(0x01) client.control_dtc_setting(0x02) client.communication_control(0x03, 0x01) # 擦除 client.routine_control(0x01, 0xFF00, data=struct.pack('>II', APP_BASE, len(firmware))) # 请求下载 resp = client.request_download( memory_location=APP_BASE, memory_size=len(firmware), data_format=0x00, address_length=4, size_length=4) max_block = resp.service_data.max_length # 分块传输 block_seq = 1 offset = 0 while offset < len(firmware): chunk = firmware[offset:offset+max_block-2] client.transfer_data(block_seq, chunk) block_seq = (block_seq + 1) & 0xFF offset += len(chunk) client.request_transfer_exit() client.routine_control(0x01, 0xFF01) # 校验 client.ecu_reset(0x01)5.3 产线刷写与OTA刷写的差异处理
产线刷写和OTA刷写虽然底层都是UDS，但侧重点完全不同。
产线刷写追求速度和稳定性。ECU在产线上是静止的，供电稳定，通信线短，所以可以用最高的波特率、最大的块长度。产线刷写通常还会做并行刷写，一个工位同时刷多个ECU，这时候要注意CAN总线负载，别把总线打满了导致丢帧。另外产线刷写一般不做断点续传，刷失败就重刷，因为重刷的成本很低。
OTA刷写追求鲁棒性和用户体验。车辆在用户手里，网络可能不稳定，供电可能波动（虽然刷写时一般要求车辆处于ON档），所以必须支持断点续传、失败回退、后台下载等特性。OTA的刷写包通常要压缩和加密，减少传输量并保证安全。刷写时机也要选好，一般建议在车辆停放且电量充足时进行，刷写过程中禁止用户启动车辆。
我参与过的一个OTA项目，刷写包做了差分压缩，1MB的固件压到200KB，传输时间从十几分钟降到两分钟。差分压缩的原理是只传新旧固件的差异部分，ECU端用旧固件加差异生成新固件。这个方案对ECU的算力和Flash空间有要求，但效果很显著。
5.4 刷写日志与版本管理
刷写日志是排查问题的第一手资料。我要求刷写工具必须记录：时间戳、发送的请求、收到的响应、每帧的耗时。日志格式用文本就行，方便grep。出问题时，把日志和ECU的故障码一起看，基本能定位到是哪一步出的问题。
版本管理方面，每个固件包都要有唯一的版本号和校验值。版本号建议用语义化版本（主版本.次版本.修订号），校验值用SHA-256。刷写工具在刷之前先读ECU当前的版本号，跟目标版本号对比，如果一样就跳过（避免重复刷），如果ECU版本比目标版本新就警告（防止降级导致不兼容）。
实操心得：固件包的命名建议包含项目代号、版本号、日期和校验值前8位，比如
BCM_v1.2.3_20240501_a1b2c3d4.bin。这样一眼就能看出是哪个项目、哪个版本、什么时候出的、校验值对不对。
6. 常见问题与排查技巧实录
6.1 刷写失败问题速查表
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 切编程会话被拒 | ECU不支持编程会话/条件不满足 | 读ECU的DID确认支持的服务 |
| 安全访问一直失败 | 密钥算法不对/种子过期 | 抓包对比种子和密钥计算 |
| RequestDownload被拒 | 地址或长度格式不对 | 检查addressAndLengthFormatIdentifier |
| TransferData中途失败 | 块序号错误/长度超限 | 检查blockSequenceCounter和maxBlockLength |
| 擦除超时 | Flash忙/擦除范围太大 | 轮询例程状态，分块擦除 |
| 校验不通过 | 数据传输出错/校验范围不一致 | 对比工具和ECU的校验值 |
| 复位后App起不来 | 有效性标志没写/App本身有问题 | 读标志，用调试器看App入口 |
| 刷写速度慢 | 波特率低/块长度小 | 升级CAN-FD/增大块长度 |
6.2 典型故障的排查思路
故障一：刷写到99%失败，重试也失败。这种情况通常是最后一帧数据有问题。先检查最后一帧的长度是不是超过了maxNumberOfBlockLength，再检查块序号是不是回绕正确。如果都没问题，可能是Flash的最后一个扇区有坏块，用调试器读出来看看是不是全0xFF。
故障二：刷写成功但App运行异常。先确认App有效性标志写对了，再确认向量表偏移设对了。如果都对了，可能是App的链接脚本跟实际Flash布局不匹配，比如App编译时假设自己从0x08000000开始，但实际烧在0x08010000，那App里的绝对地址跳转全会错。解决办法是修改App的链接脚本，把起始地址改成实际的App区地址。
故障三：OTA刷写时车辆网络不稳定，频繁断连。先确认是网络问题还是ECU问题。可以在工具端加心跳包，每隔1秒发一次0x3E，如果连续3次没响应就判定断连。断连后不要立刻重连，等5秒再试，避免网络拥塞。如果断连频繁，考虑降低传输速率或者改用更稳定的通信方式。
6.3 独家避坑技巧汇总
技巧一：刷写前先读一遍ECU的完整信息。包括版本号、硬件号、软件号、VIN（如果支持）。这些信息在刷写失败时是恢复的依据，也是确认刷写对象正确的凭证。我见过有人刷错了ECU，把A车型的固件刷到B车型上，结果ECU直接变砖。
技巧二：擦除和写入之间加延时。有些Flash芯片擦除后需要一点时间才能稳定，立刻写入可能失败。我一般擦除后延时10ms再开始写，虽然慢一点但稳。
技巧三：校验用双算法。CRC32加长度校验，两个都过才算通过。单用CRC32有极小概率碰撞，加上长度校验基本可以忽略。
技巧四：保留刷写现场。刷写失败时，不要立刻复位ECU，先读一遍Flash里的内容，跟源固件对比，看看是哪一段写错了。这个现场对定位问题非常关键，复位后就没了。
技巧五：产线刷写加防呆。刷写工具在开始前检查ECU的硬件号，跟固件包里的硬件号对比，不匹配就拒绝刷写。这个简单的检查能避免大部分刷错固件的事故。
6.4 刷写性能优化建议
刷写速度是产线的核心指标。优化方向有三个：提高波特率、增大块长度、减少交互次数。
提高波特率最直接，CAN从500kbps升到CAN-FD的2Mbps，理论速度提升4倍。增大块长度取决于ECU的接收缓冲区，缓冲区越大，单帧能传的数据越多，交互次数越少。减少交互次数还可以通过合并服务实现，比如把0x85和0x28合并成一帧发（如果ECU支持），省一个来回。
我实测过一个优化案例：某ECU原本用CAN 500kbps、块长度128字节，刷1MB固件要8分钟。改成CAN-FD 2Mbps、块长度512字节后，刷写时间降到45秒。如果再优化Flash擦除策略（按需擦除而不是全擦），还能再快10秒左右。
注意：优化刷写速度的同时要保证可靠性。我见过为了追求速度把块长度设得很大，结果ECU缓冲区溢出导致丢帧，反而更慢。块长度要跟ECU的实际能力匹配，别拍脑袋定。
7. 我个人在实际项目中的几点体会
刷写方案的设计，说到底是在可靠性、速度、成本三者之间找平衡。产线刷写可以牺牲一点可靠性换速度，因为重刷成本低；OTA刷写必须把可靠性放在第一位，因为用户不会容忍刷坏。PBL/SBL的分级、UDS服务的时序、Flash擦写的策略，每一个选择背后都是这个平衡的体现。
我踩过的最大的坑，是早期做的一个项目为了省Flash空间，把SBL和App放在同一个扇区。结果升级SBL时，擦除扇区把App也擦了，ECU直接变砖。从那以后，我坚持SBL和App必须分属不同扇区，而且SBL区要留足余量，别为了省几KB空间埋雷。
另一个体会是测试要覆盖异常场景。正常刷写谁都能过，真正体现方案质量的是掉电、断连、校验失败这些异常情况。我一般会做这几项测试：刷写中途拔通信线、刷写中途断电、传错固件包、故意让校验失败。这些测试能暴露80%以上的问题。
最后分享一个小技巧：刷写工具的日志里，给每一帧都打上时间戳和耗时。排查问题时，如果发现某一帧耗时异常长（比如正常10ms，突然变成500ms），那这一帧附近很可能就是问题点。这个习惯帮我定位过好几次偶发的刷写失败。
