前言
最近断断续续的在做基于STM32F103的UDS Bootloader,没有项目驱动,只是自己感兴趣。目前基本已经可以实现功能了,在此对做的东西进行一下总结,希望可以帮助到有需要的人。
内存分配
本次使用的单片机为STM32F103RCT6,flash大小256k,一个扇区2k,SRAM:48KB
flash起始地址为0x8000000,大小为0x40000(16进制)—>262144字节(10进制)—>256KB
RAM起始地址为0x2000000,大小为0xC000(16进制)—>49125字节(10进制)—>48KB
将flash划分为Bootloader和App两块
APP跳转到boot,这个标志放在ram中,但要保证软复位时不清除.
FlashDrive需要放到ram中,每次下载APP时先下载FlashDriver
APP有效标志放入Flash中,每次刷写前清除标志,刷写成功后写入标志。
flash分配如下:
ram分配如下:
UDS诊断协议需求
CAN ID及时间参数
波特率:500k
物理寻址ID:0x711
功能寻址ID:0x7DF
ECU 响应ID: 0x766
P2 Server:50ms P2 *Server:5000ms
P2 Client:50ms P2 *Client:5000ms
S3server:5000ms
S3client:2000ms
STmin:20ms 连续帧协议数据单元发送的最小时间间隔
BlockSize:0 每一块中包含连续帧的个数
CANFrameFillerByte:0x55 数据帧不满8byte时的填充值
诊断服务
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 |
|||
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 |
|||
85 |
01 |
ControlDTCSetting |
On |
Phy Req |
Fun Req |
85 |
02 |
ControlDTCSetting |
Off |
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 |
|||
27 |
01 |
Security Access |
Request Seed |
Phy Req |
|
27 |
02 |
Security Access |
Send key |
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:读取版本号
Routine Control DID:
FF00:擦除内存
0201:检查预编程条件
FF01:检查编程完整性和兼容性
2E服务的DID:
F15A -写指纹
刷写流程
预编程
1.进入扩展模式(功能寻址)10 83 (83表示不需要服务器应答)
2.检查预编程条件(物理寻址)31 01 XX XX,针对要刷写的ECU。一般就是检查供电电压,车速这些,如果厂家没指定,那么由ECU自己定义。如果ECU不满足预编程条件,则收到10 02进入编程模式时,返回0x22不满足条件否定响应。
3.停止DTC设置(功能寻址),85 82(82表示不需要服务器应答)
4.禁止无关通讯(功能寻址),28 83 03(83表示发送和接收报文都禁止,且不需要服务器应答,第三位01表示是应用软件报文,第三位03则表示应用软件和网络管理报文都禁止)
5.读取版本号(物理寻址)22 XX XX ,诊断仪读取当前ECU版本信息。
主编程
1.进入编程会话10 02 ,此时在APP中应该执行复位,然后进入boot中的编程模式
2.请求种子 27 01(x根据主机厂给的等级来定)
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,需要给定擦除的起始地址和大小。
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(功能寻址)
文章来源:https://www.toymoban.com/news/detail-461713.html
总结
理清需求后,再进行后面的软件开发就比较方便了。不论是开发下位机还是上位机,都需要参考这部分需求。在后面的文章中将会继续介绍软件的设计。文章来源地址https://www.toymoban.com/news/detail-461713.html
到了这里,关于STM32 UDS Bootloader开发-需求篇的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!