uds诊断协议的bootloader开发概述
本文介绍的内容基于MC9SG128 MCU和UDS 协议,包括ECU下位机开发(CW5.1),上位机开发(VS2010,C#),和APP开发(CW5.1),诊断下载流程和检测方法通过车厂企业测试标准。
主体流程:
UDS诊断进入bootloader的流程:ECU上电时,先进入bootloader,初始化MCU后读取EEPROM判断是否可以跳转到app层,如果判断条件不满足,则留在boot执行。这时上位机烧录启动后,会发送0x10 02 进入编程会话,然后解锁ECU,发送0x34,0x36,0x37等服务请求将上位机加载的app代码(.s19格式的文件)以数据的形式发送到下位机,下位机接收到代码后通过写flash,将代码保存在flash(先进行地址分区)当中。 基本逻辑就是这样。但是大部分情况都是从app跳入到boot中,这里有个关键是,上位机发0x10 02 只发一次,app接收到0x10 02 后产生复位后到boot中就会变成default session,这时需要判断复位是因为重新上下电产生还是由于app运行时接收到了0x10 02,由固定位置的EEPROM中的内容确定此时是否需要从boot层跳跳转到app层。
下载流程图如下:
本项目 bootloader原理框图:
解锁ECU算法采用的是SHA256 和 AES128加密解密算法,UDS安全访问认证流程如下图:
需要注意的几个问题:
1.bootloader flash/EEPROM 内存分配方法:
飞思卡尔9s12G128 单片机flash 内存映射表 | ||||
是否分页访问 | Page Num(0x) | Global Address(0x) | prm address(0x) | Size |
Paged | 08 | 2_0000~2_3FFF | 16K | |
Paged | 09 | 2_4000~2_7FFF | 16K | |
Paged | 0A | 2_8000~2_BFFF | 0A8000~0ABFFF | 16K |
Paged | 0B | 2_C000_2_EFFF | 16K | |
Paged | 0C | 3_0000~3_3FFF | 0C8000~0CBFFF | 16K |
No Paged | 0D | 3_4000~3_7FFF | 4000-7FFF | 16K |
Paged | 0E | 3_8000~3_BFFF | 16K | |
No Paged | 0F | 3_C000_3_EFFF | 16K |
1.1.MC9s12系列单片机寻址的特点:
由于16位单片机的 寻址范围最多是0x0000~0xFFFF(64K),为了扩大寻址范围,飞思卡尔单片机采取了地址分页机制,简单讲就是NVM通过高地址+低字节地址来确定真实的flash地址空间,从而实现对flah的读写,具体如何手写一段flash 写函数又是一篇博文了。
2.1.中断向量表必须放在非分页区
非分页区可以由CPU 的pC指针直接访问,当发生复位或者跳转时,pc指针需要找到中断向量表此时不能通过NVM来访问flash,因此应用层工程就必须将中断向量表放在非分页区。
3.1.当 flash空间不足时,(此处应该附上9s12 内存映射图)
2.s19 文件解析:附上文件解析的代码(C#)
3.C# 的简单使用:
3.1:加密/解密算法动态链接库的制作:
3.2:USBCAN_II 动态链接库的使用:
3.3:vspy3 动态链接库的添加:
3.4:c# 中“全局变量"的使用:
3.5:生成bootloader上位机界面:
4. C语言 的随机数生成:
unsigned char value = random();即可得到一个随机数(需要先#include "stdlib.h"这个头文件)
5. UDS协议网络层的概念(BS,FF,SF,CF P2Serve,P2*serve)
6. 故障触发和存储,以及读取的实现:
7. c# 窗体假死bug的解决,以及按比例缩放窗体空间的方法:
这里的假死指的是 当点击“烧录”按钮后,上位机就开始工作,此时窗体无法拖动,也不能缩小放大。
假死的本质原因:窗体线程正在进行数据收发,无法响应对窗体控件的操作。
解决此问题的办法:将数据下载的操作委托给另一个线程,这样窗体线程就能在烧录过程中响应对鼠标窗体的操作了。
附上核心代码: