企业官网建设流程全解析

简介：面向嵌入式DSP开发与工业控制领域工程师的技术文档，围绕TMS320F2811程序在线升级展开，针对传统依赖JTAG仿真器烧写、需开壳操作、后期维护困难等痛点，给出基于串口的BootLoader升级方案。文中从Flash地址空间重新划分入手，说明128K×16存储区（10个Sector）的区段用途规划、双CCS工程（辅助升级程序与待升级程序）的软件模块划分，并详细讨论引导程序流程、A/B有效区标志检测、擦除异常时的回滚机制，以及上位机与MCU之间的串口通信协议设计，配有系统工作原理框图、地址划分表和主程序流程图，可直接对照移植到同类C2000系列芯片项目。压缩包共1个文件，为239KB的PDF文档，篇幅紧凑，便于打印或随设备归档查阅。已有126人学习，适合从事DSP固件开发、希望为产品补充远程升级能力的工程师参考。

1. 机壳封死之后，DSP 在线升级为什么必须走串口这条慢路

DSP 在线升级这件事，说到底是给已经出货的板子留一条不拆壳的维修通道。设备装在控制柜里，机壳封死，前面板只有一个 DB9，为了改三行逻辑就得拆盖、接仿真器、重烧、再装回去——这种活干过一次就不想干第二次。TMS320F2811 这类老型号 DSP 的常规烧写路径是 JTAG，产线调试没问题，到了现场维护就是灾难。

这里要复现的方案，核心是把 128K×16 的片内 Flash 切成「引导区 + 两个程序区 + 一个标志区」，让芯片上电后自己去读标志、跳到当前有效区；需要升级时，通过串口把待升级的 Intel HEX 数据一帧一帧打进另一个空闲区，写完翻转标志、重启生效。适合手里有 F2811 存量板、又必须做远程或现场维护的人，也适合拿它当 BootLoader 入门样本的嵌入式新手——代码量不大，链路完整，坑还特别典型。

2. Flash 十区重排：A/B 双区乒乓与一个 2 字宽的有效标志

2.1 原厂实际扇区布局和它的代价

F2811 的片内 Flash 是 128K×16 位，按扇区（Sector）划分成 10 块，从 A 到 J。它的特点是扇区大小不均匀：A、B、I、J 各 8K×16，C 到 H 各 16K×16。擦除的最小单位就是扇区，不能按字擦，这个物理约束决定了后面所有分区方案的形状。

如果直接把整个应用塞进连续的扇区，串口升级就会出现一个无解的死局：擦除是破坏性的，擦到一半掉电，程序区就是半新半旧，板子既跑不起来也没法再进升级流程。JTAG 之所以让人放心，是因为仿真器可以在芯片「已经废了」的状态下重新灌程序；串口升级没有这条退路，所以必须用空间换安全——同一时刻，Flash 里至少有一份完整可运行的镜像。

这也是很多人第一次做 IAP 翻车的地方：只切了一个程序区，升级过程中一断电就只能返厂。双区乒乓不是过度设计，是这种芯片上唯一能自洽的结构。

2.2 重排方案：J 段放标志，D–E 与 G–H 各放一套程序

按功能的划分方式如下，A 段和 J 段是「不动产」，其余全部可换。

这个分配里最关键的一点：Bootloader 只占 A 段 8K，它不参与任何一次升级，也不允许被上位机的擦除命令碰到。它的职责被压到极小——上电后初始化时钟和串口，读 J 段标志，校验目标区首地址是否落在合法范围、校验字是否成立，然后跳过去。所有复杂业务都丢给 D–E 段的辅助升级程序。

为什么辅助升级程序和待升级程序要分两套？因为升级动作本身也需要代码来执行。如果只保留一套用户程序，那么升级到一半它自己被擦掉，就没有任何代码能继续处理串口了。把「执行升级的那段代码」单独放在 D–E 段，升级 G–H 的时候它自己在跑，逻辑才闭环。

2.3 有效标志的读写与自动回滚

