对于汽车ECU从业者来说，ECU软件刷写是一个很广泛的话题，不管客户还是供应商，不管是开发还是产线，不管是软件还是系统，都需要进行软件刷写。那你所用的刷写方式与他人所有的刷写方式是否一样？你碰到的刷写问题与他人碰到的刷写问题是否共性？这些问题首先得从你们所用的刷写方式来了解。

从原理上来说，ECU软件刷写可分为2种：基于Bootloader的刷写和调试器直接刷写。不知你对此是否有概念，Anyway，下面让我们来详细了解：

1 基于Bootloader的ECU软件刷写

基于Bootloader的ECU软件刷写场景非常多，在车上通过OBD口刷写，在实验室通过连接CAN总线刷写，以及OTA升级,它们都是通过内置的引导程序（即Bootloader）来更新软件。

Bootloader是一段启动时运行的代码，负责加载主程序，所以基于Bootloader的刷写需要ECU进入boot模式，然后使用UDS服务通过某种通信协议来传输新软件。具体过程是这样：

ECU上电或复位后，微控制器MCU先执行BootLoader程序，进行boot初始化，然后检查是否有外部刷写请求。如果有，MCU会持续运行BootLoader程序，清除非易失性存储器中的刷写请求标识，再切换到编程会话模式，进而进入基于UDS服务的ECU软件刷写流程；如果没有，则检查应用程序是否有效，有效则跳转到应用程序，无效则继续待在Booloader运行。如下所示：

针对基于Bootloader使用UDS服务的软件刷写，就个人经历接触过基于CAN总线、K-Line和DoIP这三种进行UDS服务数据传输，其中：

(1) 基于CAN总线的刷写，即通过CAN总线传输刷写数据，遵循ISO 14229-1 UDS协议或厂商自定义协议，将刷写文件分割为多个CAN帧，即多帧传输来实现。

(2) 基于K-Line的刷写，即使用K-Line（ISO 9141）单线通信协议，属于半双工通信，通过特定波特率同步ECU速率较低（通常<20 kbps）。

(3) 基于DoIP（Diagnostics over IP）的刷写，即通过车载以太网（如100BASE-T1）实现高速通信，遵循ISO 13400标准，利用IP层实现端到端可靠传输。

对于这三种方式，基于K-Line的刷写应该见不到了，主流是基于CAN总线和DoIP的刷写，注意它们只是通信协议的不同，刷写速度不同。无论利用哪种协议进行软件刷写，它们都需要Bootloader来接收和处理传输的数据，具体刷写过程可以分为刷写前、刷写中和刷写后三个阶段，如下示意：

下面我们来详细了解一下Bootloader收到外部请求后开始刷写的三个阶段

1）刷写前

进行刷写的准备，一是确保刷写阶段总线通信的稳定性，二是避免刷写阶段出现非预期的故障，三是读取车辆数据供刷写前的一些检查等，如下所示：

首先进行会话控制，通过功能寻址方式进入扩展会话模式，为后面的信息访问及其他指令做准备；

然后检查刷写的前提条件，通过物理寻址方式发送历程控制请求。比如车确实处于静止状态，供电电压稳定等条件下才允许刷写；

接着通过物理寻址方式读取ECU信息像通过DID读取ECU的指纹、生产日期和版本号等。

再通过功能寻址方式进行DTC设置，比如将可能影响后续升级的DTC设置为关闭。

最后通过功能寻址方式禁止一般报文，包括NM报文和应用报文，以确保总线刷写的稳定性。

2）刷写中

这个阶段最主要的内容是下载软件，具体过程是：

通过物理寻址方式进入编程会话，准备后续的软件刷写；

通过物理寻址方式进行安全访问，即请求种子，生成种子，发送密钥和密钥确认；

通过物理寻址方式进行写入指纹信息，记录当前刷写的信息，比如日期和刷写ID等；

通过物理寻址方式进行写入擦写软件，将FlashDriver驱动软件下载到ECU的RAM中，以便后续软件刷写的擦除和写入操作；

通过物理寻址方式检查编程完整性，检查上一步的擦写程序是否正确下载；

