萝卜小姐的整车第一弹—MCU 软件烧录及升级说明

术语

ROM
Read Only Memory

RAM
Random Access Memory

ECU
Electronic Control Unit

OBD
On Board Diagnostics

OTA
Over The Air Technology

IDE
Integrated Development Environment

概述

MCU也称为单片微控器，属于一种集成式电路芯片，主要包含CPU、只读存储器ROM和随机存储器RAM等。程序存储在ROM中，当系统上电时，CPU从ROM的起始地址读取到指令开始执行。ROM可以使其存储的数据固定不变，即使断电也能够保留数据，根据功能类型主要分为PROM、EPROM、EEROM、Flash ROM等几类。

软件烧录

MCU中Flash ROM在出厂时是空白的，需先将程序烧录到芯片中才可以正常运行。软件开发过程中通常使用MCU配套的IDE及调试器进行烧录，使用协议有SWD、JTAG等。完成程序开发后，可以直接使用数据文件(S19、HEX等)进行批量烧录，如下图：

软件升级

在装车完成后出现测试问题或软件需求出现变更，需要通过外部工具进行软件升级。除了部分安装在外部的ECU可以通过SD卡、USB等方式进行软件升级，其它车身内部的ECU通常使用OBD端口升级或者云服务器OTA远程升级。

软件烧录描述

系统描述

程序经过IDE编译生成目标代码，想要进行对MCU的软件调试，就必须使用调试器将目标代码下载到MCU中。在体系结构上MCU与PC机是完全相同的，也包括中央处理器，输入输出接口，存储器等基本单元，因而与PC机等设备的软件结构也是类似的。但是由于应用场合问题，MCU不具备标准的输入输出装置，受存储空间限制，也难以容纳用于调试程序的专用软件 。
不同的芯片有各自的调试器，例如Microchip芯片有ICD3，NXP芯片有PE，Infineon 芯片有MINIWIGGLER等，如下图：

同一个半导体制造商也会根据芯片系列配套不同的调试器。硬件在设计时需根据MCU型号预留相应的调试口，不同的芯片有不同的通信协议，常见的协议有JTAG、SWD等，例如PE调试器上有非常多的调试口，以适配不同的芯片，如下图：

系统框图

实际应用

以NXP芯片MPC5748为例，可以使用S32DS IDE结合调试器PE 进行软件烧录及调试。
1.完成代码编译
2.连接PE与目标板，上电之后PE蓝色与黄色灯亮表示连接正常，由于调试接口不是标准口，增加了转接线。

3.在S323DS上选择debug功能进行软件烧录。
4.程序下载成功后会进入调试界面，点击开始按钮可以进行程序调试，这样程序就已经下载到芯片中。

软件升级描述(Bootloader)

车载OBD升级

OBD接口为国际标准汽车通讯接口，是汽车电脑与外部通讯的标准接口，一般接口在汽车方向盘的下方，在容易接线的位置。同型号车型OBD接口位置不同，下图是OBD接口可能在的位置：
A区域：通用、大众、宝马、福持、丰田、现代、雪铁龙等品牌的绝大部分车型 ；
B区域：大众途安、进口笛克萨斯等少数车型；
C区域：东风雪铁龙少数车型等；
D区域：东风雪铁龙少数车型等。

当整车零部件需要进行软件问题需要升级时，可以通过OBD口进行升级，常用的协议是CAN。它是由研发和生产汽车电子产品著称的德国BOSCH公司开发了的，并最终成为国际标准ISO11898。CAN总线协议已经成为汽车计算机控制系统和嵌入式工业控制局域网的标准总线，并且拥有以CAN为底层协议专为大型货车和重工机械车辆设计的J1939协议。近年来，其所具有的高可靠性和良好的错误检测能力受到重视，被广泛应用于汽车计算机控制系统和环境温度恶劣、电磁辐射强和振动大的工业环境。常见OBD端口如下图：

零部件供应商需根据OEM规范开发软件升级包，PC端通过OBD口与车身相连接，上位机加载软件包发送到网关，再由网关转发至ECU完成升级。

系统框图

软件设计

整车上有各种不同的ECU，但是每个ECU需要有相同的升级流程，所以OEM会制定自己的软件升级规范，零部件供应商需根据对应的规范进行软件开发。通常规范基于汽车行业标准ISO14229，OEM在这个基础上增加自己的需求。

架构框图

一个可重编程的 ECU 包括两个可执行的软件模块： ECU 应用程序和引导程序。在常规操作时， ECU 执行的是应用程序。引导程序仅在应用程序启动下载修改版本的引用程序或系统中没有可用的应用程序时激活。

如上图所示，应用程序和引导程序占据了 Flash 的一个指定存储区域。当 ECU 执行引导程序或应用程序时，两个软件包都可以完整使用系统的 RAM 存储区。
引导程序使用了 UDS 的诊断服务，将其作为下载通信的协议。因此，引导程序须具有一个由 CAN 驱动、传输层和 UDS 协议层子集构成的通信协议。
将Bootloader再划分分为PBL(Primary Bootloader)跟SBL(Secondary Bootloader)，PBL负责正常启动引导，而SBL负责擦除及写入flash数据，为了防止意外擦除考虑SBL通过外部升级文件加载，划分图如下：

图中所示PBL已经存在于ECU中，SBL通过升级流程加载到RAM中执行。

上电流程

1. 上电之后在Boot层中判断是否存在升级请求，若存在升级请求，进入诊断的编程会话并准备开始升级流程，若不存在升级请求则继续往下执行。
2. Boot判断APP标志是否存在并有效，若应用层标志存在并有效，软件跳转到APP开始执行应用程序，若应用层标志不存在或者无效，程序继续保留在Boot中继续执行。

升级流程

基于ISO14229规范执行

1. 预编程阶段：检测当前点火状态、车速等条件，满足条件后才能开始升级流程。
2. 进入编程模式：通常上位机会在这个阶段执行读取BOOT版本号、写入刷新日期等OEM自定义操作。
3. 编程阶段：首先传输SBL文件，CRC校验通过之后擦除需要升级的flash数据块，再传输APP文件进行软件升级。
4. 后编程阶段：恢复整车网络状态并复位ECU。

VBF格式

基于不同的软件需求，零部件供应商需提供软件升级版，供ECU进行软件升级。在XX规范中，SBL及APP升级文件是必须的，根据不同的ECU还有标定数据、UI文件等。
在某规范中升级文件格式要求必须是VBF2.5格式，VBF文件是基于S19或HEX等可烧写文件的基础上增加了一个文件头，主要包含版本信息、升级数据信息等，下图提供参考：

不同的VBF版本格式要求不同，具体格式需以释放为准。厂商会释放VBF格式转换工具，可以导入S19或HEX文件转成要求的VBF文件格式。

升级上位机

PC端上位机通过CAN与ECU进行通信，根据固定的升级流程执行，下图只供参考：