基于UART 总线Ymodem 协议的Bootloader 设计与实现

李媛媛

（南京康尼机电股份有限公司， 江苏 南京 210013）

0 引言

为了避免在进行程序更新、 升级过程中拆除门控器，通过仿真器将应用程序更新到处理器中的这种繁琐、费时、耗力的工作，需要研究通过串行总线、USB 口或其它总线以及相应的通讯协议实现在线升级。 在更新过程中，可靠性是开发过程中首要考虑因素。为了应对程序更新出错的意外状况，采取在开始更新、更新过程中以及更新完成后读写同一块地址不同标志的策略增强程序的可靠性。

本文着重研究基于TMS570LS0714 处理器UART 总线Bootloader 的设计与实现， 采用Ymodem 协议实现文件传输， 通过实验说明设计的Bootloader 可以实现应用程序在线更新。

1 Bootloader 工作原理

应用Flash 程序存储器的一种编程方式称为在线应用编程IAP（In-Application Programming），它能够在应用程序正常运行过程中， 借助特定的IAP 程序读/写另一段程序的Flash 空间，甚至可以读/写某段、某页甚至某个字节， 这使得程序的在线升级和数据存储有了很大的便捷性和灵活性[1]。

为了实现IAP 功能， 通常Flash 内部要划分为两块，一块叫做Boot 区，专门用来存储Bootloader 程序，一块称为存储区，用来存储应用程序。 处理器TMS570 上电之后首先在Boot 区运行，如果有满足外部改写程序的条件，则先擦除原有程序数据， 并通过UART 总线下载待升级程序到Flash，再拷贝到RAM 中运行；如果不满足改写程序的条件，则程序指针跳转到存储区，执行应用程序，这就是IAP 功能实现原理[2]。

2 TMS570LS0714 内存分配

2.1 TMS570LS0714 简介

TMS570LS0714 处理器， 是TI 公司的一款安全控制芯片，符合功能安全要求的微控制器，具有双核校验、RAM和FLASH 的ECC 校验等系统可靠性保障手段，可以识别出系统运行过程中的各类异常并执行用户预置的异常处理程序[3]。

2.2 内存分配

TMS570LS0714 对用户可操作的Flash 范围是0x0000_0000～0x000B_FFFF，共768K[3]。 通常会安排Bootloader 代码处于Flash 的开始区域0x0000_0000， 而应用程序代码紧随其后。Bootloader 实现的功能就是升级加载应用程序，应本着可靠、简化的原则，占用的存储空间不应过大， 本文分配Bootloader 存放地址为0x0000_0000～0x0001_FFFF，共128K。剩下的Flash 空间用0x0000_0000～0x000B_FFFF 来存放应用程序。

3 基于UART 的Ymodem 协议设计

本模块通过UART 接口使用Ymodem 通信协议传输文件。 Ymodem 协议在发送方发送完成一包数据之后，需要等待接收方的确认，如果发生方收到“ACK”信号，则可以发送新的数据包，如果收到“NAK”信号，则需要重发或者错误退出。

3.1 Ymodem 协议简介

Ymodem 协议是广泛使用的异步文件传输协议之一，它是Xmodem 的改进版协议，相较于Xmodem 协议，Ymodem 协议允许批处理文件传输，传输效率、可靠性更高，一帧可以传输128*8bite 或1024*8bite， 一次传输可发送或接收几个文件，使用CRC 校验技术对发送数据包进行数据校验确保数据传输正确性。每发送一个数据包后，会等待接收端回应，直到接收到“ACK”信号后，下一个数据包才会继续传输，确保数据被接收完成。

3.2 UART 通讯格式

本模块定义的传输波特率是115200bit/s，8 个数据位，1 个停止位，偶校验。

3.3 标识符定义

本协议接收方和发送方约定的收发过程中的一些标记信号定义见表1。

表1 收发过程约定符号定义

3.4 文件传输过程

文件传输过程为[4]：

（1） 开启是由接收方的处理器发送一个大写字母“C”开启传输，之后等待发送方发送“SOH”，如果接收不到回应，则一直向上位机发送“C”，若超过5S 上位机还没有回应，则处理器会向上位机连续发送两个“CAN”，然后超时退出。

（2）发送方开始时处于等待过程中，等待“收到“C”以后，发送文件名数据包，然后进入等待“ACK”状态。

（3）接收方收到数据包之后，对数据包进行CRC 校验，校验成功则发送“ACK”信号。 发送方接收到“ACK”，又重新进入等待“C”的状态。

（4）至此文件名数据包传输完成，此后文件传输正式开启，Ymodem 支持每个数据包以128 字节以“SOH”开始或者1024 字节以 “STX” 开始， 本文规定每个数据包为1024 字节。

接收方开始准备接收文件又发出一个“C”信号，然后进入等待“STX”状态。

（5）发送接收到“C”以后，发送数据包（详见3.5 章节数据格式），等待接收方的“ACK”信号。

（6）发送方发出“EOT”信号表示文件发送完成，接收方回应“ACK”信号。

紧接着发送方发出一个全“0”数据包，接收方回应“ACK”，正式结束此次通讯。

3.5 接收数据格式

Ymodem 通信协议接收数据格式，第一包数据只是传输文件的文件名和文件大小信息， 之后传输的数据包才是文件的内容。 若最后一包内容不足1024 字节， 则以0补齐。 具体传输格式如下：

第一包：

图1 第一包发送数据格式

第二包：

图2 第二包发送数据格式

之后每一包依次类推下去。

3.6 发送数据格式

接收方以一个大写字母“C”开启传输，收到发送来的数据以后，CRC 校验满足，则发送“ACK”应答信号，CRC 校验不满足，则连续发送两个“CAN”信号，表示取消该次传输。

接收方接收数据成功以后， 开始写入flash 操作，如果写入失败，则连续发送两个“CAN”信号，如果写入成功，则发送一个“ACK” 应答信号。

接收数据过程中，如果连续收到两个“CAN”信号，则表示取消传输，发送方以发送“ACK”应答；如果连续到一个“EOT”信号，则表示文件传输结束，发送方以发送“ACK”应答。

4 Bootloader 软件实现

4.1 CMD 文件配置

配置Bootloader 的CMD 文件是应用程序能否被正确升级的关键，CMD 文件的两大主要功能是通过MEMORY伪指令来指示存储空间和通过SECTIONS 伪指令来分配段到存储空间，CMD 文件就是由这两部分内容构成的。

在控制器复位以后， 启动程序将装载引导程序的Flash API 从FLASH 中复制到RAM 中， 并在RAM 中执行装载引导程序。可以在CMD 文件中划分一段用以设置RAM 的载入和运行地址，定义输出段将被装载到哪里的关键字、输出段从哪里开始运行的关键字、API 从哪里开始下载、API 从哪里开始运行以及API 的长度等信息[5]。

4.2 串口IAP 设计流程

串口IAP 的实现流程见图3 所示，控制器复位以后，首先是在Flash 起始地址运行Bootloader 程序。Bootloader程序执行的任务就是检测是否升级应用程序， 通过判断Flash EEPROM block1 上的值是否是约定标志A，若block1 上的值不是A， 则表示要进行更新， TMS570 向上位机发送请求执行代码升级函数， 同时驱动数码管显示“CC”。

图3 IAP 实现流程

若block1 中的值满足约定条件， 则说明分配的应用程序地址空间（0x0002_0000～0x000B_FFFF）里有完整的应用程序， 不需要进行升级操作， 直接跳转到用户代码段，即起始地址0x0002_0000 执行应用程序。

定义运行Bootloader 程序， 门控器数码管显示“CC”指示Flash 中没有应用程序，数码管显示“FE”指示正在升级，数码管显示“FF”指示升级完成。

4.3 出错防护

在程序升级过程中，为了防止误升级错误的文件，或者是升级过程中出现意外导致升级失败， 升级标志在不同阶段写不同值。

即在正常运行应用程序时，收到上位机的升级请求，应用程序首先向Flash EEPROM block1 写需要升级标志B，然后关闭定时器引起复位操作，CPU 复位后进入Bootloader，重复4.1 节的操作，进入升级流程，在升级流程里，首先读取block1 中的标志是否是B，若是B，则向block1中写正在升级标志C，然后正式启动升级操作。 升级完成后，跳转到应用程序段执行应用程序，应用程序在执行正常功能之前，先读block1 中的标志是否是A，按照上述思路，这个时候block1 中存放的是标志C，而不是A，这时候CPU 立即向block1 中写标志A，然后复位重启，重复4.1 节操作。

这样略显繁琐的操作， 恰好能规避误升级错误文件的操作。 若正常升级过程出现意外导致升级失败， 重启CPU，Bootloader 上电检测block1 无标志A， 再次进入升级流程升级即可。

5 实验

本章节设计了四个试验，通过配套上位机软件发送应用APP 程序数据流到TMS570 并运行， 测试上文设计的Bootloader 能否实现预期的升级功能。 该APP 程序运行起来后循环检测有无升级请求， 并控制数码管显示“00”，输出口O0 红色指示灯以1HZ 频率闪烁， 以方便用户观察APP 程序是否得以正确并完整升级，是否能够正常运行。

5.1 Flash 中只有Bootloader 升级APP

Flash 中只有Bootloader，应用程序段是空的，启动上位机发送升级请求， 观察升级过程中数码管及指示灯情况见表2。 表中的数码管及指示灯显示情况表明该升级过程没有出现数据丢失情况，Bootloader 能完整的解码上位机发送的数据并写到相应Flash 上，升级成功。

表2 Flash 中只有Bootloader 升级APP

5.2 Flash 中有Bootloader 和APP 升级APP

继5.1 节之后，控制器输出口O0 闪烁过程中， 启动上位机发送升级请求， 观察升级过程中数码管及指示灯见情况见表3。

表3 Flash 中有Bootloader 和APP 升级APP

该试验结果表明设计的Bootloader 能够实现过程升级。

5.3 Flash 中有Bootloader 和APP 升级了错误APP

继5.1 节之后，控制器输出口O0 闪烁过程中，启动上位机发送升级请求，但是发送的不是和Bootloader 配套的APP 程序， 该APP 程序没有实时检测升级的功能，也没有点亮输出口的功能，即错误APP。观察升级过程中数码管及指示灯情况见表4。

表4 升级错误APP

该实验表明升级了错误APP 后，Bootloader 不会跳转到错误APP 程序执行，会一直等待升级， 直到升级了正确APP 后，才会跳转执行APP 程序，能有效防护误升级错误APP。

5.4 升级APP 过程出错

在升级过程中，断开上位机与控制器的连接，制造升级过程出错的现象，观察上位机显示升级超时出错，重启控制器，数码管显示“CC”，指示Flash 中没有APP 程序。该实验表明Bootloader 能够有效防护升级过程出错。

6 结论

本文设计并实现了基于Ymodem 协议的Bootloader，在开发过程中增加防错处理， 有效防止升级错误的执行文件及升级失败。经过试验证明Bootloader 能正确引导程序运行，下载数据完整、无误、快速，没有出现数据丢失、错误等现象。