J 段的前两个 16 位字用来存标志。第一个字存魔数，第二个字存区码，两个都对得上才算有效；只判断区码的话，Flash 擦除后默认值 0xFFFF 会被误判成合法值，这是最阴的一个坑。

/* 有效区标志定位在 J 段起始，链接脚本里必须与 .cmd 的 BOOT_SECTION 一致 */ #pragma DATA_SECTION(ActiveSecFile, "BOOT_SECTION") volatile Uint16 ActiveSecFile[2] = {0xAAAA, 0x0001}; #define SEC_A 0x0001 /* 当前运行 D-E 段辅助升级程序 */ #define SEC_B 0x0002 /* 当前运行 G-H 段用户程序 */ Uint16 Get_Active_Section(void) { Uint16 magic = ActiveSecFile[0]; Uint16 flag = ActiveSecFile[1]; /* 魔数不对或区码越界，一律按 A 区兜底，绝不让板子停在非法状态 */ if (magic != 0xAAAA || (flag != SEC_A && flag != SEC_B)) { return SEC_A; } return flag; } void Set_Active_Section(Uint16 sec) { /* 先擦 J 段整个 8K，再按「魔数 + 区码」的顺序写回，顺序不能反 */ Flash_Erase((Uint16 *)0x3D8000, 0x2000); ActiveSecFile[0] = 0xAAAA; ActiveSecFile[1] = sec; Flash_Program((Uint16 *)0x3D8000, (Uint16 *)ActiveSecFile, 2); }

Get_Active_Section的返回值直接决定跳转目标，所以它必须做三重校验：魔数、区码取值范围、目标区入口地址是否可执行。参数sec只接受SEC_A或SEC_B两个值，别在调用侧拼字符串或者传 0/1，一旦有人传了 0，写进去的标志就成了非法值，下次上电要走兜底分支。

Set_Active_Section里擦除长度写的是0x2000，也就是 J 段的完整 8K，不是 2 个字。原因很直接：Flash 只能按扇区擦，写之前必须先擦，哪怕你只改 2 个字。这一步如果写成「只擦 2 个字」，函数会返回错误但很多人不检查返回值，最后的表现是标志没更新、重启还是老程序——这是我在现场遇到频率最高的一类「升级成功但没生效」。

回滚逻辑藏在上电流程里。Bootloader 读标志，假设读到 A 区，就去校验 D–E 段的首地址和校验字；如果 D–E 段因为上次擦除中途掉电而损坏，Bootloader 会自动改跳到 G–H 段，由那边的程序重新把辅助升级程序写回 D–E。同理，如果标志指向 B 而 G–H 段已损坏，就退回 A 区等待重新下发。这套互救机制的正确性完全依赖「两套程序不会同时被擦」这个前提，所以擦除命令里必须先判断目标扇区编号，命中当前运行区就直接拒绝并返回错误码，不能交给上位机去保证。

3. 把段钉死在地址上：.cmd 定位脚本与 hex2000 转换链路

3.1 BOOT_SECTION / B_SEC_ADDR / B_SEC_VER 三段定位

C 语言里声明一个变量，它的地址是链接器分配的，跟你想放的扇区没有任何关系。要让它精确落在 J 段头部，只能靠.cmd链接命令文件里的MEMORY和SECTIONS两段配合。

MEMORY { PAGE 0 : /* J 段头部两个 16 位字，存有效区标志，两个工程的 .cmd 必须写成同一地址 */ BOOT_SECTION : origin = 0x3D8000, length = 0x000002 /* B 区入口记录：目标区首地址 + 校验字，升级完成后由上位机回读确认 */ B_SEC_ADDR : origin = 0x3E7FF0, length = 0x000002 /* B 区版本号，3 个 16 位字里只用最低一个 */ B_SEC_VER : origin = 0x3E7FF2, length = 0x000001 /* G~H 段主代码区，长度要避开上面两个小段，否则链接直接报溢出 */ FLASHH : origin = 0x3E0000, length = 0x003FF0 } SECTIONS { .cinit : > FLASHH PAGE = 0 .pinit : > FLASHH PAGE = 0 .text : > FLASHH PAGE = 0 .const : > FLASHH PAGE = 0 .econst : > FLASHH PAGE = 0 .switch : > FLASHH PAGE = 0 ActiveSecFile : > BOOT_SECTION PAGE = 0 BSecAddr : > B_SEC_ADDR PAGE = 0 BSecVer : > B_SEC_VER PAGE = 0 }

origin就是绝对地址，length是这段地址允许占用的字数。FLASHH的length写0x003FF0而不是0x004000，就是为了给B_SEC_ADDR和B_SEC_VER让出末尾 16 个字。这个长度差一旦写错，链接器会提示段重叠，但也有人直接改小B_SEC_ADDR的地址把冲突「绕过去」，结果就是版本号段落进了代码区，运行期被代码覆盖，回读出来的版本号永远是乱的。

ActiveSecFile必须定义成volatile，否则在开了优化的情况下，链接器认为这个变量只写不读，可能整个段被裁掉，map文件里根本找不到它，写标志那一行就变成了往一片野地址写数据。

3.2 两个工程必须对齐的三处

工程 A（辅助升级程序，烧在 D–E）和工程 B（用户程序，烧在 G–H）是两个独立的 CCS 工程，各自有一份.cmd。它们之间有三处必须严格对齐，错一处就升不上去：

第一处是BOOT_SECTION。两个工程里这段的origin和length必须完全一样，因为标志是共享的。有人图省事，在工程 B 里把这段改到自己的区里，结果就是升级完成后标志写进了 G 段，Bootloader 在 J 段读到的还是老值。

第二处是B_SEC_ADDR和B_SEC_VER的含义。这两个段只对工程 B 有意义，工程 A 的.cmd里可以删掉，但删之前要确认链接器没有别的段占用那块地址。

第三处是c_int00的入口位置。段 C 里放的是运行库启动代码，Bootloader 跳过去的时候用的就是它的首地址，所以这个地址在两次编译之间不能变。稳妥的做法是在.cmd里把c_int00所在的段固定到0x3F0000起始，然后写死一个常量在 Boot 里，而不是每次从map文件里手工抄。

3.3 hex2000 的四个宽度参数与批处理封装

CCS 编译出来的是.out文件，一种带符号和段信息的 ELF/COFF 格式，MCU 端的解析器没必要去啃这种格式。转成 Intel HEX 是行业惯例，格式简单、每行自带地址和校验和，串口传输出错也容易定位到具体行。工具用随 CCS 一起装的hex2000.exe，参数写在一个命令文件里：

first.out -i -memwidth 16 -romwidth 16 -datawidth 16 -o dsp_update_B.hex

四个参数逐个说。-i指定输出 Intel HEX 格式，不加这个参数默认输出的是 TI-Tagged 格式，行首带q、b之类的标记，MCU 端按 Intel 格式解析会全部失败。-memwidth 16告诉工具目标存储器的寻址宽度是 16 位，这直接决定 HEX 行里的地址是按字递增还是按字节递增——F2811 是 16 位字寻址，这里写成 8 会让地址整体翻倍，烧进去的程序从第二条指令开始就是错的。-romwidth 16和-datawidth 16是输出 ROM 的位宽和数据位宽，三个 16 必须一致，任何一个是 8，都会触发工具内部的字节拆分，生成一份看起来正常、烧进去跑飞的 HEX。

外层用批处理封装，把转换和错误判断放在一起，避免有人双击完看都不看就去烧：

@echo off REM 与 hex2000.exe、program.cmd、first.out 放在同一目录下执行 hex2000 program.cmd if errorlevel 1 ( echo [ERROR] hex conversion failed, check program.cmd pause exit /b 1 ) echo [OK] dsp_update_B.hex generated pause

