基于UDS服务的BootLoader架构和刷写流程

Posted TaiChiDao

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了基于UDS服务的BootLoader架构和刷写流程相关的知识，希望对你有一定的参考价值。

基于UDS服务的BootLoader架构和刷写流程

1. BootLoader支持的UDS服务

  • bootloader 不需要支持19/14等故障类服务

  • 在boot程序中， 10/27/11/3E 这样的基础服务需要支持；

  • 22/2E读写DID的服务需要支持

  • 31/34/36/37这bootloader主打服务需要支持

  • 在app段程序中，85和28服务需要支持，保证暂停CAN正常通信，暂停记录DTC，让被升级设备专心升级。

    SIDISO 14229功能描述
    0x10DiagnosticSessionControl外部设备切换会话模式
    0x85ControlDTCSetting打开或关闭DTC
    0x28CommunicationControl打开或关闭CAN报文
    0x27SecurityAccess解锁ECU
    0x34RequestDownload请求命令
    0x36TransferData传输数据
    0x37RequestTransferExit请求退出传输命令
    0x31RoutineControl触发指令
    0x2EWriteDataByIdentifier外部设备写入数据到ECU
    0x22ReadDataByIdentifier与ECU内部数据传输
    0x11EcuResetECU复位
    0x3ETesterPresent

2. Bootloader–三段式

2.1 预编程阶段

  • (1) 3E TP报文
  • (2) 10服务切换到03扩展模式
  • (3) 85服务和28服务， 关DTC和非诊断报文.使得整个CAN网络处于安静的状态
    这是对整车网络进行操作，一般以功能寻址的方式发送。 注意先用85服务关闭DTC，再使用28服务关报文
编号收发报文说明
440Rx02 3E 80 00 00 00 00 00
703Rx02 10 03 00 00 00 00 00切换到扩展诊断模式
4E0Tx06 50 03 00 14 03 E8 00P2=20ms; P2* = 1000ms
440Rx02 85 82 00 00 00 00 00关闭DTC
440Rx03 28 81 01 00 00 00 00关闭报文

2.2 主编程阶段

  • (1) 10服务切换到编程模式

    ​ 正确的方式是App段程序回复0x78 NRC， 接下来跳转到boot段程序，最后由Boot段程序来回复10 02的肯定响应。 错误的方式是由App段回复10 02的肯定响应，再进行跳转。

  • (2) 读取一个DID，tester要判断一下返回值，返回值里可能包含密钥的一部分信息

  • (3) 27服务，解锁，通过安全验证

编号收发报文说明
703Rx02 10 02 00 00 00 00 00切换到编程模式
4E0Tx06 50 02 00 14 03 E8 00
703Rx03 22 F1 00 00 00 00 00读DID = 0xF100
4E0Tx03 7F 22 78 00 00 00 000x78否定响应码
4E0Tx07 62 F1 00 01 00 00 02ECU返回0xF100的DID
703Rx02 27 05 00 00 00 00 00安全反问, 请求不同安全级别的种子
4E0Tx10 0A 67 05 08 27 11 F08字节的种子(多包第一帧数据)

  • 10 02服务不应直接进行肯定响应，存在风险

  • (1) 写DID（Data identifier）指纹， 标记写软件人的身份，ECU回复写指纹成功

  • (2) 31服务-擦除Flash。ECU肯定响应，擦除成功

  • (3) 34服务，请求数据下载，ECU回复确认最大块大小

  • (4) 36服务，开始传输数据，每个块传输完成后，ECU肯定响应，判断是否还有更多块需要下载，最多255块

  • (5) 37服务，请求退出传输。ECU肯定响应

  • (6) 31服务-检验APP段程序，检查编程一致性/完整性。ECU肯定响应。校验成功

  • (7) 若有更多块需要下载，重新执行31（擦除Flash区域）-34-36-37-31（校验）服务。若无，往下执行

  • (8) 11服务，ECU复位。之后直接跳转到新下载的APP段程序中

编号收发报文说明
703Rx21 00 02 20 02 40 02 80
703Rx22 02 F0 02 F0 02 F0 02
703Rx23 F0 02 F0 02 F0 02 F0
703Rx24 02 F0 02 F0 02 F0 02
703Rx25 F0 02 F0 02 F0 02 F0
703Rx26 02 F0 02 BF 03 03 00
703Rx27 00 00 00 00 00 00 00
703Rx03 7E 36 78 00 00 00 00
703Tx02 76 01 78 00 00 00 00完成数据传输
4E0Tx01 37 00 00 00 00 00 00请求退出传输
4E0Tx01 77 01 78 00 00 00 00
703Rx10 0A 31 01 FF 01 00 04启动例程: 校验应用程序
4E0Tx30 00 00 FF FF FF FF FF
703Rx21 6A DD AE F8 00 00 00
4E0Tx03 7E 31 78 00 00 00 00
4E0Tx05 71 01 FF 01 00 00 00校验完成
703Rx02 11 01 00 00 00 00 00ECU硬件复位

2.3 后编程阶段

  • (1) 10服务切换到03扩展会话
  • (2) 执行28服务和85服务，使能非诊断报文和DTC（Diagnostic Trouble Code）。
    • 这是对整车网络进行操作的，一般都是以功能寻址的方式来发送。注意先执行28，后执行85，避免DTC误报。
