TMS320F281x DSP串行Flash编程：基于Boot ROM的自主可控烧录方案

1. 项目概述

在嵌入式DSP系统开发，尤其是工业控制、电机驱动或数字电源这类对可靠性和现场维护有高要求的领域，如何安全、高效地将最终的应用代码“烧录”进处理器的内部Flash，是一个贯穿产品开发、测试到量产的硬核问题。直接使用JTAG仿真器配合IDE编程固然方便，但在产线批量烧录或设备现场升级时，往往不现实。这时，利用芯片自带的Boot ROM引导程序，通过串口（SCI）这样的通用通信接口进行在线编程（ICP），就成了一种极具吸引力的方案。它省去了昂贵的专用编程器，仅需一根串口线，就能完成固件的部署与更新。

德州仪器（TI）的TMS320F281x系列DSP，作为经典的C2000平台主力，其Boot ROM内建了完善的引导加载器，支持从SCI、SPI、GPIO等多种接口启动。我们今天要深入拆解的，正是如何利用这个Boot ROM的SCI-A模式，实现一套完整的、可自定义的串行Flash编程方案。这不仅仅是调用一个现成的工具，而是要从底层理解Boot ROM的握手协议、通信内核（CKFA）的加载与运行机制、Flash API的调用时序，最终打造一个属于自己的、稳定可靠的量产编程或现场升级工具链。对于需要深度定制烧录流程、集成到自动化测试设备（ATE）或追求极致成本控制的工程师来说，掌握这套方法至关重要。

2. 核心原理与方案设计解析

2.1 Boot ROM SCI引导流程的本质

TMS320F281x上电或复位后，会首先执行固化在ROM中的引导加载程序。该程序会检测特定的GPIO引脚状态，以决定从哪种外设（如Flash、SCI、SPI等）加载用户代码。当配置为SCI-A引导模式时，Boot ROM会初始化SCI-A外设，并进入一个等待状态，持续侦听串口数据。

这里的关键在于，Boot ROM期望接收到的并不是我们最终的应用代码（AppCode），而是一段特殊的“引导内核”程序。这段内核程序需要满足Boot ROM规定的特定格式：一个8位的同步字（0x08AA），后跟一个32位的入口点地址和32位的程序长度，最后才是程序本身的二进制数据流。Boot ROM负责将这串二进制流搬运到指定的RAM地址（即入口点地址），然后跳转到那里执行。这就为我们后续的操作打开了大门：我们可以精心设计一段“通信内核与Flash API程序”（CKFA），让Boot ROM把它加载到RAM并执行，从而将系统的控制权从只读的、功能固定的Boot ROM，移交到我们自定义的、功能强大的RAM程序中。

2.2 双阶段编程策略：CKFA与AppCode

基于上述原理，整个串行Flash编程过程被设计为清晰的两个阶段，我习惯称之为“引导-接管”模式。

第一阶段：CKFA的加载与启动在此阶段，PC或上位机（统称主机）通过串口，按照Boot ROM规定的数据流格式，将CKFA程序发送给目标DSP。Boot ROM在验证同步字和长度后，会将CKFA代码搬运到其链接时指定的“加载地址”（LOAD Address）。这个地址必须位于未受代码安全模块（CSM）保护的RAM区域（如M0, M1），因为此时CSM可能处于锁定状态，无法访问受保护的RAM（如H0）或Flash。搬运完成后，Boot ROM跳转到CKFA的入口点，系统控制权完成移交。

CKFA程序开始运行后，首要任务就是尝试解锁CSM（如果目标芯片被锁定）。解锁成功后，CKFA便获得了对整个内存空间（包括所有RAM和Flash）的完全访问权限。随后，CKFA会将自己从“加载地址”拷贝到“运行地址”（RUN Address），这个运行地址通常位于更大的、之前受保护的RAM区（如H0），目的是为后续接收庞大的应用代码腾出足够的缓冲区空间。至此，一个功能完备的“编程引擎”已在DSP的RAM中准备就绪，它包含了串口通信驱动和最重要的Flash擦写算法（Flash API）。

第二阶段：AppCode的传输与烧录控制权在CKFA手中，串口通信协议也由我们自定义，变得更加灵活。主机开始发送第二段数据流——最终需要烧录进Flash的应用代码（AppCode）。CKFA不会一次性接收全部AppCode，而是采用“乒乓缓冲”策略：它会在RAM中开辟两个缓冲区（例如各4K字）。当缓冲区1被填满时，CKFA立即启动Flash编程操作，将缓冲区1的数据写入Flash的对应扇区。与此同时，串口接收中断服务程序会持续工作，将后续的AppCode数据存入缓冲区2。当缓冲区1编程完成，缓冲区2也恰好（或即将）填满，两者角色互换，如此循环。

