企业官网建设流程全解析

说实话，给TMS320F28377D做Bootloader这件事，我开始是拒绝的。这芯片是双核200MHz，Flash有512KB，又有DCSM安全模块，光看TI的Boot ROM文档就能把人绕晕。但当我真正开始做电机控制产品，板子装到机箱里，客户一个电话说要改控制参数，我就知道：没有Bootloader，后面的维护成本会高到让人崩溃。

这篇文章把我在F28377D上设计串口Bootloader的全过程、完整CMD配置和踩过的坑都写出来了。不保证是最优解，但每一步都是实打实跑通的。适合正在做C2000系列产品化、需要实现固件升级功能的工程师，也适合对F28377D启动机制和Flash分区还比较模糊的入门者。看完你至少能获得一个可以照抄的框架。

1. 为什么F28377D必须做Bootloader？先搞懂启动链路

1.1 应用场景：从量产到现场维护都躲不开

我做这个Bootloader的初衷很朴素：产品已经交付，不能每次升级都拆机接JTAG。F28377D虽然在板子上留了JTAG接口，但实际工业现场根本没条件让你扛着仿真器到处跑。有了Bootloader，串口或者CAN就能完成固件刷新，维护成本直接降一个量级。

另外一个很重要的场景是量产烧录。生产线上使用TI的UniFlash批量烧录Bootloader和App，效率其实不高，尤其是每个板子都要单独烧一遍完整镜像。有了Bootloader之后，工厂只需JTAG烧录一次Bootloader，剩下全部走串口升级。这样烧录速度快，而且烧录程序一致性好。我们实际用921600波特率刷192KB的App，大概十几秒就完成，比UniFlash快太多。

1.2 F28377D上电后的启动链路

F28377D上电后的执行流程大概是这样的：CPU1先被释放，从Boot ROM开始执行。Boot ROM会读取Boot Mode引脚（或对应的寄存器配置），然后根据不同的模式跳转到不同入口，比如SCI Boot、CAN Boot、Flash Boot等。

生产环境中我们几乎总是使用Flash Boot。在这个模式下，Boot ROM会跳到Flash地址0x080000处，也就是Flash的起始位置。0x080000处存放的是谁的代码，CPU就跑谁的代码。所以整个Bootloader的核心思想就是：0x080000放Bootloader，App放到后面的Flash区域，Bootloader通过判断标志决定是直接跳App还是进入升级模式。

这里有个关键点容易被忽略：F28377D的App入口不是一条固定地址的跳转指令，而是一段叫codestart的段。CCS工程模板会自动生成这个段，里面放着一条LB _c_int00指令，用来跳转到C运行环境初始化。所以我们在做Bootloader时，必须把这个codestart段放到指定Flash地址，App工程的codestart也要放到约定的App起始地址。后面讲CMD配置时会详细展开。

1.3 Bootloader的职责边界

设计Bootloader之前一定要想清楚它该干什么、不该干什么。我的原则是：Bootloader越简单越好，复杂功能尽量全部交给App处理。

Bootloader只做这几件事：

• 上电后读取升级标志，决定进入升级模式还是跳转App。
• 通过串口接收固件数据，写入Flash。
• 校验固件完整性。
• 跳转到App。

它不应该做的事很多：不要在里面跑复杂的文件系统，不要做大量的协议解析，更不要写业务逻辑。Bootloader一旦做大，出问题的概率就成倍增加，而Bootloader出问题往往是灾难性的。我见过有人想在Bootloader里加入加密算法和压缩解压，最后把自己绕进去了，这里强烈不建议。

2. 总体设计：先把Flash分区和通信协议定死

2.1 F28377D的Flash/RAM资源盘点

TMS320F28377D的Flash总容量是512KB，起始地址0x080000，结束地址0x0FFFFF。官方按Sector管理，总共16个Sector，每个Sector大小32KB，其中Bank 0对应Sector 0到7，Bank 1对应Sector 8到15。擦除操作的最小单位是一个Sector，写操作则按128位（16字节）对齐执行。