编号收发报文说明
4E0Tx02 51 01 FF 01 00 00 00复位肯定响应
440Rx03 28 00 01 00 00 00 00连接控制请求:
使能收发应用程序报文
4E0Tx02 68 00 FF 01 00 00 00
440Rx02 85 01 00 00 00 00 00使能DTC设置
4E0Tx02 C5 01 FF 01 00 00 00
  • (1) 27服务，安全校验，准备写入数据
  • (2) 2E服务，将编程信息写入到ECU中
  • (3) 10服务，退回01默认会话。结束

3. BootLoader的启动顺序和转换流程

  • (1) ECU上电或复位之后，先进入Boot段。从Flash/EEPROM中读取App有效标志 ，运行boot标志
  • (2) 判断 运行boot标志，若为1，则进入Boot段的编程会话（安全等级为上锁），之后写Flash/EEPROM（不安全操作），运行boot标志清零。若S3定时器超时则退回Boot段默认会话。
  • (3) 经过安全访问进入Level2解锁状态，开始执行App内存擦除，擦除后App有效标志清零（不安全操作）。
  • (4) 开始烧写。烧写成功后运行boot标志 写0，App有效标志 写1。

UDS 14229 -1 刷写34，36，37服务,标准加Trace讲解，没理由搞不明白

目录

📙 RequestDownload (0x34) service

  • Tester向目标ECU请求下载服务

请求格式

  • dataFormatIdentifier ：这是第二个字节的参数，其中高4个bit表示压缩方法，低4个bit表示加密方法，一般情况就是0x00
  • addressAndLengthFormatIdentifier：请求刷写地址和长度格式，高4个bit表示下面的memorySize参数占几个字节，低4个bit表示下面的memoryAddress参数占几个字节。常规就是0x44，就是memorySize和memoryAddress各占4个字节。
  • memoryAddress ：请求刷写的首地址，这个参数占几个字节由addressAndLengthFormatIdentifier参数的低4个bit决定的
  • memorySize ： 请求刷写的字节长度，这个参数占几个字节由addressAndLengthFormatIdentifier参数的高4个bit决定的

如下图的实例Trace ： 34 00 44 52 80 90 00 00 00 16 00

正响应格式：

  • lengthFormatIdentifier：高4个bit表示下面的maxNumberOfBlockLength参数占几个字节，低4个bit默认0
  • maxNumberOfBlockLength ： 目标ECU允许Tester传输最大的字节数
  • 比如下面34服务响应的 maxNumberOfBlockLength等于0x0802,下面36服务就传输了0x0802个字节（包括36 01）
  • 0x1802的解释：CAN TP层的第一个字节的高4bit表示帧类型，1就表示是首帧，2是连续帧，3是流控帧，0是单帧。
  • 实际上，36服务传输可以小于maxNumberOfBlockLength，但不能大于，

负响应格式：

  • 0x13 ：36服务传输字节大于maxNumberOfBlockLength时
  • 0x22 ：当目标ECU正在接受数据，发送S34服务请求，ECU应该响应CNC(0x22)
  • 0x31 ：请求参数中，参数不对
  • 0x33 ：没有进入指定的安全会话
  • 0x70： 没事先擦除内存会报这个NRC

📙 TransferData (0x36) service

  • 刷写过程，即Tester向ECU中下载数据的过程叫download
  • Teser向ECU请求返回数据，即ECU向Tester传输数据的过程叫 upload

请求格式

  • blockSequenceCounter:数据传输计数器，第一帧从1开始，到了0xFF后，再从0开始，循环往复，直到下载完毕
  • transferRequestParameterRecord：传输数据，正常来说就是（maxNumberOfBlockLength - 2）

正响应格式：

  • blockSequenceCounter: 响应的结果和请求时一样
  • transferRequestParameterRecord ： 刷写过程是没有这个参数的，35服务请求数据时，才有这个参数
  • 34和35服务，互为逆过程，36服务的请求和响应也是互逆的。

负响应格式：

  • 0x24 : 不先请求34或者35服务，会响应这个NRC
  • 0x71:xxxxx
  • 0x72:xxxxx
  • 0x73:传输Block计数器错误，比如第一帧传输时不是1，或者，不连续
  • 0x92/0x93： 刷写时电压过高或者过低

📙 RequestTransferExit (0x37) service

正响应格式：

  • transferResponseParameterRecord：从没见过

负响应格式：

🌎总结

  • 🚩要有最朴素的生活，最遥远的梦想，即使明天天寒地冻，路遥马亡！

  • 🚩如果这篇博客对你有帮助，请 “点赞” “评论”“收藏”一键三连 哦！码字不易，大家的支持就是我坚持下去的动力。

以上是关于基于UDS服务的BootLoader架构和刷写流程的主要内容，如果未能解决你的问题，请参考以下文章

诊断协议那些事儿

使用Betaflight Configurator飞控刷写固件时各步骤的含义

使用Betaflight Configurator飞控刷写固件时各步骤的含义

UDS入门至精通系列：Service 29

[架构之路-25]：目标系统 - 系统软件 - bootloader uboot内存映射与启动流程

UDS诊断详解