S32K324 UDS Bootloader开发-需求篇


  • 前言

  • 内存分配

  • UDS诊断协议需求

    • CAN ID及时间参数

    • UDS诊断服务

    • DID

  • 刷写流程

    • 预编程

    • 主编程

    • 后编程

  • 总结


前言

之前做过一个STM32的UDS Bootloader,协议栈主要是NXP官网下的,最近在用NXP的S32K3开发,官网也有Bootloader的demo工程,本文记录S32K324 UDS Bootloader的开发过程,有了之前的经验,及方法论之后,整个Bootloader+APP+上位机+调通,只花了三天实际。现在整理下开发过程及遇到的一些问题。本篇是需求篇

内存分配

本次使用的单片机为S32K324,flash大小4M,一个扇区8k,SRAM:512KB
flash起始地址为0x4000000S32K324 UDS Bootloader开发-需求篇

RAM起始地址为0x2000000

S32K324 UDS Bootloader开发-需求篇将flash划分为Bootloader和App两块
APP跳转到boot,这个标志放在ram中,但要保证软复位时不清除.
FlashDrive需要放到ram中,每次下载APP时先下载FlashDriver
APP有效标志放入Flash中,每次刷写前清除标志,刷写成功后写入标志
flash分配如下

S32K324 UDS Bootloader开发-需求篇

UDS诊断协议需求

CAN ID及时间参数

波特率:500k
物理寻址ID:0x714
功能寻址ID:0x7FF
ECU 响应ID: 0x614
P2 Server:50ms P2 *Server:5000ms
P2 Client:50ms P2 *Client:5000ms
S3server:5000ms
S3client:2000ms
STmin:0ms 连续帧协议数据单元发送的最小时间间隔
BlockSize:0 每一块中包含连续帧的个数

S32K324 UDS Bootloader开发-需求篇

UDS诊断服务

Bootloader诊断服务

10

01

Diagnostic Session Control

Default Session

Phy Req

Fun Req

10

02

Diagnostic Session Control

ECU Programming Session

Phy Req


10

03

Diagnostic Session Control

ECU Extended Session

Phy Req

Fun Req

11

01

ECU Reset

Hard Reset

Phy Req

Fun Req

22


Read Data By Identifier


Phy Req


2E


Write Data By Identifier


Phy Req


27

01

Security Access

Request Seed

Phy Req


27

02

Security Access

Send key

Phy Req


31

01

Routine Control

Start Routine

Phy Req


34


Request Download


Phy Req


36


Transfer Data


Phy Req


37


Request Transfer Exit


Phy Req


APP诊断服务

10

01

Diagnostic Session Control

Default Session

Phy Req

Fun Req

10

02

Diagnostic Session Control

ECU Programming Session

Phy Req


10

03

Diagnostic Session Control

ECU Extended Session

Phy Req

Fun Req

11

01

ECU Reset

Hard Reset

Phy Req

Fun Req

14


ClearDiagnosticInformation

FF FF FF Clear all

Phy Req


22


Read Data By Identifier


Phy Req


28

00

CommunicationControl

Enable Rx and Tx

Phy Req

Fun Req

28

01

CommunicationControl

Enable Rx and DisableTx

Phy Req

Fun Req

28

02

CommunicationControl

Disable Rx and EnableTx

Phy Req

Fun Req

28

02

CommunicationControl

Disable Rx and Tx

Phy Req

Fun Req

31

01

Routine Control

Start Routine

Phy Req


85

01

ControlDTCSetting

On

Phy Req

Fun Req

85

02

ControlDTCSetting

Off



DID

22服务的DID:

F1AA:读取版本号

2E服务的DID:

F15A -写指纹

Routine Control DID:

FF00:擦除内存
0201:检查预编程条件
0202:检查checksum
FF01:检查编程完整性和兼容性

刷写流程

预编程

1.进入扩展模式(功能寻址)10 83 (83表示不需要服务器应答)
2.检查预编程条件(物理寻址)31 01 02 01,针对要刷写的ECU。一般就是检查供电电压,车速这些,如果厂家没指定,那么由ECU自己定义。如果ECU不满足预编程条件,则收到10 02进入编程模式时,返回0x22不满足条件否定响应。
3.停止DTC设置(功能寻址),85 82(82表示不需要服务器应答)
4.禁止无关通讯(功能寻址),28 83 03(83表示发送和接收报文都禁止,且不需要服务器应答,第三位01表示是应用软件报文,第三位03则表示应用软件和网络管理报文都禁止)
5.读取版本号(物理寻址)22 F1 AA ,诊断仪读取当前ECU版本信息。

S32K324 UDS Bootloader开发-需求篇

主编程

1.进入编程会话10 02 ,此时在APP中应该执行复位,然后进入boot中的编程模式
2.请求种子 27 01
3.发送密匙 27 02 key
4.解锁成功后,2E服务写入指纹信息。一般就是时间和设备号这些
5.下载flash驱动程序,34 36 37服务。因为bootloader里是不带驱动程序的,防止意外操作导致flash改变,程序出现异常,所以只在刷写的时候才允许操作flash。下载完成后一般还需要例程控制31服务进行完整性检查(CRC32校验)和依赖性检查(ecu指定,DID为FF01-14229-1规定)(该步骤暂时不做)
6.擦除内存,由31服务执行,具体的DID按14229-1应该为FF00,需要给定擦除的起始地址和大小。(实际一般擦除都是ECU自己判断的区域)
7.下载APP程序,34,36,37服务。下载完成后也需要例程控制31服务中的完整性检查(CRC32校验)和依赖性检查(ecu指定,DID为FF01-14229-1规定)
8.ECU复位,一般发送11 01进行复位,复位完成后Flash驱动程序将被清除。避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

S32K324 UDS Bootloader开发-需求篇

后编程

1.主编程完成后,ECU复位,诊断仪发送进入扩展模式10 83(功能寻址,不需要ECU回复)
2.恢复通讯28 80 03(功能寻址,不需要ECU回复,03表示网络管理报文和应用报文都恢复)
3.开启DTC诊断85 81(功能寻址,不需要ECU回复)
4.清除刷写ECU的故障信息(物理寻址14 FF FF FF)
5.进入默认会话模式10 81(功能寻址)

S32K324 UDS Bootloader开发-需求篇

总结

刷写流程和UDS协议和之前的都差不多,主要是需要弄清楚芯片的flash和ram区域,以及分配合适的空间给Boot和APP。后面就是Boot和APP软件的开发了。将会在后面的文章中详细介绍。

S32K324 UDS Bootloader开发-需求篇


原文始发于微信公众号(汽车电子学习笔记):S32K324 UDS Bootloader开发-需求篇

版权声明:admin 发表于 2023年10月24日 下午8:43。
转载请注明:S32K324 UDS Bootloader开发-需求篇 | CTF导航

相关文章

暂无评论

您必须登录才能参与评论!
立即登录
暂无评论...