RAM方面，F28377D总共有200KB左右的RAM，分布在M0、M1、LS0-LS7以及全局RAM区域。Bootloader运行时虽然占不了多少RAM，但因为Bootloader需要把Flash API拷贝到RAM中执行，所以至少要预留一个较大的RAM段做代码执行区。

在动手写代码之前，把这些资源搞清楚很重要。很多人做Bootloader翻车，就是因为在Flash擦写过程中CPU去读了一段已经被擦掉或者正在被写入的Flash内容，导致CPU直接跑飞。后面的设计会专门规避这个问题。

2.2 Flash分区：对齐Sector是底线

给F28377D做分区时，我强烈建议所有区域都对齐到Sector边界，也就是32KB的整数倍。这样擦除时只擦目标区域，不会误伤相邻区域。我的实际分区如下：

Bootloader只占32KB，实际上我们的Bootloader在优化后不到16KB，非常宽裕。Sector 1专门用来保存升级标志和App的有效信息，这个区域在App的正常运行中不会去写，只有升级流程才会修改。

预留区目前没用到，但将来如果要支持双镜像备份和回滚机制，这个区域就是A/B镜像的舞台。现在先留着，不影响当前功能。

App区起始地址是0x090000，跳转目标地址也就是它。需要提醒的是，一旦分区定了，两个工程（Bootloader和App）的CMD文件就要把这些地址用宏或者常量统一约定好，不要在代码里到处飘数字。

2.3 串口升级协议：帧格式、命令字与校验

通信协议是整个Bootloader另一条命脉。我选择SCI串口作为升级通道，因为F28377D的SCI外设稳定、实现简单，多数产品板上也都会引出串口。波特率我用的是460800，实测在一般的连接线缆下非常稳定，线材差一点也能扛住。如果想更快，921600也没问题，但需要保证连接线短、地线可靠。

协议帧格式如下：

// 帧结构：帧头 + 命令 + 地址 + 长度 + 数据 + CRC32 // 帧头：0xAA 0x55 // 命令：1字节 // 地址：4字节（小端） // 长度：2字节（小端，最多2048） // 数据：N字节（N = 长度） // CRC32：4字节，覆盖"命令+地址+长度+数据"

命令字定义：

协议交互流程是：上位机先发SYNC握手，成功后发ERASE擦除整个App区，然后按帧发送PROGRAM，每帧最大2048字节，Bootloader写完一帧后回ACK，上位机收到ACK再发下一帧。全部发完后发VERIFY，Bootloader将Flash中的数据和CRC结果返回，上位机对比通过后发JUMP命令，Bootloader跳转App。

每帧都要等ACK的设计看起来会牺牲一点速度，但可靠性大幅提升。尤其是在整个Flash擦写过程中，Bootloader需要时间完成操作，上位机等ACK反而是天然的保护机制。

3. CMD文件配置：让链接器把代码放对位置

3.1 Bootloader工程的CMD关键段解析

CMD文件的作用就是告诉链接器：什么段放在什么内存区域。Bootloader工程里，最关键的一点是让codestart段落在Flash起始地址0x080000，其他代码段紧随其后，同时把Flash API相关函数放到RAM中执行。

下面是我整理后的Bootloader工程CMD文件，为了便于理解，删减了F28377D用不到的内存区域：

MEMORY { /* RAM区域 */ RAMM0 : origin = 0x000000, length = 0x000400 RAMM1 : origin = 0x000400, length = 0x000400 RAMGS0 : origin = 0x00C000, length = 0x001000 RAMGS1 : origin = 0x00D000, length = 0x001000 /* Flash区域 */ FLASH_BL : origin = 0x080000, length = 0x007000 FLASH_PARAM : origin = 0x087000, length = 0x001000 } SECTIONS { codestart : > FLASH_BL .text : > FLASH_BL .cinit : > FLASH_BL .const : > FLASH_BL .switch : > FLASH_BL .stack : > RAMM1 .ebss : > RAMGS0 .cio : > RAMGS0 .sysmem : > RAMGS1 /* Flash API代码段放到RAM运行 */ .TI.ramfunc : LOAD = FLASH_BL, RUN = RAMGS1, LOAD_START(_RamfuncsLoadStart), RUN_START(_RamfuncsRunStart), SIZE(_RamfuncsLoadSize) }

codestart是F28377D上电从Flash启动时最先执行的段，里面就是一条跳转到_c_int00的指令，它必须严格放在0x080000处。如果你在CCS工程中查看生成的map文件，应该能看到codestart的地址就是0x080000。

.TI.ramfunc段非常重要。Flash API库的所有函数都要标成ramfunc属性，或者用#pragma CODE_SECTION把它们放到.TI.ramfunc段里。因为Bootloader自身运行在Flash中，而Flash API要做的事情恰恰是擦除/写入Flash。如果在擦写Flash的过程中，CPU去取一条还在Flash里的指令，而那个区域恰好正在被擦掉，CPU直接取指失败。解决方式就是把这些函数在启动时拷贝到RAM中执行。

拷贝的代码在main函数开头用memcpy完成，配合_RamfuncsLoadStart等链接器生成的符号。这几个符号由CMD文件中的LOAD_START、RUN_START、SIZE自动生成，不需要手动定义。

3.2 App工程CMD如何避开Bootloader

App工程的CMD文件同样重要，而且更容易出错。App不能覆盖Bootloader的Flash区域，也不能在RAM使用上和Bootloader起冲突。好消息是跳转到App之后，Bootloader所占用的RAM可以被完全覆盖，因为App会重新初始化自己的运行环境。

App工程的CMD文件中，主要改动如下：

MEMORY { RAMM0 : origin = 0x000000, length = 0x000400 RAMM1 : origin = 0x000400, length = 0x000400 RAMGS0 : origin = 0x00C000, length = 0x001000 RAMGS1 : origin = 0x00D000, length = 0x001000 RAMGS2 : origin = 0x00E000, length = 0x001000 RAMGS3 : origin = 0x00F000, length = 0x001000 FLASH_APP : origin = 0x090000, length = 0x030000 } SECTIONS { codestart : > FLASH_APP .text : > FLASH_APP .cinit : > FLASH_APP .const : > FLASH_APP .switch : > FLASH_APP .stack : > RAMM1 .ebss : > RAMGS0 .cio : > RAMGS0 .sysmem : > RAMGS1 .TI.ramfunc : LOAD = FLASH_APP, RUN = RAMGS2, LOAD_START(_RamfuncsLoadStart), RUN_START(_RamfuncsRunStart), SIZE(_RamfuncsLoadSize) }

App的codestart要放在0x090000，因为Bootloader跳转时就跳到这个地址。你可能会问：Bootloader跳过来时，codestart里是什么？和Bootloader自己的启动过程一样，codestart是一段跳转到_c_int00的指令，App正是在这里完成C环境的初始化。

CMD文件是Bootloader和App之间的隐藏契约。建议在两个工程中都加上编译期检查，比如在代码里定义一个常量APP_START_ADDR，Bootloader在跳转前用它来校验当前地址，App工程里用它来确认链接器指令位置，防止改CMD时两边没同步。

3.3 两个工程RAM段不冲突的注意点

F28377D的双核架构下，CPU1和CPU2各有自己的RAM和共享RAM。默认情况下，CPU1的局部RAM段从0x000000开始，全局共享RAM段从0x00C000开始。Bootloader跳转前虽然不需要刻意清理RAM，但有一个细节必须注意：App的.stack段不要和Bootloader跳转前正在使用的栈区域完全错开，以免App初始化前压栈出问题。

实操中，两个工程都使用RAMM1作为.stack，RAMGS0作为.ebss，这在跳转时没有问题。因为Bootloader通过函数指针跳转时，压栈在栈顶，而进入App的codestart后第一条指令就是跳到_c_int00，它会重新初始化SP。只要SP所指的内存物理存在，就不会出问题。

唯一的坑是：如果你在Bootloader中用了大量全局变量，并且这些变量所在的RAM区域被App的.ebss覆盖，跳转瞬间会怎样？答案是没问题，因为Bootloader已经不再使用这些变量了。但如果Bootloader的某些外设中断在跳转瞬间还在产生，中断向量表又在RAM中，而App还没重新初始化PIE，就可能触发一次异常。所以跳转前关全局中断、清外设中断标志非常必要，这个在第4节会详细讲。

4. 关键代码实现：接收、擦写、跳转的完整闭环

4.1 Flash API的正确使用姿势

TI在C2000Ware里提供了F2837xD的Flash API库，实际上是一组带ramfunc属性的C函数。这组函数不能直接从Flash里调用，必须拷贝到RAM。使用流程分三步。

第一步，在链接层面把Flash API代码段放到.TI.ramfunc，这个上面CMD已经做了。

第二步，在代码中声明外部符号并拷贝：

extern uint16_t RamfuncsLoadStart; extern uint16_t RamfuncsLoadEnd; extern uint16_t RamfuncsRunStart; void initFlashRamFuncs(void) { memcpy((uint32_t *)&RamfuncsRunStart, (uint32_t *)&RamfuncsLoadStart, (uint32_t)&RamfuncsLoadEnd - (uint32_t)&RamfuncsLoadStart); }

第三步，调用Flash API执行擦除和编程。这里要特别提醒，不同版本的C2000Ware中Flash API函数原型有所区别。我以当前常用版本为例：

#include "FlashAPI_F2837xD.h" // 擦除App区Sector 2-7 #include <flash_api.h> uint16_t eraseAppSectors(void) { uint16_t status = 0; uint16_t sectorMask = 0; // 按位设置要擦除的Sector：Sector 2到7 sectorMask = FLASH_SECTOR_2 | FLASH_SECTOR_3 | FLASH_SECTOR_4 | FLASH_SECTOR_5 | FLASH_SECTOR_6 | FLASH_SECTOR_7; status = Flash_Erase(FLASH0CTRL_BASE, sectorMask, FLASH_WRITE_WAIT_STATE_COUNT); if (status != STATUS_SUCCESS) { return status; } // 擦除后校验，确认全部为0xFF status = Flash_VerifyErase(FLASH0CTRL_BASE, sectorMask, FLASH_WRITE_WAIT_STATE_COUNT); return status; }

编程函数则按帧写入：

uint16_t programAppData(uint32_t dstAddr, uint16_t *buf, uint16_t len) { return Flash_Program(FLASH0CTRL_BASE, dstAddr, buf, len, FLASH_WRITE_WAIT_STATE_COUNT); }

有两个参数需要特别关注。一个是FLASH0CTRL_BASE，这是F28377D Flash控制器寄存器的基地址，具体值在头文件里定义，直接用宏即可。另一个是等待状态数FLASH_WRITE_WAIT_STATE_COUNT。F28377D在200MHz主频下，Flash读取等待状态一般配置为4，写入等待状态要参照Flash API手册。如果这个参数设错了，Flash操作会不稳定甚至直接失败。

我在第一次调试时曾经在200MHz下用过默认的等待状态值3，结果擦除偶尔成功、偶尔返回错误，排查了很久才发现是等待状态位数不对。后来把每个API调用都打印返回状态，才定位到这个问题。建议你用仿真器跟踪一下Flash API的返回值，不要盲目信任函数执行成功。

4.2 串口状态机与解析流程

串口接收不能简单用一个中断然后逐字节进数组就完事了。Bootloader的接收必须设计成状态机，才能处理粘包、断帧、错位这些实际串口通信中一定会遇到的问题。

我设计的接收状态机如下：

#define FRAME_HEAD1 0xAA #define FRAME_HEAD2 0x55 #define FRAME_BUF_LEN 2060 // 2048数据 + 帧头2 + cmd1 + addr4 + len2 + crc4 typedef enum { WAIT_HEAD1 = 0, WAIT_HEAD2, WAIT_CMD, WAIT_ADDR, WAIT_LEN, WAIT_DATA, WAIT_CRC, FRAME_DONE } FrameState; FrameState frameState = WAIT_HEAD1; uint8_t rxBuf[FRAME_BUF_LEN]; uint16_t rxIndex = 0; uint16_t frameDataLen = 0; void sciRxISR(void) { uint8_t ch = ScibRegs.SCIRXBUF.all & 0xFF; switch (frameState) { case WAIT_HEAD1: if (ch == FRAME_HEAD1) { rxBuf[0] = ch; frameState = WAIT_HEAD2; } break; case WAIT_HEAD2: if (ch == FRAME_HEAD2) { rxBuf[1] = ch; rxIndex = 2; frameState = WAIT_CMD; } else { frameState = WAIT_HEAD1; // 重新等帧头 } break; case WAIT_CMD: rxBuf[rxIndex++] = ch; frameState = WAIT_ADDR; break; case WAIT_ADDR: rxBuf[rxIndex++] = ch; if (rxIndex == 6) // 2 + 1 + 4 = 7? 这里根据实际索引调整 frameState = WAIT_LEN; break; // ... 后续按帧结构推进 } }

这个状态机的核心思路是：任何一字节不符合当前状态，就回到WAIT_HEAD1重新开始，这样可以保证即使上位机发来一堆垃圾字节，也能在正确的AA 55帧头出现时恢复同步。

在接收数据帧时，我还会维护一个接收超时计数器。如果超过一定时间没有收到下一字节，就认为当前帧已经结束，丢弃并回到初始状态等待新帧。这个细节在SDRAM式的调试中看起来没什么，但实际现场线缆干扰、静电跳变都可能造成数据中断。没有超时机制，Bootloader会在WAIT_DATA状态卡死，后续所有命令都无法响应。

代码里的rxIndex == 6这类边界判断容易写错，建议用结构体解析，而不是靠裸数组索引。我工作里常用的方式是定义一个Union，把收到的字节流直接映射到帧结构体上，既清晰又不容易下标越界。

4.3 从Bootloader安全跳转到App

跳转看起来就是调用一个函数指针，但实际操作中有很多现场才爆的坑。我的跳转函数长这样：

#define APP_START_ADDR 0x090000 #define APP_ENTRY_MODE_BIT 0x1 // C28x函数指针最低位 void jumpToApp(void) { // 1. 关闭全局中断和PIE DINT; IER = 0x0000; IFR = 0x0000; PieCtrlRegs.PIECTRL.bit.ENPIE = 0; // 2. 禁看门狗（App重新配置前防止意外复位） ServiceDog(); WatchdogRegs.WDCR = 0x0068; // 3. 关闭Bootloader用到的外设 // 这里以SCI-B为例，把所有用过的外设都复位 CpuSysRegs.PCLKCR0.bit.SCI_B = 0; CpuSysRegs.SOFRST3.bit.SCI_B = 1; // 软复位 CpuSysRegs.SOFRST3.bit.SCI_B = 0; // 4. 设置SP指向App约定的栈顶 // 这个栈顶地址要和App工程的CMDB文件中的.stack段保持一致 __asm(" MOV SP, #0x000500"); // 5. 取入口地址并跳转 void (*appEntry)(void) = (void (*)(void))(APP_START_ADDR | APP_ENTRY_MODE_BIT); appEntry(); // 理论上不会走到这里 while(1); }

关于第2步禁看门狗，有的人会选择在跳转前喂一下狗再离开，让App自己接管。我建议禁掉，防止App启动过程较长（Flash API重新初始化、外设配置等）导致看门狗在App初始化中途超时。

第4步SP的设置要单独解释。F28377D的C28x内核，栈指针在跳转瞬间必须有效。虽然App的_c_int00会重新设置SP，但函数指针调用时C编译器会使用当前的SP来压栈保存返回地址和寄存器。如果Bootloader的SP区域和App的初始化代码冲突，跳转过程可能压栈压到App要清掉的区域，造成返回地址丢失。我踩过一次这个坑，现象是跳转后程序跑飞，追踪了半天，最后发现是SP挂在RAMM1的尾部，而App的BSS清零过程把这个区域清成了0，导致返回地址被抹掉。所以跳转前手动把SP设置到App的.stack区域，就彻底规避了这类问题。

