UDS刷写--文件下载参数说明

最新推荐文章于 2024-12-23 14:10:03 发布
原创 最新推荐文章于 2024-12-23 14:10:03 发布 · 501 阅读 · 6 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#c++ #java

  1. 擦除指令 31，可用例程服务31代替(这里可以选择不擦除，用例程服务31+擦除地址和长度等信息代替)；
  2. ● 擦除内存参数说明：

名称

功能说明

不擦除

不擦除内存

分块擦除

按设置块大小擦除内存

总擦除

擦除Flash所有内存

 

● 参数类型+擦除指令：默认31 01 FF 00，可以修改

名称

功能说明

自定义参数

按照擦除指令设置发送

带地址类型，地址，长度

擦除指令+地址类型+地址信息+长度信息

带地址，长度

擦除指令+地址信息+长度信息

● 应答校验：擦除指令31的校验，默认71 01，可以手动填写

2.请求下载 34

 ● 传输方式参数说明

名称

功能说明

34标准流程

34+36(01.02.03...FF...)+37

多个34，一个37

34+36(01.02.03...FF...)+34+36(01.02.03...FF...)...+37

● 拆分最大块：将文件拆分，设置块大小，分块刷；默认0是不拆分；

34块延时：每个34指令收到74响应，再发34的延时；

36块延时：每个36指令收到76响应，再发36的延时；

3.流控设置

 

● Bstime：每个块之间的延时，默认按照ECU的流控；可以用自定义手动设置。

● Tx_STime：发送的最小时间，默认ECU流控；可以用自定义手动设置。

4.34请求下载

 

● 34请求数据格式：默认 ”00“，可手动设置。

● 地址格式：勾选时34指令后面加上地址格式(如：34 00 44+)，默认”44“，可手动设置。

● 结束请求37+：37结束下载指令，请求可以手动设置。

● 校验应答77

5.36数据下载

● 36固定总长：固定36一次最大传输长度。

● 36传输序号：设置36传输要按照”块序号“传输。

● 起始值：传输序号起始值。

● 大端(小端)：传输数据字节顺序，大端是高字节在前，小端是低字节在前。

● 补全块：补全不连续的块。

6.校验地址格式：校验指令的地址格式。

7.导入刷写文件，支持 .hex/.s19/.bin/.app

● 重新加载文件：刷新加载文件。

● 计算校验值：计算块校验值。

8.下载文件地址，长度和校验值管理

 

● 合计：全选所有块序号。

● 地址信息：地址信息和长度信息可以手动填写，默认加载 .hex/.s19文件自动识别。

● 校验值：37指令的校验值，可以手动填写。

 

