当前位置：首页 > news >正文

F28335代码固化Flash全攻略：从RAM调试到独立运行

news 2026/8/17 9:37:28

1. 项目概述：为什么要把F28335的代码下载到Flash？

如果你刚开始接触TI的DSP，尤其是像TMS320F28335这类经典的浮点DSP控制器，你可能会发现一个现象：在CCS（Code Composer Studio）里默认编译、下载、调试，程序好像直接就跑起来了。但如果你拔掉仿真器，重新给芯片上电，程序就“消失”了，一切又回到了起点。这背后的原因，就是你正在RAM里调试，而程序最终需要“固化”到非易失性的Flash存储器中。

简单来说，F28335芯片内部有两块主要的内存区域：一块是易失性的RAM，掉电数据就丢失；另一块是非易失性的Flash，掉电后数据依然保存。我们开发调试时，为了追求极快的下载和调试速度，通常会把程序先放到RAM里运行。但产品最终是要独立工作的，不能总连着仿真器，所以必须把经过验证的代码“烧写”到Flash里。这个过程，就是“代码下载到Flash”。

这不仅仅是点一下“下载”按钮那么简单。它涉及到编译器链接命令文件（.cmd）的配置、运行时支持库的切换、以及一套专门的“从Flash引导到RAM运行”的机制。很多新手在这里踩坑，比如程序在RAM里跑得好好的，一烧进Flash就死机，或者根本启动不了。今天，我就结合自己这些年调试电机控制、数字电源等项目的经验，把F28335代码下载到Flash的完整流程、核心原理和那些容易掉进去的“坑”，给你彻底讲明白。

2. 核心原理与准备工作：理解Flash与RAM的差异

在动手操作之前，我们必须先搞清楚F28335的存储结构，这是所有后续操作的基础。知其然，更要知其所以然。

2.1 F28335的存储空间映射

F28335的存储器采用的是哈佛结构，程序和数据空间分开。对于我们开发者而言，最需要关注的是以下几个关键区域：

M0 SARAM (1K x 16位)：这是片上RAM，速度最快，通常用于存放中断向量表、频繁使用的全局变量或堆栈。掉电丢失。
M1 SARAM (1K x 16位)：同样是片上RAM，用途与M0类似。
L0-L7 SARAM (各4K x 16位，共32K)：大容量的片上RAM，是程序在RAM中调试时的主要栖身之所，也是程序从Flash搬移到RAM运行时的目标区域。掉电丢失。
Flash (256K x 16位)：这就是我们今天的主角，非易失性存储器。它的容量大，但访问速度比RAM慢（尤其是在不使能流水线缓存的情况下）。程序最终需要固化在这里。
OTP (1K x 16位)：一次性可编程存储器，通常用于存放需要永久保护且不再更改的数据或代码，如加密密钥、唯一ID等。

当我们说“在RAM中调试”时，是指编译链接器把程序的所有代码段（.text）、常量段（.const）等都直接分配到L0-L7这类SARAM中。CCS通过仿真器（如XDS100v3, XDS560）将程序直接加载到这些RAM地址，然后芯片从RAM开始执行。这种方式下载速度极快，几乎秒完成，调试体验流畅。

而“下载到Flash”则意味着，链接器要把这些段分配到Flash的地址空间（例如0x3F 8000开始的区域）。编译生成的可执行文件（.out）包含了这些地址信息。烧写工具（通常是CCS自带的Flash烧写插件或脚本）会通过仿真器，按照这个地址映射，将程序数据写入芯片内部的Flash物理单元中。

2.2 关键文件：CMD文件的双重角色

CMD文件是连接软件（你的C代码）和硬件（芯片内存布局）的桥梁。它告诉链接器：把哪一段代码或数据，放到内存的哪个地址上去。

在F28335的开发中，你通常会看到两个（或更多）CMD文件：

