车载MCU CAN UDS刷写流程(新手自学笔记,欢迎指正)

参考出处:

车载ECU的Bootloader流程 - 知乎

UDS基础知识介绍_uds功能寻址和物理寻址-CSDN博客

https://download.csdn.net/download/weixin_42555769/88652927

13:50:36:160 0x709 3e 00

//3E-会话保持服务

这个服务的目的是确保诊断服务或者之前激活的通信还处在激活的状态,可以保持当前的非默认(Default Session)会话,通过周期地发送请求帧来阻止自动跳转回默认(Default Session)会话。

13:50:37:160 0x709 3e 00

13:50:37:167 0x789 7e 00

//肯定响应

zeroSubFunction = 00 肯定响应

详解文章:

UDS-3E服务_uds 3e服务-CSDN博客

开始刷写:13:50:37:167

13:50:37:167 :--->准备进入Extended Session 

13:50:37:167 0x7df 10 03

13:50:37:178 0x789 50 03 00 32 01 f4                

//进入扩展对话

13:50:37:367 :--->准备进入Request Seed

13:50:37:367 0x709 27 01

13:50:37:379 0x789 67 01 04 47 27 13            //获取种子,计算密钥

13:50:37:379 :--->准备进入Send Key

13:50:37:381 0x709 27 02 9a c0 49 13

13:50:37:387 0x789 67 02                                //发送密钥

详解文章:【ISO14229_UDS_0x27服务详解】_27服务安全算法密钥78-CSDN博客

13:50:37:387 :--->准备进入Check Programming Precondition

13:50:37:387 0x709 31 01 df fd

13:50:37:397 0x789 71 01 df fd 00

//Bootloader会计算所有下载数据的校验和,此校验和将于31服务发送的Data进行比较。如果相同则认为数据可用。

13:50:37:397 :--->准备进入DTC Setting Type=Off

13:50:37:397 0x7df 85 02

13:50:37:407 0x789 c5 02                                    //ECU应停止诊断故障码设置

参考文章:【车载开发系列】UDS诊断---控制DTC设置($0x85)_关闭dtc存储时发送报文-CSDN博客

13:50:37:598 :--->准备进入Disable Non Diagnostic Communication

13:50:37:598 0x7df 28 01 01

13:50:37:608 0x789 68 01

                                                                               //Disable应用报文收发

13:50:37:798 :--->准备进入Program Session

13:50:37:798 0x709 10 02

13:50:37:818 0x789 7f 10 78

13:50:37:925 0x789 50 02 00 32 01 f4

                                                                                //通过10 02切换到ProgrammingSession。

详解文章:

UDS统一诊断服务【一】诊断会话控制0X10服务_uds诊断会话切换-CSDN博客

13:50:37:925 :--->准备进入Request Seed

13:50:37:925 0x709 27 05

13:50:37:932 0x789 67 05 00 01 cb 91

//请求种子

13:50:37:932 :--->准备进入Send Key

13:50:37:932 0x709 27 06 2d e7 76 dc

13:50:37:939 0x789 67 06

//发送密钥

13:50:37:939 :--->准备进入Erase Memory

13:50:37:939 0x709 31 01 ff 00 44 01 00 00 10 00 1c a8 68

13:50:37:971 0x789 7f 31 78

13:50:39:908 0x789 7f 31 78

13:50:42:877 0x789 7f 31 78

13:50:45:846 0x789 71 01 ff 00

//擦除RAM内的程序

13:50:45:849 :--->准备进入Request Download                

//通过34、36、37服务下载APP程序,即最终的mcu程序。

13:50:45:849 0x709 34 00 44 01 00 00 10 00 1c a8 68

13:50:45:861 0x789 74 20 0f fa

13:50:45:861 序号:1 长度(Bytes):4088

13:50:45:861 0x709 36 01

13:50:46:456 0x789 7f 36 78

13:50:46:471 0x789 76 01

13:50:46:471 序号:2 长度(Bytes):4088

13:50:46:471 0x709 36 02

13:50:47:067 0x789 7f 36 78

13:50:47:080 0x789 76 02

13:50:47:080 序号:3 长度(Bytes):4088

13:50:47:080 0x709 36 03

13:50:47:674 0x789 7f 36 78

13:50:47:699 0x789 76 03

//此处省略刷写内容。

13:55:28:900 序号:458 长度(Bytes):4088

13:55:28:900 0x709 36 ca

13:55:29:494 0x789 7f 36 78