这种设计巧妙地将耗时的Flash写入时间与串口数据传输时间重叠起来，极大地提升了整体编程效率。Flash API本身提供了回调函数机制，使得在Flash编程期间，CPU可以响应中断并处理串口数据成为可能。当所有AppCode数据接收完毕并成功编程到Flash后，CKFA会计算整个Flash区域的校验和，与预设的期望值比对，完成最终验证。最后，CKFA将程序计数器（PC）设置为Flash中AppCode的入口地址（通常是0x3F7FF6），并跳转执行，或者直接复位芯片，让芯片从Flash正常启动。

2.3 方案优势与选型思考

为什么选择这种基于Boot ROM的自定义方案，而不是直接使用TI推荐的SDFlash图形化工具？这完全取决于应用场景。

SDFlash的优势在于开箱即用，它提供了友好的Windows界面，集成JTAG和SCI支持，适合研发阶段的调试和小批量生产。然而，它的局限性也很明显：依赖Windows PC环境，难以集成到全自动的产线测试设备（ICT）中；对于需要定制通信协议、加密传输或与特定上位机软件深度整合的场景，灵活性不足。

自定义CKFA方案的核心价值在于“自主可控”和“可集成性”。你可以将CKFA和AppCode的传输逻辑封装进你自己的量产测试软件、甚至另一个微控制器中。它不依赖于任何特定的操作系统或商业软件，只需要一个支持串口通信的宿主即可。这对于构建无人值守的自动化烧录站、实现远程OTA升级服务器、或是成本极其敏感的海量生产场景，是唯一可行的技术路径。当然，这意味着你需要投入开发时间，去理解并实现整个流程，但换来的是一套完全贴合自身产品与生产流程的解决方案。

3. 软件准备：从源码到二进制流

要实现上述流程，软件侧需要精心准备两个核心文件：CKFA.bin（通信内核）和AppCode.bin（应用代码）。它们的生成过程略有不同，但目标一致：得到纯净的、可供串口逐字节发送的二进制文件。

3.1 应用代码（AppCode）的预处理关键点

AppCode的预处理有一个容易被忽略但至关重要的要求：必须填满整个目标Flash空间。对于F2810，是64K字（0x3E8000 - 0x3F7FFF）；对于F2812，是128K字（0x3D8000 - 0x3F7FFF）。CKFA编程逻辑是连续写入整个Flash区间，如果AppCode的链接输出没有覆盖所有地址，那么未覆盖的区域内容将是不可预测的，导致校验和计算错误，甚至可能让芯片运行到未初始化的指令上，引发不可预料的故障。

3.1.1 使用链接器（Linker）填充未用空间在链接器命令文件（.cmd）中，除了分配各个代码段和数据段到Flash地址，还需要为每个Flash存储区域（SECTOR）指定填充（FILL）值。通常，我们填充0xFFFF。原因有三：第一，TI出厂时Flash全为0xFFFF（已擦除状态），填充此值可避免对已擦除位进行不必要的编程操作，略微提升速度；第二，0xFFFF在C28x指令集中对应一个非法操作码，如果程序跑飞至此，会触发非法指令陷阱，便于调试和增加系统鲁棒性。

// 以F2812的FLASHC段为例，在.cmd文件中 MEMORY { PAGE 0: ... FLASHC : origin = 0x3F0000, length = 0x004000, fill = 0xFFFF ... } SECTIONS { ... .text : > FLASHC, PAGE = 0 ... }

链接后，你可以通过生成的.map文件检查填充是否生效，确认fill一列显示为ffff。

3.1.2 使用Hex转换工具查漏补缺链接器的fill指令并非总能覆盖所有情况，特别是当某个存储区域（MEMORY范围）完全未被任何SECTION使用时，链接器可能不会对其进行填充。这时就需要Hex转换工具（hex2000.exe）进行最终保障。在其命令文件（.cmd）中，同样可以对ROM范围指定fill参数。

// AppCode_hex_2812.cmd ROMS { FLASH2812: origin = 0x3D8000, len = 0x20000, romwidth = 16, fill = 0xFFFF }

hex2000会将COFF格式的.out文件转换为ASCII十六进制格式（如Motorola-S或Intel Hex）。通过其生成的.map文件，可以再次核验所有地址是否已被正确填充。

3.1.3 生成最终的二进制文件（.bin）Boot ROM和CKFA都需要传输原始的二进制机器码，而不是ASCII十六进制文本。因此，需要将hex2000输出的.hex文件转换为纯二进制.bin文件。TI的示例中使用了FileIOShell.exe工具。这个过程可以通过在CCS的工程构建选项中添加后处理步骤（Post-build steps）来自动化：

// 在CCS项目Build Options的Post-build Steps中 cd ${Proj_dir}\Debug hex2000 ${Proj_dir}\AppCode_hex_2812.cmd FileIOShell.exe -I AppCode.hex -o AppCode.bin

这样，每次编译链接后，都会直接生成可供下载的AppCode.bin。

3.1.4 计算并嵌入校验和校验和是验证Flash编程是否正确的最后一道关卡。CKFA在编程结束后，会重新读取整个Flash区域，计算其16位累加和。这个值需要与一个“期望值”进行比较。我们可以在开发阶段，先用CCS的Flash编程器插件或JTAG工具，将正确的AppCode烧录一次，然后使用其“Calculate Checksum”功能得到这个期望值。之后，将这个值作为常量CHECKSUM_EXPECTED，更新到CKFA的源文件（如Example_Flash281x_API.c）中并重新编译CKFA。

实操心得：校验和的陷阱计算校验和时，务必确认CKFA中计算校验和的算法与CCS插件使用的算法完全一致。通常都是简单的16位字累加（忽略进位）。另外，一定要包含Flash中所有被编程的地址，包括填充区域。如果CKFA计算的Flash范围（由FLASH_START和FLASH_END定义）与AppCode实际占用的范围不一致，校验必然会失败。最稳妥的方法是让CKFA计算整个Flash空间（如0x3D8000到0x3F7FFF），AppCode的填充也覆盖整个空间。

3.2 通信内核（CKFA）的配置与生成

CKFA工程基于TI提供的Flash API示例代码构建，它本身也是一个完整的DSP程序，需要被编译链接。

3.2.1 关键配置参数

• 时钟配置 (PLLCR_VALUE,CPU_RATE): 在Example_Flash281x_API.h和Flash281x_API_Config.h中，必须根据目标板上的晶振频率正确设置PLL倍频值和CPU时钟速率。Flash API内部的擦除和编程时序严重依赖于CPU_RATE这个宏定义，设置错误会导致时序不准，轻则编程失败，重则损坏Flash单元。例如，30MHz晶振，欲得150MHz SYSCLKOUT，则需设置PLLCR_VALUE为0xA，CPU_RATE为6.667L（单位：ns）。
• 目标器件类型: 在Flash281x_API_Config.h中，通过#define选择正确的器件（F2810, F2811, F2812）。这会决定CKFA内部使用的Flash扇区映射和大小。
• 代码安全模块密码: 如果目标DSP的CSM已被密码锁定，你需要在CKFA的源文件中（通常是Example_Flash281x_API.c里一个名为CsmPwl的数组）填入正确的128位密码。对于全新或已擦除的芯片，此步可省略。

3.2.2 生成CKFA的二进制文件CKFA的生成流程与AppCode类似，但有一个重要区别：CKFA的二进制文件格式必须严格符合Boot ROM SCI引导协议。它不是一个简单的内存映像转储。TI的示例中，CKFA工程使用了一个额外的转换工具HEX2BIN.exe（或类似功能的脚本），在hex2000生成Intel Hex格式文件后，将其转换为包含同步头、长度和入口点信息的特定二进制格式。务必使用项目中原有的、经过验证的转换脚本（如CKFA_COFF2BIN.bat），不要自己随意转换，否则Boot ROM将无法识别。

4. 硬件连接与实操流程

4.1 硬件接口与配置

4.1.1 串口连接目标DSP的SCI-A接口（通常是GPIOF4/SCITXDA和GPIOF5/SCIRXDA）需要与主机的串口（或USB转串口适配器）连接。注意电平匹配，F281x的I/O口是3.3V CMOS电平，确保主机串口也是3.3V电平或经过电平转换。

4.1.2 启动模式配置必须通过DSP的GPIO引脚设置正确的启动模式。将GPIOF4,GPIOF12,GPIOF3,GPIOF2这4个引脚（具体请查阅芯片数据手册）在上电复位时拉高或拉低，配置为“SCI-A Boot”模式。通常，这需要设置开发板上的跳线帽。

4.1.3 硬件连接清单以F2812 eZdsp开发板为例：

1. 电源: 确保开发板供电正常。
2. 串口: 连接开发板的SCI-A接口（通过板载的RS-232芯片或直接连接GPIO）到PC的COM口。
3. 跳线: 设置启动模式跳线为SCI-A引导（例如，根据板卡手册，将BOOT_EN引脚拉低，并配置GPIOF4/12/3/2为相应状态）。
4. 复位: 准备进行硬件复位。

4.2 完整操作步骤

步骤1：环境与文件准备

1. 在PC上准备好终端软件（如Tera Term、SecureCRT或古老的HyperTerminal），配置好正确的COM端口。
2. 将生成的CKFA.bin和AppCode.bin文件放在PC端易于访问的目录。
3. 准备一个简单的文件发送工具或脚本，能支持发送纯二进制文件。许多终端软件都有“发送文件”功能，但必须选择“二进制”或“Raw Data”模式，而不是文本模式。