一个用于RAM调试(例如28335_RAM_lnk.cmd)：这个文件里，MEMORY部分将程序段（PAGE 0）和数据段（PAGE 1）都定义在SARAM（如L0L1）的地址范围。SECTIONS部分则将.text,.cinit等段分配到这些RAM区域。
一个用于Flash固化(例如F28335.cmd或28335_FLASH_lnk.cmd)：这个文件里，MEMORY部分的PAGE 0会包含FLASH区域（如BEGIN : origin = 0x3F8000, length = 0x002000），SECTIONS部分会将主要的代码段分配到FLASH，而将需要快速访问的数据段（如.ebss,.stack）分配到RAM。

注意：很多初学者犯的错误就是，在编译Flash版本时，没有在工程设置中把链接命令文件从RAM的CMD切换到Flash的CMD，导致代码还是被链接到了RAM地址，烧写后自然无法运行。

2.3 工具准备：CCS与Flash API库

工欲善其事，必先利其器。你需要确保环境就绪：

Code Composer Studio (CCS)：建议使用较新的版本，如CCSv10或CCSv11。它们对C2000系列的支持更完善。安装时务必勾选C2000编译器和支持包。
C2000ware：这是TI提供的官方外设驱动库、示例代码和实用工具库。从TI官网下载对应你芯片型号（F2833x）的C2000ware包。里面包含了我们最需要的Flash API库和Flash烧写示例工程。
仿真器：确保你的仿真器（如XDS100v3, XDS200, XDS560）驱动已正确安装，并能正常连接和识别到F28335芯片。

3. 完整实操流程：从工程配置到成功烧写

理论铺垫完毕，现在我们进入实战环节。我会以一个从零开始的新建工程为例，演示如何一步步配置并成功将代码烧写到Flash。

3.1 步骤一：创建或转换工程基础配置

假设你已经有一个在RAM中调试正常的工程。如果还没有，可以先创建一个简单的LED闪烁工程进行测试。

导入Flash API库：
- 在C2000ware安装目录下，找到device_support\f2833x\vXXX\examples\cpu1\flash_programming这样的路径。里面会有Flash28335_API_V210.lib这样的库文件（版本号可能不同）。
- 在你的CCS工程中，右键点击工程名 ->Add Files...，将这个.lib文件添加到工程中。通常我习惯把它放在一个叫lib或driverlib的文件夹里，方便管理。
- 同样，找到Flash28335_API_V210.h头文件，将其所在路径添加到工程的Include Options中。在工程属性 ->Build->C2000 Compiler->Include Options里添加。
切换链接命令文件：
- 在CCS的Project Explorer视图中，右键你的工程 ->Properties。
- 导航到Build->C2000 Linker->File Search Path。
- 在Include library file or command file as input一栏，移除原来的RAM链接文件（如28335_RAM_lnk.cmd），点击Add，选择你的Flash链接文件（如F28335.cmd）。
- 关键检查点：确保Command File预览框里显示的是Flash CMD文件的完整路径。

3.2 步骤二：修改主程序与添加烧写引导代码

程序不能直接就在Flash地址上运行，因为Flash速度慢，尤其是初始化代码（如.cinit运行时初始化）如果放在Flash里执行，效率会很低。标准的做法是“从Flash引导，拷贝到RAM运行”。

复制Flash到RAM运行函数：

在C2000ware的Flash示例工程中，找到一个名为MemCopy或CopyDataFromFlashToRAM的函数。它的作用是在main()函数之前，将指定的代码段（例如.ramfuncs，里面存放着对速度要求极高的函数，如中断服务程序）从Flash复制到RAM。
将这个函数及其相关声明复制到你的工程中。通常你需要自己写一个简化的版本：

// 假设我们将需要快速运行的函数放在一个叫 .ramfuncs 的段里 #pragma CODE_SECTION(MyFastFunction, ".ramfuncs"); void MyFastFunction(void) { // 你的快速函数代码，例如PWM中断服务函数 } // 在main()函数最开始调用 void main(void) { // 1. 初始化系统控制（PLL, 看门狗，时钟） InitSysCtrl(); // 2. 复制.ramfuncs段从Flash到RAM // MemCopy(&RamfuncsLoadStart, &RamfuncsLoadEnd, &RamfuncsRunStart); // 上述符号在CMD文件中定义，需要根据实际情况调用Flash API或memcpy // 3. 初始化Flash（设置等待周期，使能流水线缓存） InitFlash(); // 这是Flash API库里的关键函数！ // 4. 你的其他初始化（GPIO, 中断，外设） // ... while(1) { // 主循环 } }

