基于CAN总线的DSP28335 IAP在线升级方案与Bootloader设计详解

做DSP28335应用开发的人，基本都体会过一种尴尬：整机已经装配完毕，外壳固定好了，或者设备已经在现场跑了大半年，这时候突然要改一个控制参数、修一个不起眼的逻辑bug，拿JTAG下载器过去才发现，拆机麻烦不说，很多工业环境根本不允许你随意断电停产。我们当时就是在某台DSP28335控制器上做了在线升级(IAP)功能，利用控制器上现成的CAN总线做升级链路，上位机通过CAN逐包下发固件，下位机Bootloader负责擦写Flash、校验数据和跳转应用，整套流程基于CCS6.1.3的下位机工程联调成功。这篇文章就是把这套IAP+CAN方案的完整设计思路和实操过程整理出来，包括Flash分区、Bootloader架构、CAN升级协议、Flash API的使用细节，以及在联调阶段踩过的坑。想做28335这类C2000系列芯片在线升级的工程师，或者正在纠结用什么通信方式做远程固件更新的朋友，这篇应该能给你一些直接能用的参考。

1. 项目背景与方案选型：为什么偏偏是CAN总线做IAP

1.1 需求来源与设计目标

先说需求背景。当时要解决的设备是一个基于TMS320F28335的电机控制器，已经形成批量生产。开发阶段大家都在用JTAG口烧录程序，这没问题，但产品一旦发货到现场，后续的固件维护就变得非常痛苦。现场调试人员不可能扛着一台台式机加仿真器，更不可能把控制器从柜子里拆出来重新烧录。我们的核心目标非常简单：在不打开机壳、不连接JTAG、不中断主电路的前提下，通过设备已有的通信总线把新版固件写进Flash，并可靠跳转到新程序运行。

最初考虑过SCI串口升级，28335的SCI资源也够用，而且串口程序写起来简单。但在实际工业场景里，串口往往用来接触摸屏或者做调试输出，总线负载已经不小；更重要的是，串口通信的可靠性在长距离、强干扰环境下并不理想，一旦升级过程中出现误码，代价就是整台设备变砖。而CAN总线本身就是为工业环境设计的差分信号，抗干扰能力强，带CRC校验和错误重发机制，设备控制器里为了和上位机或其他节点通信早就布好了CAN网络，直接复用这条链路做固件传输，几乎不需要额外增加硬件成本。最终方案定为：CAN总线 + Bootloader在线升级，开发环境使用CCS6.1.3。

1.2 JTAG、SCI、CAN三种升级方式对比

这里把三种常见升级方式放在一起对比，方便还没定方案的读者做选型。

选型的时候我很明确，这玩意儿不是实验室里演示一把就完事，而是要长期在产线设备和现场设备上跑的。串口方案看起来开发容易，但到了现场，线缆五花八门，共地问题、信号衰减问题会折腾死人。CAN的报文机制天然适合打包传输，而且大部分28335控制器项目里本来就有CAN通信，不管是和上位机、触摸屏还是其他控制器交互，硬件上已经是现成的。就算让我重新选择一次，我依然会选CAN。

1.3 IAP整体逻辑链

这套IAP方案由两部分程序构成：一个是常驻Flash最前端的Bootloader，负责上电引导和固件接收；另一个是用户应用App，也就是真正干活的逻辑代码。升级的本质逻辑链如下：

上位机通过CAN发送升级握手命令 -> Bootloader进入升级模式 -> 擦除应用区Flash -> 上位机分包发送固件 -> Bootloader逐包接收并写入Flash -> 全部接收完成后校验数据 -> 校验通过，跳转至App运行

关键点在于，Bootloader和App是两套独立的工程，有各自的链接文件（CMD）、中断向量表和程序入口。为什么Bootloader要独立成工程而不是和App混在一起？因为Flash擦写最怕写坏了没法恢复，Bootloader必须在任何时候都能独立启动，哪怕App区域已经完全崩溃。这一块在后面的Flash分区里会详细说。

