1. 内容整体设计与思路拆解
1.1 为什么别小看"建模板"这一步
做DSP开发，尤其是TI C2000系列，很多新手第一步就栽在工程模板上。TMS320F280025这颗芯片，属于C2000家族的Piccolo系列，主打电机控制、数字电源、工业驱动这些实时性要求极高的场景。它内部集成了FPU浮点单元、TMU三角函数加速器、CLA控制律加速器，主频最高跑到100MHz，外设也够丰富——12位的ADC、PWM带死区配置、CAN FD、PMBus等等。芯片本身性能不差，但如果你工程模板搭得不顺手，后面写再多代码都像是在沙地上盖楼。
我见过不少人在CCS里新建一个空工程，然后开始一通操作。等到要配置时钟树、初始化GPIO、搬运行程序到RAM里跑的时候，才发现缺这少那，一会儿报错找不到文件，一会儿烧录进去根本没反应。这些问题的根源，90%都是模板工程结构没理清楚。
所谓模板Template，本质上是把"芯片上电后到main函数执行前"之间的所有固定动作，提前做好封装，同时把链接脚本、启动文件、外设初始化代码、编译器选项这些基础设施一次性配置合理，让你后续开发只需要关心业务逻辑。对于TMS320F280025这种高性能实时控制芯片来说，这一步做得越扎实，后续踩坑的概率越低。
1.2 TMS320F280025的架构特点决定了模板的写法
F280025和传统的F2833x、F2806x不太一样，它属于更新一代的架构，内存映射、中断向量表、启动引导方式都有变化。最关键的一个区别是：F280025支持从Flash启动，也支持从RAM启动；而它的Flash等待状态、RAM分区、Boot ROM版本，都会影响工程配置。
更要命的是，它新引入了syscfg图形化配置工具。你可以用图形界面配置引脚、时钟、外设，然后工具自动生成C代码。这个工具用好了效率翻倍，用不好反而增加混乱——因为它生成的代码量不小，如果你不理解背后做了什么，出了bug根本不知道去哪里查。
所以我在这个模板里采用的思路是：半自动配置+手动兜底。外设初始化这类可以放syscfg让工具生成，但工程基础结构、链接脚本、启动流程、编译选项这些，必须自己完全掌控。这样既不丧失效率，又不至于被工具牵着鼻子走。
1.3 模板应该具备的四个硬性能力
一个合格的工程模板，至少要满足四个硬性能力：上电即跑、调试可看、外设可改、性能不丢。
上电即跑，说的是模板烧录进Flash后，断电重新上电能正常运行，而不是只能在调试器连接状态下跑。这个问题在C2000上特别典型，因为从RAM启动和从Flash启动，代码搬运、时钟初始化顺序是完全不同的。调试可看，是说你至少能通过CCS的Expression窗口、Graph工具看到关键变量的实时变化，不然写控制算法就是盲人摸象。外设可改，意思是模板里提供的DSP2800x_GlobalVariableDefs.c这类文件不要乱动，但GPIO、ADC、PWM的初始化代码要留好清晰的修改口子。性能不丢，则涉及编译优化选项、FPU快速库的链接、内联函数的使用时机——不能为了代码好读就把实时性牺牲掉。
这四个能力看着简单，实际把它们同时做到，模板才真正算立住了。下面我会从环境准备到工程创建，再到模板结构解析和问题排查，一步步讲透。
2. 环境准备与工具链选型
2.1 开发环境版本要选对
先说CCS版本。TI的Code Composer Studio现在分成两条线：老牌的CCS 12.x系列（基于Eclipse）和新出的CCS Theia系列（基于Eclipse Theia框架）。对于TMS320F280025，TI官方推荐使用CCS 12.5以上版本，或者CCS Theia 1.4以上的版本。
我的建议是：如果你刚接触，直接用CCS Theia版本。虽然改版后一些快捷键和界面布局变了，但从TI近两年的研发投入趋势来看，Theia肯定是未来方向，而且对syscfg的支持更顺畅。我自己现在主力用的是CCS Theia 1.5，整体体验稳定，编译速度也比老版本快一些。当然如果你手头有大量老工程（比如F2833x的代码），继续用CCS 12.x也没毛病，两个版本可以共存于同一台电脑。
还有一点容易踩坑：CCS版本和SDK版本之间有匹配关系。F280025对应的SDK是C2000Ware，目前常用的是C2000Ware 5.02.00.00这个版本。装好CCS之后，建议在CCS的App Center里直接把C2000Ware装好，不要单独去官网下载解压再手动配置路径，那样很容易出现头文件找不到、SDK路径变量没设置的问题。
2.2 仿真器与硬件准备
调试F280025，官方原厂仿真器XDS110是性价比最高的选择。它是USB接口，不需要外部供电，支持SWD模式和cJTAG模式。F280025的JTAG引脚是标准的TRST、TMS、TCK、TDI、TDO，接法跟着EVM板走就行。
如果你用的是第三方仿真器（比如XDS100V2），也能用，但要注意F280025是3.3V IO逻辑，有些老仿真器只支持5V电平，会存在电平不匹配的风险。另外，F280025的TRST引脚内部默认是弱下拉，如果仿真器连接不稳定，可以检查一下TRST引脚上是否外接了合适的上拉电阻。这个细节我在帮人排查问题的时候遇到不下三次——仿真器识别不到芯片，最后都是TRST电平问题。
硬件方面，我强烈建议手头备一块TI官方的LAUNCHXL-F280025C开发板，两百多块钱，自带XDS110仿真器、一个用户LED、一个用户按键、还引出了大部分引脚，做前期验证和跑模板测试非常方便。学习阶段完全不需要自己画板子，等模板跑通了再设计自己的底板，能省下大量排查时间。
2.3 安装C2000Ware SDK与路径规划
C2000Ware的安装路径其实很有讲究。Windows下默认装在C:\ti\c2000\C2000Ware_5_02_00_00，这个路径本身没问题，但要注意：整个路径不能出现中文、空格和特殊字符。别小看这个问题，CCS的编译器对路径解析非常敏感，一旦路径里有空格，编译的时候会莫名其妙报一些找不到文件的错误，而且报错位置还不固定，特别难查。
如果你打算把工程放在其他盘符，建议统一在一个固定的工作目录下管理，比如D:\Workspace\DSP_F280025\。把SDK、我的工程、脚本工具分开存放，避免后面工程多了找起来混乱。
装完SDK后，CCS会自动检测到SDK路径，并在新建工程时列出可用的SDK组件。如果你的CCS没有自动识别，可以在Window -> Preferences -> Code Composer Studio -> Products里手动添加SDK的路径。还有一个隐藏技巧：在工程的Properties -> Build -> C2000 Compiler -> Include Options里，可以看到SDK所有头文件路径已经通过变量的方式引用进来了，比如${COM_TI_C2000WARE_INSTALL_DIR}。这个变量最怕的就是被解析成带空格的长路径，如果编译报头文件打不开，优先查这里。
3. 工程模板创建实操全流程
3.1 新建工程的关键选项怎么选
在CCS里新建工程，File -> New -> CCS Project，弹出的窗口里有几个选项是决定工程能否跑起来的关键。
第一，Target选择。直接在型号栏输入TMS320F280025，注意不要选错成TMS320F280025C（那个是带Connectivity版本的）。虽然绝大多数情况下二者代码兼容，但启动文件和链接脚本是有细微差别的。
第二，编译器版本选择。CCS会自动匹配当前环境里可用的TI C2000 Compiler版本。如果你装了好几个版本（比如20.2和22.6），建议选最新的稳定版。我在F280025上实测，TI编译器20.2以上的版本对C99和C11的支持都很好，但有个别老的编译器版本（比如16.9）在编译某些内建函数的时候会生成低效代码，性能敏感的场景要特别注意。
第三，也是最重要的：Project type和Tool-chain那个字段。默认是Executable（可执行文件），这个不要动。关键是下面Output type的选项——如果只是做模板，选Executable即可，它最终会生成.out文件，供仿真器烧录调试。
第四，Linker command file选项。CCS会问你"是否拷贝linker cmd文件到工程中"，这里我建议手动勾选"Linker command file"并后续自己添加，或者选"None"然后从SDK拷贝。原因后面讲链接脚本时会详细说明——默认的CMD文件不一定适合你的应用场景，用系统浮点库还是快速浮点库，会让CMD文件内容完全不同。
3.2 选择空工程还是syscfg工程
CCS新建工程时还有一个分支选项：是创建一个完全空的工程，还是创建一个带syscfg配置文件的工程。
对于TMS320F280025，我的建议是创建空工程，然后再手动添加syscfg配置文件。别选CCS直接帮你生成的那个"Empty Project with syscfg"模板，因为它会生成一堆默认配置和说明文件，反而干扰你的理解。空工程虽然一开始什么都没有，但每一步你都清楚，出了问题你能定位到具体环节。
创建完空工程后，你应该能看到这几个文件：空的main.c（有的版本可能连main.c都没有，需要自己创建）、linker cmd文件（取决于你在向导里的选择）、以及工程配置文件.project和.ccsproject。这时候工程还编译不过，因为连main函数都没有，需要自己把启动引导那一套补齐。
这一步非常关键：从"空工程"到"能点灯"中间，差的正是整个模板的核心内容。下面我按步骤拆解。
3.3 启动文件与系统初始化代码的移植
F280025的启动流程其实不复杂，但顺序错了就全盘皆输。整个启动过程大致是：上电后CPU从Boot ROM开始执行，Boot ROM根据GPIO状态或者OTP配置决定从Flash启动还是从RAM启动。如果从Flash启动，会跳转到Flash入口地址，执行c_int00（C运行时初始化），然后调用main函数。
这里的核心是：c_int00之前需要完成时钟初始化、Flash等待状态配置、看门狗关闭，以及把运行期间需要高速访问的代码段从Flash搬运到RAM（比如ADC中断服务函数、PWM ISR这些对时序要求高的代码）。
你会发现SDK里已经提供了一个系统初始化文件，通常在device_support\f28002x\common\source\system_init.c。这个文件里的SystemInit()函数做了芯片时钟、Flash、看门狗等基础初始化，但是它是面向SDK例程的，不一定完全适配你自己的模板需求。我建议的做法是：把system_init.c拷贝到自己的工程目录下，然后删减冗余内容，只保留必要的初始化，并把时钟主频明确配置为100MHz（F280025最大主频）。
在main.c里，你需要按固定顺序调用初始化函数：
#include "driverlib.h" #include "board.h" void main(void) { // 初始化系统时钟，关闭看门狗，配置Flash等待状态 SystemInit(); // 初始化PIE中断控制器，清空中断标志 InitPieCtrl(); IER = 0x0000; IFR = 0x0000; InitPieVectTable(); // 用户外设初始化 DeviceInit(); // 使能全局中断 EINT; // 主循环 for(;;) { // 用户应用逻辑 } }注意SystemInit()和InitPieVectTable()的顺序不能反。PIE向量表必须在中断使能之前就把所有中断服务函数的地址装好，否则一旦有中断触发，CPU会跳到一个空向量，直接跑飞。
3.4 Flash等待状态与时钟配置的坑
关于时钟配置，F280025内部有一个片上振荡器（INTOSC1和INTOSC2），默认10MHz。通过PLL倍频可以到100MHz。SysCtrlRegs里面PLLCR寄存器是16位的，但只有低4位有效，倍频系数和F280025参考手册里的表格一一对应。如果你在SystemInit里看到的配置是乘10倍频——10MHz × 10 = 100MHz，那说明配置正确。
但这里有一个特别容易忽略的坑：当系统时钟从默认频率切换到100MHz之后，Flash的等待状态必须同步调整。F280025的Flash运行在100MHz时，至少需要3个等待状态（等待周期），否则Flash读取时序跟不上CPU速度，程序表现出的现象非常诡异——有时候能跑有时候死机，有时候换个编译优化等级就崩了。Flash等待状态的寄存器是FlashCtrlRegs.FRAC1，标准值是3个等待周期。SDK里的SystemInit已经配好了，但我见过有人精简代码的时候把这行误删过，导致程序运行不稳定，排查了很久才找到原因。
注意：不要随意改动Flash等待状态为0或1。F280025的Flash在100MHz主频下物理上就要求至少3个等待周期，改成更低的值会让取指出现随机错误，极难排查。
3.5 连接器CMD文件深度解析
链接脚本（CMD文件）是整个模板里技术含量最高的部分。它决定了代码段和数据的存放位置。F280025的内存映射里，Flash从0x080000开始（大小随型号不同有128KB和256KB的差异），RAM分为M0（1KB）、M1（1KB）、LS0-LS7（每段2KB）、GS0-GS3（每段4KB）等区域，另外还有一块受保护的RAM。
一个常见的错误做法：把所有代码都放在Flash里跑，所有变量都在RAM里，不用任何段搬移。这在简单例程里能跑，但在做电机控制或者数字电源这种实时性很强的场合，中断服务函数放在Flash里执行是有代价的——每次取指都要经过Flash的缓存和等待状态，中断响应的延迟会变差。正确的做法是把时间关键型代码段放进RAM中运行。
来看一下我模板中CMD文件的核心部分：
MEMORY { FLASH : origin = 0x080000, length = 0x00020000 /* 128KB Flash */ RAMLS0 : origin = 0x008000, length = 0x000800 /* 2KB */ RAMLS1 : origin = 0x008800, length = 0x000800 /* 2KB */ RAMGS0 : origin = 0x00C000, length = 0x001000 /* 4KB */ BOOTROM : origin = 0x3F8000, length = 0x008000 } SECTIONS { codestart : > BOOTROM, PAGE = 0 .text : > FLASH, PAGE = 0 .TI.ramfunc : > RAMLS0, PAGE = 0 .cinit : > FLASH, PAGE = 0 .stack : > RAMLS1, PAGE = 1 .ebss : > RAMGS0, PAGE = 1 .sysmem : > RAMGS0, PAGE = 1 .cio : > RAMGS0, PAGE = 1 }这里有几个关键点：
第一，codestart段必须放在Boot ROM区域（0x3F8000附近）。这个段存放的是跳转指令，它负责在芯片上电后引导到c_int00。如果没有这个段，芯片从Flash启动时会直接跑飞。TI的启动代码里一般有一个InitBoot函数，里面就是一条跳转指令，编译后放在codestart段。
第二，.TI.ramfunc段。凡是需要搬移到RAM中运行的函数，你需要在函数定义时加上__ramfunc修饰符，链接器就会把这个函数放到.TI.ramfunc段，启动代码中的CopyToRAM函数会在main之前把这些函数从Flash拷贝到RAM。F280025的启动代码里已经包含了这个拷贝逻辑，你只需要在CMD文件里预留好RAM空间就行。
第三，.stack段的RAM分配要留够。F280025默认栈大小一般是0x400（1KB）。如果你用了比较深的中断嵌套，或者在中断里调用了带局部大数组的函数，1KB可能不够。栈溢出在DSP上往往不会即时崩溃，而是过一段时间后才出现随机死机或者变量被莫名其妙改掉——这种坑非常难查。我的习惯是设置0x800（2KB），给足余量。
3.6 syscfg图形化配置与代码生成
TMS320F280025对syscfg的支持比较完善。配置文件的后缀是.syscfg，在CCS的工程里双击就能打开图形化界面。你可以在里面勾选要用的外设（GPIO、ADC、PWM、SPI、I2C、CAN等），配置引脚复用关系，设置时钟树参数，然后保存，CCS会自动生成对应的board.c和board.h文件。
我模板里的做法是：在工程中新建一个syscfg文件，配置下面这些基础外设：
- 系统时钟：设置PLL倍频到100MHz
- 一个GPIO输出（初始用于点灯测试，后续可以复用到其他功能）
- 一个GPIO输入（接用户按键，用于调试触发）
- ADC模块初始化（采用EPWM触发采样模式，这个在控制类应用中属于标配需求）
保存syscfg后，CCS会生成board.c，里面包含了Board_init()函数。这个函数会完成所有你在图形界面里配置的外设初始化。在main函数里调用这个函数，外设就处于可用状态了。
不过，syscfg生成的代码有一个特点——它默认把函数、结构体都封装好了，但如果你之后在代码里手动修改了寄存器配置，再重新生成syscfg，手改的部分会被覆盖。所以我的习惯是：board.c文件只由syscfg管理，永不做任何手动修改。所有个性化的寄存器配置都放到用户自己的源文件中，放在board.c的外面。这样即使重复生成，也不会丢掉你的定制内容。
3.7 点灯测试与烧录验证
模板工程编译通过后，先做一个最简单的点灯测试，确认全链路正常。F280025的EVM板上LED接在GPIO34上，输出低电平点亮。在main函数里加上GPIO初始化并翻转电平：
#include "driverlib.h" #include "board.h" void main(void) { // 初始化系统时钟 SystemInit(); // PIE中断初始化 InitPieCtrl(); IER = 0x0000; IFR = 0x0000; InitPieVectTable(); // 通过syscfg初始化的外设 Board_init(); // 手动配置GPIO34为输出，初始输出高电平（LED灭） GPIO_setPinConfig(GPIO_34_GPIO34); GPIO_setDirectionMode(34, GPIO_DIR_MODE_OUT); GPIO_setPadConfig(34, PIN_GPIO_PUSH_PULL); GPIO_writePin(34, 1); for(;;) { DEVICE_DELAY_US(500000); // 延时500ms GPIO_togglePin(34); } }编译后烧录，注意烧录时要选Flash的配置（F280025 Flash）。烧录完成后，按一下开发板上的复位键——如果LED开始按1Hz频率闪烁，说明模板的启动、时钟、GPIO整个链路已经通了。
这一步看似简单，其实是在验证三个核心环节：编译产物能否正确烧录进Flash、CPU能否从Flash正常启动并进入main函数、GPIO配置是否正确。任何一环出错，LED都不会按预期闪烁。
4. 模板工程结构与关键文件说明
4.1 一个清晰的目录结构长什么样
工程模板搭好之后，目录结构最好能一眼看出每个文件夹的职责。不要把所有源文件堆在根目录下，那样工程一膨胀就乱了。我的排列习惯是：
F280025_Template/ ├── main.c /* 主函数，仅保留系统初始化和主循环框架 */ ├── device/ /* 芯片相关文件 */ │ ├── system_init.c /* 系统时钟、Flash等待状态初始化 */ │ ├── startup_28002x.c /* 启动文件 */ │ └── 28002x_codestartbranch.asm /* 启动跳转汇编 */ ├── board/ /* 板级外设配置 */ │ ├── board.syscfg /* syscfg图形化配置文件 */ │ ├── board.c /* syscfg生成的外设初始化代码 */ │ └── board.h ├── drivers/ /* 用户外设驱动 */ │ ├── gpio_driver.c/h │ ├── adc_driver.c/h │ └── pwm_driver.c/h ├── app/ /* 业务逻辑层 */ │ └── user_app.c/h └── linker/ /* 链接脚本 */ ├── 28002x_flash_lnk.cmd └── 28002x_ram_lnk.cmd /* 可选，用于RAM调试 */device目录下的文件，来自SDK的device_support目录。TI官方SDK里提供的启动文件和codestart汇编可以直接用，不需要修改，但system_init.c建议按你的主频要求审视一遍——SDK默认可能是配置到120MHz（某些型号的最高主频），在这里你需要确认实际配置是否匹配F280025的100MHz。
board目录就是syscfg的天下，我只做配置，不手动改生成的代码。drivers目录放自己封装的外设驱动，小程序可能觉得没必要封装，但工程一旦大起来，良好的分层能极大提升维护效率。app目录是业务逻辑，比如你要写一个电机控制算法，就把算法模块放这里。
4.2 startup文件与codestart段的作用
boot ROM完成后，CPU跳转到Flash中固定的启动地址，这个地址上存放的就是28002x_codestartbranch.asm文件生成的跳转指令。跳转到哪里？跳转到c_int00——C运行时的初始化入口。c_int00做的动作包括：初始化C环境（变量清零、全局变量赋值）、调用系统的初始化钩子，最后跳到main函数。
在F280025的开发中有一个容易被忽略的文件是startup_28002x.c。这个文件里定义了标准C运行时需要的底层函数，比如_stack_init、_cinit初始化等。如果你用的是TI官方SDK，这个文件会通过头文件方式被自动引用，不需要显式添加到工程中。但如果编译时提示找不到_abort或者__TI_auto_init符号，就要检查这个文件是否被正确引用了。
有一个细节值得注意：F280025是从Flash启动的，Flash中代码的读取涉及静态随机存储器的缓冲和预取机制。所以启动文件里有一项重要工作：验证Flash配置是否正确。如果你的Flash配置有误（比如等待状态过少），启动过程中代码取指就会出错，导致c_int00都没跑完就死机。在调试这种问题时，把断点设置在c_int00入口处，单步执行几步，看PC指针是否乱跳，是最快的定位方式。
4.3 CMD文件的选型：Flash与RAM两套方案
我在模板里保留两套CMD文件：一套是烧录到Flash用的（28002x_flash_lnk.cmd），一套是RAM调试用的（28002x_ram_lnk.cmd）。为什么两套都需要？
Flash模式用于实际的烧录和产品验证，但每次修改代码都需要重新烧录，耗时相对长。RAM模式则是把代码直接加载到RAM中运行，下载速度快，调试迭代体验好。两种模式各有利弊，工程中通常会预备两套配置，通过编译器预定义宏来切换。
RAM模式下的CMD文件，所有段都会分配到RAM区域。这时需要注意：RAM空间总共只有几十KB，如果代码量大了，链接器会报space overflow，这时候你就要回到Flash模式去跑完整代码。RAM调试只是为了功能验证阶段能快速迭代，不是所有场景都适用。
切换方式很简单：在工程Properties -> Build -> C2000 Linker -> File Search Path中，把当前激活的CMD文件做切换。或者在工程中放两个编译配置（Debug和Release），一个用Flash CMD，一个用RAM CMD。
4.4 头文件包含路径与预定义宏配置
工程模板要编译通过，头文件路径必须配置正确。F280025相关的头文件分布在C2000Ware SDK的几个子目录里：
C2000Ware_5_02_00_00/device_support/f28002x/common/include/ C2000Ware_5_02_00_00/device_support/f28002x/headers/include/ C2000Ware_5_02_00_00/driverlib/f28002x/driverlib/在CCS工程里，右键工程 -> Properties -> Build -> C2000 Compiler -> Include Options，把上面几个路径加进去。SDK安装正常的情况下，CCS会自动把这些路径解析好。但如果你的环境变量有问题，可以手动添加。
预编译宏也要配置好。F280025在编译时需要定义CPU1这个宏（在f28002x系列老式寄存器头文件架构下定义CPU1），另外在driverlib（外设库）架构下通常还需要定义F28002x_DRIVERLIB_MACROS。系统初始化文件里的SystemInit函数，会根据这些宏决定是否编译某些寄存器地址的映射代码。如果宏没定义，编译阶段依然能过，但运行阶段访问外设寄存器时可能会访问到错误的地址映射，导致外设完全不工作。这个坑我见过不少次——编译零错误，运行零反应，最后查出来是宏定义缺失。
5. 常见问题与排查技巧实录
5.1 仿真器连接不上芯片
现象：CCS点调试按钮后报错，提示无法连接目标，或者停留在"Connecting to target..."卡住不动。
排查顺序：
- 检查仿真器USB是否被正确识别，设备管理器里能看到XDS110的串口设备。
- 检查JTAG线序，F280025要求TRST、TMS、TCK、TDI、TDO五根信号线，外加GND。线松一根都不行。
- 检查目标板供电，F280025的JTAG接口有时需要目标板先上电，仿真器才能检测到目标芯片。
- 在CCS的Debug Configuration里，把JTAG通讯速度调低，比如从默认的5MHz调到1MHz。很多连接不上的问题，其实是布线质量不好导致高速JTAG通讯失败。
我实测下来，F280025的JTAG对线缆长度和信号质量比较敏感。如果你用杜邦线连接自制底板，超过10厘米就容易出现连接失败，换成屏蔽线或者缩短距离会立刻正常。
5.2 编译报错找不到头文件或SDK变量未定义
错误提示类似：#10008 cannot find file "driverlib.h"，而工程里明明已经加了include路径。
这种问题通常出在SDK路径变量上。CCS在工程中引用SDK头文件时，用的是变量${COM_TI_C2000WARE_INSTALL_DIR}。如果这个变量没有被正确解析（比如SDK没安装到默认位置，或者环境变量残留在旧版本），编译器就找不到实际路径。
解决办法：Properties -> Build -> C2000 Compiler -> Include Options里查看有没有一行包含上面这个变量，点击变量旁边的Browse按钮查看解析出来的实际路径。如果路径不对，直接改为绝对路径把问题绕过去。还有一种可能：多个SDK版本共存导致变量指向了错误版本，建议只保留一个C2000Ware版本，减少这种隐性冲突。
5.3 程序烧进Flash但复位后不运行
这个问题的特征非常典型：在线调试模式下，程序跑得好好的；烧录完成后拔掉仿真器，重新上电，芯片没有任何反应。
排查第一步：确认烧录的是Flash还是RAM。如果点击的是"Load Program"而不是"Flash Burn"，程序只存在于RAM中，断电即失，当然复位后不运行。正确操作是使用CCS的Flash烧录功能，或者点击Debug后程序加载进Flash再复位运行。
排查第二步：确认codestart段是否链接到Flash的启动地址。如果codestart段缺失或者地址不对，CPU从Boot ROM跳到Flash时找不到有效的跳转指令，会直接空转。
排查第三步：检查复位引脚。看门狗如果意外触发复位，或者复位引脚上有毛刺干扰，可能导致芯片反复复位，表现为"看起来没运行"。把看门狗在SystemInit里第一时间关掉，这是模板里默认要做的事。
5.4 使用syscfg之后编译冲突
配置syscfg后，有时会报重复定义错误，比如某个外设结构体symbol被定义了两次。这通常是因为你既在syscfg里勾选了该外设，又在自己的C文件里手动做了同样的初始化定义。
解决办法：明确分工。syscfg里只负责"板级外设启用"，用户代码只负责"业务逻辑里的参数配置"。比如ADC的采样触发源、采样窗口这类业务参数，不适合放在syscfg里配置，因为syscfg面对的是固定外设，对业务参数的支持不够灵活。把这些参数放在你自己的adc_driver.c中，用函数参数方式传入。这样既不冲突，又便于软件上的动态调整。
5.5 printf输出重定向与CIO问题
调试阶段想用printf打印信息，却经常发现数据不输出，或者程序卡死在某个位置。F280025内部有一个CIO（C I/O）缓冲机制，如果启用了printf，编译器会要求链接器提供.cio段。如果工程里没分配这个段，链接阶段可能报错；如果分配了但调试会话没有配置好CIO，运行时会卡在终端通信上。
解决方式有两种：
- 不启用CCS的CIO调试终端，而是把printf输出重定向到UART，用串口助手查看。
- 在工程里加一个简单的retarget函数，把fputc改写到UART发送函数上。
我更推荐第二种，因为模板最终是要跑在无调试器环境下的，串口打印才是产品阶段最可靠的调试手段。重定向代码也就十几行，模板做好这一步，后面调试效率提升非常明显。
6. 模板后续扩展与维护建议
工程模板做好了，接下来的扩展空间其实很大。基于这个模板，你可以快速新建ADC采样任务、EPWM波形生成、CAN通信调试、PMBus配置等各类功能。
比如做电机控制项目时，只需要在drivers目录下新增一个motor_ctrl.c，在app目录下新增对应的控制算法模块，main循环里把控制状态机挂上去即可。模板本身不需要做大的改动，最多在syscfg里增加几个PWM通道和ADC引脚的配置。
还有一点后期维护的建议：模板工程和业务工程尽量分开。模板作为一个独立工程存档，每次升级工具链或者SDK版本，都先在模板工程上验证一遍编译、烧录、运行，确认无问题再同步到业务工程。不要直接在业务工程里反复修改基础设施内容，那样久而久之，模板和业务代码纠缠在一起，维护成本越来越高。
再一个建议是：把常用的初始化代码写成宏或者函数。比如GPIO翻转、PWM占空比更新、ADC启动采样，这些操作在项目里会被高频调用，封装成内联函数（用static inline），既保持代码可读性又不损失性能，C2000编译器对这类内联函数优化得很好。
7. 写在最后的个人经验
从我实际折腾F280025模板的过程中总结几点体会，希望能帮你少走弯路。
第一个体会是：别嫌模板搭建麻烦。这个步骤省下的时间，会在后面无数个调试之夜还给你。我最早从F28335转过来时，也嫌SDK自带例程太臃肿，想自己从零搭建精简模板，前后折腾了差不多一周，中间踩了启动文件、Flash等待状态、CMD文件段的坑。但模板稳定之后，后续做ADC采样、SPI通信、电机控制驱动，基本都是几天一个功能，效率提升不是一点半点。
第二个体会是：多看TI官方手册里的Figure和Table，比看正文文字有效得多。F280025的芯片手册是SPRSP65（具体版本号会更新），里面Memory Map那张大表值得反复看，把Flash、RAM、Boot ROM的地址关系弄懂了，CMD文件怎么写都不会错。
第三个体会是：善用CCS的反汇编窗口。很多看起来玄学的运行异常，放到反汇编窗口下看几条指令，真相立刻浮现。比如栈溢出导致的函数返回地址被改写，反汇编窗口里能看到PC跳到了根本不该出现的地址。
这个模板我会持续维护，后续也可能把基于这个模板的ADC采样、EPWM中断、串口打印这些外设扩展模块再整理出来，继续分享。DSP开发这件事，把地基打好，上层建筑就稳了。
