这款TMS32F28P550是我最近一个电机控制项目里用到的核心主控调试过程可以用“一波三折”来形容。从拿到样板开始就陆续遇到了仿真器连接不稳定、程序跑飞、串口乱码、外设不工作等一串问题中间还夹杂着不少玄学最后靠着逐项排查和原理图、手册反复核对才把问题一个个摁下去。这篇实录不是官方手册的复读而是把我实际踩过的坑、排查的思路、以及最终验证过能用的操作步骤全部记录下来给正在用或者准备用这颗料做硬件调试的朋友一份参考。考虑到这颗芯片属于C2000系列的新型号网上详细的中文调试资料还不算多很多朋友第一次上手可能连CCS环境配置都会卡住。所以这篇文章会从项目整体思路讲起把调试环境搭建、启动流程、电源时钟、SCI串口、常见问题排查这几个大块拆开来讲每一块都会带上具体的操作步骤和我实测后的心得。不管你是刚接触C2000系列的新手还是从F28335、F280049切过来的老手这篇文章应该都能帮你省下不少时间。1. 项目全景这次调试到底遇到了什么问题TMS32F28P550这颗料定位是实时控制MCU适合电机控制、数字电源、储能逆变器这类对PWM分辨率和ADC采样精度要求很高的场景。我这次的项目是做一台低压伺服驱动器主控需要同时输出三路互补PWM、实时采集两路电流和一路母线电压、还要跑一整套FOC闭环算法对主频、ADC时序和外设联动的要求都比较苛刻。选F28P550的原因很简单C2000生态成熟代码迁移成本低而且这颗料在Math加速和三角函数运算单元上做了不少升级处理FOC这类算法比老型号轻松得多。板子回来后我最初以为硬件调试能一路顺利结果从第一次上电开始就没消停过。今天尝试连接XDS110仿真器时报错明天程序烧进去几秒钟后反复复位后天串口打印乱码再往后GPIO输出电平不对外设怎么配都没反应。这些问题单个拿出来都不算稀奇难的是它们会相互干扰——电源不稳可能导致仿真器连接失败时钟配置错误又会让串口波特率算错最后表现出的症状五花八门。所以这篇文章的第一件事就是帮你建立一份完整的问题地图让排查思路从追着症状跑变成按模块逐项扫。我把这次调试中遇到的主要问题按优先级排了个队方便后续展开第一优先级仿真器连接失败、连接不稳定、经常掉线第二优先级程序烧录后无法运行、反复复位、跑飞进入异常中断第三优先级GPIO输出异常、外设寄存器写不进、中断不触发第四优先级SCI串口乱码、波特率不准、收发行为诡异第五优先级Flash烧写失败、烧完上电不运行、程序跑了但像没烧进去问题看着多其实根源往往集中在几个点上。仿真器连接问题八成都出在供电、复位电路和JTAG引脚复用上程序跑飞和反复复位多半是看门狗、时钟源选择、堆栈配置这三件事没处理好串口乱码则要重点看波特率误差、参考地电位和电平转换电路。后面的章节我会按照这个逻辑线逐步拆开每个问题都给出我实际验证过的排查步骤。2. 调试环境与工具链搭建别在起点就翻车2.1 开发环境版本选择CCS不是越新越好C2000系列的传统开发环境是CCSCode Composer Studio。F28P550属于新系列必须使用CCS的较新版本才能正确识别设备型号和下载driverlib库文件。如果你还在用CCS 6或者CCS 7这种老版本接上仿真器后大概率会提示“Unknown device”或者无法加载C2000器件支持包。建议直接安装CCS 12.x或更新版本在安装组件时把“C2000 MCU”组件勾选完整包括编译器工具链、SysConfig用于外设配置的图形化工具和Flash插件。我刚开始图省事装的是精简版结果很多外设驱动库和链接命令文件缺失后面还是要回头补装浪费时间。编译器方面建议使用TI官方推荐的C2000编译器版本不要太旧。CCS的工程属性里可以看到编译器版本新系列芯片如果有更新CCS会自动提示可用的编译器升级建议升级到当前稳定版本。在使用driverlib API开发时不同编译器版本之间通常不会有大问题但老版本编译器偶尔会有浮点运算优化异常的情况遇到“测得数据完全不对”而又找不到逻辑错误时顺手切一下编译器版本可能就解决了。2.2 仿真器与调试器选型XDS110优先C2000常用的调试器有XDS110、XDS100v2/XDS100v3以及TI LaunchPad板上自带的仿真器。对于F28P550这颗新料我建议直接用XDS110。原因很现实XDS110支持较新的target configuration调试速度更快对5V/3.3V目标板的兼容性更好而且TI官方很多新板的调试器都是XDS110方案社区里遇到问题更容易找到参考。如果你手头只有XDS100v3也不一定不能连但在创建target configuration时要注意选择正确的连接类型。我实际测试下来XDS110在TCK频率设置、固件自动升级和稳定连接方面的体验明显更好。调试时如果遇到连接不稳定优先怀疑调试器固件过旧——CCS会提示升级XDS110固件直接升级即可。选好调试器后接线是关键。F28P550支持JTAG和cJTAG两种模式XDS110默认使用cJTAG。如果目标板上没用标准的14pin或者20pin JTAG插座而是自己引出的测试点一定要核对清楚TCK、TMS、TDI、TDO和GND的顺序。我在调试初期就因为把TDI和TDO接反而折腾了半小时现象是仿真器能识别到目标板电压但连接器件时一直报找不到DSP。注意任何情况下都强烈建议先给目标板单独供电再用调试器连接。XDS110的3.3V输出能力非常有限只适合作为参考电压不能作为目标板的电源否则会在连接瞬间供电跌落导致仿真器掉线。2.3 串口调试助手的正确姿势串口调试这块我用过SSCOM、XCOM、友善串口助手等好几款工具。对于Windows用户个人推荐XCOM或者SSCOM两个都稳定功能也齐全。Mac用户可以用串口调试助手for Mac但功能相对精简关键的hex显示和时间戳功能还是有的。移动端调试不太方便一般还是建议直接在电脑上操作。使用串口助手的几个细节要注意波特率、校验位、数据位必须与目标板SCI初始化一致F28P550的SCI默认一般是8N18数据位、无校验、1停止位。打开串口前确认一下的COM口号避免打开错误端口导致乱码或设备占用。如果使用的是USB转TTL模块还要确认模块侧电平是3.3V还是5V——F28P550的IO是3.3V电平如果你用5V的USB转TTL模块直接接轻则通信异常重则损坏引脚。串口无法打开时优先检查驱动。CH340芯片的USB转串口在Windows下需要装驱动装完驱动后设备管理器里如果出现感叹号可以试试更换USB线缆或插到机箱后置USB口。我的经验是USB转串口模块的供电能力往往不稳定如果模块还要额外给目标板供电极容易造成串口通信异常这时候用独立的稳定电源给目标板供电串口模块只接TX、RX、GND三根线问题通常会直接消失。3. 启动流程与Boot模式程序“跑不起来”的第一步排查3.1 Boot引脚与启动顺序C2000系列的芯片内部固化了一段Boot ROM上电后会根据Boot模式引脚的电平状态决定从哪里加载应用程序。F28P550的Boot模式选择引脚通常在GPIO24TMS和GPIO32TDI等引脚上具体以数据手册的Boot Mode表格为准。常见模式包括从Flash启动、从SCI启动串口烧录/加载、从CAN启动以及并行IO启动。调试中最容易犯的错是开发阶段用仿真器加载程序到RAM里跑得好好的但一旦断电重新上电程序就不运行了。原因多半是Boot引脚被拉到了非Flash启动模式或者程序压根没烧到Flash里。我建议在硬件设计阶段就默认把Boot引脚配置为“从Flash启动”只在特殊场景下才手动切换。如果有需要从串口启动的场景就要把BOOT引脚拨到SCI Boot模式。F28P550在SCI Boot时默认使用某个固定波特率一般是9600或115200不同器件可能不同引导程序会通过串口接收应用程序数据并加载到RAM中。这种模式在量产烧录时比较有用但正常调试时容易让人蒙圈——明明程序在Flash里为什么上电后没反应大概率就是Boot引脚被意外拉到了SCI模式。3.2 复位电路与复位引脚F28P550的复位引脚低电平有效硬件复位电路的核心诉求是保证上电时复位信号持续时间足够长使得电源稳定前芯片不会开始执行程序。我见过不少新手用RC复位电路结果电阻电容值取得不合适复位时间不够电路上电后芯片处于不确定状态最终表现就是仿真器需要反复尝试才能连上。调试时最直接的检查方法是用示波器看复位引脚的波形上电瞬间应该有一个由低变高的跳变而且低电平持续时间不能太短。如果示波器显示复位脚一直有周期性脉冲那很可能是外部看门狗芯片或某个外设在反复拉低复位线比如复位芯片的阈值电压设置错误、电源纹波过大导致复位芯片频繁触发这些都是要优先排查的。示波器看波形时建议使用单次触发捕捉上电瞬间的复位时序。有的复位芯片带手动复位按键按键按下时复位脚应为低电平松开后应恢复高电平这个也可以用万用表简单验证。3.3 看门狗是个“隐形杀手”C2000系列内部有看门狗模块默认上电后是开启的。如果应用代码里没有及时喂狗或者看门狗时钟源配置异常程序就会陷入不断复位循环。表现出来就是程序烧写后运行一瞬间然后马上复位周而复始跟“程序压根没烧进去”或者“Flash没擦干净”的表现很像。排查看门狗问题的方法很简单在main函数最开始加上禁用看门狗的代码确认程序能不能稳定运行。C2000的driverlib里有对应API直接调用即可。如果在初始化阶段禁用看门狗后程序恢复正常那说明问题确实在看门狗喂狗逻辑或者中断优先级上。后续正常的应用开发中根据项目需求决定是否启用看门狗如果需要启用喂狗代码要放在主循环的固定位置不能在中断里喂狗也不能在某些阻塞循环里长时间不喂狗。我还踩过一个坑在调试时通过CCS的暂停功能停住程序查看变量结果停下来期间看门狗还在跑恢复运行时触发了复位。这种情况会干扰调试进程所以调试阶段建议先禁用看门狗等调完功能再统一处理。4. 电源与时钟系统C2000调试最容易翻车的两个地方4.1 电源供电与去耦设计F28P550的供电引脚虽然不多但要求不少。VDDIO供电3.3V模拟电源VDDA一般也是3.3V内核电压有的器件由内部LDO产生有的需要外部稳压器供电。在调试初期首先要确认万用表测量到的各电源引脚电压是否在规格范围内特别是VDDA和VDDIO的电压纹波不能太大。一个容易被忽略的细节是C2000的上电时序。有的系列要求模拟电源先于数字电源稳定虽然新型号的电源时序要求放松了很多但为了稳妥硬件设计时最好能让电源同时建立或者确保3.3V电源的建立时间远小于复位时间。如果上电时序不对可能出现芯片能连上仿真器但外设行为异常的情况这种问题非常隐蔽。去耦电容的位置也很关键。每个电源引脚旁边都应有0.1uF高频去耦电容而且电容要尽量靠近引脚放置VDDIO和VDDA分别放置。如果板子空间紧张至少也要保证模拟电源引脚附近的去耦电容到位否则ADC采样值跳变、SCI通信偶发错误这类“玄学”问题就会接踵而至。我在调试中遇到的一个典型现象是程序和仿真器都正常但每次电机启动瞬间芯片就会复位或者SCI通信中断。用示波器一测发现是电机驱动的功率部分在切换时导致电源电压跌落了几百毫伏持续时间只有几十微秒但足以让芯片复位。后来在电源输入端加大电解电容、并对驱动部分做了更充分的滤波才解决。这个问题的本质是电源动态响应不足而非F28P550本身有问题。4.2 时钟源选择与PLL配置时钟配置是C2000调试的分水岭时钟没配好所有外设看起来都不正常。F28P550有多路时钟源包括内部振荡器INTOSC和外部晶振输入。上电默认使用内部振荡器内部振荡器频率精度足够跑通用代码但如果你的应用依赖精确的波特率比如SCI通信就必须用外部晶振并正确配置PLL。PLL配置的核心思路是先选定参考时钟再根据目标系统时钟计算倍频和分频系数。配置完PLL后建议读取PLL状态寄存器确认锁相成功再继续初始化外设。如果PLL配置参数不合法或者参考时钟不稳定PLL会处于“未锁定”状态这种情况下程序虽然能执行但外设时钟频率完全是错的串口、PWM、ADC全都会出现诡异的异常。调试时钟最简单的工具是CCS的寄存器窗口直接查看系统时钟相关寄存器。另外很多C2000的driverlib会提供SystemClock初始化函数参数里直接填目标时钟频率库内部会计算配置值。但有一个关键点函数参数是基于某个特定参考时钟频率计算的比如8MHz晶振和10MHz晶振传入相同目标频率时实际配置结果会不同。修改晶振后必须同步修改代码里的参考时钟值否则就会得到错误的PLL配置。5. SCI串口调试实战从乱码到稳定通信5.1 SCI初始化关键参数与波特率计算串口调试看似简单但越简单的东西越容易在细节上出错。SCI模块的初始化主要包括引脚复用配置把GPIO配置为SCIRX和SCITX功能、外设时钟使能、波特率设置、数据格式设置、FIFO配置、中断配置如果使用中断方式接收。引脚复用配置是很多人容易忽略的一步。F28P550的GPIO默认是普通IO功能必须通过GPIO MUX寄存器或者driverlib的GPIO_setPinConfig函数把对应的引脚切换到SCI功能。没有做这一步程序里初始化SCI寄存器是完全无效的因为信号根本没被路由到外部引脚上。波特率计算是另一个重灾区。SCI的波特率由LSPCLK和波特率寄存器BRR决定计算公式大致是波特率 LSPCLK / (8 × (BRR 1)) 或 波特率 LSPCLK / (16 × (BRR 1))取决于BRR是否为0。由于BRR是整数计算出的实际波特率与目标波特率之间必然存在误差。当LSPCLK较高、目标波特率也较高时误差可能会变大导致通信质量下降。以LSPCLK 25MHz、目标波特率115200为例算出来的BRR可能是某个值实际波特率与115200之间的误差需要控制在2%以内才比较安全。我调试时直接用一个USB转TTL模块和一个串口助手最开始用115200通信完全正常后来换了一个目标板同样的代码却出现乱码。排查了半天发现是晶振频率变了LSPCLK也随之改变理论上BRR还是按旧值配的导致波特率偏离。所以一旦更换晶体或者调整时钟树就一定要重新核算波特率寄存器。5.2 乱码常见原因不只是波特率串口乱码大家第一个想到的是波特率不匹配这没错但还有几个原因经常被忽略。地线问题排在首位——如果目标板和串口模块不是同一个电源系统供电而且没有共地那么RX/TX信号的电平参考点就不一致数据完全没法正确解析。我自己调试时遇到过一种情况用USB供电时正常换成外接电源后就乱码后来发现是因为USB转串口模块和外接电源各自的地没有连好两端地电位差导致通信异常。其次是电平标准问题。F28P550的SCI逻辑电平是3.3V TTL而如果串口模块是RS232电平正负电压逻辑两者不能直接相连中间必须加MAX3232这类电平转换芯片。很多人买了带DB9接口的串口线直接接板子结果完全不通就是这个原因。正确做法是使用USB转TTL模块或者确保板子上已经集成了RS232收发器。然后还有TX/RX交叉的问题。目标板的TX要接串口模块的RX目标板的RX要接串口模块的TX。看起来简单但我在示波器上量到目标板TX引脚确实有波形输出接上串口助手就是收不到数据最后发现是杜邦线插反了。另外如果使用的是带USB转串口的调试板部分模块的TX/RX引脚空闲状态是低电平需要确认模块的输出空闲电平是否符合RS232/TTL标准。有些廉价模块会在TX空闲时输出错电平那也会导致接收端持续认为收到数据表现为乱码或者不断进入接收中断。5.3 收发异常与中断丢失串口能打印数据但数据内容不正确可能是数据位、校验位、停止位配置错误。我之前为了调试一个传感器模块把数据位配成了7位结果通信一直不正常后来发现传感器模块输出是8位数据。所以SCI格式配置不仅要和目标端匹配还要确认对端设备的真实配置。如果使用中断方式接收数据还需要注意中断优先级和FIFO设置。C2000的SCI自带FIFO如果FIFO中断阈值设置太高可能数据还没来得及触发中断FIFO就溢出了如果阈值设置太低频繁进中断又会干扰实时控制任务。一般调试阶段建议先使用查询方式接收确认数据确实到达了再切换为中断。另外还要检查SCI的中断使能是否在PIE模块中被正确配置。C2000的中断系统使用PIE外设中断扩展如果PIE使能没有打开或者中断向量表没正确映射SCI接收中断永远不会触发。检查方法是设个断点看程序是否进入中断服务函数。5.4 485通信的额外注意事项如果项目里用到RS485总线的串口通信还有一个额外的关键点方向控制DE/RE。RS485是半双工通信发送时必须把DE拉高发送完成后必须把DE拉低否则接收端永远收不到数据或者发送完无法接收。F28P550的SCI本身没有专用485方向控制引脚一般用GPIO控制MAX485或类似芯片的DE/RE引脚。调试485总线时最容易出现的问题是方向切换时序没处理好。发送最后一个字节后如果立即把DE拉低可能最后一个字节还没完整的发出去就会截断数据。我一般在发送完最后一个数据后加一个延时视波特率而定比如9600波特率至少延时1ms以上再切换方向。另一种方案是使用SCI的TX中断标志来判断发送寄存器是否为空但最保险的还是延时法简单粗暴且可靠。485总线还有一个常见问题总线空闲时A、B两线之间电压差必须在200mV以上接收端才会判断为逻辑1。如果总线上只有一个设备而没有加终端电阻和偏置电阻接收端可能处于不确定状态导致数据乱码或根本收不到数据。调试时可以在A、B之间加上120欧终端电阻如果总线较长或节点较多并在主设备端用10K上拉电阻到5V、下拉电阻到地把总线空闲电平偏置到确定性状态。6. 常见问题排查与解决方案速查表为了让你在板子出问题时能快速定位方向我整理了一张故障速查表这部分是这次调试中最实在的经验总结。症状可能原因排查方向与解决方案仿真器连接不上提示找不到目标供电不足、复位引脚异常、JTAG引脚复用、调试器接线错先量电源电压示波器看复位信号断开外设只留最小系统降低TCK频率核对JTAG接线顺序连接成功但程序无法烧写Flash芯片被锁定、Flash密码区错误、Flash等待周期不足检查CSM模块是否锁定尝试整片擦除确认CLK频率在Flash可承受范围内必要时先解锁再烧写烧写后上电程序不运行Boot引脚配置错误、程序没烧到Flash、看门狗复位核对Boot引脚电平确认烧写地址看复位引脚是否有周期性脉冲先禁用看门狗程序运行中反复复位看门狗没喂、电源跌落、堆栈溢出、非法中断先禁用看门狗测试示波器监控电源检查栈大小检查所有中断的向量是否有效串口输出乱码波特率误差过大、地线没连、电平不匹配、TX/RX接反核算BRR寄存器确保共地确认TTL电平交叉检查接线串口完全收不到数据引脚复用没配置、SCI外设时钟没开、对方没发数据检查GPIO MUX配置确认SCI时钟使能用示波器量TX/RX引脚波形GPIO输出电压不对引脚复用配置错误、输出模式没配、上拉下拉影响确认用的GPIO对应外设还是普通IO输出模式下DAT方向寄存器是否配置为输出ADC采样值跳变严重参考电压不稳、模拟电源去耦不够、采样窗口太短检查VDDA电压纹波加大采样时间软件滤波检查ADC通道是否被占用复用PWM输出没有波形EPWM时钟没使能、引脚复用错误、比较值写入不正确检查系统时钟里EPWM模块是否使能确认MEMORY映射寄存器确实写入了用示波器逐级检查中断不触发PIE使能没开、中断向量表没配、外设中断标志没清打开PIE模块确认中断服务函数地址映射正确发送过程中先清标志再使能中断6.1 “玄学”问题的通用排查法我在调试中还遇到过几次“跑了第一次正常复位后就不正常”、“昨天还好好的今天一上电就不行”这类玄学现象。面对这种问题我总结出了一套套路化排查法能解决大部分临时性故障。把目标板恢复到最小系统状态也就是只保留供电、复位、时钟、JTAG连接和最小启动电路把所有外设断开确认最小系统能稳定连接仿真器并运行点灯程序。如果最小系统没问题再逐步把外设接回去每接一个外设就测试一次。这个方法虽然土但比直接对着代码猜效率高得多。电源质量是所有玄学问题的头号嫌疑。你可以在示波器上观察3.3V电源是否有高频噪声、有没有周期性跌落。很多用了开关电源的板子如果布局不合理电源纹波会直接导致芯片工作不稳定。这时候在电源入口加一个LC滤波或者更换低纹波的LDO问题立刻消失。另一个容易被忽略的是引脚浮空问题。F28P550的部分引脚在上电复位期间是浮空态如果这些引脚恰好被外部电路拉到了某个电平可能影响芯片启动模式。在硬件设计时关键的Boot引脚最好加上确定的上拉或下拉电阻防止悬浮导致Boot模式随机变化。软件层面在进入main后尽早把关键GPIO设置为已知状态也能减少启动阶段的意外行为。6.2 调试器连接失败的特殊场景仿真器连接失败是最耽误时间的问题我把我遇到的几种特殊场景展开说。场景一可以识别到目标板供电电压但连接器件时报错。这种问题多半是JTAG线路时序不对。解决办法是降低TCK频率CCS的Target Configuration里可以设置TCK的频率。把频率从默认的较高值降到1MHz甚至更低可能就连接成功了。如果你的板子JTAG走线较长、或者用了杜邦线连接信号质量很难保证降频是最快的解决方案。场景二第一次连接成功运行过程中掉线重新连接时失败。这通常是程序运行后把JTAG引脚复用成了普通GPIO导致调试器无法访问芯片。F28P550的Boot引脚和JTAG引脚是复用的程序初始化阶段如果把这些引脚配置为特定GPIO功能仿真器必然会断开。解决办法是在程序启动时延迟一段时间再配置复用引脚或者通过CCS的连接设置指定使用软件复位方式连接。场景三CCS可以连接但烧写Flash时报错“Flash operation failed”。这种问题往往是程序运行时已经禁用了Flash相关的访问或者Flash配置的等待周期不正确。需要检查代码里是否有关闭Flash模块的操作并确认PLL配置后的系统时钟频率在Flash的规格范围内。如果系统时钟跑得太高而Flash等待周期配得太少写Flash就会不稳定出现偶发失败。6.3 代码层面的排查技巧硬件排查了半天发现一切正常最后九成问题会落到代码上。这里分享几个代码排查的技巧。善用断点。不管是仿真器还是调试器设置断点是基本功能。在关键函数入口设置断点单步执行观察程序流向是否符合预期。如果程序进入某个异常中断在异常中断服务函数里设置断点可以看到是从哪一步跳进去的。C2000的一些异常中断会包含CPU状态信息CCS的寄存器窗口里能查到返回地址顺着地址反查代码就能定位是哪一行出了问题。善用条件断点和日志输出。如果程序是跑在实时控制场景里直接断点会影响运行时序这时候可以把关键变量值通过SCI串口周期性打印出来。打印日志这件事看起来简单但要注意打印本身的耗时如果打印频率太高会干扰实时性能。我一般用一块缓冲区保存日志数据在主循环空闲时统一发送或者用DMA方式发送避免占用CPU太多时间。对比寄存器状态。如果你身边有一块正常的板子哪怕型号不同比如F280049对照着看两个板子同样状态下的寄存器值能快速发现哪里的配置被遗漏了。CCS的寄存器窗口支持导出功能你可以把正常板子的寄存器快照保存下来再和异常板子的快照做对比这种“差分法”在排查外设配置问题时极其高效。7. 调试验证与Flash烧写从RAM调试到独立运行7.1 RAM调试和Flash调试的差异工程开发阶段我们一般会先在RAM里调试程序因为RAM的读写速度快下载也快不会磨损Flash。但RAM调试有个坑代码和数据都放在RAM里程序运行速度可能比最终Flash运行要快一些有些时序敏感的外设在RAM调试时表现良好一旦烧录到Flash运行就会出现细微差别。Flash调试需要把代码链接到Flash地址段同时在初始化代码里把需要高速运行的函数或者常量复制到RAM中执行这是C2000工程里常见的处理手段。TI的driverlib工程链接脚本一般已经处理好了这些细节但在自定义工程或者从老工程迁移时要特别注意代码段和数据段的内存分配是否落在了合法的Flash地址范围内。如果烧录进Flash后程序不运行首先检查生成的.map文件确认main函数的入口地址是否在Flash范围内确认所有代码段都被成功链接到了Flash地址而不是意外跑到了一段不存在的内存区域。然后检查复位向量C2000的Boot ROM从Flash加载程序时会读取Flash入口地址如果Flash头部信息被破坏或者烧写不完整程序就会执行不了。7.2 烧写Flash的几个实践建议烧写Flash之前建议先做整片擦除。部分新手直接点烧录不先擦除最后程序写入不完整表现就是“烧写成功但运行不正常”。CCS的Flash工具里提供了擦除、烧写、校验等选项烧写之前先执行整片擦除然后再烧写烧写完成后务必勾选“Verify”校验一下确保写入的数据和bin文件完全一致。如果烧写过程中途断电或者调试器断开Flash里可能留下半截程序。这种情况再次连接时可能提示识别到未编程设备也有可能因为Flash密码区被写了一半而锁定芯片。大厂的新芯片一般可以通过整片擦除恢复但万一密码区CSM被意外烧写恢复起来会比较麻烦。调试阶段建议不要随便往密码区对应地址写数据除非你能承受芯片报废的风险。这里提一个我常用的操作习惯每次烧写Flash之前先把当前工程在RAM调试模式下全速跑一遍确认所有功能正常之后再切到Flash模式下烧写。这样能大幅减少“烧进Flash后运行异常”时排查问题的范围至少可以先把软件逻辑问题排除掉。7.3 脱离仿真器独立运行时的检查点最后程序在仿真器下跑得好好的断电后重新上电却不行这类问题的排查思路要从仿真环境和非仿真环境之间的差异入手。仿真器连接情况下程序可能在CCS的启动方式里被配置为先下载到RAM再运行而不是从Flash直接运行。断开仿真器后芯片上电从Boot ROM开始按照Boot引脚的配置决定加载路径。如果Boot引脚没有正确配置为Flash启动程序当然跑不起来。仿真器连接时芯片的电源由外部电源和仿真器同时供给断开仿真器后如果外部电源带不动板子芯片会反复复位。所以断开仿真器测试时要格外关注电源纹波及电压跌落可以再次用示波器检查上电波形。另外一个常见原因是GPIO状态。调试时某些GPIO由CCS强制拉高或拉低断开仿真器后这些GPIO执行的是程序里的初始化逻辑。如果你的程序依赖外部上拉或下拉信号来进入正常状态而这些外部电路又没焊上那独立运行时的GPIO状态就会和调试时完全不同从而引发一系列功能异常。8. 写在最后调试F28P550的心得与建议这次调试TMS32F28P550的过程前后用了大概一周。我最深刻的体会是C2000系列的调试问题绝大多数不是芯片本身的问题而是电源、时钟、引脚复用和启动配置这四个基础模块没打好地基。很多人在芯片不工作或者外设行为异常时第一时间去翻代码逻辑查外设寄存器结果查了两三天还是找不到原因最后发现是电源纹波超标或者某个Boot引脚被焊错电平。所以如果你也在调试这颗料我强烈建议先按电源、时钟、复位、Boot模式、仿真器连接这个顺序过一遍再投入精力去看具体外设。另外一点是关于工具链。CCS本身功能已经很完善但很多调试技巧比如寄存器快照对比、条件断点、日志缓冲输出需要自己主动去摸索和积累。XDS110虽然贵一些但在调试新系列芯片的时候效率提升是实打实的。串口调试助手看着不起眼却是排查问题的利器建议手边多备几个不同工具在特殊场景下有各自的优势。比如有的工具在连续接收大数据时会卡有的工具则在hex格式显示上更直观多试几个能找到适合自己的组合。我的建议是先做一块最小系统板把电源、复位、时钟、JTAG、SCI这五个部分都引出来测试全部通了再去做功能底板。最小系统板能稳定连接仿真器、烧写Flash、打印串口日志之后再逐步扩展外设每一步都验证过再往下走整个项目的调试成本会低很多。这算是我这次项目里最想分享的心得希望能帮你少走一些弯路。