2. Flash分区策略与Bootloader架构设计

2.1 28335 Flash结构简析与分区规划

TMS320F28335的片上Flash从地址0x300000开始，整体大小256K×16位，分成若干扇区。不同扇区大小不完全一样，擦除的最小单位是扇区。设计升级方案时，第一件事就是把Flash空间重新划分清楚，不能让App随意占满全部Flash，否则Bootloader没有地方放，升级标志也没地方存。

我们当时的分区大致是这样：

• Bootloader区：0x300000 ~ 0x304000，16K字，放上电引导代码和CAN升级代码
• 应用App区：0x304000 ~ 0x33E000，约232K字，放用户业务程序代码和中断向量表
• 参数/升级标志区：0x33F000 ~ 0x33F800，独立扇区，存放升级标志、固件版本、固件长度、CRC校验值等

要注意的是，这两个程序的CMD文件必须严格按上面的地址范围来做MEMORY定义，否则Bootloader编译出来几百字节也许没问题，App编译结果一旦超出App区边界，就可能覆盖到Bootloader的代码空间，导致下次上电引导直接失败。这是分区设计时最容易犯的错误，后面联调阶段我会讲具体现象。

之所以把升级标志和参数从App代码空间里单独拿出来，是因为：当Bootloader需要判断“是直接跑App还是进入升级模式”时，它不能依赖App里的全局变量，因为App一旦崩溃，这些变量就不可信了。Flash里的参数区才是唯一可靠的信息源。每次准备升级前，上位机先发一条命令，Bootloader在参数区写入“升级请求”标志并复位；上电后Bootloader读取该标志，有就留在Bootloader等待CAN数据，没有就直接跳App。

2.2 Bootloader的职责边界

设计Bootloader时，我已经给自己划好了一条红线：能不做的事坚决不做，越简单越可靠。Bootloader不是操作系统，不需要支持复杂调度，它的核心职责只有四件事：

1. 初始化基础外设（时钟、看门狗、CAN、串口调试口）
2. 根据Flash参数区的标志决定是进入升级流程还是跳转App
3. 在升级模式下，接收、解析、存储CAN报文，并驱动Flash擦写API完成固件落地
4. 完成校验后跳转App

很多新手在写Bootloader时会不自觉地把App里的一堆外设初始化代码拷过来，实际上完全没必要。Bootloader里只需要初始化它自己会用到的外设即可，App启动后还会重新做一套完整的系统初始化。当时我们为了调试方便，在Bootloader里单独接了串口打印，用SCI输出些状态信息，这个串口和App的串口是各自独立初始化的，互不影响。

2.3 上电引导流程与升级标志位

上电后的引导判断流程如下：

