前言在2个月前Bootloader开发对我来说犹如天花板一样的存在高高在上就像睥睨众生的撒旦在天上呼吸着稀薄的空气可望而不可即令基础软件开发的人们望而却步但这2个月走来从新的工具链使用开始到APP程序下载成功后一连串的绿色对号我惊讶的发现Bootloader开发被神话了其实难度没有那么大有过一次经历之后7天开发一个Bootloader问题不大。UDS学习套件暨便携式UDS诊断服务端我已经把这套Bootloader和使用的UDS协议栈集成到这个小ECU中用于实习UDS和Bootloader刷写流程非常适合汽车电子初学者。BOOT不神秘先别害怕我们对比一下BOOT和APP的异同压压惊Bootloader与普通App的对比BOOTAPP启动代码有有链接文件有有中断有有内核驱动有有外设驱动有有入口地址跳转有--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即可。软件架构不复杂简单说一下我做的Bootloader1. Timer模块主要为OS(时间片)提供定时同时该Timer还可以用来实现UDS协议中的时间参数N_xxBS STminS3Server...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其他模块。学习计划我已经把这套Bootloader和使用的UDS协议栈集成到这个小ECU中用于实习UDS和Bootloader刷写流程非常适合汽车电子初学者。未来个把月我会逐步把每一个环节的开发过程以及踩过的坑写出来。并将我在网上下载的英飞凌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课 软件下载流程和程序跳转逻辑★★★
前言在2个月前Bootloader开发对我来说犹如天花板一样的存在高高在上就像睥睨众生的撒旦在天上呼吸着稀薄的空气可望而不可即令基础软件开发的人们望而却步但这2个月走来从新的工具链使用开始到APP程序下载成功后一连串的绿色对号我惊讶的发现Bootloader开发被神话了其实难度没有那么大有过一次经历之后7天开发一个Bootloader问题不大。UDS学习套件暨便携式UDS诊断服务端我已经把这套Bootloader和使用的UDS协议栈集成到这个小ECU中用于实习UDS和Bootloader刷写流程非常适合汽车电子初学者。BOOT不神秘先别害怕我们对比一下BOOT和APP的异同压压惊Bootloader与普通App的对比BOOTAPP启动代码有有链接文件有有中断有有内核驱动有有外设驱动有有入口地址跳转有--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即可。软件架构不复杂简单说一下我做的Bootloader1. Timer模块主要为OS(时间片)提供定时同时该Timer还可以用来实现UDS协议中的时间参数N_xxBS STminS3Server...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其他模块。学习计划我已经把这套Bootloader和使用的UDS协议栈集成到这个小ECU中用于实习UDS和Bootloader刷写流程非常适合汽车电子初学者。未来个把月我会逐步把每一个环节的开发过程以及踩过的坑写出来。并将我在网上下载的英飞凌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课 软件下载流程和程序跳转逻辑★★★
