汽车Bootloader原理
关键词 Bootloader ECU 汽车 UDS
摘 要 汽车Bootloader原理
1. 适用范围
适用于对汽车Bootloader原理不了解的工程师，本文有一定的启发意义。
2. 原理概述
单片机通常烧录有三种：
-
ISP（In-System Programming）
在系统编程，使用引导程序（Bootloader）加上外围UART/SPI等接口进行烧录。 -
ICP （In-circuit programmer）
在电路编程，使用SWD/JTAG接口。 -
IAP（In-Application Programming）
指MCU可以在系统中获取新代码并对自己重新编程，即用程序来改变程序。
平时开发使用主要IAP升级方式，对ECU更是如此。
单片机正常时运行上电/复位，第一条指令是固定的，程序正常顺序运行到Bootloader，由Bootloader跳转到APP程序运行。
图1-1 Bootloader简易流程
3. 准备工作
3.1 环境准备
- 代码编辑器
3.2 资源准备
- ISO 13400涉及到电子、电气设备、公路车辆使用、维护与修理。
- ISO 17897是一个多点，低成本，易实现的通信在汽车总线，工作作为在大多数应用子总线控制器局域网。
- ISO 14229 一个用于汽车行业诊断通信的需求规范，它只规定了与诊断相关的服务需求，并没有涉及通信机制，因此要实现一个完整的诊断通信还需要定义网络层协议（比如ISO 15765），还有底层硬件实现方式（比如CAN控制器）。由于不涉及网络通信机制，可以架设在各种网络之上，因此ISO 14229也称为UDS（Unified Diagnostic Services）。
- ISO 15765 协议是一种CAN总线上的诊断协议。ISO 15765 3 协议是按照 ISO 14229 1，描述了在 ISO 11898 定义的控制器局域网中统一诊断服务(UDS)的实施。它给所有汽车连接至CAN网络服务器及外部测试设备提供诊断服务及服务器存储器编程的需求。
- ISO 17987 其中定义LIN通信相关部分。
- IEEE 802.3是工作组和工作组制定的电气和电子工程师协会 （IEEE）标准的集合，该工作组定义了有线以太网的物理层和数据链路层的介质访问控制 （MAC）。 这通常是具有一些广域网 （WAN）应用的局域网（LAN）技术。
- ISO 11898 CAN 国际标准。
- ISO 26262《道路车辆功能安全》国际标准是针对总重不超过3.5吨八座乘用车，以安全相关电子电气系统的特点所制定的功能安全标准，基于IEC 61508《安全相关电气/电子/可编程电子系统功能安全》制定。
4. 技术分析
4.1 什么是Bootloader
单片机正常运行时总是从固定地方取指令，顺序运行，这将对编写程序的人产生巨大的挑战，程序更新时需要使用烧录器等工具烧录，于是有人将程序设计成，由一个程序跳转到另一个程序，这个程序通常称作Bootloader，另一个叫做APP。
Bootloader程序常常具有通信接口和擦写内部存储空间的功能，可将需要更新的APP擦除，写入新的APP。有时会设计成相互跳转，技术也是可以实现的。有些为了保证程序不丢失，单独预留出备份区和出厂版本，出现某些错误时可以恢复到出厂版本或使用其他APP均可。
图1-2 Bootloader扩展流程
4.1 ECU的Bootloader
ECU是MCU的一种，专门用在汽车上。ECU经常会用在汽车零部件中，零部件密封性等要求都比较苛刻，并且装车，如果想取下零部件可能需要将车拆解才可以做到，这种行为是不被允许的，成本极高，操作复杂，因此大多主机厂（厂商）要求ECU具有升级功能，并且通过多年的积淀制定了行业标准UDS。
UDS简介：
UDS（Unified Diagnostic Services，统一诊断服务）诊断协议是用于汽车行业诊断通信的需求规范，由ISO 14229系列标准定义。应用于OSI七层模型的应用层（第7层），它只规定了与诊断相关的服务需求，并未涉及通信机制，所以，它可以在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet 和 K-line）上实现。
ISO 14229-1 定义了诊断服务，只有应用层，不涉及网络及实现。
ISO 14229-3定义了UDS在CAN总线上的实现。
诊断通信用于建立诊断仪与ECU之间的通信连接，并负责将ECU中的诊断结果输送到诊断仪中。
UDS的作用非常广泛，几乎跟随ECU软件开发的全过程。
- ECU开发过程要用到它来构建bootloader，上传和下载数据，即软件刷写，控制器Reset；
- 测试时要用它来读写存储，控制外设；
- 产线上，要用它来校准机械件，控制例程，进行下线执行器测试，刷新软件，配置防盗，读取号码，下线配置等。
- 在行驶过程中，要用它来监测各种故障，并记下故障码；
- 4S店里，技师需要读取当前故障、历史故障，读取故障发生时刻环境信息状态，清除故障，判断故障发生点，还可以用来升级ECU程序。
汽车明确规定通过UDS进行更新程序，主机厂要求擦写内部存储的代码不可写入正常代码中。汽车电子中ECU一旦设计完成，装车量产就很难再拆卸并返回零部件供应商完成功能升级或补丁修复。一旦出现售后质量问题，如果召回的话，零部件供应商和整车厂将面临严重的经济损失，因此设计基于CAN总线的ECU在线程序更新Bootloader可以很好的解决这一问题，将零部件供应商和整车厂的损失降低到最小。目前国外大部分汽车整机厂（主机厂）和全球的一级汽车零部件供应商 (Tier 1) 都要求在其设计的ECU实现Bootloader功能。
图1-3 Bootloader简易框图
假如使用CAN，框架则会设计成如图1-3。
4.2 Bootloader框架
Bootloader由主机厂或者自己，可以选择用或者不用，本次主要针对使用Bootloader情况进行分析。主机使用协议由自己进行定义，ECU启动模式选择由芯片厂商进行技术支持（如果没有厂商支持是不可以的，是不被主机厂认可的，大多数是购买商业软件包，由服务商进行技术支持与芯片厂商共同支持的）。内部编写均需要遵循协议，大多数开发都是由多年开发经验沉淀下来，修改而成的，协议依然在进步，代码可能无法维护而无法支持，主机厂也会被迫选择使用旧版协议。
图1-4 Bootloader架构
4.3 ECU Bootloader原理
主机厂规定不可把擦写内部代码的功能直接写入程序中，因此，只能每次用时才能将代码放入ECU，ECU内部可以有Bootloader，但不可以有擦写内部代码的功能，擦写代码的功能称作NVM (None Valitale Momory–非易失性存储器)驱动程序。
图1-5 NVM驱动示意图
主机将NVM驱动程序下载到RAM区域，用NVM驱动程序对内部NVM进行擦除写入新数据等，在最后跳转即可完成更新。
UDS服务设计复杂，Bootloader升级一般分为三部分：
- 预编程：主要进行一些环境配置
- 编程： 刷写过程
- 刷新完成：恢复配置
Bootloader可以保证在上述三个阶段任一问题出现都能再次进入该过程重新刷新。 - 预编程阶段
在进入刷新之前，UDS的85服务和28服务，关DTC和非诊断报文。使整个CAN网络处于安静的状态。这是对整车网络进行操作的，一般都是以功能寻址的方式来发送。注意先用85服务关闭DTC，再使用28服务关报文。通常都会关闭故障码保存，关闭CAN通信是为了加快刷写速度，过程如下：
图1-6 预编程流程
5. 编程阶段
图1-7 编程流程
UDS设计了安全访问功能，安全访问是为了保证ECU数据的安全，实现方式是由ECU发送一个种子到主机，主机通过dll文件算法算出结果与ECU算出结果进行比对，结果一致则解锁成功通过安全验证。ECU解锁可以存在多个等级。
写时候先写DID指纹，标记写软件人的身份（按照主机厂要求），擦写下载等操作。
7. 编程结束
刷写完成之后，ECU进行重启，重新进入扩展会话，打开之前关闭的配置即可。
4.4 策略
策略是对主机和ECU流程设计的，分为主机的策略和ECU Bootloader的策略，有些为了避免出现问题设计复杂策略。
图1-8 主机策略
图1-9 ECU策略1
图2-1 ECU策略2
图2-2 ECU更新流程
这里ECU有两种方式，一种可以把程序拷贝到RAM，另一种是直接下载到RAM。依据这个原理可以实现Bootloader更新下一个Bootloader，再由新更新的Bootloader去执行上文所述的步骤，这个就是Bootloader更新，国内基本没有人这么做，首先ECU资源很少，其次多了一个步骤增加了出错概率，开发周期也增加，测试更加繁琐。
5. 实现
5.1 Bootloader应用逻辑
应用逻辑通过接口的抽象函数写成状态机类似标准化代码，这部分逻辑固定，不会随下面接口实现而影响（绝大部分情况）。
5.2 UDS服务
UDS服务为了统一标准，所以实现时可以成为通用代码，可以多项目复用，即使UDS标准更新，改动也不会很大。
5.3 传输协议
传输协议相对固定，虽然不同的设备有些差异，通信标准都遵循各种协议。可与下层硬件接口进行对接，以保证上层应用不需要改变。
5.4 工具
现在代工具的发展极大的方便了开发，绝大多数的开发人员开发只是在学习如何使用软件，而不是再去实现一遍代码，如果再实现一遍成本极高，首先，协议有多种，编写的代码需要满足协议要求，协议依然需要花费巨大的精力进行理解参悟，一般配有专人进行解读，协议解读也存在不同的理解，其次，实现代码并不能保证其稳定可靠，这种是对安全的不负责任，需要进行比普通更长时间的更苛刻的测试。
Bootloader一般芯片厂商都提供代码和服务，但大部分选择购买商业软件包，不在这部分花费大量的时间精力，专注于应用的开发。虽然，有一些是自己开发，自己开发也是十分坎坷，需要懂各种协议的人员长时间理解协议，编写代码的人也需要过硬的架构能力，一个团队经过长时间的开发重构再开发积淀下的成果，成果大多成为通用代码，此部分代码绝不允许开发人员再次进行修改，仅供开发调用接口使用。
现在已然是图形化进行配置，生成代码，几乎很少有自己进行写代码，开发迅速稳定，协议相关软件图形化均符合，这对自己写代码开发的进行挑战，自己写代码开发是没人愿意再尝试的情况了。
5.5 实例
以NXP推荐设计简单讲解原理。NVM驱动NXP官方提供完整的实现函数库，不需要自行实现，实际开发中也是如此，大部分是对工具的使用，而不是从零开始开发功能。
- 使用脚本文件抽取指定ECU的NVM驱动代码，全部代码是以C语言const数组存储。
- 将NVM驱动函数地址存储在指定地址作为 NVM 驱动函数地址表。
- 因为全部使用const关键词修饰，全部存储在常量区域，只读数据段，修改链接文件将只读数据段固定到RAM设定地址，则NVM驱动编译后存储在RAM区域，生成S19文件。
- 从得到的S19文件分离出NVM驱动和NVM 驱动函数地址表的S19文件，称为NVM 驱动S19文件
- 将NVM 驱动S19文件与应用S19文件合并生成完整的Bootloader。NVM 驱动S19文件需要保持在整个文件的开始，以保证系统能够正常运行找到NVM驱动。
NVM驱动是NVM 独立驱动是灵活可裁剪的。 因此可以根据 Bootloader 的功能选择必要的 NVM驱动函数，从而减少其占用的 RAM 空间，以适应小RAM尺寸的ECU(比如 1KB RAM 的ECU 系列)， 当然还需要改变其编译地址和 NVM 驱动函数映射地址表。
6. 总结
虽然是一个比较复杂的问题，在分析问题时，将问题分解，比如，整个Bootloader分为通信、存储等，梳理过原理之后，可以预测到代码实现逻辑，再追踪定位，验证预测。为保证安全提出并实现了一种基于总线通信将NVM驱动程序由上位机下载到 RAM 中运行而非让其驻留于ECU片上FLASH的安全Bootloader 设计，有效避免了应用程序跑飞运行至驻留于片上 FLASH的NVM驱动代码所造成的程序/数据丢失失效。但对于汽车上不是一朝一夕能实现的，虽然单一功能简单，为了保证这个功能而设计很多框架用来保证，框架是各种协议的实现，难度极大，需要长时间积淀才能理解其中奥义。