调用InitFlash()函数：
- 这是至关重要的一步。InitFlash()函数来自我们导入的Flash API库。它的作用是配置Flash存储器的等待状态（wait-states）和使能流水线模式（pipeline）。如果不调用它，CPU以高速时钟访问Flash时，会因为Flash反应慢而导致读取错误，程序跑飞或死机。
- 这个函数必须在系统时钟（PLL）初始化之后，任何试图从Flash执行代码的操作之前调用。所以把它放在InitSysCtrl()之后，其他初始化之前是最稳妥的。

3.3 步骤三：编译与生成可烧写文件

编译工程：
- 点击CCS的编译按钮。确保编译0错误，0警告。如果有“section placement fails”之类的链接错误，通常是CMD文件配置有问题，回去检查MEMORY和SECTIONS的定义，确保地址和长度没有冲突或溢出。
生成Hex或Bin文件（可选但推荐）：
- 对于量产或脱机烧录，我们通常需要生成标准的Hex（Intel HEX）或Bin（二进制）文件。
- 在工程属性 ->Build->C2000 Hex Utility中，可以配置输出格式。
- 勾选Enable C2000 Hex Utility。
- 在Output Format中选择intel-hex或binary。
- 指定输出文件名和路径。重新编译后，在输出目录（通常是Debug或Release文件夹）就能找到.hex或.bin文件。

3.4 步骤四：使用CCS进行Flash烧写

这是最后一步，也是最容易出问题的一步。

连接目标板并上电：确保仿真器连接可靠，目标板供电正常。
进入Debug模式：点击CCS的Debug按钮（虫子图标）。CCS会连接芯片，加载程序（注意，此时加载的是.out文件信息，用于调试，并非烧写）。
运行Flash烧写工具：
- 在CCS的Tools菜单下，找到On-Chip Flash或F28xx On-Chip Flash工具。如果没找到，可能需要手动安装或从C2000ware中加载。
- 打开工具后，界面会显示芯片型号、Flash扇区等信息。
配置与擦除：
- 选择操作：通常选择Program（编程）。
- 输入文件：点击Browse，选择你刚编译生成的.out文件（不是.hex）。工具会从.out文件中提取地址和代码信息。
- 擦除选项：强烈建议在烧写前先执行擦除。可以选择Erase Sectors（擦除用到的扇区）或Erase Entire Flash（全擦）。全擦更干净，但耗时稍长。
- 验证选项：勾选Verify after program，烧写完成后会自动校验，确保数据正确。
执行烧写：
- 点击Execute或Program按钮。下方控制台会显示擦除、编程、验证的进度和结果。
- 耐心等待： Flash烧写比RAM下载慢得多，256K的Flash可能需要几十秒到一分钟，这是正常的。
复位与运行：
- 烧写并验证成功后，先点击CCS的Terminate退出调试连接。
- 给目标板完全断电再上电（或者按硬件复位键）。这一步是必须的，目的是让芯片从硬件复位状态开始，执行内部的BootROM引导程序，从Flash的起始地址（0x3F 7FF6）开始读取复位向量，从而跳转到你的应用程序入口。
- 重新连接调试器，点击Run，你应该能看到程序在Flash中正常运行了。此时拔掉仿真器，重新上电，程序也应能独立启动。

4. 深度解析：CMD文件配置与Boot流程

为了让你的理解更透彻，我们深入两个最核心的细节。

4.1 Flash专用CMD文件详解

我们以TI示例中常见的F28335.cmd为例，拆解关键部分：

