uds 诊断协议的bootloader开发

                                                              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 内存分配方法：                                                                                                                                             

    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的解决，以及按比例缩放窗体空间的方法：

      这里的假死指的是 当点击“烧录”按钮后，上位机就开始工作，此时窗体无法拖动，也不能缩小放大。

      假死的本质原因：窗体线程正在进行数据收发，无法响应对窗体控件的操作。

      解决此问题的办法：将数据下载的操作委托给另一个线程，这样窗体线程就能在烧录过程中响应对鼠标窗体的操作了。

      附上核心代码：