基于TMS320F28335 芯片CAN Bootloader 程序升级方法

顾瀚戈，钟洪念，冉万宁，范晋文

（中科芯集成电路有限公司，成都 610000）

1 引言

随着嵌入式技术的发展，芯片应用需求不断增加，应用场景也不断增多。TMS320F28335 通用的更新程序方式是采用CCS 集成开发环境通过JTAG 仿真器进行程序下载烧写，但在部分应用场景中，JTAG 接口不便于密封系统引出，并且引出后可能导致信号易受干扰而影响程序升级的可靠性，同时JTAG 线过长，设计时需考虑增加驱动电路，增加了硬件成本[1]。CAN总线具有实时性强、传输距离远、检错能力强、抗电磁干扰能力强等优点。本文提出了一种通过CAN Bootloader 引导程序实现DSP 程序升级的方法，不需要使用仿真器与JTAG 口相连，通过CAN 端口以及CAN 通讯设备实现程序在线升级，符合部分复杂应用场景的实际使用需求。

2 方法介绍

本方法包含上位机CAN 调试软件、CAN Bootloader 引导程序和应用程序，其中CAN 调试软件为CAN 总线设备配套软件，具有通用性，降低了开发难度，缩短了开发周期；引导程序预烧写在DSP 芯片Flash 上，DSP 上电启动后，烧写在DSP 芯片Flash 上的引导程序运行，该引导程序用于接收上位机软件通过CAN 接口下发的程序BIN 文件，并将接收的BIN文件烧写至指定Flash 区域；应用程序为用户编写的DSP 功能代码，通过调用CCS 工具，将编译生成的应用程序.out 文件转化为程序BIN 文件。待BIN 文件完成烧写，引导程序将跳转至应用程序开始运行。

根据设计，将引导程序分配在Flash A 扇区，将用户应用程序分配在Flash B～Flash H 区域，空间分配如图1 所示。

图1 TMS320F28335 Flash 空间分配

3 引导程序设计

3.1 引导程序介绍

CAN 通讯上位机软件通常与CAN 通讯设备配套，上位机软件需识别CAN 通讯设备号，软件具有单次发送和文件整体发送功能[2]。本方法利用文件发送功能，着重对引导程序进行设计，将下发文件进行循环缓冲接收和Flash 烧写，实现程序升级功能，提高开发效率，同时减小升级程序接收存储空间。

3.2 引导程序启动流程及CMD 设计

TMS320F28335 芯片的Boot ROM 位于片内地址空间0x3FE000～0x3FFFFF 的一块8k×16 位的只读存储器，片内Boot ROM 在出厂时固化了引导加载程序以及定点和浮点数表[3]。当芯片上电复位后，固化程序会从复位向量0x3FFFC0 处取得复位向量，并跳转至InitBoot 处执行，InitBoot 会根据GPIO87、GPIO86、GPIO85 和GPIO84 的值选择不同的启动方式[4]，具体对应关系如表1 所示。

表1 控制引脚与引导模式关系

编写的引导程序和应用程序存放在Flash 中，因此选择Jump to Flash 引导方式，系统默认使能4 个引脚的内部上拉功能，则无需为这4 个引脚外接控制电路。选择Jump to Flash 引导方式，系统自带的引导加载程序会跳转到Flash 地址0x33FFF6 处，在引导程序的CMD 文件中有如下代码：

将Codestart 代码放置在BEGIN 0x33FFF6 处，根据DSP2833x_CodeStartBranch. asm 关于Codestart 段的定义，

Codestart 包含一个跳转指令，使程序跳转至_c_int00 处，_c_int00 代码会调用并运行引导程序中的main 函数，从而实现引导程序上电Flash 方式启动[5]。通过配置引导程序工程中的CMD 文件，将SECTIONS 中的存储模型均存放至FlashA，保证了引导程序执行文件均在FlashA 中，执行Flash 擦除操作时，不操作FlashA 区，确保引导程序一直保存在FlashA 扇区中。

3.3 引导程序流程

当DSP 上电启动，程序指针根据CMD 文件引导跳转至引导程序起始地址，开始运行引导程序main 函数。引导程序主要功能为启动TMS320F28335 芯片的CAN 模块，等待接收上位机下发CAN 烧写命令，若接收到烧写指令，则开启烧写模式，若未收到，则在规定时间后将程序指针跳转至应用程序起始地址，开始运行应用程序。引导程序流程如图2 所示，程序详细流程步骤如下：

图2 引导程序流程

a)通过InitSysCtrl()函数对系统锁相环（PLL）、看门狗、使能外设时钟进行初始化；

b)通过以下函数：

MemCopy(&RamfuncsLoadStart,

&RamfuncsLoadEnd,&RamfuncsRunStart);

MemCopy(&Flash28_API_LoadStart,

&Flash28_API_LoadEnd,&Flash28_API_RunStart);

将ramfuncs 段函数和Flash28_API 段函数复制到RAM 内存运行，通过InitFlash () 函数初始化内部Flash；