MEMORY { PAGE 0: /* 程序存储器 */ FLASH : origin = 0x3F8000, length = 0x002000 /* 第一个8K Flash扇区 */ ... /* 可能还有其他Flash扇区定义 */ RAML0 : origin = 0x008000, length = 0x000800 /* RAM区域，用于运行 */ ... /* 其他RAM */ PAGE 1: /* 数据存储器 */ ... /* 各种数据RAM区域 */ } SECTIONS { /* 将代码段分配到Flash */ .text : > FLASH, PAGE = 0 .cinit : > FLASH, PAGE = 0 /* C语言全局变量初始化表 */ .switch : > FLASH, PAGE = 0 /* switch语句跳转表 */ .reset : > FLASH, PAGE = 0, TYPE = DSECT /* 复位向量，特殊处理 */ /* 将需要快速运行的函数段单独定义，加载在Flash，但运行地址在RAM */ ramfuncs : LOAD = FLASH, /* 加载地址：Flash */ RUN = RAML0, /* 运行地址：RAM */ LOAD_START(_RamfuncsLoadStart), LOAD_END(_RamfuncsLoadEnd), RUN_START(_RamfuncsRunStart), PAGE = 0 .ramfuncs : > ramfuncs, PAGE = 0 /* 将变量、堆栈等分配到数据RAM */ .ebss : > RAML1, PAGE = 1 .stack : > RAMM1, PAGE = 1 ... /* 其他数据段 */ }

关键点解读：

LOAD和RUN地址分离：这是实现“拷贝到RAM运行”的语法基础。链接器会为ramfuncs段生成两套地址符号：_RamfuncsLoadStart/End指向Flash中的存储位置，_RamfuncsRunStart指向RAM中的运行位置。你的MemCopy函数就利用这些符号进行数据搬运。
.reset段：这个段比较特殊，TYPE = DSECT表示它是一个“虚拟段”，不占用实际的存储空间，但它定义了复位向量的目标地址。芯片复位后，会跳转到这个地址（在Flash中）执行。

4.2 F28335的Bootloader流程

理解芯片上电后的行为，对调试启动失败问题至关重要。

硬件复位：芯片上电或复位后，首先执行固化在芯片内部ROM中的Bootloader程序。
检查引导模式： Bootloader会检查GPIO引脚（如F28335的GPIO84, GPIO85）的电平状态，决定从何处引导。常见的模式有：
- 跳转到Flash：当引导模式引脚配置为从Flash启动时（通常是通过上拉/下拉电阻实现），Bootloader会跳转到Flash的起始地址0x3F 7FF6。注意：这个地址存放的不是代码，而是一个跳转指令（LB _c_int00）的地址。_c_int00是C运行环境（RTS）的入口，它负责初始化全局变量（.cinit）、设置堆栈，然后调用你的main()函数。
- 其他模式：从SCI、SPI等外设引导，或从OTP引导，这里不展开。
执行用户代码：成功跳转到_c_int00后，就进入了你的程序世界。此时，CPU开始从Flash中取指执行。如果你的程序开头没有调用InitFlash()，CPU可能会以高达150MHz的速度去访问未配置等待状态的Flash，导致取指失败，程序“跑飞”。

5. 常见问题、排查技巧与避坑指南

这部分是我多年调试积累的血泪经验，希望能帮你节省大量时间。

5.1 问题一：程序在RAM调试正常，烧进Flash后不运行或死机

