S32K324 UDS Bootloader开发-需求篇
文章目录
- 前言
- 内存分配
- UDS诊断协议需求
- CAN ID及时间参数
- UDS诊断服务
- Bootloader诊断服务
- APP诊断服务
- DID
- 22服务的DID:
- 2E服务的DID:
- Routine Control DID：
- 刷写流程
- 预编程
- 主编程
- 后编程
- 总结
前言
之前做过一个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软件的开发了。将会在后面的文章中详细介绍。