13:55:29:518 0x789 76 ca

13:55:29:518 序号:459 长度(Bytes):4088

13:55:29:518 0x709 36 cb

13:55:30:111 0x789 7f 36 78

13:55:30:136 0x789 76 cb

13:55:30:136 序号:460 长度(Bytes):1728

13:55:30:136 0x709 36 cc

13:55:30:393 0x789 7f 36 78

13:55:30:403 0x789 76 cc

13:55:30:403 :--->准备进入Request Transfer Exit

13:55:30:403 0x709 37 01

13:55:30:429 0x789 7f 37 78

13:55:32:060 0x789 77 01 7b c6

//Upload Download functional unit总共定义了5个诊断服务,分别是:

RequestDownload (0x34):客户端向服务器请求下载数据

RequestUpload (0x35)客户端向服务器请求上传数据

TransferData(0x36) 客户端向服务器传数据(下载),或者服务器向客户端传数据(上传)

RequestTransferExit(0x37)数据传输完成,请求退出

RequestFileTransfer(0x38) 传输文件的操作,可以用于替代上传下载的服务。

        引用出处:统一诊断服务 (Unified diagnostic services , UDS) (七) - 程序员大本营

13:55:32:060 :--->准备进入Check Programming Integrity

13:55:32:060 0x709 31 01 df ff

13:55:32:088 0x789 7f 31 78

13:55:32:259 0x789 7f 31 78

13:55:32:402 0x789 7f 31 78

13:55:32:467 0x789 71 01 df ff 00

//通过31服务检查APP程序的数据一致性和完整性。

13:55:32:467 :--->准备进入Check Programming Dependencies

13:55:32:467 0x709 31 01 ff 01

13:55:32:494 0x789 7f 31 78

13:55:32:526 0x789 71 01 ff 01 00

//通过31服务请求目标ECU运行一个例程,检查所有下载的软件部分的依赖关系。

13:55:32:526 :--->准备进入Hard Reset

13:55:32:526 0x709 11 01

13:55:32:532 0x789 51 01

13:55:37:532 :--->准备进入Default Session

13:55:37:532 0x7df 10 01

13:55:37:545 0x789 50 01 00 32 01 f4

//进入默认会话

13:55:37:732 :--->准备进入Clear Diagnostic Information

13:55:37:732 0x709 14 ff ff ff

13:55:37:774 0x789 7f 14 78

13:55:38:034 0x789 54

//清除诊断信息

参考文章:

汽车UDS诊断之清除诊断信息服务(0x14)深度剖析_cdtcipr-CSDN博客

刷写完成:13:55:38:622

刷写总耗时:301s

刷写App平均速度:51.57 kbps

  • 11
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
LabVIEW是一种图形化编程语言,常用于数据采集、控制和监测等工程领域。CAN(Controller Area Network)和UDS(Unified Diagnostic Service)是用于汽车电子系统的通信协议。刷bootloader是指将设备的bootloader固件升级或修改。 要通过LabVIEW来刷CAN UDS Bootloader,可以按照以下步骤进行: 1. 准备硬件设备:LabVIEW开发环境、CAN接口卡和适配器、可工作的目标设备以及相应的CAN UDS Bootloader固件。 2. 在LabVIEW中创建一个新的项目,然后添加CAN通信和UDS相关的库函数。这些库函数通常由硬件设备厂商提供,可以通过导入库文件或使用现成的API函数实现CAN通信和UDS协议。 3. 在LabVIEW中编写代码来实现对目标设备的CAN UDS Bootloader升级。首先,通过CAN接口卡与目标设备建立CAN通信连接。然后,使用UDS协议与目标设备进行通信,发送相应的命令和数据来进行bootloader的刷写。 4. 调试和验证:在LabVIEW中,可以使用调试工具和示波器,对通信过程和数据进行监测和分析。确保数据的正确性和Bootloader固件的刷写成功。 需要注意的是,CAN UDS Bootloader的刷写过程可能涉及额外的安全验证和权限控制,以防止未经授权的固件刷写。在实际应用中,需要遵循相关的安全要求和规范,并按照设备厂商的文档和指南进行操作。 总结而言,通过LabVIEW实现CAN UDS Bootloader的刷写需要合适的硬件设备和相关库函数的支持。编写LabVIEW代码来建立CAN通信连接和发送UDS指令,实现相应的Bootloader固件刷写。最后,通过调试和验证来确保刷写过程的成功。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值