目录
#0x31服务 $31 01 02 03（例程控制，校验编程完整性）
#0x10服务 $14 FFFFFF （清除所有的DTC故障码）
一、前言
这个系列的文章不会详细介绍关于UDS协议的具体细节，分享的重点是如何通过CANoe的CAPL实现自动化测试和刷写，如果有小伙伴不熟悉UDS协议的建议先去学习一下基础的知识，包括基本的刷写步骤和诊断原理、能够理解诊断报文非常重要！
这个系列会手把手教你如何使用CAPL实现bootloader，以及搭建一个自动测试框架和建立自己的诊断测试用例库，纯手打哦！
由于本人也是刚接触这块领域，也是在不断学习的过程，如果有不足请指点出来【感谢】。
二、UDS-Bootloader刷写基本流程
UDS-bootloader刷写一般分为三个阶段，预编程、编程、后编程。
1.物理寻址和功能寻址的区别
物理寻址：一对一发送，物理寻址只能与特定ID的某个ECU进行通信。
功能寻址：一对多发送，功能寻址CAN网络上的所有支持UDS协议的ECU都能接收到数据。
2.预编程阶段
预编程阶段主要是为刷写做准备，一般是进行下载前的安全条件检查、关闭非诊断网络通信、停止DTC更新、会话控制等。
#0x10服务 $10 01 默认会话控制
使用功能寻址发送该请求，为跳转到扩展会话做准备。
#0x10服务 $10 03 拓展会话控制
使用功能寻址发送该请求进入拓展会话，在该会话下进行DTC和通信设置。
#0x31服务 $31 01 02 03 检查编程前提条件
使用物理寻址发送该请求，这个请求会执行一个例程，主要是检查当前电压、车速等是否满足安全条件。
#0x22服务 $22 F1xxx
使用物理寻址，用该服务读取DID信息，包括上一次的编程日期、指纹信息、软件版本号、硬件版本号等等，不同的厂家有不同的要求。
#0x85服务 $ 85 02
使用功能寻址，为了防止在编程的时候会意外记录不必要的DTC，所以要在预编程阶段将DTC记录关闭。
#0x28服务 $ 28 03 01
使用功能寻址，为了防止在刷写过程中不相关的报文信息会干扰刷写，导致刷写不稳定，所以在预编程阶段要将非诊断通信全部关闭。
3.编程阶段
编程阶段主要是进入编程会话后进行安全解锁、写编程日期，最最重要的是下载FlashDriver和Application，具体的服务下面会详细介绍。
#0x10服务 $10 02 编程会话控制
使用物理寻址，发送请求后进入编程会话，在此会话下才能进行刷写相关操作。一般进入编程会话后程序会执行一次复位操作，使得程序从App跳转到Bootloader程序并停留bootloader进行程序刷新。
#0x27服务 $27 01 （请求种子）
使用物理寻址，发送请求，下位机会回复一个种子给上位机。
#0x27服务 $27 02 （发送密钥）
使用物理寻址，收到种子后会根据车厂的安全算法计算出一个密钥，然后通过该服务下发，下位机通过对比校验密钥的正确性，从而决定ECU是否解锁，只有解锁状态下才允许编程相关的服务执行（后面的文章会详细介绍）。
#0x2E服务 $2E F1xxx （写指纹信息）
使用物理寻址，该服务会向ECU写入指纹信息，包括诊断仪编号、变成日期等，不同厂家会有不同要求。
编程中最重要的三个服务：#0x34#0x36#0x37
#0x34服务 $34 xxx
使用物理寻址，该服务为请求下载数据，向ECU发送要刷写的数据地址和数据长度，ECU会校验地址和数据大小的合法性，没问题才能进行下一步的数据传输。
#0x36服务 $36 xxx
使用物理寻址，该服务为请求数据传输，刷写工具通过该服务向ECU发送固件，ECU会一边接收数据一边向FLASH写数据，循环往复直到数据发送完成，此时并不确定数据的正确性，接着往下看。
#0x37服务 $37 xxx
使用物理寻址，0x36服务将数据发送完成后刷写工具通过该服务请求退出数据传输，执行该服务意味着数据传输已经完成。
#0x31服务 $31 01 02 03（例程控制，校验编程完整性）
使用物理寻址，该请求会使ECU执行校验编程完整性的相关例程，如果校验结果跟上位机的结果不一致则应用程序无效。到这里编程阶段已经完成。
注意：所有的数据下载都是经过以上几个服务（0x34、0x36、0x37、0x31）实现，包括flashDriver和Application，不同的是数据和刷写地址，我们需要ECU在刷写的时候识别是写什么数据，从而选择不同的驱动。
4.后编程阶段
后编程阶段主要是在数据下载完成后恢复系统的网络通信和DTC更新，具体服务下面会详细介绍。
#0x11服务 $11 01 （软件复位）
使用物理寻址，固件传输结束并且通过编程完整性校验后发送该请求，执行一次软件复位，随后跳转到app运行。
#0x10服务 $10 03 （进入拓展会话）
使用功能寻址，复位进入到app运行后发送该请求进入拓展会话，准备恢复CAN网络上在预编程阶段关闭的网络通信和DTC更新。
#0x28服务 $28 00 03 （恢复非诊断网络通信）
使用功能寻址，发送请求重新打开被关闭的通信，使得ECU能重新接收其他的报文。
#0x85服务 $85 01 （恢复DTC刷新）
使用功能寻址，发送请求重新打开所有ECU的DTC更新。
#0x10服务 $14 FFFFFF （清除所有的DTC故障码）
使用物理寻址，发送请求清除旧版app记录的所有DTC故障码（该步骤不同车厂会有不同的要求，根据实际情况选择该步骤）
#0x10服务 $10 01 （进入默认会话）
使用功能寻址，发送请求，所有ECU恢复到默认会话模式。
最终效果如下：
三、总结与展望
到此整个bootloader的刷新已经完成，以上这些步骤只作为参考，实际情况会因车厂需求不同而有一定的变化，但是大差不差，一般就是这些步骤。
再次强调本文不会强调每个服务的具体细节，只是大概讲述整个刷写的流程，相当于是一个复习吧。这个系列的重点我会放在如何使用CAPL实现刷写和自动测试，后续我会持续更新，感兴趣的朋友可以关注下专栏，你们的关注和互动是我更新的最大动力哦【调皮】。
下一篇：《CANoe_UDS-boorloader 自动测试系列（三）基础功能：CAPL实现UDS协议下的CAN报文接收#解析#发送》
敬请期待！
如果这篇博客对你有帮助，请 “点赞” “评论”“收藏”一键三连 哦！码字不易，大家的支持就是我坚持下去的动力。
作者：小鸟鹏
联系方式：
邮箱：502756962@qq.com
2007
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