void main(void) { // 系统初始化：时钟、看门狗、CAN、SCI InitSysCtrl(); InitCan(); InitSci(); // 读取参数区的升级标志 upgrade_flag = ReadParamFlag(); if (upgrade_flag == UPGRADE_REQUEST) { // 停留在Bootloader，执行CAN升级流程 RunBootloader(); } else { // 正常运行标志，跳转App JumpToApp(APP_START_ADDR); } while(1); }

这个判断逻辑看起来简单，但要注意：参数区的读取必须是硬件层面的直接读Flash，不能用任何可能被App修改过的缓存副本。另外，升级完成后要立刻擦除升级标志，或者写成“升级完成标志”，避免下次又重复进入Bootloader。我们实际调试时遇到过一次“升级完了重启又进入Bootloader”的怪现象，排查到最后就是标志位没擦干净，Bootloader读到的还是旧标志。

3. 基于CCS6.1.3的工程实现：CAN协议与Flash API联调细节

3.1 CCS6.1.3工程结构与链接文件设置

CCS6.1.3是基于Eclipse框架的集成开发环境，创建DSP28335工程时，一般都会基于官方库或团队沉淀的底层库来搭。我在做这个项目时，工程结构大致包含：DSP2833x_common和DSP2833x_headers公共库部分、自己写的板级驱动（CAN、SCI、Flash操作）、以及Bootloader或App的主逻辑代码。

对Bootloader工程而言，最核心的配置点是CMD文件。我的Bootloader CMD文件写出来大概是这个意思：

MEMORY { PAGE 0: BOOT_FLASH : origin = 0x300000, length = 0x004000 APP_FLASH : origin = 0x304000, length = 0x03A000 PARAM_FLASH : origin = 0x33F000, length = 0x000800 BOOT_RAM : origin = 0x008000, length = 0x000800 APP_RAM : origin = 0x009000, length = 0x001000 } SECTIONS { .text :> BOOT_FLASH, PAGE = 0 .cinit :> BOOT_FLASH, PAGE = 0 .switch :> BOOT_FLASH, PAGE = 0 .stack :> BOOT_RAM, PAGE = 0 .ebss :> BOOT_RAM, PAGE = 0 .econst :> BOOT_FLASH, PAGE = 0 // Flash API代码段复制到RAM运行 .TI.ramfunc :> APP_RAM, PAGE = 0 }

App工程的CMD则完全不同，它的MEMORY范围只能落在APP_FLASH段对应的地址空间，并且中断向量表也要放到App区。如果两个工程的地址空间有重叠，生成出来的hex文件烧进去后，Bootloader和App会互相覆盖，这属于绝对要避免的低级错误。每次改动CMD文件后，我都习惯先编译一次看map文件，确认.text段和全局变量落在哪个地址，再决定要不要继续往下测。

3.2 CAN驱动与升级协议字段设计

CAN驱动本身不算难，28335的DSP内部集成CAN控制器（DCAN模块），支持标准帧和扩展帧。我们CAN总线波特率配置为1Mbps，采样点约75%，这个配置在项目里的其他CAN节点上已经验证过稳定性，升级通道直接沿用，没有为升级单独降低速率。速率的设置要结合CAN时钟和CANBTC寄存器里的BRP、TSEG1、TSEG2参数计算，这里不展开推导，只提醒一句：上位机和下位机用的波特率采样点必须一致，否则经常出现一帧都收不到或者只有短报文能通过的现象。

升级协议是我们自定义的，基于CAN标准帧，ID分配如下：

固件数据帧因为CAN单帧载荷只有8字节，我们定义的数据区格式为：

为什么只留6字节有效负载而不是直接8字节全做数据？因为我们需要在每一帧里携带包序号和结束标志，否则Bootloader无法判断数据边界，也无法应对重传场景。经过这么一设计，一帧CAN报文实际能传6字节，一个256KB的App大约需要传4万多帧，按1Mbps速率跑，实际传输时间大概一两分钟。这个速度在工业现场升级的场景下完全可以接受，毕竟升级不是一个频繁操作。

握手和应答机制也值得一提。上位机发握手帧0x100后，Bootloader收到就回复0x101，并在回复报文里携带当前Bootloader版本和App区状态。如果Bootloader回复“App区无有效程序”，上位机就必须走全量升级流程。收到数据帧后，Bootloader每收一帧就回复一帧0x103，携带当前累计接收的字节数，上位机把它当作进度反馈。不建议上位机一口气把所有包全发完再等结果，因为CAN接收FIFO深度有限，Bootloader擦写Flash的时候没法同时处理CAN中断，丢帧几乎不可避免，所以逐帧应答、超时重传才是最稳的策略。

3.3 Flash API的正确集成方式

DSP28335的Flash擦写必须使用TI提供的Flash API函数，不能像单片机那样直接往Flash地址写数据。这里最容易被坑的一点是：Flash API的代码本身放在Flash中，但在擦写Flash期间，CPU不能从Flash取指令，否则程序直接跑飞。解决办法是把Flash API从Flash复制到RAM中运行。

我们在CCS6.1.3工程中的做法大致是：

extern Uint16 Flash28335_Erase(Uint16 *FlashStart, Uint16 *Buffer, Uint16 NumberOfSectors); extern Uint16 Flash28335_Program(Uint16 *FlashStart, Uint16 *Buffer, Uint32 Length); #pragma CODE_SECTION(Flash28335_Erase, ".TI.ramfunc"); #pragma CODE_SECTION(Flash28335_Program, ".TI.ramfunc"); void InitFlashApi(void) { external FlashApiCopy ; // 实际工程里定义一个复制函数 memcpy(&RamfuncsRunStart, &RamfuncsLoadStart, (Uint32)&RamfuncsLoadSize); }

在CMD文件里，我已经把.TI.ramfunc段定义到了RAM区，并且用了load和run地址分开的方式：加载地址放在Flash，运行地址放在RAM。这样，程序上电后通过一段复制代码，把Flash里的API函数实体从Flash搬运到RAM，之后所有擦写操作都是在RAM中执行代码，就不会存在“指令取自正在被擦除的Flash区域”这种自毁操作了。

擦除和编程的耗时也要有心理准备。F28335的Flash擦除是按扇区来的，一个扇区的擦除时间可能到百毫秒级别。这段时间内不能有中断干扰，否则Flash状态机可能出错。如果系统里有重要实时任务依赖中断，也必须先把中断屏蔽掉，擦完再开。更稳妥的做法是关闭全局中断，以空间换时间。

3.4 App工程侧的中断向量表重映射

App工程并不是简单地把代码链接到0x304000就完事了。28335的中断向量表属于PIE向量表，它默认在RAM里。Bootloader运行的时候，PIE向量表指向的是Bootloader自己的中断服务函数；跳转到App之后，PIE向量表必须重新初始化成App的服务函数，否则任何一个中断进来，都有可能跳到一个已经被覆盖或失效的地址，导致系统异常。

在App工程里，main函数的第一件事通常就是：

void main(void) { // 禁止全局中断 DINT; // 初始化PIE控制寄存器 InitPieCtrl(); // 屏蔽所有PIE中断 IER = 0x0000; IFR = 0x0000; // 初始化PIE向量表，把新App的中断服务函数挂进去 InitPieVectTable(); // 重新使能需要用到的外设中断 EALLOW; PieVectTable.CANINT0 = &CAN_ISR_App; EDIS; // 开始执行业务逻辑 ... }

为什么这一步如此关键？因为跳转之后，CPU的程序计数器指向App入口，但中断系统还是Bootloader留下的配置。如果不重置PIE向量表，一旦CAN中断或者定时器中断发生，CPU直接跳进一个早已不存在的Bootloader中断函数里，运行结果不可控。我们联调时出现过“升级成功后App跑了一个多小时，突然一次CAN中断就死机”的情况，排查到最后就是App侧中断向量表没有及时重映射，这个问题有一定隐蔽性，因为可能跑很久才触发一次对应中断，很难第一眼定位。

3.5 跳转实现与SP栈指针处理

跳转本身不复杂，关键是跳转前的现场清理。代码示意如下：

#define APP_START_ADDR 0x304000 void JumpToApp(Uint32 appAddr) { void (*pAppEntry)(void); // 关闭看门狗 EALLOW; SysCtrlRegs.WDCR = 0x0068; EDIS; // 关闭所有中断 IER = 0x0000; IFR = 0x0000; DINT; // 跳转前把PIE向量表恢复成默认值，防止App初始化前有中断渗入 EALLOW; InitPieVectTable(); EDIS; pAppEntry = (void (*)(void))appAddr; pAppEntry(); }

这里有个隐藏很深的问题：Bootloader的栈空间可能和App的栈空间位置不同。如果直接在Bootloader的C环境里用函数指针调用App入口，App执行后用到的栈可能还是Bootloader时期的栈，栈大小不够或地址不对，运行一段时间后变量被冲掉，表现为偶发死机。稳妥的做法是在跳转前，把SP指向App规定的栈顶。这个地址可以通过App工程的CMD文件里的符号拿到。我当时在App的CMD里给栈顶定义了一个全局符号，然后在Bootloader里用extern声明引用，跳转前用内联汇编把SP设过去，测试下来稳定多了。

extern Uint16 AppStackTop; asm(" MOV SP, #_AppStackTop");

这种写法在不同CCS版本里汇编语法略有差异，但思路是一致的：别让App跑到一半才发现栈不对。

4. 联调过程实录与常见问题排查

4.1 联调前的准备工作

联调前，我准备了三样东西：一块带CAN接口的USB分析卡，一台装有CCS6.1.3的电脑，还有一台串口调试助手用来显示Bootloader日志。CAN分析卡负责模拟上位机发送握手帧和数据帧，CCS负责看到底是Bootloader卡在Flash擦除还是卡在CAN接收。其实有条件的话，建议用CCS连上JTAG一边跑一边看变量，但现场场景下JTAG连不上，所以我在Bootloader里埋了不少状态变量，通过串口打印出来。

联调的完整步骤是这样：

1. 给控制器上电，Bootloader从参数区读到“无升级标志”，直接跳转App，App正常运行
2. 上位机发送0x100握手帧，Bootloader收到后，在参数区写入升级标志，并回复0x101
3. 上位机再发送复位指令（或者确认Bootloader已经复位进升级模式），控制器重新上电，Bootloader读到升级标志，留在Bootloader
4. 上位机发0x102固件数据帧，Bootloader逐帧接收并写入Flash
5. 发最后一帧，Bootloader写入长度信息和CRC
6. 上位机发送0x104校验请求，Bootloader对App区做CRC校验，返回0x105，内容为校验结果
7. 校验通过，Bootloader清升级标志，跳转App

实际联调中，这些步骤并不是一次就跑通的，问题主要集中在中后段。

4.2 典型问题：Flash擦写期间看门狗复位

第一次测试升级流程时，Bootloader收到上位机发来的擦除命令后，程序就自动复位了。从串口日志看，擦除刚开始执行，整个控制器就重启，重启后Bootloader又收到上位机的数据帧，但由于Flash没有擦干净，写入报错。

排查后确认：看门狗没有在擦除前关闭或喂狗。Flash擦除一个扇区要百毫秒量级，默认的看门狗周期只有几十毫秒，可不就复位了。解决办法很简单，在EALLOW/EDIS保护下把看门狗关掉，或者在一个超长循环里定期喂狗。我选择先关狗，因为升级期间本身不应该有其他任务干扰，而且Flash擦除过程中喂狗要保证喂狗指令不会正好落在Flash操作的关键状态机间隙里，控制不好反而更危险。

顺带说一句，关闭看门狗的口令要写在擦除代码的入口处，不能放在初始化时。因为如果App运行一段时间后调用了跳转Bootloader的指令，等Bootloader再跑到擦除点时，看门狗可能早就该复位了。把关狗动作放在真正需要的时间点，能减少误复位。

4.3 典型问题：Flash API代码未复制到RAM导致跑飞

这个问题出现的时机在第一次完整联调时。当时我图省事，没有在CMD里专门定义.TI.ramfunc段，也没执行复制，直接在Bootloader代码里调用了TI官方的Flash28335_Erase函数。结果就是：上位机收到握手响应，发送擦除命令后，Bootloader没有任何串口输出，控制器直接死灯。

把程序跑到擦除调用处单步跟踪，发现PC指针跳到一个完全无效的地址，程序卡死在非法指令陷阱里。原因前面讲过：擦除操作还没有开始，CPU在Flash里取擦除函数指令，Flash控制器忙起来后，取指总线直接异常。把Flash API复制到RAM后再调用，问题立即消失。

这是整个联调中印象最深的一个坑，也值得所有做28335升级方案的人反复确认。有些人可能觉得官方例程里擦写函数能直接调，为什么自己的工程就不行，问题往往就出在CMD文件没有给API代码分配RAM运行空间。

4.4 常见问题速查表

我把联调中遇到的其他问题整理成一张速查表，方便你对照排查：

4.5 升级失败后的恢复策略

这套方案还做了一个很实际的保护：如果升级过程中途掉电或者传输断开，Bootloader下一次上电时发现参数区里存在“升级请求”标志，但App区的CRC校验结果不对，就不会贸然跳App，而是停留在Bootloader继续等待上位机重新发送固件。也就是说，哪怕升级中途失败，设备也不会变成死砖，只要重新走一遍升级流程就能救回来。

实现这个逻辑的关键点，是在每次上电决定跳转之前，都对App区做一次快速合法性检查。检查内容包含：App区首个地址是否为有效的程序入口、固件长度是否匹配参数区记录、CRC校验值是否一致。只有三项全通过，才允许跳转。这个检查虽然会花费几十毫秒，但换来的可靠性非常值。

5. 性能优化与工程经验总结

5.1 升级速度与稳定性如何平衡

按照我们的协议设计，单帧有效负载6字节，总固件大小约200KB时需要发送约34000帧。1Mbps波特率下，每帧耗时约0.2ms，纯数据发送时间约7秒。但实际还包含逐帧应答、Flash写入耗时和擦除时间，整个升级过程大约两三分钟。这个速度对于工业现场来说完全可以接受，因为升级本身就是低频操作。

如果你觉得这个速度太慢，可以考虑把单帧有效载荷提到7字节或8字节，然后把包序号用单独一个字段压缩到3位，或者改用扩展帧一次传更多标志位。但每帧载荷增加就意味着单帧信息量变大，一旦某帧出错，重传代价也变大，所以并没必要一味追求极限速度。稳，才是升级通道的第一需求。

另外，实际项目里可以在Bootloader里加一个“静默超时”机制：如果连续若干秒没有收到任何CAN帧，Bootloader判定升级失败，自动清标志并跳回App。现场好处是，即使有人误触发了升级模式但没继续操作，设备也会自动恢复正常运行，不用人工干预。

5.2 灰度升级与版本回退的一点建议

如果产品线里有多台控制器，建议在第一台上验证完整升级流程，再批量刷。我在某台样机上先刷了Bootloader，再反复升级、降级App，确认整条链路稳定后才铺开到其余设备。另外，升级前一定要让上位机读回当前App区的版本号，和将要升级的版本号做比对，防止拿旧固件覆盖新固件，这个低级错误在产线上真出现过。

如果要更稳妥，可以再做一个简单的备份区方案：把上一版正常运行的固件保留在另一个Flash分区里，新固件写入后再切换。这样即使新固件本身有bug，Bootloader还能自动回退到旧版本。28335的空间虽然不算特别宽裕，但200多K的App区，如果业务程序不是特别大，是可以挤出30~40K做备份的。

5.3 我个人在实操中的一点体会

整套IAP+CAN在线升级方案做下来，我最深的感受是：写Bootloader并不难，难的是把所有失败路径都考虑到。很多人第一次做完升级功能，只是在“一切顺利”的前提下跑通了流程，于是信心满满地上现场，结果一次掉电、一根坏线、一个没按住的看门狗就全暴露了。我后来养成了一个习惯，每次烧完新固件，都会故意在上位机发送到一半的时候拔掉CAN线，测试Bootloader能不能自动复位或等重传；也会在上位机发完校验帧之前强行断电，看看下次上电能不能恢复正常。多模拟几次异常场景，比在实验室多跑十遍正常流程管用得多。

这个方案现在已经稳定跑了好几个月，后来还顺手把CRC校验从累加和升级成了CRC32，协议层也加了简单的加密混淆，防止产线上有人随便抓包刷固件。对于大多数DSP28335项目来说，这套CAN+IAP的框架已经完全够用，如果你也准备给自己的设备加在线升级，照着这个思路去搭，应该能少走不少弯路。