errorlevel判断不能省。hex2000在输入文件缺失、段溢出、参数非法的时候都会返回非零，但它不会弹窗，只是命令行一闪而过。少了这个判断，最后拿到的是一个上次编译留下的旧 HEX，烧进去当然「升级成功」，只是升的还是老版本。

3.4 产物核对：HEX 首行和 map 文件

转换完不要急着烧，做两个核对。

第一，打开 HEX 文件看第一行数据记录的地址字段。工程 B 的代码起始地址应该是0x3E0000，转换成 Intel HEX 的记录地址就应该是3E00（Intel HEX 的地址字段是字节地址，对于 16 位字寻址的芯片，工具会自动处理扩展地址记录）。如果首行地址是3D80或者0000，说明.cmd里的段分配没生效，链接器把代码放回了默认位置。

第二，翻map文件，确认ActiveSecFile的地址是0x3D8000、BSecVer是0x3E7FF2。map文件里还有每个段的长度，看一眼.text段是不是超过了FLASHH的0x003FF0——超了的话链接器会报警，但报的是「段溢出」，不会告诉你是哪个变量太大，得回去查。

4. 一帧一擦一写：命令字、CRC 与 115200 下的超时账

4.1 帧格式设计

串口上跑的是二进制数据，没有任何边界标记，靠超时切帧在 115200 下极不可靠。所以每一帧都必须自带帧头、长度、校验和帧尾，四个要素缺一不可。

数据域上限压到 128 字节，不是随便定的。F2811 的 Flash 一次写入 16 位，但串口接收缓冲区通常只开到 128 或 256 字节，帧太长会在擦写 Flash 关中断的那几百毫秒里溢出。128 字节对应 64 个 16 位字，正好是一个可以接受的重传粒度。

命令字只保留六个，够用且好排查：

4.2 五步命令序列与时序

一次完整的升级是严格串行的五步，上位机每发一帧都要等应答，不能连续猛发。

第一步，ENTER_UPDATE。MCU 收到后把当前有效区码回给上位机，上位机据此决定这次往哪个区写——如果当前跑 A 区，就往 G–H 写；跑 B 区，就往 D–E 写。这一步是整个流程的安全阀，上位机绝对不能自己猜目标区。

第二步，ERASE_REGION。MCU 收到后先做一次范围检查，确认目标区不是当前运行区，也不是 A 段 Bootloader，检查通过才真正擦除。擦一个 16K×16 的扇区在 F2811 上大约需要几百毫秒，上位机的等待超时不能按普通命令的 200ms 设，建议单独给擦除命令 3～5 秒。

第三步，WRITE_BLOCK。从 HEX 里解析出来的数据按 128 字节切片，每片配上目标地址。MCU 收到后先写 Flash 缓冲区，再触发写入，写完后回一个结果字节。这一步最忌讳上位机「发完就完事」，必须等应答再发下一帧，否则 MCU 的接收缓冲区在擦写期间会溢出，表现为随机丢块、最后 CRC 对不上。

第四步，CHECK_CRC。上位机把整份 HEX 数据的 CRC32 发过去，MCU 把刚写入的区域读回来算一遍，比对一致才回成功。这一步是唯一能证明「数据真的落到 Flash 里」的环节，跳过它，就只能靠重启后程序跑不跑来验证，太晚。

第五步，JUMP_NEW。MCU 更新 J 段标志，然后触发软复位或者直接跳到新程序入口。跳转前要关掉全局中断、关看门狗、把用到的外设恢复到复位状态，否则新程序的c_int00会在一个被污染的环境里跑起来。

4.3 上位机侧的 HEX 解析与组帧

上位机用 Python 写最省事，pyserial加一个 CRC 函数就够了。关键是把 Intel HEX 的扩展地址记录处理好，很多解析器只认类型 00 记录，遇到类型 04 就跳过，结果地址超过 64K 的部分全部错位。