步骤2：建立Boot ROM通信

1. 将目标板设置为SCI-A启动模式，并上电或按下复位键。
2. 立即启动PC端的终端软件，并开始以115200波特率（这是F281x Boot ROM SCI-A的固定速率）、8数据位、1停止位、无奇偶校验、无流控的设置，发送CKFA.bin文件。
3. 此时，Boot ROM正在等待接收数据。发送成功后，Boot ROM会将CKFA加载到RAM并运行。如果连接和发送正确，你通常会在终端上看到CKFA程序启动后发送回来的提示信息，例如“CKFA Ready”或等待下一步指令的提示符。

步骤3：CKFA接管与AppCode烧录

1. CKFA运行后，它会重新初始化串口，并可能根据其内部设置切换到一个更高的波特率（如921600或1.875Mbps）以加速数据传输。终端软件需要根据CKFA的提示，将波特率切换到对应值。
2. 切换波特率后，CKFA通常会等待接收一个“开始编程”的指令或直接进入等待AppCode数据的状态。
3. 使用终端软件或自定义的上位机程序，以新的波特率发送AppCode.bin文件。
4. CKFA接收数据，进行“乒乓缓冲”式编程。过程中，它可能会通过串口反馈进度信息，如“Programming Sector X...”或“Checksum OK”。
5. 传输和编程完成后，CKFA会计算Flash校验和并与期望值比较，输出成功或失败信息。

步骤4：验证与启动

1. 编程成功后，将目标板的启动模式跳线改回“Flash Boot”模式（通常是将所有启动模式引脚拉高）。
2. 复位目标板，DSP将从Flash的入口地址（0x3F7FF6）开始执行新烧录的AppCode。你可以通过观察板载LED、测量特定引脚波形或通过串口打印信息来验证应用程序是否正常运行。

5. 常见问题排查与深度优化

5.1 典型故障与解决方法

5.2 性能优化与高级技巧

1. 提升传输速率：Boot ROM阶段的115200波特率是固定的，无法改变。但CKFA运行后，你可以将其配置为更高的波特率。在CKFA_SCI.c（或类似名称的通信驱动文件）中，修改SCI的波特率寄存器设置。计算公式为：BRR = (LSPCLK / (BaudRate * 8)) - 1，其中LSPCLK是低速外设时钟。确保主机端能跟上这个高速率，并考虑线缆质量和长度对高速信号的影响。

2. 实现通信协议与可靠性增强：Boot ROM使用简单的“数据流+校验”模式。在CKFA阶段，你可以设计更健壮的协议。例如：

• 添加数据包结构：将AppCode数据分块，每块包含序号、长度、数据和CRC校验。CKFA每接收一块，立即校验并回复ACK/NAK。
• 实现断点续传：在协议中支持查询当前编程进度，如果传输中断，可以从断点处继续，而不必重头开始。
• 增加身份验证与加密：在传输开始前进行简单的身份握手，甚至对AppCode.bin进行加密，CKFA端解密后再编程，提高固件安全性。

3. 集成到自动化测试系统：这是此方案最大的用武之地。你可以用LabVIEW、Python（使用pyserial）或C#等语言编写上位机程序，实现以下功能：

• 自动检测串口，识别设备。
• 一键完成：发送CKFA -> 切换波特率 -> 发送AppCode -> 验证结果。
• 批量处理：连接多个工位，并行或依次对多块板卡进行编程。
• 日志记录：记录每个板卡的序列号、烧录结果、校验和、操作时间等，用于生产追溯。

4. 处理大容量应用代码：如果AppCode非常大，接近或超过可用RAM缓冲区总和，上述“乒乓缓冲”机制需要扩展。可以设计一个更复杂的流控协议，让CKFA在编程完一个缓冲区块后，主动向上位机请求下一个区块，而不是依赖中断持续接收。这要求上位机与CKFA之间有双向命令交互。

最后，分享一个我实践中总结的黄金法则：在搭建任何自定义烧录流程前，务必先用成熟的工具（如CCS + JTAG）验证你的AppCode本身在目标板上是能正常运行的。这能排除应用程序本身存在的硬件配置、时钟初始化、外设驱动等问题。然后，再用这套串口编程方法去烧录这个已知正确的二进制文件。这样，一旦串口编程失败，你就可以将问题范围锁定在Boot ROM引导、CKFA加载、通信协议或Flash API调用这几个环节，极大地简化了调试复杂度。这套基于TMS320F281x Boot ROM的串行Flash编程方法，虽然步骤略显繁琐，但一旦打通，它就成为了一个强大、灵活且成本极低的量产利器，其价值在批量生产和现场维护阶段会体现得淋漓尽致。