SCI论文（www.lunwensci.com）:
摘 要：本文针对 AC78xx 系列单片机,参照整车厂和 UDS 服务诊断规范要求,设计了一种基于 UDS 规范的,以 CAN/ CANFD 通信方式的 Bootloader 上下位机升级方案。上位机以 Qt 5.14.2 为开发环境, 支持 Vector VN1610、USB2CAN、 ZCAN_USBCANFD_200U 硬件设备与下位机进行 CAN 或 CANFD 通信, 支持 S-Record、HEX、ELF 文件的解析与刷写。下 位机以 Eclipse CDT、arm-none-eabi-gcc 为集成开发环境, 将 Flash 划分为 Bootloader+Config+App 的形式, 通过检查 Flash 配置字更新用户 App 标志位的有效性来触发 App 程序的升级,且可通过更改 Map 文件选择下位机与上位机的通信方式 为 CAN 或 CANFD,整个升级过程严格遵从 UDS 协议规范。通过多次实车测试与验证,结果表明 ：该 Bootloader 上下位机方案实现了在 UDS 标准下基于 CAN/CANFD 通信的 Bootloader 升级,整个升级流程快速、稳定,并具有极高的拓展性,证明了该方案在 Bootloader 刷写过程中的可靠性和稳定性。
关键词：Bootloader ；UDS 诊断规范 ；CAN/CANFD 通信
Design of Bootloader Upper and Lower Computer Based on UDS
【Abstract】： This article focuses on the AC78xx series microcontroller, and refers to the requirements of the vehicle factory and UDS service diagnostic specifications. It designs a Bootloader upper and lower computer upgrade scheme based on the UDS specification, using CAN/CANFD communication mode. The upper computer uses Qt 5.14.2 as the development environment, supporting Vector VN1610, USB2CAN, and ZCAN_ USBCANFD_ 200U hardware device communicates with the lower computer through CAN or CANFD, supporting the parsing and writing of S-Record, HEX, and ELF files. The lower computer uses Eclipse CDT and arm-none-eabi-gcc as the integrated development environment, dividing the Flash into the form of Bootloader+Config+App. By checking the validity of the Flash configuration word to update the user's App flag bit, the upgrade of the App program can be triggered. The communication method between the lower computer and the upper computer can be selected as CAN or CANFD by changing the Map file, and the entire upgrade process strictly follows the UDS protocol specification. Through multiple actual vehicle tests and verifications, the results show that the bootloader upper and lower computer solution has achieved a bootloader upgrade based on CAN/CANFD communication under the UDS standard. The entire upgrade process is fast, stable, and has high scalability, proving the reliability and stability of the solution in the bootloader writing process.
【Key words】： Bootloader;UDS diagnostic specification;CAN/CANFD communication
0 引言
随着汽车行业的发展,以及汽车产品的不断更新迭代,导致整车电控单元软件的更新替换越来越频繁。由于车载控制器系统在汽车上的安装位置环境复杂,不易拆卸,通过传统的 SWD、JTAG、UART 等方式进行 升级需要额外地增加外部电路,不仅增加了制造成本, 也不利于整车布线 [1,2]。本文利用汽车整车厂预留在汽 车上 的 CAN/CADFD 总线接 口, 参考 ISO14229 标准的 UDS 诊断协议,并结合整车厂的相关诊断规范,设 计了一套基于 UDS 的 Bootloader 上下位机升级方案。 本方案的设计实现,使得对车载控制器软件升级时,不 需要额外增加外部电路,且不需要对控制器进行拆卸就 可以完成整个升级过程,大大提高了开发效率和软件升 级的便捷性,同时保证了升级过程的稳定性和安全性。
1 Bootloader 系统总体设计
1.1 Bootloader 原理
Bootloader 升级系统分为两个部分,第一部分是上位机编写 的 Bootloader 刷写软件, 通过 CAN/CANFD 通信方式与下位机通讯,更新下位机用户 App 升级标志 位,并将待刷写的用户 App 程序镜像通过 Vector 1610、 USB2CAN 等 CAN 分析仪设备传输至下位机。
第二部分是下位机的 Bootloader 程序,它是单片 机一上电就开始运行的一小段程序 [3],可以分为两个阶 段 ：第一阶段称为启动阶段,该阶段程序是由汇编语言 编写, 主要作用是设置堆栈指针 SP, 将程序计数器指 针 PC 指向 Reset_Handler 函数入口地址, 并将存放 在 Flash 中的程序段和数据段加载到 RAM,以及初始 化系统时钟,设置中断向量表的对应中断地址,再将程 序入口函数设为 Main,并引导程序进入 C 语言环境。 第二阶段程序通常由 C 语言编写,主要作用是初始化 Bootloader 阶段使用到的 CAN、Flash、看门狗、定 时器等硬件设备,检查是否更新用户 App 程序,负责 与上位机进行通信,并通过 CAN 通信方式将从上位机 下载得到的用户 App 程序镜像写入 Flash 的对应地址, 完成用户 App 程序更新后跳转到用户 App 程序的入口 地址,最终完成 Bootloader 功能。
本文遵循 UDS 通讯协议规范,上位机 Bootloader 刷写软件通过 USB2CAN 等设备向下位机发送指令和数 据, 下位机根据上位机发送的 UDS 服务请求作出响应, 从而实现用户 App 程序的更新。Bootloader 系统总体 结构如图 1 所示。
1.2 Bootloader 相关的 UDS 服务
UDS 通信协议是一种面向整车所有 ECU 的通信协 议,外部设备与汽车进行 CAN 通信时都需要遵循 UDS 协议标准 [4]。本文 Bootloader 升级系统就是基于 UDS 服务的 ISO 14229 协议框架下开发的,主要使用了以下UDS 服务 ：
(1) 10 服务 ：10 服务是诊断会话控制服务,该服 务又分为 3 个子模式 ：默认会话模式、扩展会话模式、 编程会话模式,通过切换不同的会话模式, ECU 可以 处于不同的服务请求状态,以便执行不同的诊断任务和 编程操作 [4]。
(2) 3E 服务 ：该服务的目的是确保诊断服务或者之 前激活的通信还处在激活状态,可以保持当前的非默认 会话,通过周期地发送请求帧来阻止下位机自动跳转回默认会话。
(3) 22 服务和 2E 服务 ：22 服务主要用于上位机 读取 ECU 中的存储数据,如 ECU 软件版本号等信息 ； 2E 服务用于写 ECU 的相关参数和配置信息,如指纹信息等。
(4) 31 服务 ：31 服务用于控制一个例程的开始、 结束和查看例程的执行结果。
(5) 85 服务和 28 服务 ：85 服务用于开启和关闭 ECU 的 DTC 诊断 ；28 服务用于开启和关闭 ECU 的 报文传输。在程序升级时,需要关闭其他 ECU 单元的 DTC 故障诊断,同时关闭其他 ECU 单元的报文传输, 以减小总线负载。
(6) 27 服务 ：27 服务主要用于需要对 ECU 写数 据时安全解锁。上位机向下位机请求随机种子,将接 收到的随机种子按照安全加密算法计算出一个 Key 值, 下位机接受来自上位机算出来的 Key 并与内部算出的 Key 比较,如果一致则解锁成功,否则解锁不成功。
(7) 34 服务、36 服务和 37 服务 ：34 服务主要用 于请求下载数据,上位机将待下载数据的长度和数据的 写入地址发送给 ECU。36 服务进行数据的传输操作 [5]。 37 服务用于 36 服务传输数据完成且校验正常后,上位 机发送 37 服务表示数据传输完成。
2 Bootloader 上位机软件设计
2.1 UI 界面设计
上位机支持 USB2CAN、Vector VN1610、ZCAN_ USBCANFD_200U 硬件设备与下位机进行 CAN/CANFD 通信。为方便用户调试,设计了一套交互界面供用户选 择不同的设备类型、索引号以及波特率等配置信息 [6], 程序通过获取 UI 界面用户输入的信息,进行相应的 CAN、CANFD 驱动配置。同时, 可通过 CRC、Reset 复选框,选择数据传输过程中的校验方式及对下位机的 复位操作。用户交互界面如图 2 所示。
2.2 硬件配置
由于上位机端主要提供通用的输入输出接口(如USB、串口等),而不直接提供 CAN 接口。为了在电脑与单片机之间实现 CAN 通信,需要使用专门的硬件适配器或接口设备,如 USB2CAN、Vector VN1610 和 ZCAN_USBCAN_200U 等, 如图 3 所示。在实现 CAN 通信之前,用户点击 Connect 按钮,用户可以通过 UI 界面获取用户输入的硬件设备信息,根据设备类型、设备索引号打开相应的设备,并初始化 CAN 通道,完成 驱动的配置。
2.3 文件解析与烧写
编译器生成的可执行程序通常无法直接烧录到单片 机上,需要将其转化为适用于直接烧写的格式文件 [7]。 为了适应不同编译器生成的文件,上位机软件需要编写 不同的接口函数,用于解析和烧写 S-Record、HEX 和 ELF 文件。这些文件均是常见的用于嵌入式系统编程和 固件更新的文件格式,包含了烧写程序的起始地址、数 据长度、数据内容和校验和等信息,可用于将程序或数 据加载到目标设备的内存中。上位机程序根据用户输入 的不同文件格式, 选择相应的文件解析方式, 以 2048 字节有效数据为一个数据包进行数据传输。
3 Bootloader 下位机软件设计
3.1 硬件平台配置
下位机 Bootloader 设计与具体的嵌入式系统硬件 密切相关 [8],本文是基于 AC78xx 系列单片机开发设 计 的。AC78xx 系列单片机是 以 ARM® Cortex-M3 为内核的车规级 MCU,主要应用于汽车电子和高可靠性 工业领域。配备先进的 CAN/CANFD 总线接口,丰富 的外设及大容量的 Flash, 适配灵活、功耗低、可靠性高。根据不同容量大小的 Flash,有以下两种划分内存 的方式,如图 4 所示。
3.1.1 Boot +App
该方案只有 Boot+App, 升级时跳转到 Boot 然后 擦除 App 进行升级,升级成功后跳转回 App 继续运行。 此方案占用 Flash 空间小,实现逻辑简单,但 App 没 有备份,擦除 App 后如果出现掉电等意外会导致异常, 对此需要做特殊处理。
3.1.2 Boot+App1+App2
该方案为 Boot+App1+App2, 即 App1 可 以运行 应用程序, App2 也可以运行应用程序, Boot 启动的时 候,判断当前是运行 App1 还是 App2,然后跳转至相 应的区域运行。升级时则是运行在 App1 时对 App2 进 行升级,运行在 App2 区时对 App2 区进行升级,也可 以跳转到 Boot 再对 App/ App2 进行升级。该方案因为 有两个区运行应用程序,当最新的区域代码存在异常, 可以切换回上一版本的区域进行运行,故而有很高的可 靠性,但 App 需要双倍 Flash 空间,且控制逻辑复杂。
为了满足不同系列AC78xx 控制器的需求,本文对小容 量 Flash 选择 Boot + App 方式的 Flash 划分管理方法,大 容量 Flash 选择 Boot+App1+App2 的方式。以 AC78013 控制器为例,AC78013 的存储器由一个 20Kbyte 的静 态 SRAM 和一个高达 128Kbyte 的 Flash 存储器组成, 属于小容量 Flash。 将 AC78013 的 Flash 0x08000000 - 0x080077FF 地址的 30K 作为 Bootloader 代码存储区 域,将 0x08007800 - 0x08007FFF 的 2K 作为配置字段, 用于存储更新 App 程序的标志位和刷写软硬件版本号等信 息。 将 0x08008000 - 0x0801FFFF 的 96K 作 为 App 应用程序的存储区域,如图 5 所示。
Bootloader 是固化在整车网关等 ECU 微控制器的 内部 Flash 中某特定位置的一段程序代码,应用程序同 样也是存储在内部 Flash 中,两者共同占据 Flash 存储 空间,所以二者的存储地址要正确分配,避免重叠。在 刷写 Bootloader 程序时, 将 ID 文件中的 Flash 起始 地址改为 0x08000000,在刷写用户程序时,将 ID 文件 中的 Flash 起始地址改为 0x08008000,如图 6 所示。
3.2 升级触发方式设计
进入 Bootloader 程序之后,需要检测用户 App 更 新标志位状态,判断是否需要更新用户 App。通常用户 App 更新标志位的置位方式有三种。
第一种方式是根据 ECU 在一定时间内是否接收到 正确的握手请求来判断是否启动用户 App 升级程序。 如果 ECU 在规定时间内收到了正确的握手请求,则会 进入用户 App 升级程序,否则将跳转至旧的 App 程序 入口地址。虽然这种方式逻辑比较简单,但是在 ECU 不需要升级时,它会导致 App 程序启动较慢,同时安 全性也相对较低。
第二种方式是通过检测 ECU 的 IO 管脚电平状态来 判断是否需要升级,这种方式虽然逻辑控制简单,但是整车上主机厂一般不会预留外部 IO 口给用户,因此这种 方式的应用情况较为有限,不适用于对整车控制器升级。
第三种方式是通过更新 Flash 页配置信息来检查是 否有需要进行 App 升级的标志位。若标志位有效,则 程序会进入 App 升级程序 ；若标志位无效则程序会判 断是否有来自上位机的更新 Flash 配置页信息请求,有 则更新 Flash 页配置信息,并进行单片机复位操作 ；若 没有接收到更新请求则跳转到 App 入口程序。
本 Bootloader 升级方案采用第三种方式。下位机 Bootloader 程序上电检测 App 更新标志位是否有效, 有效则进入 App 升级程序 ；无效则等待上位机程序刷新 App 升级标志位,下位机 2S 内收到更新 App 升级标志 位请求,则更新标志位并进行复位 ；超过 2S 就跳转至用 户 App 程序。此种方式的优点是能够保证 Bootloader 升级的可靠性和安全性,同时确保了用户 App 程序的 正常运行,避免了在升级过程中发生意外的情况。实现 方案如图 7 所示。
3.3 预编程阶段
下位机在检查软件更新标志位有效后,进入预编程 阶段 [9]。预编程主要是做编程前的网络准备,主要内容 包括 ：(1)检查升级前置条件 ；(2)提高刷写网络速度 ； (3)禁止其他 ECU 的网络报文并关闭 DTC 设置。
上位机通过 10 01 服务请求使下位机进入默认会话 层 ；通过 22 服务读取当前 ECU 状态信息,满足升级要 求后请求 10 03 服务,使下位机进入扩展会话模式,获 取 31、85、28 服务权限 ；通过 31 服务检查升级前置条件,满足升级条件则继续进行 85、28 服务请求,禁用 CAN 总线上各 ECU 的网络报文和 DTC 故障码检测。 同时上位机在会话过程中通过 0x3E 服务与 ECU 建立 心跳,使 ECU 保持在当前的会话模式状态。
3.4 主编程阶段
完成预编程阶段后, Bootloader 的升级进入主编 程阶段。主编程阶段的主要作用是将上位机下发的程序 映像,刷写至下位机的 Flash 相应地址区域,主要包 括 ：(1) 进入特定的安全等级 ；(2) 写入指纹信息 ；(3) 下载用户程序映像,具体步骤如图 8 所示。
上位机通过 10 02 服务请求使 ECU 进入编程会话 模式,以支持主编程阶段用到的其他服务。通过 27 服 务与下位机进行安全访问控制,上位机向下位机请求一 个随机种子 Seed,再根据安全加密算法计算出该 Seed 对应的密钥 Key1,并将 Key1 的值发送给下位机,下 位机也根据自己的加密算法得到 Key2,将 Key1 与 Key2 的值比较,相同则上位机通过安全访问请求,继 续后续服务请求 ；否则退出程序烧录。上位机继续发送 2E 服务向 ECU 的 Flash 配置页写入 DID 对应的数据。 再通过 31 服务擦除 Flash 的用户 App 程序存储地址, 通过 34 服务告知下位机将要刷写的数据内存地址和字 节数,通过 36 服务传输二进制用户 App 程序映像,以 2048 个字节大小作为一个传输数据块的最大传输单位,当一个数据块传输完成后,进行 37 服务,将发来的数 据块写入相应的 Flash 地址, 继续 34、36、37 服务, 直到所有程序映像传输完成。上位机通过 31 服务检查 下位机所下载的程序镜像的完整性和编程依赖性,再通 过 22 服务写指纹信息,完成主编程阶段。
3.5 后编程阶段
主编程阶段完成后, 通过 10 03 服务进入扩展会话 模式,通过 28 服务使所在 CAN 网络的电控单元恢复正 常通信。通过 85 服务打开记录 DTC 功能,允许 CAN 网络中连接的电控单元记录 DTC。再通过 10 01 服务恢 复控制器的默认会话,完成后编程阶段。
4 软件测试和实验结果
本文选择 USB2CAN 分析仪作为上、下位机 CAN/ CANFD 通信设备,上下位机 CAN 通信数据波特率都 设置为 500kbps(CANFD 通信的仲裁波特率为 4Mbps, 数据波特率设置为 500kbps)。点击烧录按钮,等待程 序烧录完成,如图 9 所示。在刷写完成后,使用 J-Link 内存查看工具,检查下位机写入 Flash 内容是否正确写 入 Flash 的对应地址,以确保烧写操作的准确性和有效 性,如图 10 所示。
经过多次刷写测试和调试验证,整个系统烧写过 程运行稳定,能够在较短的时间内完成用户程序的更 新。通过对不同大小 S-recode 文件的刷写测试, 使用 CANFD 的刷写速率是 CAN 刷写速率的 8 倍左右,如 表 1 所示。同时采用了多种安全性和可靠性方案来保证 烧录过程中的数据完整性和稳定性,例如,使用 CRC 校验算法、异常处理机制等,避免因意外故障导致数据 丢失或破坏。
5 结论
本文遵循 UDS 协议规范,基于 AC78xx 控制器通过 CAN/CANFD 通信方式, 实现了上下位机 Bootloader 升级 设计。上位机升级程序支持 Vector VN1610、USB2CAN 等硬件设备与下位机进行 CAN、CANFD 通信,支持 SREC 文件格式的用户程序镜像刷写,具有良好的兼容 性和灵活性。下位机可通过更改 Map 文件,实现与上位 机通信方式的选择(CAN 或 CANFD),以及对不同的AC78xx 系列单片机进行固件升级。测试实验表明,此 Bootloader 使用便捷, 擦写 Flash 过程稳定, 能实现 ECU 的固件升级功能,提高了目前汽车电子控制器软件下载更新的速率。同时,本方案严格遵循整车厂的诊断规范和刷写流程,确保这一设计方案可以适用于后期 的 FOTA 软件升级扩展,为用户提供更安全、更可靠、更高效的汽车软件体验。
参考文献
[1] 陈祖锐,廖振伟,谷城,等.基于UDSonCAN的Bootloader设 计[J].汽车零部件,2022,(9):36-39.
[2] 刘佳楠.汽车电子控制器硬件抽象与软件开发[D].成都:电子 科技大学,2012.
[3] 许化,黎蕾,倪云龙,等.基于TMS320F28335的二次Bootloader 在线升级方法[J].电子技术应用,2023,49(3):139-142.
[4] 陈佳臻.基于CANoe和ISO15765的ECU在线升级设计[J].电 子测试,2020(11):85-87.
[5] 袁帅,李瑜,苗坤怡,等.基于UDSonCAN的BootLoader上位 机开发[J].汽车实用技术,2020(15):97-99.
[6] 杨朝阳,阮海庭,罗永革,等.基于CAN FD的在线编程系统设 计[J].单片机与嵌入式系统应用,2019,19(5):21-24+28.
[7] 李浩,赵晨希,关冰.面向多核DSP的可靠二级Boot方法研究 [J].单片机与嵌入式系统应用,2021,21(11):22-26+29.
[8] 袁锋,丁元章,张伟,等.基于S32K148的车辆网关CAN Bootloader 开发与实现[J].汽车电器,2021(12):30-32+35.
[9] Bronislaw Wajszczyk.Analysis of Using a Micro Bazel Processor for Hardware Implementation of Algorithms for Data Processing in Electronic Recognition Devices and Systems Based on the Example of a XILINX FPGA system[C]//Conferenceon Reconnaissance and Electronic Warfare System,2019.
关注SCI论文创作发表，寻求SCI论文修改润色、SCI论文代发表等服务支撑，请锁定SCI论文网！
文章出自SCI论文网转载请注明出处：https://www.lunwensci.com/jisuanjilunwen/63447.html