import serial import time FRAME_HEAD = b'\xAA\x55' FRAME_TAIL = b'\x0D' def crc16(buf): """与 MCU 端一致的 CRC16/MODBUS，初值 0xFFFF，多项式 0xA001""" crc = 0xFFFF for b in buf: crc ^= b for _ in range(8): crc = (crc >> 1) ^ 0xA001 if crc & 1 else crc >> 1 return crc & 0xFFFF def build_frame(cmd, payload=b''): """命令字 + 长度 + 数据 参与校验，帧头帧尾不参与""" body = bytes([cmd]) + len(payload).to_bytes(2, 'little') + payload return FRAME_HEAD + body + crc16(body).to_bytes(2, 'little') + FRAME_TAIL def parse_hex(path): """返回 [(线性地址, 数据bytes)]，类型 04 记录负责切换高 16 位基址""" records, base = [], 0 with open(path, 'r', encoding='ascii') as f: for line in f: line = line.strip() if not line.startswith(':'): continue raw = bytes.fromhex(line[1:]) n = raw[0] addr = (raw[1] << 8) | raw[2] rtype = raw[3] data = raw[4:4 + n] if rtype == 0x00: # 数据记录 records.append((base + addr, data)) elif rtype == 0x04: # 扩展线性地址 base = ((data[0] << 8) | data[1]) << 16 elif rtype == 0x01: # 文件结束 break return records

crc16的初值和多项式必须跟 MCU 端逐位一致，两边各自实现、各算各的，是校验失败的头号原因。parse_hex里把类型 04 的扩展地址左移 16 位累加到基址上，这一步对应 F2811 的 0x3E0000 这类地址，漏掉就会把整份数据当成从 0x0000 开始。

下发循环的骨架如下，重点是每帧之后必须读应答：

def send_and_wait(ser, cmd, payload=b'', timeout=0.2): ser.write(build_frame(cmd, payload)) ser.timeout = timeout resp = ser.read(8) # 应答帧定长 8 字节 if len(resp) < 8 or resp[3] != 0x80 | cmd: # 应答命令字 = 请求 | 0x80 raise IOError('frame timeout or bad ack') return resp[4]

timeout默认 0.2 秒适用于握手和写块，擦除命令要单独传 5.0。应答帧定长 8 字节是刻意设计的——变长应答需要额外的长度字段解析，在现场调试时远不如定长好处理。

5. 避坑排查：六个把板子刷成砖的现场记录

5.1 提示升级成功，重启还是老程序

现象：上位机五步全部返回成功，断电重启后程序行为没有任何变化，读版本号还是旧值。

原因：标志位写进去了，但 Bootloader 读的不是同一个地址。常见两种情况，一是工程 B 的.cmd里BOOT_SECTION的origin跟工程 A 不一致，二是Set_Active_Section里擦除长度只写了 2 个字，Flash 擦除返回错误但代码没检查返回值，后面的写入实际没生效。

解决：在两个工程的map文件里搜ActiveSecFile，确认地址都是0x3D8000；擦除函数的返回值必须判断，失败就回错误码给上位机，别让流程往下走。

5.2 HEX 转换成功，烧进去从第二条指令就跑飞

现象：CRC 校验能过，说明数据确实写进去了，但程序一跑就进非法中断。

原因：hex2000的-memwidth写成了 8。地址按字节递增生成，MCU 端按字地址去取指令，每条指令都偏移了一倍，前几条还能碰巧执行，后面全乱。

解决：三个宽度参数统一写 16，转换完打开 HEX 看第一条数据记录的地址是不是3E00，对不上就回去改命令文件，别靠烧板子验证。

5.3 擦除中途断电，板子彻底不启动

现象：升级到一半设备掉电，再上电串口无任何输出，仿真器也连不上。

原因：擦除范围没有做保护，把当前运行区或者 A 段 Bootloader 擦掉了。Bootloader 一旦被擦，芯片上电后没有任何代码可执行，只能返厂用 JTAG 救。

