基于UDS的BootLoader下载,可以支持ECU生命周期的无限次刷写,通过CAN网络进行无需拆壳和DEBUG口的应用程序刷写,本文介绍了刷写服务和是三个阶段的刷写流程。也可通过无线模块实现空中升级,即OTA技术。 通过下面两张图了解一下bootloader的软件堆栈架构及刷写的流程。
Q:图中的烧写顺序是34-36-34-36-34-36-37,但另一些材料中的顺序是34-36-36-36-37。 A:这个问题这样理解,34-36-36-36-37的前提是你要下载的数据是连续的数据,每个36所使用的地址信息,都是34中包含的地址信息再加上一定的偏移量。如果需要下载不连续的数据,就需要重新进行34服务或31(擦除)-34服务。 1 为什么要搞Bootloader?为什么要基于UDS搞Bootloader 那为什么使用UDS呢?主要是为了规范bootloader的全过程。比如烧写小明牌ECU时,我们肯定希望其他牌子的ECU处于一个静默的状态,都歇一歇,这就需要一个大家共同执行的标准来进行规范,什么时候停发数据,什么时候不能再储存DTC了等等。 又比如在调试时,大家肯定希望你的控制器经由CAN烧写的过程是大家都能看得懂的,是满足于某种规范的。由此,UDS在设计时考虑了bootloader的需求,专门为bootloader设计了几个服务,供大家使用。主机厂在发需求时自然就要求大家要在UDS规范的基础上完成bootloader功能了。 2 Bootloader应支持的UDS服务 在boot程序中,10/27/11/3E这样的基础诊断服务需要支持,22/2E读写DID的服务需要支持,31/34/36/37这4个bootloader主打服务需要支持,共10个。 在app段程序中,85和28服务需要支持,保证暂停CAN正常通信,暂停记录DTC,让被升级设备专心升级。
3E TP报文。 (2)主编程阶段 10服务切换到编程模式,这里要注意,正确的方式是App段程序回复0x78 NRC,接下来跳转到boot段程序,最后由Boot段程序来回复10 02的肯定响应。错误的方式是由App段回复10 02的肯定响应,再进行跳转。 注意10 02服务不应直接进行肯定响应,存在风险 写DID指纹,标记写软件人的身份,ECU回复写指纹成功。(根据OEM要求来执行) (3)后编程状态 10服务切换到03扩展会话。 27服务,安全校验,准备写入数据。 4 BootLoader的启动顺序与转换流程 ECU上电或复位后,先进入Boot段。从Flash/EEPROM中读取 App有效标志,运行boot标志 。 3*. 50ms后判断 App有效标志 ,若为1,则 跳转到 App段默认会话。实现时使用汇编指令执行APP段程序;若为0,退回Boot段默认会话,且不再判断 App有效标志,不会再尝试进入App段。 4*. App段程序若收到了编程会话请求, 运行boot标志写1 ,随即执行ECU复位,这样会重新进入boot段程序。 注:从BOOT跳入APP前需要判断APP的数据完整性,例如进行CRC校验。 5 问题点 A:参照电脑的开机方式,在ECU开机之后,预留很短的一段时间维持在boot状态,在这段时间内,若收到指定报文(比如,电脑是按住F8),那么就不跳转到App段了。 Q:运行boot标志和App有效标志为了安全起见,应该保存到哪里? A:运行boot标志可以放置在RAM中,由Boot和App共用。 Q:上文图中的CAN数据实例,为什么出现了两次CRC的校验?CRC校验是对哪些数据的校验? A:OEM不希望ECU中保存有可以擦写Flash的代码,所以BootLoader需要在烧录App之前,先把擦写Flash的代码通过UDS烧写到RAM中,烧完了之后进行一下31服务下的CRC校验。之后烧录ECU的App程序,App可能会因为地址不连续而分为很多段下载。下载完毕后需要进行总的CRC校验。不管哪次校验,CRC所校验的数据是代码的数据段,即36服务中传输的有效数据。 |
|
来自: 瑞莱ppuieg8vcd > 《待分类》