01
为什么要基于UDS搞Bootloader
假如你的控制器有外壳，却没有设计bootloader的话，每次更新ECU的程序，你都需要把外壳拆开，用烧写器来更新程序。有了bootloader，你就可以通过CAN线来更新程序了。更方便些的话，甚至可以通过OTA进行远程升级。
那为什么使用UDS呢？主要是为了规范bootloader的全过程。比如烧写小明牌ECU时，我们肯定希望其他牌子的ECU处于一个静默的状态，都歇一歇，这就需要一个大家共同执行的标准来进行规范，什么时候停发数据，什么时候不能再储存DTC了等等。
又比如在调试时，大家肯定希望你的控制器经由CAN烧写的过程是大家都能看得懂的，是满足于某种规范的。由此，UDS在设计时考虑了bootloader的需求，专门为bootloader设计了几个服务，供大家使用。主机厂在发需求时自然就要求大家要在UDS规范的基础上完成bootloader功能了。
02
Bootloader应支持的UDS服务
显然bootloader不需要支持19/14等故障类服务。
在boot程序中，10/27/11/3E这样的基础诊断服务需要支持，22/2E读写DID的服务需要支持，31/34/36/37这4个bootloader主打服务需要支持，共10个。
在app段程序中，85和28服务需要支持，保证暂停CAN正常通信，暂停记录DTC，让被升级设备专心升级。
10种boot段服务+2种app段服务
03
测试设备在线Bootloader——三段式
（1）预编程阶段
1. 3E TP报文。
2. 10服务切换到03扩展模式。
3. 85服务和28服务，关DTC和非诊断报文。使整个CAN网络处于安静的状态。这是对整车网络进行操作的，一般都是以功能寻址的方式来发送。注意先用85服务关闭DTC，再使用28服务关报文。
（2）主编程阶段
1. 10服务切换到编程模式，这里要注意，正确的方式是App段程序回复0x78 NRC，接下来跳转到boot段程序，最后由Boot段程序来回复10 02的肯定响应。错误的方式是由App段回复10 02的肯定响应，再进行跳转。
2. 读取一个DID，tester要判断一下返回值。返回值里面可能包含密钥的一部分信息。
3. 27服务，解锁，通过安全验证。
注意10 02服务不应直接进行肯定响应，存在风险
4. 写DID指纹，标记写软件人的身份，ECU回复写指纹成功。（根据OEM要求来执行）
5. 31服务-擦除Flash。ECU肯定响应，擦除成功。
6. 34服务，请求数据下载，ECU回复确认最大块大小。
7. 36服务，开始传输数据。每个块传输完成后，ECU肯定响应。判断是否还有更多块需要下载。最多可以支持255个块。
8. 37服务，请求退出传输。ECU肯定响应。
9. 31服务-校验APP段程序，检查编程一致性/完整性。ECU肯定响应。校验成功。
10. 若有更多块需要下载，重新执行31（擦除Flash区域）-34-36-37-31（校验）服务。若无，往下执行。
11. 11服务，ECU复位。之后应直接跳转到新下载的APP段程序中。
31（擦Flash）-34-36
36-37-31（校验）
（3）后编程状态
1. 10服务切换到03扩展会话。
2. 执行28服务和85服务，使能非诊断报文和DTC。这是对整车网络进行操作的，一般都是以功能寻址的方式来发送。注意先执行28，后执行85，避免DTC误报。
3. 27服务，安全校验，准备写入数据。
4. 2E服务，将编程信息写入到ECU中。
5. 10服务，退回01默认会话。结束。
04
BootLoader的启动顺序与转换流程
1. ECU上电或复位后，先进入Boot段。从Flash/EEPROM中读取 App有效标志，运行boot标志 。
2.判断 运行boot标志 ，若为1，则进入Boot段的编程会话（安全等级为上锁），之后写Flash/EEPROM（不安全操作）， 运行boot标志 清零。若S3定时器超时则退回Boot段默认会话。
3. 经过安全访问进入Level2解锁状态，开始执行App内存擦除，擦除后 App有效标志 清零（不安全操作）。
4. 开始烧写。烧写成功后 运行boot标志 写0，App有效标志 写1。
2*. 判断 运行boot标志 ，若为0，则进入Boot段的默认会话。
3*. 50ms后判断 App有效标志 ，若为1，则 跳转到 App段默认会话。实现时使用汇编指令执行APP段程序；若为0，退回Boot段默认会话，且不再判断 App有效标志，不会再尝试进入App段。
4*. App段程序若收到了编程会话请求， 运行boot标志写1 ，随即执行ECU复位，这样会重新进入boot段程序。
注：从BOOT跳入APP前需要判断APP的数据完整性，例如进行CRC校验。
0