解决：ERASE_REGION的处理函数里，第一步就做地址白名单判断：目标起始地址只能是0x3E0000或0x3EC000，且必须不等于当前有效区。Bootloader 所在 A 段（0x3F6000起）永远不在白名单里。这个判断放在 MCU 端，不放在上位机，因为上位机是可以被改的。

5.4 大数据量升级必然丢块

现象：小文件（小于 4K）升级稳定，一超过 16K 就随机出现 CRC 失败，重试几次有时能过。

原因：上位机连续发送不等应答，MCU 在擦写 Flash 期间关了中断，串口接收 FIFO 溢出。擦一个扇区几百毫秒，这期间发过来的帧全丢。

解决：每一帧等应答，擦除命令单独给 5 秒超时；MCU 端的串口接收用中断加环形缓冲，不要用查询方式；帧数据域不超过 128 字节。

5.5 版本号回读永远是 0xFFFF

现象：升级流程全部成功，READ_VERSION返回的三个字节全是0xFF。

原因：BSecVer变量没有被任何代码引用，开了优化后被链接器裁掉，段根本没有分配地址；或者FLASHH的length写得太大，把0x3E7FF2覆盖进了代码区，写版本号的时候写到了代码上。

解决：BSecVer声明为volatile并在代码里至少有一次读取操作；FLASHH的length卡到0x003FF0，转换完查map确认版本号段的地址。

5.6 跳转后新程序不进 main

现象：JUMP_NEW之后串口彻底没反应，但重新上电又能正常进入新程序。

原因：跳转前没有关中断和看门狗。老程序里开着定时器中断，跳过去之后新程序的向量表还没建立，中断打到旧的入口地址，直接跑飞；或者看门狗在跳转后溢出复位，正好落在新程序初始化的中间状态。

解决：跳转函数里先DINT关全局中断，再喂一次狗并关闭看门狗，然后清掉所有外设使能位，最后用函数指针跳到c_int00的首地址。跳转前把新程序的入口地址从BSecAddr读出来，别用硬编码常量。

6. 升级到底成没成：三层验证与一条回滚后悔药

判断一次升级是否真的成功，不能只看上位机弹的那个「成功」提示，我一般会走三层验证，任何一层过不了就当失败处理。

第一层是数据层，CHECK_CRC返回一致。这一层只证明写进 Flash 的数据跟 HEX 文件一致，不证明程序能跑。第二层是版本层，READ_VERSION读回的版本号跟编译时写进BSecVer的值一致。版本号建议用「主版本 + 次版本 + 编译日期低字节」三个字，别用递增整数，因为递增整数在多次回滚之后会分不清哪个是哪个。第三层是行为层，也是最容易被跳过的一层：断电重启，观察设备能不能在正常时间内进入工作状态，串口有没有按预期输出心跳。

回滚这条后悔药要提前埋好，不能等出事再想。做法是让 Bootloader 支持一个「强制回退」入口：上电时如果检测到某个特定 GPIO 被拉低，或者串口在 2 秒内收到连续三个0x55，就无条件把标志翻到另一个区。这个入口不需要上位机软件配合，现场只要短接一个测试点就能救回来。D–E 段的辅助升级程序在写 G–H 段之前，也要先把 G–H 段的入口地址和校验字备份到 F 段，这样即使 G–H 被擦了一半，Bootloader 也能判断出「B 区不完整」并自动退回 A 区。

还有一个容易被忽略的细节：升级完成后第一次重启，建议在辅助升级程序里做一次「自检延时」——延时 3 秒再做别的动作，同时等上位机发一个确认帧。如果新程序有问题，这 3 秒内还能收到回退命令。这个窗口不长，但足够覆盖大部分「升完就发现不对」的场景。

从那以后我每次做这类串口升级，都会在动板子之前先把「强退入口」和「版本号回读」这两条路走一遍，确认它们在没有上位机软件的情况下也能工作，才敢往 Flash 里写第一帧。血泪经验是，升级流程本身很少出问题，出问题的永远是出问题之后你还有没有第二条路。希望帮到你。

本文还有配套的精品资源，点击获取