APP_ENTRY_MODE_BIT这个最低位也很关键。C28x指令是16位宽，字节寻址时一条指令的地址最低位用来标记处理器模式（0表示汇编模式，1表示C模式）。如果你直接拿0x090000当函数指针调用，等于告诉编译器这是汇编模式，跳过去之后可能执行异常。加| 1这个操作虽然看起来别扭，但它是C28x平台上跳转的标准做法。

跳转不是终点。App启动后，应该主动通过串口发一个APP_READY握手包，上位机收到后才能确认升级成功。否则Bootloader跳过去之后，上位机不知道App有没有跑起来，屏幕上就会一直卡在“等待跳转”这个状态。

5. 常见问题与可靠性设计：把坑提前填平

5.1 问题排查速查表

做Bootloader过程中我积累了不少排查经验，整理成一张表，遇到问题先对号入座。

其中“跳转App后死机”和“Flash API执行跑飞”是两个最高频的坑，我甚至遇到过一个同事在F28377D上照搬F280049C的Flash API用法，结果因为API版本不匹配导致错误。强烈建议每次拿到新的C2000Ware版本，都以头文件里的Flash API函数原型为准。

5.2 可靠性设计：让升级过程“摔不坏”

Bootloader设计得再好，也无法避免现场遇到掉电、线缆松动、静电干扰。我们要做的不是保证一次都不出错，而是出错之后还能恢复到可升级状态。

我采用的策略是：在任何时刻，Flash中都不存在一个“半个App”。具体做法是把“升级完成”的标记放在最后一步。

升级流程严格按这个顺序执行：

1. 上位机发送SYNC，Bootloader确认通信正常。
2. 上位机发送ERASE命令，Bootloader擦除App区Sector 2-7。
3. 在标志区的upgradeInProgress字段写入“0x0000”，表示当前正在升级，App不可用。
4. 上位机分帧发送PROGRAM，Bootloader逐帧写入Flash。
5. 全部写完后，上位机发VERIFY，Bootloader回读Flash并计算CRC。
6. 校验通过后，上位机发JUMP命令。Bootloader先更新标志区，写入App版本和CRC结果，再设置“App有效”标志，最后跳转App。

如果升级在步骤4或5中掉电，下次上电Bootloader检查标志区发现“App无效”，就直接进入升级模式等待重新刷写，不会尝试跳转一个不完整的App。因为App不足32KB对齐的部分会保留为0xFF，CRC校验自然通不过，所以不会误判。

这个方案不是万能的，比如App固件本身有bug导致跑飞，Bootloader无法自动回滚，但至少能够保证升级过程本身不把设备变成砖。如果要支持回滚，可以把预留区做成A/B双镜像，这里就不展开了。

另一个容易被忽视的可靠性细节是：Bootloader自身的喂狗策略。在串口等待升级时，Bootloader不能一直喂狗，否则看门狗失去意义。但如果长时间不进数据，看门狗就会复位整个芯片，然后又进入Bootloader等待升级，看起来像没有复位一样。这里我建议给升级模式加一个超时自动跳转App的逻辑：如果检测到App有效且3分钟内没有收到任何合法帧，Bootloader直接跳转App。这套逻辑在实际产品中很管用，因为现场工程师发完升级命令后可能忘了关设备，等几分钟后设备要能自动恢复运行正常App。

写在最后的实操体会

如果让我从头再做一次F28377D的Bootloader，我会把更多时间花在两件事上：一是把CMD文件对齐和跳转栈设置作为优先级最高的检查项，二是多花时间把上位机的升级进度显示和错误重传机制写好。底层Bootloader本身代码量并不大，真正的复杂度在于两端的时序配合和异常处理。

做这个Bootloader过程中，我最大的感受是：不要迷信网上流传的C2000老系列Bootloader代码直接搬过来，F28377D的双核架构、Flash API接口和内存映射细节都变了不少。踏踏实实看一遍TRM里的Boot ROM章节和Flash API文档，比什么都强。

这套方案现在已经在我的项目里稳定跑了一年多，刷过新版固件也有几十次了。如果你正准备给F28377D做Bootloader，按我的这个框架走，应该能少走不少弯路。