S32K324 UDS Bootloader开发-需求篇

前言

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

内存分配

本次使用的单片机为S32K324,flash大小4M，一个扇区8k,SRAM：512KB

flash起始地址为0x4000000

RAM起始地址为0x2000000

将flash划分为Bootloader和App两块

APP跳转到boot,这个标志放在ram中，但要保证软复位时不清除.

FlashDrive需要放到ram中，每次下载APP时先下载FlashDriver

APP有效标志放入Flash中，每次刷写前清除标志，刷写成功后写入标志。

flash分配如下

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 每一块中包含连续帧的个数

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版本信息。

主编程

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驱动程序将被清除。避免意外激活这些可能会进行非预期的内存擦除或程序操作的代码。

后编程

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（功能寻址）

总结

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