c)初始化CAN GPIO 口，初始化CAN 模块，初始化TIMER0 定时器模块，配置CAN 中断和定时器中断，使能全局中断；

d)进入while(1)循环程序，判断定时器模块是否累加至规定时间，若到达规定时间，则将程序跳转至应用程序BEGIN 地址，开始运行应用程序；

e)若在规定时间内，CAN 中断接收到烧写指令，该烧写指令为8 B，包含2 B 帧头，2 B 帧尾以及4 B程序总长度信息，关闭定时器模块计时，对应用程序Flash 扇区进行擦除，待擦除成功后，向上位机反馈成功信息，开启烧写程序流程，上位机通过文件下发功能将BIN 文件整体下发，芯片通过循环接收并烧写下发的升级程序文件；

f)待烧写完成后跳转至应用程序，开始运行应用程序。

3.4 引导程序CAN 接收中断函数设计

当CAN 接收中断触发后，程序跳转至解析烧写命令帧分支，流程如图3 所示，若成功解析帧头、帧尾，保存命令帧中4 B 升级文件长度信息，将应用区Flash擦除标志位置1，关闭此分支，并打开环形缓冲分支。若未成功解析，则继续等待下一帧。

图3 CAN 接收中断函数流程

进入环形缓冲分支后，上位机下发的全部数据皆存储在环形缓冲数组中，每存储一条数据，写指针增加相应长度，当写指针指向到数组末尾时，重新跳转回数组首地址继续存储[6]，接收环形缓冲数组见图4。

图4 接收环形缓冲数组示意

3.5 主循环函数设计

主循环函数流程如图5 所示，循环判断Flash 擦除标志位是否为1，当标志位为1 时，表示接收到烧写指令，对应用程序Flash 扇区进行擦除，程序如下：

图5 主循环函数流程

待擦除完成，通过CAN 向上位机发送擦除成功指令，操作人员接收到成功指令，通过软件文件发送功能，将升级BIN 文件整体下发，软件下发设置为每50 ms 下发一帧，每帧长度为8 B。

主循环程序开始判断读取指针与写入指针位置指向的环形缓冲数组位置是否一致，若不一致，表明CAN 中断已成功接收部分BIN 文件数据，将新接收数据烧写至指定Flash 地址，移动读取指针，并累加记录烧写数据长度。若累加记录烧写长度与下发烧写长度(包含在烧写指令中)一致，则表示BIN 文件烧写完成，向上位机反馈烧写完成指令。待应用烧写完成后，跳转至应用程序，开始运行应用程序。

4 应用程序设计

应用程序根据使用实际需求进行代码编写，需要对应用程序CMD 文件进行设计，并调用CCS 编译工具将.out 文件生成.bin 文件。

4.1 应用程序CMD 文件设计

应用程序从FlashH 首地址开始存储，引导程序跳转至应用程序BEGIN 地址，实现应用程序启动[7]，应用程序CMD 文件设计代码如下：

4.2 应用程序生成BIN 文件

BIN 文件通过CCS 软件中的post-build 命令实现，CCS 安装时已经自动安装了一个工具mkhex4bin，可以将.out 文件转化成.bin 文件，通过在CCS post-build 中输入以下指令调用该工具：

通过编译，可直接在该工程Debug 子文件夹下生成升级用的BIN 文件。

5 试验验证

以TMS320F28335 系统板为验证平台，使用XDS100V3 JTAG 仿真器将引导程序预烧写至FlashA扇区， 验证试验 CAN 总线设备型号为USBCANFD200U，上位机CAN 通讯软件ZCANPRO是与设备相配套的标准软件。验证平台搭建完成后开始试验验证，验证操作步骤如下：

a)通过CCS 软件编写应用程序代码，生成BIN文件，测量BIN 文件总长度；

b)编写预烧写指令，格式为“2 B 帧头+4 B BIN文件总长度+2 B 帧尾”；

c)验证平台通过CAN 总线设备与上位机相连，打开上位机CAN 通讯软件，设置波特率，帧格式、帧类型、帧ID；

d)系统板上电，发送预烧写指令，待接收到Flash 擦除成功消息后，打开BIN 文件，开始BIN 文件发送，文件烧写过程如图6 所示。待烧写完成，引导程序跳转至应用程序起始地址，应用程序成功运行，表明验证成功。

图6 试验验证烧写过程

6 结论

本文介绍了一种通过CAN Bootloader 引导程序对TMS320F28335 芯片进行程序升级的方法，讨论了该芯片通过Flash 启动的流程机制，并对DSP 的链接命令文件(CMD 文件)、引导程序和应用程序进行相应设计。经过试验验证，该方法稳定可靠，能够通过CAN总线设备实现芯片程序在线升级，可以实现烧写一次引导程序，即可多次更新应用程序的功能。该方法已在实际现场调试中成功应用，解决了部分场景程序升级时设备需要拆卸的问题，提高了调试效率。