2020 年以前，汽车电子电气架构主要采用分布 式架构，该架构无法应对功能快速迭代升级和定制 化生产的需求，也无法满足未来汽车庞大的算力和 数据要求。2023 年开始，主机厂开始选择集中式域 控架构作为解决方案。集中式域控架构包括中央域、 智驾域、信息娱乐域和区域控制等关键控制器。这 些域控制器集成了分布式架构下控制器的众多功能， 由于软件迭代频繁，所以这些控制器的软件升级就 显得格外重要。 控制器供应商排查整车问题时常用的是Bootloader 刷新。CANFD 通信可以增加通信速率[1] 。本文依据 ISO 14229 标准的 UDS 诊断协议，并结合整车厂的刷 写规范，设计一套基于 CANFD UDS 的 BootLoader 上 下位机升级方案。一个可重编程的 ECU 包含 Bootloader （BT） 和App 程序。Bootloader 是 MCU 上电后运行的第一段程 序[2] ，它可初始化硬件设备、建立内存空间的映射， 也可对 Flash 进行擦除和编程，起到引导应用程序和 升级应用程序的作用。简而言之，Flash Bootloader 通过 CAN 总线升级 App 程序。一个 ECU 如果没有 BT，那么更新程序只能通过烧录器，反之，则可以 通过诊断接口进行升级，这在整车上是非常方便的， 不用拆件[3] 。仅当应用程序无效、上电之初和软件升 级时才会运行 Bootloader。ECU 在多数时间执行的是 应用程序。Bootloader 在产品出厂时就会固定下来，当需要 更新程序时，通过 BT 程序对 App 程序进行擦除和重 新写入，即产品出厂后只更新 App 软件。ECU 正常 上电走完初始化后，会判断是否有升级请求，如果 没有则跳到 App 程序运行；如果有升级请求，则运 行 BT程序进行升级[4] 。BT程序一般放在 Flash的最开 始处，App 程序在其后，这样可以独立配置两个区 域的内存保护。如图 1 所示，App 程序和 BT 程序占 用不同的 Flash，App 程序和 BT 程序的区别在于它通过控制驱动芯片、功率芯片和通信芯片，从而具有 了输入输出功能。Bootloader 是 Boot 加 Loader，Boot 是引导，用于 初始化硬件设备，是为 Loader 做准备的。Loader 是 加载器，Boot 准备好环境后，Loader 将要执行的程 序从非易失性存储设备中加载到内存中运行。Boot loader 通过调用特定 IAP 程序对另外一段 Flash 空间 进行读与写操作，从而实现对 MCU 程序的更新[5] 。 ECU 如果有 BT 程序，则可通过 CAN 刷写进行版本修 改、升级，不用拆件，极大地方便了开发者。 图 1 中，BT 程序使用 UDS 的诊断服务作为通信 协议，它具有 CAN 驱动、传输层和 UDS 协议层的通 信堆栈。由于 BT 程序的重要性，它应该被存放在已 进行保护 （软件上锁或硬件保护） 的存储区域。考 虑可能刷写失败导致丢失 App 程序，可以在 Flash 中 增加 App备份、BT备份程序。本文 Flash Driver 指 MCU 厂商提供的擦写 Flash 的驱动函数，当升级时，Flash Driver 会被临时下载 到 RAM 中，软件升级完成后复位就会删除。这样可 以避免程序正常运行中误调用 Flash Driver导致 Flash 程序被改写。Flash Driver至少包含四个 Flash接口函数：初始 化、反初始化、擦除和写入。初始化函数，BT 程序 调用此函数为 Flash 编程执行硬件特定的初始化；反 初始化函数，下载完成后，BT 调用此函数执行特定 的硬件操作来完成 Flash编程，擦除函数，BT程序调 用此函数擦除指定的内存区域；写入函数，BT 程序 调用此函数把数据写进 Flash。Flash Tool可以使用 C++[6] 、C#[7] 等进行开发。如 图 2 所示，刷写上位机导入安全算法文件、Flash Driver、App 文件后自动解析出 bin 文件里的起始地 址 、 长 度 等 信 息[8] ， 通 过 CAN 卡 （CANoe、 Vspy、 Kvaser、 同 星 等） 发 送 诊 断 报 文 与 下 位 机 进 行 交 互[9] 。下位机接收到诊断报文后调用 Flash Driver 里 的擦写函数进行 App 程序升级。如果上位机发报文格式错误或者下位机响应错误都将导致刷写失败。Flash Tool下载流程如下。 1） 读取编译后的目标文件 （s19、hex）。 2） 控制下载流程。 3） 基于协议执行数据传输。 4） 执行验证。复位后，ECU 从 BT 程序开始运行，确保 BT 程 序不受特定应用程序硬件设置的影响。为确保 BT 程 序不被修改，有些 MCU 厂商还会给 BT程序加锁实现 保护。如图 3 所示，ECU 启动完成初始化后判断是否 有外部升级请求，有则跳到 BT 程序；没有则判断 App程序是否有效，有效则跳到 App程序，无效则跳 到 BT程序。ISO 14229 系列标准定义的统一诊断服务 （Unified Diagnostic Services，UDS） 诊断协议是用于汽 车行业诊断通信的需求规范。表 1 是刷写常用的诊 断服务[10] 。基于 UDS 诊断协议和整车厂的刷写规 范，将刷写分为三个步骤：预编程、服务器编程和 后编程。预编程通过物理寻址和功能寻址发送诊断报文 为编程网络准备网络。检查编程条件是为了判断当 前条件是否可以升级。当条件不满足时 （高压上电、低压异常或车速不为 0），刷新服务请求将被拒绝。 关闭 DTC 记录和所有非诊断报文传输是为了降低总 线负载率，为接下来的服务器编程准备网络。预编 程步骤如图 4所示。服务器编程是整个编程步骤的重点，它包含了 安全算法、写指纹信息、下载 Flash Driver、升级 App程序、校验程序完整性一致性等关键步骤。ECU 收到 10 02 指令后将外部刷新请求标志位 设置为有效并执行 ECU 重启。解锁 ECU，Flash Tool 向 ECU 请求种子，Flash Tool 和 ECU 都计算出密钥， Flash Tool将密钥发送给 ECU。ECU 将匹配自己算出 的值和 Flash Tool收到的密钥值，如果一致，则通过 安全算法。写指纹信息是将诊断仪完成的刷写信息 写进 ECU，这样可以追溯到对应的诊断仪。因 为 Flash 中 存 储 Flash Driver 有 风 险 ， 所 以 Flash Driver 是通过 34、36、37 服务下载到 RAM。如 图 5所示，写 App程序需要参数为$31 $01 $FF $00的 RoutineControl 服务请求擦除请求的逻辑块。逻辑块 的所有段都通过服务 RequestDownload （参数为起始 地址和段的长度）、TransferData 和 RequestTransferExit 的序列下载到 ECU。在 34 服务之后，段的所有 数据字节由 36 服务传输。传输完所有的段字节后， 使用 37服务结束下载。如图 6 所示，后编程步骤由 2E 服务和硬复位等 步骤完成。写编程日期将编程日期写入 Flash 中，可以追溯到最近一次刷写的时间。硬复位将重启 ECU 并最终跳转到 App程序运行。本文基于域控制器进行 CANFD 的刷写试验，采 用同星 TC1013 为刷写 CAN 卡，同星配套软件 Tsmaster 为上位机。假如刷写条件 （供电电压、车速等） 不满足，刷写会失败；假如刷写过程中断电，由于 有 App 备份，ECU 依然具有备份的 App 程序。整个 试验过程检验了 Flash Tool上位机的功能，也检验了 域控制器的 BT 程序。整个刷写流程满足国标和企标 要求，试验成功。如图 7所示。实践证明，MCU 复位电路的选型需结合具体应 用环境，选择适配性和抗扰性良好的电路，以提升 系统设计的稳定性。本文提供的设计、分析、选型 思路，可为相关行业应用提供参考。