可能原因1：未调用InitFlash()或调用时机不对。
- 排查：检查main()函数开头，在InitSysCtrl()之后，是否立即调用了InitFlash()。确保没有在调用InitFlash()之前，执行任何复杂的函数调用或访问大量全局变量（这些操作可能隐含了从Flash取代码或数据的行为）。
- 解决：将InitFlash();作为main()函数中仅次于系统初始化的第二行代码。
可能原因2：链接命令文件未切换或配置错误。
- 排查：在CCS中，编译后查看生成的map文件（.map）。在map文件的“MEMORY CONFIGURATION”和“SECTION ALLOCATION MAP”部分，检查你的.text、.cinit等关键段是否被分配到了Flash地址（如0x3F8000附近），而不是RAM地址（如0x008000附近）。
- 解决：确认工程属性中链接的是Flash CMD文件，并检查CMD文件中Flash区域的origin和length定义是否正确，没有与其他区域重叠。
可能原因3：中断向量表未正确重映射或初始化。
- 排查：在RAM调试时，中断向量表可能被直接加载到M0 SARAM（地址0x000000）。但在Flash运行时，你需要将向量表拷贝到RAM中，并配置PIE向量表指针。查看你的中断初始化代码，是否有类似MemCopy(&PieVectTableInit, &PieVectTable, sizeof(PieVectTable));和InitPieVectTable();的调用。
- 解决：确保在main()中正确初始化PIE向量表，并将所有用到的中断服务程序（ISR）的入口地址赋值给对应的PIE向量。

5.2 问题二：CCS Flash烧写工具报错

错误：Error erasing flash或Error programming flash
- 可能原因：芯片锁死、Flash保护、电源不稳定、仿真器连接不良、时钟配置异常导致通信失败。
- 排查与解决：
  1. 检查连接：重新插拔仿真器JTAG口，确保接触良好。尝试降低JTAG时钟频率（在CCS的Target Configuration里设置）。
  2. 检查电源：用万用表测量芯片核心电压（1.9V）和IO电压（3.3V）是否稳定、纹波是否过大。
  3. 解锁芯片：如果之前烧写过带有代码安全模块（CSM）密码的程序，且密码未知，芯片可能被锁。这非常麻烦，可能需要通过特定的“密码擦除”流程，或者寻求TI官方支持。强烈建议在工程中预留一个不设置密码或使用已知密码的扇区。
  4. 尝试“擦除-编程-验证”分步进行：不要一键操作。先单独执行“Erase”，成功后再“Program”。

5.3 问题三：程序在Flash中运行速度异常慢

可能原因： Flash等待周期设置过小，或流水线未使能。
排查：检查你调用的InitFlash()函数具体实现。它应该根据你的系统时钟频率（SYSCLKOUT）来配置Flash控制寄存器的等待状态。例如，对于150MHz的时钟，通常需要设置较高的等待状态。
解决：确保你使用的Flash API库版本与你的芯片型号和CCS编译器版本兼容。也可以直接参考C2000ware中对应你芯片型号的最新示例工程里的Flash初始化代码。

5.4 独家避坑技巧

调试Flash程序的“笨”办法：当程序在Flash中运行异常，但又难以在线调试时（因为单步调试会触发Flash访问），可以这样做：在程序开头、InitFlash()之后，立刻点亮一个LED（GPIO输出高电平）。如果上电后LED亮，说明程序至少执行到了这里，问题在后面。如果不亮，问题在引导或最开始的初始化。再往后，每隔一段功能代码就切换一下LED状态，用这种“灯语”来定位死机位置，虽然原始但极其有效。
map文件是你的好朋友：养成查看map文件的习惯。它能告诉你每个函数、每个变量最终被放在了哪个地址，占用了多大空间。这对于排查内存溢出、地址冲突问题至关重要。
保留一个RAM链接的工程副本：始终保留一个配置为RAM调试的工程副本。当Flash版本出现诡异问题时，切换回RAM版本测试，可以快速判断是代码逻辑问题还是Flash配置/引导问题。
注意编译优化等级：高等级的编译优化（如-O2, -O3）可能会对代码进行重排、内联，有时会与依赖特定内存布局的启动代码或Flash拷贝代码产生微妙冲突。如果遇到难以解释的问题，尝试将优化等级调到低（-O0）或None进行测试。

把代码成功下载到Flash并独立运行，是DSP开发从“玩具”走向“产品”的关键一步。这个过程涉及硬件知识、编译器链接原理和芯片启动流程，综合性很强。希望这篇笔记能帮你打通任督二脉。记住，耐心和细致是调试嵌入式系统最重要的品质，每次遇到问题并解决它，都是你功力增长的时刻。

查看全文

http://www.jsqmd.com/news/1410133/