通过物理寻址方式进行擦除内存；

通过物理寻址方式下载待刷写软件，将待刷写软件通过擦写软件驱动下载到指定地址，通过34、36、37三个服务多帧传输下载；

通过物理寻址方式检查编程完整性，对下载写入的刷写软件进行完整性校验；

通过物理寻址方式检查编程依赖性；

下载步骤完成后，通过物理寻址方式请求ECU复位，然后ECU将复位重启。

在这些步骤中，任何一步失败都将终止软件的刷写。

3）刷写后

刷写后阶段主要用于软件刷写成功后总线网络的同步设置，因为在刷写前阶段将网络状态设置为关闭状态。具体内容包括：

先通过功能寻址方式进入扩展会话模式，以便后续的刷写”恢复“操作；

然后通过功能寻址方式开启报文控制，恢复ECU的应用报文和NM报文通讯；

再通过功能寻址方式开启DTC设置，恢复ECU的DTC诊断；

最后通过功能寻址方式回到默认会话模式，这样整个刷写就此完成。

2 直接刷写

关于直接刷写，最常见的是调试器刷写（比如Lauterbach（TRACE32）、J-Link（SEGGER）和iSystem等），均基于调试接口协议和微控制器（MCU）底层访问能力实现。也就是说所有调试器均通过ECU的MCU预留的调试接口（如JTAG、SWD、DAP、cJTAG等）进行通信，直接访问MCU的调试核心（Debug Core）。

比如：

ARM Cortex-M系列：使用SWD（Serial Wire Debug）或JTAG接口。

PowerPC/Aurix系列：使用Nexus或DAP（Debug Access Port）接口。

可以这样理解，调试器相当于是硬件桥梁，它通过调试接口接管MCU的执行流程，暂停当前程序并进入调试模式；然后进行内存访问，直接擦除Flash存储器的原有程序，写入新固件（BIN/HEX文件）；以及部分情况下可以绕过安全机制，解除读/写保护。

调试器通过标准协议（如JTAG的IEEE 1149.1、ARM的SWD）与MCU交互，实现对MCU的寄存器读写、内存擦写和执行控制，通过调试接口直接操作Flash控制器（如擦除、写入校验），或调用MCU内部的BootROM代码进行直接刷写。

反正无论使用哪种调试器，核心刷写流程均包含以下步骤：

连接与初始化：调试器通过线缆连接ECU的调试接口，发送初始化指令握手。

暂停MCU：暂停正在运行的ECU固件，防止写入冲突。

擦除Flash：发送擦除指令清空目标存储区域。

写入新固件：将编译后的二进制代码按地址逐块写入Flash。

校验与复位：校验写入数据的完整性，复位MCU并退出调试模式。

3 两者比较

实际应用中，现代汽车ECU普遍采用复杂的Bootloader方案以应对日益严苛的功能安全与信息安全要求；而调试器直接刷写主要在开发或维修阶段，通过JTAG接口直接读写存储器，完全控制CPU和存储单元，无需依赖Bootloader的软件逻辑，刷写快速调试。

更为直接的体现就是：

在整车上的刷写都是基于Bootloader的刷写，包括OBD口刷写和OTA远程刷写，换句话说ECU未开盖进行的刷写都是基于Bootloader来实现。

而调试器刷写需要ECU开盖，这种方式主要用于底层软件开发人员，因软件调试需要，以及工厂预刷写（End-of-Line Programming），因为在生产线上，ECU的存储器处于空白状态，无Bootloader存在，需要直接通过JTAG或SWD接口刷写完整固件（包括Bootloader和应用程序）。

调试器直接刷写因为需要拆开ECU，物理接触芯片，存在一定的风险，如果操作不当，可能导致ECU无法启动，变成砖头。另外需要专门的工调试器，这意味着成本投入，以及对技术人员有要求，因此限制人员的使用。而基于Bootloader的刷写是不需要拆机，比较方便，通常需要特定的触发条件让ECU进入bootloader模式，比如汽车诊断仪通过发送特定指令让ECU进入刷写模式，然后传输数据，校验后重启，其安全性更高，可防止刷写错误导致系统崩溃。