基于EcuBus-Pro实现LIN UDS升级

前言

• 基于EcuBus-Pro实现CAN UDS升级

之前分享了基于EcuBus-Pro实现了CAN UDS bootloader功能的文章，链接如上。当时手上没有合适的LIN工具以及开发板，所以LIN UDS bootloader功能的相关文章一直延期。

最近有在支持客户使用纳芯微的NSUC1612，该芯片自带ROM boot，并且符合LIN UDS协议，正好借这个机会，分享下如何基于EcuBus-Pro实现LIN UDS bootloader。

如果想要了解NSUC1612，可以点击下方链接进行查看：

• 单芯片驱动，解锁汽车智能执行器更高性价比！纳芯微推出全集成电机驱动SoC NSUC1612

1.搭建环境

1.1 开发板

使用纳芯微官方提供的NUSC1612评估板，如下所示：

1.2 CAN卡

使用EcuBus-Pro推荐的LinCable，介绍链接如下：

• https://app.whyengineer.com/zh/docs/um/hardware/lincable.html

2.工程配置

2.1 基础配置

1. 新建一个只有诊断帧的LDF文件，并导入数据库。

如下是一个LDF文件参考示例：

LIN_description_file;
LIN_protocol_version = "2.2";
LIN_language_version = "2.2";
LIN_speed = 19.2 kbps;Nodes {Master: LinCable, 1 ms, 0.1 ms ;Slaves:  ;
}Signals {
}Diagnostic_signals {MasterReqB0: 8, 0 ;MasterReqB1: 8, 0 ;MasterReqB2: 8, 0 ;MasterReqB3: 8, 0 ;MasterReqB4: 8, 0 ;MasterReqB5: 8, 0 ;MasterReqB6: 8, 0 ;MasterReqB7: 8, 0 ;SlaveRespB0: 8, 0 ;SlaveRespB1: 8, 0 ;SlaveRespB2: 8, 0 ;SlaveRespB3: 8, 0 ;SlaveRespB4: 8, 0 ;SlaveRespB5: 8, 0 ;SlaveRespB6: 8, 0 ;SlaveRespB7: 8, 0 ;
}Frames {
}Diagnostic_frames {MasterReq: 0x3c {MasterReqB0, 0 ;MasterReqB1, 8 ;MasterReqB2, 16 ;MasterReqB3, 24 ;MasterReqB4, 32 ;MasterReqB5, 40 ;MasterReqB6, 48 ;MasterReqB7, 56 ;}SlaveResp: 0x3d {SlaveRespB0, 0 ;SlaveRespB1, 8 ;SlaveRespB2, 16 ;SlaveRespB3, 24 ;SlaveRespB4, 32 ;SlaveRespB5, 40 ;SlaveRespB6, 48 ;SlaveRespB7, 56 ;}
}Node_attributes {
}Schedule_tables {
}Signal_encoding_types {
}Signal_representation {
}

2. 新建device并导入数据库的LDF，然后保存配置。

3. 在network界面新建一个LIN IA并和device绑定。

4. 转到诊断菜单，设置寻址方式和NAD，如果不确定NAD，可以使用广播地址，即0x7F。

2.2 服务配置

2.2.1 DiagnosticSessionControl(诊断会话控制)($10)服务

• 进入编程会话的配置如下：

2.2.2 ECUReset(ECU 复位)($11)服务

• 硬件复位的配置如下，这里使用硬件复位。

2.2.3 SecurityAccess(安全访问)($27)服务

• EcuBus-Pro对$27服务增加了配置，可以通过导入DLL文件的方式，避免使用脚本，配置如下：

文末网盘链接里System32文件夹的两个DLL，如果自身电脑C盘同名文件夹没有，需要复制过去，否则algorithm文件夹的GenerateKeyEx.dll无法被正确加载。

目前提供的DLL针对的是出厂默认配置的NSUC1612，实际使用时需要加载符合产品加密算法的DLL。

2.2.4 RoutineControl(例程控制)($31)服务

• RoutineID为0xFF00的配置如下，0xFF00用于通知ECU节点擦除Flash。

• RoutineID为0xFF01的配置如下，0xFF01用于通知ECU节点检查编程依赖。

• RoutineID为0xF001的配置如下，0xF001用于通知ECU节点检查内存完整性，主要是传输bin文件的CRC校验值，目前还需要脚本配合。

2.2.5 文件传输(包含$34、$35、$36服务)

• EcuBus-Pro对$34、$35、$36服务进行了整合，不需要脚本配合就可以实现bin文件传输，配置如下：

2.3 流程配置

整个LIN UDS升级的流程配置如下图：

整个升级流程相比CAN UDS精简了一些，流程图如下，详细过程就不赘述了。

3.功能实现及测试

3.1 准备工作

1. 在工程所在目录新建一个ts文件；

2. 将升级需要用到的文件放到工程所在目录；

3. 在UDS Tester加载该脚本文件，并打开vs code进行脚本编写；

3.2 脚步编写

该TS脚本主要实现的功能为：

• 读取需要升级的bin文件
• 按照约定好的算法计算出整个bin文件的校验值
• 将校验值通过$31服务传输给ECU

整个脚本文件的内容如下：

// 导入Node.js内置模块
import fs from 'fs/promises'  // 文件系统模块的异步版本，用于读取文件
import path from 'path'       // 路径处理模块，用于构建文件路径// 导入ECB模块中的CRC和DiagRequest类
import { CRC, DiagRequest } from 'ECB'// 初始化ECU测试程序
Util.Init(async ()=>{// 构建固件文件的完整路径// 使用环境变量PROJECT_ROOT作为基础路径，拼接firmware目录和project_rom_boot.bin文件名const fw=path.join(process.env.PROJECT_ROOT,'firmware','project_rom_boot.bin')// 异步读取固件文件内容const content=await fs.readFile(fw)// 创建CRC32_JAMCRC校验算法实例const crc= CRC.buildInCrc('CRC32_JAMCRC')// 计算固件文件内容的CRC32校验值const crcValue=crc.computeBuffer(content)// 创建诊断请求服务// 使用'NSUC1612_LIN_UDS_Tester.RoutineControl_routineID$F001'作为服务标识const service=DiagRequest.from('NSUC1612_LIN_UDS_Tester.RoutineControl_routineID$F001')// 设置诊断服务的参数// 将计算得到的CRC值设置为'routineControlOptionRecord'参数的值service.diagSetParameterRaw('routineControlOptionRecord',crcValue)// 执行服务变更，发送诊断请求await service.changeService()
})

3.3 测试效果

工程的测试情况如下：

4.数据解析

• 基于NXP例程学习CAN UDS刷写流程

之前借助EcuBus-Pro的log数据分析过CAN UDS刷写流程，如上链接。LIN的UDS刷写流程和CAN UDS刷写流程类似，有几点的细微差异。

• LIN的NAD都是放在数据段的第一个字节，整个传输层的格式如下：

• 在执行UDS协议时，LIN的数据段都是8个字节，不足8个字节会使用0xFF填充，校验和使用标准型校验和。

• LIN的UDS协议不需要流控帧，因为不管是请求还是应答，都是主机发起。

该工程的数据log解析如下：

5.工程分享

如上工程作者已打包上传至百度网盘，下载链接如下（后续会集成到EcuBus-Pro的自带例程中）：

• 链接:https://pan.baidu.com/s/11GUnTXkbiV0md370iONcBA
• 提取码:m4p9