基于UDS的Bootloader上下位机设计.pdf

SOFTWARE软 件2023第 44 卷 第 7 期2023 年Vol.44,No.7湖北省自然基金项目：机电磁液热耦合系统的一体化瞬态数学建模与计算方法研究（2021CFB592）作者简介：杨朝阳（1971），男，湖北十堰人，博士，副教授，从事汽车电子、无人驾驶方面的研究工作。基于 UDS 的 Bootloader 上下位机设计杨朝阳 黄凯旋 仝秀峰 闫永鑫（湖北汽车工业学院汽车工程学院，湖北十堰 442002）摘要：本文针对 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 通信中图分类号：TP311.1 文献标识码：A DOI：10.3969/j.issn.1003-6970.2023.07.011本文著录格式：杨朝阳,黄凯旋,仝秀峰,等.基于UDS的Bootloader上下位机设计J.软件,2023,44(07):042-047Design of Bootloader Upper and Lower Computer Based on UDSYANG Zhaoyang,HUANG Kaixuan,TONG Xiufeng,YAN Yongxin(School of Automotive Engineering,Hubei University of Automotive Industry,Shiyan Hubei 442002)【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 users 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 标准43杨朝阳 黄凯旋 仝秀峰等：基于 UDS 的 Bootloader 上下位机设计的 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 所示。上位机Bootloader烧录软件USB2CAN下位机Bootloader程序图 1 Bootloader 系统总体结构Fig.1 Overall structure of the Bootloader system1.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 硬件配置由于上位机端主要提供通用的输入输出接口（如44软 件第 44 卷 第 7 期SOFTWAREUSB、串口等），而不直接提供 CAN 接口。为了在电脑与单片机之间实现 CAN 通信，需要使用专门的硬件适配器或接口设备，如 USB2CAN、Vector VN1610 和ZCAN_USBCAN_200U 等，如图 3 所示。在实现 CAN通信之前，用户点击 Connect 按钮，用户可以通过 UI界面获取用户输入的硬件设备信息，根据设备类型、设备索引号打开相应的设备，并初始化 CAN 通道，完成驱动的配置。图 3 上位机硬件通信设备Fig.3 Hardware communication equipment of host computer2.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 空间，且控制逻辑复杂。AppBootBootBoot+AppBoot+App1+App2App1BootApp2图 4 Flash 内存划分方式Fig.4 Flash memory partitioning为了满足不同系列AC78xx控制器的需求，本文对小容量Flash选择Boot+App方式的Flash划分管理方法，大容量Flash选择Boot+App1+App2的方式。以 AC78013控制器为例，AC78013 的存储器由一个 20Kbyte 的静态 SRAM 和一个高达 128Kbyte 的 Flash 存储器组成，属于小容量 Flash。将 AC78013 的 Flash 0 x08000000-0 x080077FF 地址的 30K 作为 Bootloader 代码存储区域，将 0 x08007800-0 x08007FFF 的 2K 作为配置字段，用于存储更新 App 程序的标志位和刷写软硬件版本号等易倍思设备信息设备类型设备索引号CAN索引号数据波特率仲裁波特率ZCAN_USBC005000kbps1000kbps烧录设置connect文件路径展示烧录进度展示resetCRC烧录检验类型CRC0%调试信息清除选择文件图 2 上位机用户交互界面Fig.2 User interface of host computer45杨朝阳 黄凯旋 仝秀峰等：基于 UDS 的 Bootloader 上下位机设计信息。将 0 x08008000-0 x0801FFFF 的 96K 作为 App应用程序的存储区域，如图 5 所示。AppConfigBootloader0 x0802 00000 x0800 80000 x0800 78000 x0800 0000图 5 Flash 区域划分Fig.5 Flash area partitioningBootloader 是固化在整车网关等 ECU 微控制器的内部 Flash 中某特定位置的一段程序代码，应用程序同样也是存储在内部 Flash 中，两者共同占据 Flash 存储空间，所以二者的存储地址要正确分配，避免重叠。在刷写 Bootloader 程序时，将 ID 文件中的 Flash 起始地址改为 0 x08000000，在刷写用户程序时，将 ID 文件中的 Flash 起始地址改为 0 x08008000，如图 6 所示。MEMORY FLASH(rx):ORIGIN=0 x08008000,LENGTH=96K RAM(xrw):ORIGIN=0 x20000000,LENGTH=20K MEMORY_B1(rx):ORIGIN=0 x60000000,LENGTH=0K图 6 用户 App 的 ID 文件修改Fig.6 ID file modification of user App3.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 所示。进入App升级程序结束更新App升级标志位开始复位跳转至用户App程序是是否否更新App标志位是否有效2s内是否有更新App升级标志位请求图 7 更新 App 标志位流程图Fig.7 Flow chart of updating App flag bit3.3 预编程阶段下位机在检查软件更新标志位有效后，进入预编程阶段9。预编程主要是做编程前的网络准备，主要内容包括：（1）检查升级前置条件；（2）提高刷写网络速度；（3）禁止其他 ECU 的网络报文并关闭 DTC 设置。上位机通过 10 01 服务请求使下位机进入默认会话层；通过 22 服务读取当前 ECU 状态信息，满足升级要求后请求 10 03 服务，使下位机进入扩展会话模式，获取 31、85、28 服务权限；通过 31 服务检查升级前置条46软 件第 44 卷 第 7 期SOFTWARE件，满足升级条件则继续进行 85、28 服务请求，禁用CAN 总线上各 ECU 的网络报文和 DTC 故障码检测。同时上位机在会话过程中通过 0 x3E 服务与 ECU 建立心跳，使 ECU 保持在当前的会话模式状态。3.4 主编程阶段完成预编程阶段后，Bootloader 的升级进入主编程阶段。主编程阶段的主要作用是将上位机下发的程序映像，刷写至下位机的 Flash 相应地址区域，主要包括：(1)进入特定的安全等级；(2)写入指纹信息；(3)下载用户程序映像，具体步骤如图 8 所示。开始10 02 服务 进入编程会话27服务 安全访问控制2E服务 写DID信息31服务 擦写Flash34服务 启动下载传输36服务 传输数据37服务 退出下载传输22服务写指纹信息结束否是程序镜像是否下载完成图 8 主编程流程图Fig.8 Process flow chart上位机通过 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 所示。易倍思设备信息设备类型设备索引号CAN索引号数据波特率仲裁波特率USBCANII00500kbps1000烧录设置文件路径展示烧录进度展示resetCRC烧录0%调试信息清除disconnectPTC_APP_V4_24_V3_1.srecDevice Connection Successfulstrted time1:16:55:27.679end time1:16:55:40.541The Burning Program Is Successful22检验类型CRC选择文件图 9 上位机刷写过程Fig.9 Brushing process of host computer经过多次刷写测试和调试验证，整个系统烧写过程运行稳定，能够在较短的时间内完成用户程序的更新。通过对不同大小 S-recode 文件的刷写测试，使用CANFD 的刷写速率是 CAN 刷写速率的 8 倍左右，如表 1 所示。同时采用了多种安全性和可靠性方案来保证烧录过程中的数据完整性和稳定性，例如，使用 CRC校验算法、异常处理机制等，避免因意外故障导致数据丢失或破坏。47杨朝阳 黄凯旋 仝秀峰等：基于 UDS 的 Bootloader 上下位机设计表 1 CAN 与 CANFD 刷写文件速率对比Tab.1 Comparison between CAN and CANFD file write rate刷写数据大小/KBCANFD 刷写时间/sCAN 刷写时间/s400.875.57590.856.85881.7012.935 结论本文遵循 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 systemC/Conferenceon Reconnaissance and Electronic Warfare System,2019.图 10 Flash 内存部分内容Fig.10 Part of Flash memory