COOLDAY666
关注
UDS系列-31服务（Routine Control）
诊断协议那些事儿's blog
06-18 6323
客户端使用 RoutineControl(例程控制)服务执行指定的步骤顺序并获取任何相关结果。该服务具有较大的灵活性，但一般应用可以包括清除内存、重置或学习白适应数据、运行白检、覆盖正常的服务器控制策略和控制服务器值随时间而变化，以及预定义序列(如关闭敞篷车顶)等。在一般情况下，将该服务用于控制输出时，该服务可用于更为复杂类型的控制，而 inputOutputControlByldentifier (按标识符的输入输出控制)却用于相对简单(如静态)的输出控制.
UDS诊断服务基础详解之七-31服务
车载网络小D的博客
09-28 4875
本节内容主要是讲解诊断服务中的31服务，包含31服务的使用场景，请求报文格式，响应报文格式，以及举例对31服务进行相关的说明
uds下载服务流程图_UDS—ECU刷写
weixin_39964391的博客
12-23 1898
刷写，顾名思义就是两个动作：刷和写：刷是擦除ECU芯片内存上原有的数据；写是重新在ECU芯片内存上写入新的数据(Applicationor Calibration Data……)； 在控制器量产之初，会将valid application data烧录到控制器芯片内存上。但随着时间推移，控制器中运行代码出现Bug或者更新控制器功能(比如车载娱乐系统中导航地图更新)，需要更新...
汽车网络安全基础知识：UDS刷写详细流程，威胁及防御
2301_76563067的博客
08-30 1万+
刷写前，刷写工具读取 ECU 的 Boot 软件版本号(F180)、软件版本(F188)、 VIN(F190)、 硬件版本(F191)，根据从 ECU 获取到的相关信息到刷写数据库中查找对应的升级文件。如果不是连续的，刷写设备应该为每个要刷写的数据块发送一个单独的请求。检查刷写的数据的完整性，确定来源合法，通过CRC、哈希、数字签名等方法，保证刷写过程中不会出错，且刷写的数据是来自合法的提供者。检验刷写的数据的可靠性，在软件/数据刷写完毕时，刷写设备通过例行程序服务来验证刷写到内存区域的每块数据是否成功。
UDS
qq_25126391的博客
10-06 6365
UDS(ISO 14229-1&ISO 15765-2) U 可以基于任何总线 VIN :车辆识别号，是主机厂对一辆车的唯一标识码，是在下线检测的时候写入到ECU当中 诊断的作用：读取软硬件版本号，故障检测，程序升级刷写，下线检测，IO控制（比如雨刮器的耐久测试） UDS 定义了一种C/S架构的诊断响应机制 OBD: 与排放相关的，可支持CAN LIN K ，主要与法规相关 UDS是应用层协议，与底层的通讯介质不相关，所以可以在任何形式的通讯介质上实现 UDS 也是参考ISO 七层网络协议模型：每一
ODX-D诊断文件中UDS服务ClearDiagnosticInformation详解
一直在水些技术小文
11-16 261
ODX，全称Open Diagnostic data eXchange，是一种用于描述汽车电子系统和网络的标准格式。它被设计为不同诊断工具之间的通用交换格式，旨在提高不同制造商之间的诊断数据的兼容性和可交互性。本文深入介绍了ODX的基本概念，阐述了UDS诊断服务中的ClearDiagnosticInformation，并演示了在ODX-D诊断描述文件中如何描述这一服务。
CAN数据记录仪-UDS刷写--文件下载参数说明
gududeshui的博客
12-23 667
● 地址格式：勾选时34指令后面加上地址格式(如：34 00 44+)，默认”44“，可手动设置。● Bstime：每个块之间的延时，默认按照ECU的流控；● 拆分最大块：将文件拆分，设置块大小，分块刷；● 应答校验：擦除指令31的校验，默认71 01，可以手动填写。● 结束请求37+：37结束下载指令，请求可以手动设置。36块延时：每个36指令收到76响应，再发36的延时；● 34请求数据格式：默认 ”00“，可手动设置。● 校验值：37指令的校验值，可以手动填写。● 计算校验值：计算块校验值。
精选资源
基于PCAN的UDS-Bootloader软件刷写上位机Qt源码
04-09
在探讨基于PCAN（PCA9221）的UDS（统一诊断服务）Bootloader软件刷写上位机Qt源码之前，我们首先需要了解UDS协议和PCAN接口的基本概念。UDS是汽车诊断通信标准ISO 14229-1，它定义了车辆诊断服务的请求和响应消息...
UDS诊断刷写--刷写文件(app.hex)的地址不连续
gududeshui的博客
11-11 344
正常情况下ECU的刷写地址都是连续的，一个完整的刷写块有起始地址和刷写长度，诊断刷写仪根据地址信息和刷写长度往该内存写数据。第一块：比如要刷写文件的第一块的起始地址是0x08006000，擦除长度和刷写长度是0x4000，参数填写如下：擦除选择总擦除或分块擦除+擦除参数类型(31发送擦除指令)-->34请求的格式设置-->36下载设置-->37校验。第二块：起始地址是0x0800a100，擦除长度和刷写长度是0x1000，参数填写如下，此时第二块和第一块地址不连续。以此实现不连续地址的刷写需求。
UDS 简述 UDS简介
12-28
其实诊断通信的机制很简单，可以类比client-server通信方式，即客户端发送request，服务器收到request之后进行处理，然后向客户端发送response。但是，诊断协议有自己的特色，它规定了在request和response的格式，在收到request的时候要做格式的检查。同时由于寻址方式的不同，有无sub-function的支持等，也会影响request和response的处理方式和结果。下面将我就具体情况分析，尽量做到简介明了。
UDS文档的阅读
weixin_33862188的博客
05-27 258
通读一下，熟悉一下文档风格。 ISO 14229-1 UDS的需求和详细定义。ISO 14229-2 会话层（session layer）的服务。ISO 14229-3 UDS在can上面的实现。暂时没有看到太多的关于需求、实现或者测试相关的太多内容。 ISO 15765-1 UDS的基本信息和三中常见的应用场合。ISO 15765-2 UDS在can上面的关于传输层和网络层的信息。...
【UDS学习笔记】
weixin_43405695的博客
10-30 5606
UDS学习笔记
【AUTOSAR】UDS协议的代码分析与解读（十二）----UDS请求退出传输37h 请求文件传输 38h
hellotzx的博客
06-20 663
由于某种故障而拒绝诊断工具的下载操作时，发送此否定响应码。模块的下载过程中收到请求，发送此否定响应。83 请求退出传输服务的否定响应码。接收到此服务请求时编程进程没有完成。77 请求文件传输服务的否定响应码。如果报文长度错误，发送此否定响应码。如果报文长度错误，发送此否定响应码。81 请求退出传输服务的请求报文。82 请求退出传输服务的肯定响应。75 请求文件传输服务的请求报文。76 请求下载服务的肯定响应。.18.2 支持的否定响应码。请求下载或请求上传服务无效。以下情况发送此否定响应码。
五分钟搞懂UDS刷写34/36/37服务（内含S19文件解读）
欢迎来到eee的博客
03-29 9815
理论太多总是让人头昏，本文通过举例的方法学习刷写以及S19文件
UDS诊断入门学习资料
一树荼蘼的博客
10-22 3200
UDS诊断入门学习资料 学习资料: 1.统一诊断服务 (Unified diagnostic services ， UDS) （一） 2.统一诊断服务 (Unified diagnostic services ， UDS) （二） 3.统一诊断服务 (Unified diagnostic services...
【UDS诊断】——0x31服务
热门推荐
LOVE135149的博客
02-21 7万+
文章目录一、服务概述二、报文1.请求报文定义2.肯定响应3.报文讲解3.1格式及内容3.2举例 19服务作用是允许外部诊断仪（Client）通过该服务读取存储在ECU芯片内的故障码（DTC）状态信息 一、服务概述 二、报文 1.请求报文定义 2.肯定响应 3.报文讲解 3.1格式及内容 发 送： 19 +02+DTCStatusMask（状态掩码） 正响应： 59+02+DTCStatusAvailabilityMask（ECU支持的状态掩码）+DTC-状态位 3.2举例 ①：DTC DIDs(随便举的
UDS诊断（ISO14229-1） 31服务
m0_56208280的博客
01-15 2万+
31服务，即 RoutineControl（例程控制）服务，该服务允许客户端使用 RoutineControl（例程控制）服务执行指定的步骤顺序并获取任何相关结果。
UDS诊断系列介绍13-31服务
initiallizer的博客
01-16 9801
31服务，即例程服务，其全称为RoutineControl service，可以通过诊断仪/上位机通过相关诊断命令发起对例程的启动、停止或获取例程执行的结果。
CAPL UDS刷写.bin文件
最新发布
09-23
<think> 我们正在讨论如何使用CAPL进行UDS刷写.bin文件的方法。根据之前的引用，特别是引用[2]，我们可以看到使用CAPL函数读取.bin文件并发送UDS请求（0x36服务）的基本步骤。同时，引用[1]强调了理解.bin文件组织结构的重要性，而引用[3]提到.bin文件解析相对简单（没有像S19或HEX文件那样的复杂结构）。 因此，我们可以总结出以下步骤： 1. **设置文件路径并打开文件**： - 使用`setFilePath`设置文件路径。 - 使用`openFileRead`以二进制模式打开.bin文件。 2. **读取文件内容**： - 使用`fileGetBinaryBlock`函数分块读取.bin文件的数据到一个缓冲区（例如数组）。 3. **发送UDS下载请求（0x36服务）**： - 将读取到的数据块通过UDS 0x36服务发送出去。注意，每个数据块可能需要按照ECU的要求添加地址信息和数据格式（通常需要指定内存地址和块大小）。但.bin文件通常不包含地址信息，所以我们需要事先知道要写入的起始地址，并在每个0x36请求中指定。 4. **退出传输（0x37服务）**： - 当所有数据发送完成后，使用0x37服务退出传输。 此外，需要注意的是，在刷写过程中可能还需要进入扩展会话、安全访问等步骤，但问题主要集中在.bin文件的解析和传输上。 下面我们按照这些步骤来详细说明。 ### 使用CAPL进行UDS刷写.bin文件的步骤 #### 1. 设置文件路径和打开文件 ```c char binFile[] = "D:\\刷写文件\\program.bin"; // .bin文件路径 dword fileHandle; // 设置文件路径（如果需要） // setFilePath(binFile); // 根据引用[2]，可以使用setFilePath设置路径，但openFileRead也可以直接使用完整路径 // 以二进制模式打开文件 fileHandle = openFileRead(binFile, 1); // 第二个参数1表示二进制模式 if (fileHandle < 0) { write("Error: 无法打开文件 %s", binFile); return; } ``` #### 2. 定义缓冲区并读取文件 通常，UDS下载服务的最大块大小受限于CAN报文的最大长度（比如8字节数据，但使用CAN FD则更长）。但实际中，0x36服务允许一次传输多个连续字节（具体数量取决于ECU的配置），因此我们可以定义一个较大的缓冲区（如1024字节），然后分块读取。 ```c byte dataBuffer[1024]; // 假设我们每次读取1024字节 dword bytesRead; dword totalBytesRead = 0; ``` #### 3. 循环读取文件并发送0x36服务 在发送0x36服务时，我们需要指定要写入的内存地址。通常情况下，.bin文件是从起始地址（如0x80000000）开始的连续二进制数据。因此，我们需要知道起始地址，并在每次传输中递增地址。 假设起始地址为0x80000000，那么每次读取一块数据后，我们就发送一个0x36请求，其中包含当前地址和该块数据。 ```c dword startAddress = 0x80000000; // 刷写的起始地址 dword currentAddress = startAddress; dword blockSize = elcount(dataBuffer); // 块大小，这里为1024 while ((bytesRead = fileGetBinaryBlock(dataBuffer, blockSize, fileHandle)) > 0) { // 注意：bytesRead是实际读取的字节数，可能小于blockSize（最后一次读取） // 构造0x36请求：格式为36 [地址][数据格式] [数据] // 假设地址格式为4字节，数据格式为32位（4字节地址），那么地址需要按大端或小端排列？ // 根据ECU要求，通常地址使用大端模式（高位在前） byte request[4 + bytesRead]; // 请求数据：4字节地址 + 数据 dword addrTemp; // 将地址转换为大端模式（高位字节在前） addrTemp = swapDWord(currentAddress); // 假设swapDWord函数实现大端转换 // 将地址放入请求的前4个字节 memcpy(request, &addrTemp, 4); // 将数据缓冲区复制到请求的后面 memcpy(request+4, dataBuffer, bytesRead); // 发送0x36服务请求 UDS_SendRequest(0x36, request, elcount(request)); // 自定义发送函数，需要实现 // 等待响应并处理（这里需要检查正响应，否则重试或报错） if (UDS_GetPositiveResponse() == 0) { // 发送失败处理，例如重试机制（后面会讨论） // 这里简单示例：重试3次 int retryCount = 0; while (retryCount < 3) { // 重发 UDS_SendRequest(0x36, request, elcount(request)); if (UDS_GetPositiveResponse() == 1) { break; } retryCount++; } if (retryCount >= 3) { write("错误：下载数据块失败！"); break; } } // 更新当前地址和已读取字节 currentAddress += bytesRead; totalBytesRead += bytesRead; // 显示进度 write("已发送: %d 字节", totalBytesRead); } ``` #### 4. 关闭文件和发送0x37服务 ```c closeFile(fileHandle); // 关闭文件 // 发送0x37服务退出传输 byte exitRequest[4]; // 0x37服务通常需要上传前面下载的数据长度（总长度）和校验和等，具体根据ECU要求 // 假设只需要总长度（4字节，大端） dword totalLength = totalBytesRead; dword tempTotal = swapDWord(totalLength); memcpy(exitRequest, &tempTotal, 4); UDS_SendRequest(0x37, exitRequest, 4); // 检查响应 if (UDS_GetPositiveResponse() == 1) { write("下载成功完成！"); } else { write("退出传输失败！"); } ``` #### 辅助函数：swapDWord（大端转换） 由于地址和长度通常需要大端模式（网络字节序），我们需要一个转换函数： ```c dword swapDWord(dword data) { return ((data >> 24) & 0x000000FF) | ((data >> 8) & 0x0000FF00) | ((data << 8) & 0x00FF0000) | ((data << 24) & 0xFF000000); } ``` ### 关键技术点说明 1. **地址递增**：.bin文件是纯粹的二进制数据，不包含地址信息，因此我们必须事先知道写入的起始地址，并在每次传输后递增地址。 2. **块大小选择**：块大小（每次读取和传输的字节数）应适应ECU的要求。通常，ECU会规定最大块大小，不能超过该值。另外，也要考虑CAN/CAN FD的传输效率。 3. **错误处理**：在发送0x36服务时，如果收到负响应，需要重试机制。上面的代码提供了一个简单的重试3次的示例。实际应用中，可能需要更复杂的机制，比如延时重试、记录错误日志等。 4. **大端模式转换**：在汽车电子中，大部分ECU要求地址和长度以大端模式传输，因此需要转换。 5. **0x37服务**：退出传输时，通常需要提供整个下载数据的长度（有时还需要校验和），具体格式需参考ECU的规范。 ### 注意事项 - 在开始传输之前，必须完成进入扩展会话（0x10 03）和安全访问（0x27）等步骤。 - 传输结束后，一般需要执行ECU复位（0x11）或检查校验和（0x31）等操作。 ### 相关问题 根据用户要求，生成相关问题： §§相关问题§§ 1. 如何确定.bin文件的刷写起始地址？ 2. 在CAPL中如何实现UDS的安全访问（0x27服务）？ 3. 使用CAPL进行UDS刷写时，如何处理大文件（超过100MB）？ 4. UDS刷写过程中，如何设计断点续传功能？ </think> ### 使用CAPL进行UDS刷写.bin文件的完整方法 #### 一、核心步骤详解 1. **文件路径配置与打开** ```c char binPath[256] = "D:\\ECU_Flash\\program.bin"; // 文件路径 dword fileHandle = openFileRead(binPath, 1); // 二进制模式打开 if(fileHandle < 0) { write("错误: 文件打开失败 [代码:%d]", fileHandle); // 错误处理 return; } ``` > 路径长度建议≥256字节避免溢出，返回值<0表示错误代码[^2] 2. **数据块读取与传输** ```c byte dataBuffer[1024]; // 缓冲区(大小匹配ECU块尺寸) dword blockSize = elcount(dataBuffer); // 动态获取数组尺寸 dword bytesRead; dword baseAddress = 0x08000000; // Flash起始地址(根据ECU确定) while((bytesRead = fileGetBinaryBlock(dataBuffer, blockSize, fileHandle)) > 0) { // UDS 0x36服务发送(地址+数据) UDS_Download(baseAddress, dataBuffer, bytesRead); // 自定义发送函数 // 地址递增 baseAddress += bytesRead; // 线性地址增长 // 进度更新 float progress = (fileGetPos(fileHandle) * 100.0) / fileGetSize(fileHandle); write("已传输: %.1f%%, 地址: 0x%08X", progress, baseAddress); } ``` 3. **退出传输与关闭** ```c closeFile(fileHandle); // 必须关闭文件描述符 // UDS 0x37退出传输(需包含校验和数据长度) byte exitData[4]; dword totalSize = fileGetSize(binPath); exitData[0] = (totalSize >> 24) & 0xFF; // 大端格式长度 exitData[1] = (totalSize >> 16) & 0xFF; exitData[2] = (totalSize >> 8) & 0xFF; exitData[3] = totalSize & 0xFF; UDS_Request(0x37, exitData, elcount(exitData)); // 触发退出[^2] ``` #### 二、关键技术实现 1. **UDS下载服务封装** ```c void UDS_Download(dword address, byte data[], dword size) { byte request[4 + size]; // 地址(4B)+数据 request[0] = (address >> 24) & 0xFF; // 地址大端格式 request[1] = (address >> 16) & 0xFF; request[2] = (address >> 8) & 0xFF; request[3] = address & 0xFF; // 复制数据 memcpy(request+4, data, size); // 发送0x36服务 UDS_Request(0x36, request, elcount(request)); // 等待肯定响应(0x76) if(!waitForResponse(0x76, 2000)) { // 2秒超时 write("下载失败! 地址:0x%08X", address); // 重试机制... } } ``` 2. **内存映射处理** ```c struct MemoryMap { // 多内存区域管理 dword startAddr; // 起始地址 dword endAddr; // 结束地址 dword blockSize; // 最大块尺寸 } memSectors[3]; // 初始化示例(假设AURIX多核MCU) memSectors[0] = {0x08000000, 0x0803FFFF, 2048}; // CPU1 Flash memSectors[1] = {0x08100000, 0x0811FFFF, 1024}; // CPU2 Flash ``` 3. **大文件处理优化** ```c // 使用分块定位避免全文件加载 dword chunkSize = 0x10000; // 64KB分段 for(dword pos = 0; pos < fileSize; pos += chunkSize) { fileSetPos(fileHandle, pos); // 跳转文件位置 dword readSize = min(chunkSize, fileSize-pos); fileGetBinaryBlock(dataBuffer, readSize, fileHandle); // 处理数据块... } ``` #### 三、刷写流程控制 ```mermaid graph TD A[1. 10 03进入扩展会话] --> B[2. 27 01安全访问] B --> C[3. 擦除存储区域] C --> D[4. 打开.bin文件] D --> E{是否还有数据?} E -->|是| F[读取数据块] F --> G[36服务下载] G --> H[检查响应] H -->|失败| I[重试机制] I --> H H -->|成功| E E -->|否| J[37服务退出传输] J --> K[11 01 ECU复位] ``` #### 四、注意事项 1. **地址对齐要求** 多数ECU要求4字节对齐，需校验地址偏移量： $$ \text{address} \mod 4 = 0 $$ 否则需填充空字节[^1] 2. **数据完整性验证** 推荐SHA-256校验： ```c byte calcHash[32]; cryptoHash(SHA256, dataBuffer, bytesRead, calcHash); // 与ECU返回的哈希比对 ``` 3. **刷写超时处理** 建议实现看门狗机制： ```c timer tTimeout; startTimer(tTimeout, 5000); // 5秒超时 // 在数据发送后检查 if(tTimeout.timeout()) { write("错误：ECU响应超时"); } ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值