一种主从刷写方案的简单概述

        在汽车零部件固件升级方案里，通过诊断进行刷写是一个较为常用的方案。各家OEM都有自己各自的刷写规范和流程，但是万变不离其宗，可以作一个大致的总结。

1、一般刷写

        接下来，展开说说流程中各个服务起到的作用是什么，有诊断基础的读者可以直接跳过。

        首先，10服务，若是ECU本身处于APP下运行，那么可以通过1002服务进行地址跳转至BTLD程序，进入编程会话为即将进行的刷写升级做准备。既然提到了这里，可以顺便讲下跳转的逻辑，以Vector方案为例：

        在ECU上电后，首先会跑到BM，在BM中按照如下的状态机运行，首先会去确认ReprogFlag和MagicFlag等标记（比如ReprogFlag是否等于0xB5），而后确认了目标BHMD后，通过CallTarget进行跳转。

        而ECU在APP下，若收到1002的跳转指令（暂不考虑前置情况，例如要求先进拓展会话或者有其他编程预检测条件），则程序跑到Dcm_SetProgConditions，在满足各项条件后执行跳转，回到BTLD （可见诊断复位）。

        27服务，安全访问，通过种子和钥匙的形式，解锁ECU的权限，使ECU能够进行后续对Flash的操作（DFlash或者PFlash）。

        2E服务，不同主机厂差异较大，且容易理解，略过。

        在通过了27服务之后，就可以对PFlash进行擦除，这个过程可以由一个31历程来实现。

        在擦除了PFlash后，可以通过34服务像上位机请求下载程序数据。此外，部分主机厂不会在烧写流程中定义擦除PFlash，若主机厂不允许我们单独增加一个擦除历程，则可以放在34服务中。

        按序执行36数据传输，在完成所有数据的传输后，上位机发送34服务指令，宣告程序数据的传输完成。

        为了确保程序数据的完整性，需要设计一个31历程对传输的程序数据以某种方式做校验，或签名或CMAC或两者皆有。

        在校验无误后，通过11服务复位，通过BM跳转至APP的起始地址，开始运行APP程序。至此完成了一次APP诊断升级。

2、主从刷写

        对于绝大部分无其余特殊要求的控制器而言，做到如图所示的刷写流程及正常的跳转即可进行正常的诊断刷写升级。但对于一块控制板上存在好几颗ECU，并要求一并升级的场景，这个基础的流程不足以满足需求。为此，我们可以提出一种主从刷写的方案，通过将多个ECU的APP软件集成至一个HEX文件中，而后主ECU通过CAN通信将程序数据转发至从芯片上做一个诊断升级。

        若要将多个ECU的APP软件集成在一起，可以分为如下几步：

① 首先明确从ECU的芯片类型，从ECU的APP软件起始地址、长度；

② 为从ECU的APP软件按照主ECU的APP软件地址layout预留相应位置；

③ 将主ECU与从ECU合并，并按需求在相应的位置预留签名等校验信息。

        而落到烧写过程中，就是主ECU首先接收并烧入自身的APP信息，而后接收并转发从ECU的APP信息。

        那么在从ECU烧写的阶段，接收并转发的逻辑可以概括为：

① 34服务收到上位机发送的数据；

② 判断数据属于主还是从ECU；

③ 若是从ECU，则开始数据的转发：

④ 转发完成，给上位机反馈正响应。

        转发的逻辑可以理解为：

        34服务发送数据，而后转换上文集成过的Hex文件的地址与从芯片实际的地址，通过主从间的诊断报文，使用3D服务按地址写入该从ECU。例如一次34服务传递128 byte的数据，若设置一次3D服务写入16byte的数据，那么就需要在这一次34服务中，循环发送8帧3D服务的TP帧。确认烧入后，给上位机正响应，使其继续下一次的34服务请求。