前言
在2个月前,Bootloader开发对我来说,犹如天花板一样的存在,高高在上,就像睥睨众生的撒旦在天上呼吸着稀薄的空气,可望而不可即,令基础软件开发的人们望而却步!但这2个月走来,从新的工具链使用开始,到APP程序下载成功后一连串的绿色对号,我惊讶的发现,Bootloader开发被神话了,其实难度没有那么大!有过一次经历之后,7天开发一个Bootloader问题不大。
BOOT不神秘
先别害怕,我们对比一下BOOT和APP的异同,压压惊:
BOOT | APP | |
---|---|---|
启动代码 | 有 | 有 |
链接文件 | 有 | 有 |
中断 | 有 | 有 |
内核驱动 | 有 | 有 |
外设驱动 | 有 | 有 |
入口地址跳转 | 有 | -- |
Data Flash | 有 | 有 |
Self-Programming (Code Flash) | 有 | -- |
多核同步 | -- | [有] |
看上表,Bootloader并没有什么什么神秘的,
地址跳转这一块就三行代码的工作量,通过一个函数指针跳转到一个固定的偏移地址,如0x20000。
相比APP开发,唯一的难点就是Self-Program(即对自身ROM的擦写),如果你的程序可以对Code/Program Flash擦/写,那就可以改造成Bootloader了!就这么简单。
大量代码可参考
我们在设计顶层架构的时候本着将可移植性最大化的原则,来设计Bootloader,这样就能在日后开发新的Bootloader时照搬很多很多 -- 这就是7天征服Bootloader的基础。博主身边还真有大神(至少2位)在7天之内搞定Bootloader开发。
是不是很担心UDS这一块?认为这是个大头?--现身说法的讲,事实正于此相反,网上关于BOOT的UDS协议栈很多,随便下载一个做一下裁剪和适配即可,并不需要完全从零做起。我们只造车不造轮子!
UDS这一块是纯软件的一个标准,完全脱离硬件,TC397上面的UDS和TC275上面的UDS是完全一样的。而完全一样的UDS对底层的命令也是完全一样的,所以HAL部分的接口也不因硬件改变而改变。在HAL之下,部分MCAL标准接口实现的功能也不用变。
下图中未蒙版的模块即为可重用的部分。 可见,做好软硬件的解耦后,开发一款新的Bootloader只需要配置/手写底层的MCAL,外加一个简短的时间片OS即可。
软件架构不复杂
简单说一下我做的Bootloader:
1. Timer模块,主要为OS(时间片)提供定时,同时该Timer还可以用来实现UDS协议中的时间参数:N_xx,BS, STmin,S3Server...
2. OS在Timer的基础上定时的调用任务,为各个函数的执行提供了触发条件。
3. MCAL模块,为实现Bootloader所需功能做的底层驱动。
4. HAL模块,作为UDS和底层驱动之间的桥梁。它对于日后的移植至关重要,UDS需要的硬件操作全都面向HAL而不面向MCAL,一是软件结构清晰,二是实现软件上的UDS协议与硬件的解耦,为可移植性提供实现基础。日后开发新的Bootloader的时候保持HAL里面的接口不变,只将接口内函数做修改(甚至有些使用MCAL标准接口做的函数也不用动,因为MCAL也是标准的啊).
5. MINI-UDS协议栈,该模块从CAN的RX回调函数中获取总线数据,并将RAW数据解析成UDS命令,MINI-UDS模块因为不面向硬件,所以这一块如果设计的好了,可以实现100%的移植!
工作目标很明确
总结起来,开发Bootloader工作就这么几步:
1. 启动代码,在main()函数之前初始化中断向量表,RAM,通用寄存器等-- 保证程序能进入main。
2. 链接文件Ld/Lsl文件,因为Bootloader对程序跳转地址和所在ROM区域都有严格要求,所以必须通过链接文件将Bootloader所用的资源划分好,保证Boot不被APP程序覆盖,并且在Code Flash进行数据擦写的时候一部分代码要运行在RAM中,就需要通过链接文件指定其地址。
3. OS编写。手写代码/MCAL配置GPT/STM实现一个短小精悍的OS-- 保证任务都能如期执行。
4. MCAL配置,最先要使用的是CAN模块,保证能从总线收/发数据。CAN的RX回调函数中,触发数据读取,然后传给UDS协议栈解析。Port/Dio是为控制MCU复位用的,CanTrcv的驱动也有可能会用到。看门狗这个就不用说了。CRC则是用来在下载过程和下载完成之后进行数据校验的。升级过程中数据是总线->RAM->ROM,而Code/Program Flash用来将代码保存到ROM中,Data Flash则是用来将数据(2E服务要写入的数据或APP完整性标志)保存到MCU里的。可以说,Bootloader开发中最大的幺蛾子往往就出在Flash这一块。SPI则是为一些复杂的CAN Trcv驱动准备的。
5. HAL开发。所有对底层的操作都在此做了封装。保证MINI-UDS能正确操作硬件。
6. MINI-UDS协议栈开发。将CAN总线上的命令/数据解析出来。向上经CAN总线发送UDS响应,向下传递数据到Flash/传递指令到MCAL其他模块。
学习计划
未来个把月,我会逐步把每一个环节的开发过程以及踩过的坑写出来。并将我在网上下载的英飞凌TC2xx的UDS协议栈作为base来深入剖析,从UDS入门,结合Bootloader设计需求,深刻掌握Bootloader设计思路,从而流水线式Bootloader开发。为日后的职业生涯积累筹(jia)码(xin)。
入门篇
课程 | 难度 |
七天征服Bootloader 开发- 第1课(启动代码和链接文件) | ★★★★★ |
七天征服Bootloader 开发- 第2课(STM驱动和时间片OS开发) | ★★ |
七天征服Bootloader 开发- 第3课(CAN模块MCAL配置) | ★★ |
七天征服Bootloader 开发- 第4课(Flash固件库集成) | ★★★★★ |
七天征服Bootloader 开发- 第5课(MCAL其他模块配置) | ★★ |
七天征服Bootloader 开发- 第6课(HAL硬件抽象层开发) | ★★★ |
七天征服Bootloader 开发- 第7课(UDS协议栈移植) | ★★★ |
精通篇
课程 | 难度 |
七天征服Bootloader 开发- 第8课(UDS之TP层开发,报文获取、拆包、打包) | ★★★★★ |
七天征服Bootloader 开发- 第9课(UDS之Timer的开发) | ★ |
七天征服Bootloader 开发- 第10课(UDS之10_11_22_2E服务开发) | ★★★ |
七天征服Bootloader 开发- 第11课(UDS之27服务开发) | ★ |
七天征服Bootloader 开发- 第12课(UDS之31服务开发) | ★★★★ |
七天征服Bootloader 开发- 第13课(UDS之34_36_37服务开发) | ★★★ |
七天征服Bootloader 开发- 第14课( 软件下载流程和程序跳转逻辑) | ★★★ |