这个项目标题我一眼就认领了。TMS32F28P550，TI C2000家族里一颗很有代表性的芯片，主打电机控制、数字电源、工业现场控制，性能强、外设丰富，但调试起来的坑也是真不少。这篇文章我打算把我实际调试这块板子时踩过的雷、排过的障完整写出来，从硬件上电、仿真器连接、Flash烧写、SCI串口调试，到运行时看门狗、中断、GPIO那几个经典疑难杂症，全过一遍。内容基本按我自己的排查顺序来，尽量把每一步的判断依据和操作理由说清楚，希望能帮到正在跟这颗芯片较劲的同行。也顺便给新手填一填那些手册上不会写、但实际必然会遇到的信息差。
1. 为什么要专门写这款芯片的调试实录
TMS32F28P550不是那种你拿来点个灯就能收工的芯片。它属于TI的C2000实时控制系列，核心是C28x DSP内核，带FPU、TMU，部分型号还有CLA协处理器，主频能做到接近200MHz的量级。这颗芯片在电机控制、数字电源、光伏逆变、储能PCS这些场景里出镜率很高，因为它天生就为高实时性闭环控制设计的，PWM、ADC、比较器、eQEP这些外设的配合是硬功夫。
但说句实在话，芯片本身再强，调试不顺利也是白搭。我最初拿到这块板子的时候，以为就是照着例程编译、下载、跑起来。结果从上电到连接仿真器，再到跑通一个最小的串口收发，中间折腾了整整两天。这个过程中暴露出来的问题，很多不是芯片本身的问题，而是调试工具链、硬件设计细节、芯片特有配置跟传统MCU开发习惯之间的冲突。
所以这篇东西的定位不是芯片手册的复述，也不是官方例程的照搬，而是站在一个实际使用者角度，把我认为最值得注意的调试要点、最容易卡人的环节、以及排查问题的思路整理出来。无论是刚接触C2000的新手，还是从STM32这类MCU转过来的老手，哪怕只避开其中一两个坑，这篇文章就没白看。
顺便说一句，因为C2000系列芯片的调试环境和调试思路跟ARM内核的MCU有比较大的差别，所以我后续所有排障思路都会尽量说清楚“为什么会这样”，而不是只给结论。知其然也知其所以然，后面遇到类似问题才能举一反三。
2. 上电排查：从“连不上目标板”说起
2.1 供电、复位与时序：三个容易忽略的基础项
第一块板子上电，我先用的普通直流稳压电源供电，电压设成3.3V，结果芯片压根没反应，仿真器也识别不到。这个问题的根子在于，F28P550是双电源架构，内核电压和I/O电压是分开的。I/O是3.3V，内核需要1.2V左右，板上必须有可靠的电源转换电路。只给3.3V，内核没有能量来源，芯片当然不工作。
正确的做法是上电前先看原理图，确认板上有没有独立的1.2V内核电源，或者至少确认电源方案能同时产生这两个电压。TI对F28P55x系列的上电时序有明确要求，一般是内核电源先起来，I/O电源后起来，或者同时起来，绝不能让I/O电源明显早于内核电源。这个时序要求如果板子设计没问题，通常由电源芯片的使能引脚或者软启动顺序来保证；但如果你的板子是手工飞线改的，或者用了可调压模块，就一定要用示波器双通道确认两个电源轨的上升沿时序。
复位引脚同样值得单独检查。F28P550的复位脚是低有效，有些设计会在上面加RC延时，也有些直接连到仿真器的复位输出上。如果你连接仿真器时一直报目标板无响应，可以用示波器量一下复位引脚在按下复位键或者仿真器尝试连接时有没有一个正常的下拉脉冲。我遇到过一块板子复位引脚被一个没焊接好的0欧电阻断开，看起来一切正常，实际上芯片一直停在上电复位状态，什么调试操作都白搭。
上电之后还有一个不能忽略的动作：确认TMS32F28P550的电源指示灯正常，核心供电电压纹波不要太大。这个芯片对电源质量有一定要求，我用示波器量过，开关电源直接供电时纹波接近100mV，后来换成LDO供电，纹波降到20mV以内，整个系统的稳定性好了很多。如果条件允许，建议用LDO给模拟部分和数字部分分别供电。
2.2 仿真器连接失败：从驱动到目标配置的完整排查链路
连仿真器是这块芯片调试里最经典的一道坎。我用的是XDS110仿真器，在CCS里创建目标配置时选择的是TMS320F28P550SJ这个型号。首次连接，CCS直接报“Error connecting to the target”，错误码大概是-1135之类。这里我总结一个半官方的排查顺序，基本能覆盖九成以上的连接问题：
第一步，检查仿真器驱动是否正常。在Windows设备管理器里要能看到Texas Instruments Debug Probe相关的设备节点。如果插上去没有任何反应，大概率是驱动没装好，或者USB线只能充电不能传数据。注意，仿真器线材的问题出现频率比想象中高得多，换一根高质量的数据线往往直接解决问题。
第二步，确认目标板的JTAG/cJTAG连接方式。F28P55x支持JTAG和cJTAG两种模式，cJTAG只需要两根线（TCK和TMS），能省引脚，但前提是芯片侧使能了cJTAG模式。如果目标配置里选的是JTAG而板上实际只引出了cJTAG接线，连接必然失败。这个我在一块自制的测试板上踩过，折腾了很久才发现是模式不匹配。
第三步，用CCS的Test Connection按钮测试连接。连接成功后，CCS会打印出扫描到的JTAG IR length、IDCODE这些信息。IDCODE能读出来，说明仿真器和芯片之间的物理链路没问题，问题大概率出在时钟配置或者芯片处于非调试状态。如果IDCODE全为FF或者0，首先要怀疑是供电问题，其次是复位脚被拉死，最后再怀疑JTAG引脚有没有被复用成GPIO从而干扰了调试链路。
第四步，如果你用的是XDS100系列的仿真器，务必确认固件版本和CCS版本兼容。我自己的经验是XDS110在新版CCS下的兼容性比XDS100好很多。现在CCS已经更新到比较高的版本，老版本CCS配合新固件经常出现莫名其妙的“could not determine device type”报错，升级CCS或者升级仿真器固件都能解决。
2.3 时钟配置和Boot模式跳线：容易被忽略的两块绊脚石
连上仿真器之后，还有两个和芯片启动状态密切相关的因素非常容易踩坑。
一个是时钟源。F28P55x支持内部振荡器，也支持外部晶振。芯片出厂时默认使用的时钟源由硬件配置决定，如果你的硬件设计用了外部晶振，但外部晶振起振失败，芯片会停留在一种半死不活的状态，仿真器能连上，但程序一跑全是奇怪的异常。最气人的是这种问题看起来很像代码逻辑错误。排查方式是看CCS寄存器窗口里CLKSRCCTL1相关寄存器的值，确认当前的时钟源选择是否和硬件一致。如果主时钟源没准备好，可以临时切换到内部时钟先把环境跑起来。我那次就发现是晶振的负载电容贴错了封装，换掉后问题立刻消失。
另一个是Boot模式引脚。F28P55x根据Boot引脚的电平状态决定是从Flash启动、从SCI启动、还是从并行IO启动。如果板子上的Boot模式脚被拉成SCI启动模式，程序烧进Flash后重新上电却跑不起来，因为芯片根本没有从Flash启动。这种情况在调试阶段不算少见，因为很多开发板出厂时Boot脚默认设置成串行下载模式，方便量产烧录。判断方法很简单，看一下GPIO配置对应的Boot表格，把Boot引脚拨到Flash启动模式再复位，程序就开始跑了。
这里还有一个容易忽略的关联点：连接CCS进行RAM调试时，芯片是从调试器引导的，跟Boot引脚没关系；但断开仿真器、独立上电运行时，Boot引脚的电平就决定了一切。我见过有人调试时一切正常，一拔仿真器就程序丢失，其实就是这个原因。
3. 烧写Flash与调试模式切换：RAM调试和Flash调试是两回事
3.1 RAM调试与Flash调试的本质区别
C2000系列芯片支持两种调试方式：RAM调试和Flash调试。这两个概念很多新手搞不清，实际上它们的区别直接决定你的程序能不能在掉电后保存、以及烧录过程是否顺利。
RAM调试，就是把代码加载到SRAM里运行。优点是烧写速度快、没有擦写次数限制、修改代码后可以立即运行，非常适合功能开发阶段的反复调试。缺点是掉电即失，程序无法独立启动。F28P55x内部有较大容量的SRAM，足够放大部分代码，但如果你代码量大，或者用了大量常量表，RAM可能会不够用。
Flash调试，就是把代码烧进内部Flash，然后从Flash里运行。缺点是烧写需要时间，Flash有擦写寿命限制（虽然现在动辄十万次，但也不要滥用）。优点是掉电不丢，程序能独立运行。真正产品上的代码，最终必然跑在Flash里。
CCS工程里通常会有两个linker command文件，一个用于RAM调试，一个用于Flash调试。很多踩坑的根源，是拿RAM版本的CMD文件去烧Flash，出来的现象是仿真器看起来烧录成功，但程序一复位或者重新上电就飞了。原因很简单：RAM版本的CMD文件根本没有把段分配到Flash地址空间，烧进去的东西根本不在Flash里。
3.2 Flash擦写、烧录报错的定位过程
我遇到过最典型的一次Flash烧写失败，报错是“Flash programming failed during erase sector”。排查过程让我印象非常深刻。
首先怀疑的是Flash烧写算法匹配问题。CCS在烧写Flash时会调用TI提供的Flash plugin，这个插件和芯片型号必须严格匹配。我在目标配置里如果选错了具体型号，比如将F28P550SJ选成了带A后缀的版本，烧写就会失败。核对型号后问题没解决，我随后开始怀疑供电稳定性。Flash擦写时电流需求比正常运行时高，如果电源带载能力不足，擦除过程中电压跌落，就会导致擦写失败。我给板子换了个输出能力更大的电源，问题依旧。
真正的原因最后锁定在Flash等待状态配置上。具体来说，Flash烧写对主频和Flash等待周期的配合有要求，如果芯片运行时钟过高而Flash等待状态配置不足，擦写就会出现偶发失败。解决方式是先降到较低频率，或者按照TI烧写工具要求把Flash等待状态设为最保守值，烧写完成后再恢复。这个问题的坑点在于芯片在正常调试运行时可能完全正常，一旦进入Flash擦写这种特殊操作就暴露了。
还有一个我后来养成的习惯：使用UniFlash工具做Flash烧写和擦除，而不是全依赖CCS的Debug模式。UniFlash是TI专门用来做Flash烧写的独立工具，它能把烧写过程跟调试环境剥离开，问题定位思路会清晰很多。而且在UniFlash里能直接读取Flash内容用于校验，这对判断烧写是否真正成功非常直观。
3.3 DCSM安全模块：烧写保护的隐形坑
F28P55x带一个叫DCSM（Dual Code Security Module）的安全机制，说白了就是防止别人读取你的Flash代码的安全模块。它通过存储在特定区域的安全密码控制Flash的读写权限。这个模块对产品防抄板很有用，但对调试来说，它就是一颗不定时炸弹。
如果你不小心烧录了一个使能DCSM安全保护的工程，然后修改了安全密码，那么在未解锁状态下，仿真器就再也不能通过JTAG访问Flash了，报错通常是“Secure device locked”或者“Cannot access memory at address”。我第一次踩到这个坑，心里凉了一半，以为是芯片报废了。后来才知道TI提供了通过特定引脚组合进入解锁模式的方法，可以重新连上仿真器，但Flash会被强制擦除以解除保护。
这里有一个非常实在的建议：在调试早期不要使能DCSM保护。等产品功能完全稳定、准备进入试产阶段，再研究安全模块的使能流程，并且把安全密码用离线方式妥善保管。调试阶段加了这层保护，除了增加你自己排查问题的难度，没有任何收益。
4. SCI串口调试：看似简单，实则扎心的一个环节
4.1 SCI配置和引脚复用：无声无息的杀手
串口是调试嵌入式系统最常用的工具，C2000的SCI模块使用起来也不算复杂。但F28P55x的SCI引脚默认不是SCI功能，而是GPIO。如果你在代码里初始化SCI外设，却没有把对应的GPIO引脚配置为SCI复用功能，那么发出去的数据根本到不了引脚上。
这种问题的迷惑性非常强，因为程序逻辑看起来完全正常：波特率配置正确、发送寄存器写入成功、发送中断也正常触发。用逻辑分析仪去量引脚，却一点波形都没有。我第一次遇到时，几乎把所有寄存器翻了个遍，最后才意识到是GPIO MUX的问题。F28P55x的GPIO复用配置通常在GPxMUX寄存器里，需要把对应引脚从普通GPIO模式切换到SCI模式，同时还要配置GPxDIR、GPxQSEL这些寄存器，确保输入限定和方向正确。
这里我建议大家养成一个习惯：所有外设调试前，先用GPIO寄存器窗口或代码确认引脚复用状态。特别是从开发板原理图搬到自研板子的过程中，引脚编号一旦对不上，整个外设就像凭空消失了一样。用代码的话，类似GPIO_setPinConfig(GPIO_28_SCIRX_A)这样的操作要逐行确认。
4.2 波特率偏差：信号看起来对了，数据全是乱码
解决了引脚复用问题后，另一个经典问题接踵而来：串口调试助手里收到的数据全是乱码。这种情况十有八九是波特率偏差过大。
F28P55x的SCI波特率是由系统时钟分频得到的。如果你的系统时钟配置跟波特率计算函数里的时钟假设不一致，实际波特率就会和理论值产生偏差。比如你实际跑在120MHz，但代码里默认的是100MHz，那么同样的分频系数产生的波特率就会明显偏离目标值。UART通信两端波特率偏差超过2%-3%，就很容易出现连续误码。
排查手段分两步。第一步，先确认代码里SCI的时钟源是哪个。F28P55x的SCI外设时钟来源可能是系统时钟，也可能是某个外设时钟域，这个要查看芯片手册的时钟树。第二步，用示波器或者逻辑分析仪去量TX引脚，测出实际输出的波特率，跟理论值对比。如果偏差大，就回头检查PLL配置、分频系数以及SCI Baud寄存器里的BRR值。
我还遇到过一种更有迷惑性的情况：发送端波特率完全正确，但接收端就是乱码。后面发现是PC的USB转串口模块质量一般，板子上的TXD和RXD被反接了，整个链路的数据本来就是断的。所以调试串口时，先做回环测试：把板子的TXD直接短接到RXD，看能不能自发自收。能收到，说明SCI外设和引脚没问题，问题出在链路另一端。
4.3 串口调试助手的正确打开方式
PC端工具，我用过的串口调试助手挺多的，SSCOM、XCOM、正点原子的XCOM、MobaXterm的串口会话都试过。F28P55x调试过程中，我个人比较常用的还是SSCOM和XCOM，两个都轻量、稳定性好，支持HEX显示和发送，够用。需要特别强调的几个设置点：
波特率、数据位、停止位、校验位必须和芯片侧配置完全一致。比如芯片侧设置的是8N1，工具里就得是115200-8-N-1，任何一位不匹配都是乱码。打开HEX显示模式可以排除ASCII编码层面的干扰，直接看到底层字节内容，判断数据是否正确。发送时如果需要周期性发送测试数据，工具里的定时发送功能比手动点发送高效得多。
还有一个容易被忽略的点：如果PC上有多个USB串口设备，调试助手很容易选择错误的COM口号。设备管理器里确认USB转串口模块对应的COM号，插拔时观察COM号变化，能避免误接。别问我为什么会特别提这一点，问就是曾经对着一个已经被别的软件占用的COM口折腾了半天。
4.4 从串口回溯到协议和业务逻辑
串口通了之后，往往会发现下一层问题：数据帧格式或者协议内容不对。这个阶段我建议采用分层排查的思路：第一层物理链路，用示波器或者回环测试确认有波形；第二层字节层，用HEX显示确认每个字节的数值符合预期；第三层协议层，对照帧头、长度、校验字段逐字段核对。
F28P55x在电机控制应用里，串口通常用于上位机调参或者调试数据实时上传。这种场景下的协议设计建议要带帧头、功能码、长度、数据和校验字段，一个都不能少。不要因为嫌麻烦就不加校验，数据在复杂电磁环境下出错的概率比你想象的高。做电源或者驱动的开发环境里，电机启停瞬间的干扰甚至能让串口数据连续出错，没有CRC校验根本没法排查。
5. 运行期疑难杂症：看门狗、中断和GPIO的连环坑
5.1 看门狗反复复位：调试时最容易被忽略的“隐形杀手”
这是我认为F28P55x调试过程中最常见、也最隐蔽的问题之一。C2000系列的看门狗复位在默认情况下可能是使能的，而且它不像有些MCU那样需要你专门去关。你在调试时如果一直不喂狗，芯片就会每隔一段时间自动复位一次，导致程序看起来像随机死机。
这种问题在RAM调试中特别恶心。因为RAM调试时程序下载完后，CCS通常会从复位向量开始执行，然后停在main函数入口。这个过程中如果看门狗已经跑起来，而你又没有在启动代码里及时禁用或者喂狗，芯片可能在CCS准备停在main入口之前就复位了。表现出来的现象用一句话形容就是：“代码一下载就全速跑，但每次跑不过几毫秒就重启，断点形同虚设”。
解决办法是在调试会话连接成功后，立刻在CCS的寄存器窗口里把看门狗控制寄存器WDCR设置为禁用状态，或者写一小段初始化代码在系统时钟配置完成后马上关喂狗操作。如果用的是TI的例程，通常在Device_init函数里就已经处理好了；但如果你是自己从零搭的工程，一定要检查启动代码。
看门狗问题的另一个变种是：芯片在正常运行几分钟后复位，看门狗中断标志位已经在复位原因寄存器里置位。排查这种问题时，CCS的寄存器窗口能读复位原因，在Memory Browser里查看复位状态寄存器，就能区分是上电复位、看门狗复位还是外部复位。有了方向之后，再针对性检查喂狗代码是放在主循环里还是定时器里，如果喂狗操作被某个耗时操作阻塞了，就会周期性地触发看门狗。
5.2 中断不响应和中断向量表偏移
F28P55x的中断体系基于PIE（Peripheral Interrupt Expansion）模块，和Cortex-M内核的NVIC有很大区别。PIE把外设中断映射到CPU的INT1到INT14这些中断线上，每个中断源都对应PIE向量表中的一个入口。如果你漏掉了中断向量表在RAM和Flash模式下的地址偏移设置，中断发生后CPU跳转的位置就是错的，实际表现是“中断标志位已经置位，但中断服务函数根本进不去”。
具体到F28P55x，初始化PIE中断向量表时，需要先把PIE控制寄存器里的向量表地址指向正确的存储区域。在RAM调试模式下，向量表放在RAM里；在Flash调试模式下，向量表需要重映射到Flash或者先拷贝到RAM。很多从STM32转过来的开发者容易忽略这个步骤，因为在Cortex-M上向量表偏移通常只需要改一个VTOR寄存器，但在C2000上，PIE向量表的初始化既涉及段分配，又涉及运行时重映射。
遇到中断不响应，我的排查顺序是：第一步看外设的中断标志位有没有置位。如果没置位，说明中断事件本身没触发，问题在外设配置或者事件源；如果置位了，说明事件发生了但CPU没响应，问题在PIE使能、CPU中断使能、或者向量表配置上。第二步看PIE中断应答位是否被清除，PIE模块的中断机制要求ISR里对中断组标志进行明确应答，不然同组中断会被一直屏蔽。这种细节在C2000上非常常见，代码里漏掉一句PIE_clearInterruptGroupFlag就能让你的中断只进一次。
5.3 GPIO配置对调试链路的干扰
GPIO相关的坑虽然通俗，但实际杀伤力一点不小。F28P55x的大部分引脚都可以复用为JTAG功能或者GPIO功能。如果你在初始化代码里把JTAG引脚配置成了GPIO输出，那么在下一次仿真器尝试连接芯片时，就会遇到“can‘t connect to target”之类的错误。
这类问题在RAM调试阶段经常出现：你今天在代码里把某个JTAG引脚（比如TDI或者TDO）配置成了GPIO，正常连接仿真器时没有问题，因为仿真器连接发生在程序运行之前；但当你执行了全速运行，芯片上的JTAG引脚立刻被代码改成GPIO功能，此时你再暂停或者重新连接仿真器，就会发现自己丢失了调试能力。
这有点像把自己锁在了门外。解决办法有两种：一种是利用CCS的Connect期间复位目标板功能，让芯片在代码跑起来之前先恢复JTAG引脚；另一种是用仿真器强制复位后暂停，在程序还没执行到GPIO配置之前抢占控制权。实在不行，把Boot引脚拨到其他模式，让芯片不从Flash启动，不发生GPIO重配置，就又能连上了。
我自己后来养成了一个好习惯：调试阶段不要碰JTAG引脚作为普通GPIO的功能。哪怕代码里写了GPIO初始化，也要把JTAG相关引脚单独隔离开，不让它们参与常规测试。等产品正式阶段做了引脚复用优化，再考虑是否让某些JTAG引脚真正变成GPIO。
6. 用好CCS：几个直接提升调试效率的实操技巧
6.1 表达式窗口和寄存器窗口的妙用
CCS可能是C2000系列上用得最多的IDE了。很多人只是把它当编辑器和烧写工具用，其实一些调试功能用好了，排查问题的效率能提升一大截。
表达式（Expressions）窗口可以实时观察变量的值。配合实时更新模式，在全速运行状态下也能看到变量的动态变化。这在调试电机控制算法或者电源环路时非常有用。你可以把PID输出、电流采样值、PWM占空比这些关键变量拖进表达式窗口，观察它们随系统运行的变化趋势。
寄存器（Registers）窗口则可以直接查看和修改CPU寄存器以及外设寄存器。调试外设问题时，比反复修改代码重新编译要快得多。比如怀疑SCI波特率配置有问题，直接在寄存器窗口改BRR值，观察串口是否恢复正常，能快速验证判断。
CCS还有一个十分好用的功能：在断点处设置条件，或者用硬件断点。F28P55x支持一定数量的硬件断点，可以在不修改代码的情况下对指定内存地址的访问进行触发。遇到那种需要监视某个变量在什么时候被异常改写的问题，硬件数据断点几乎是唯一高效的手段。
6.2 实时仿真与多核协同调试的建议
F28P55x如果有CLA协处理器，调试时可能会遇到一个认知上的盲区：CLA是一个独立于CPU的处理器，它有自己独立的寄存器和程序空间，很多初学者以为CLA跑在CPU里，实际上它独立执行任务。在CCS里调试CLA程序时，需要显式连接CLA的窗口，并且把断点设置在CLA的代码空间里，而不是在CPU的代码里设置断点，否则你可能永远也等不到断点触发。
顺带一提，在调试C2000的多核或者带CLA的芯片时，CCS会自动识别多个目标。你需要确保调试配置脚本把CPU、CLA、以及可能的其它辅助子系统都正确关联起来。如果没有关联好，代码下载到CPU后，CLA程序可能不会自动同步，运行起来就会莫名其妙。这种问题通常不会报错，只能靠经验判断。
6.3 关于调试数据保存和日志管理
调试到后期，数据记录就变得很重要。CCI的Console窗口输出和日志功能，可以把调试信息同时保存到文件。我个人的习惯是：每次跑一轮测试，把Console窗口的完整输出保存到日志文件，并且按日期命名，方便后续回溯。这一点在排查偶发问题时尤其有价值，因为偶现问题如果你没有日志，全靠人脑回忆，基本是浪费时间。
如果需要打印大量的调试变量，传统的串口打印可能不够快，可以考虑用CCS的实时数据交换功能或者图形显示工具。C2000的调试环境配合TI的Graph工具，可以直接在调试界面里画出曲线，对观察电流波形、速度曲线这些东西非常直观。本质上就是把数据从芯片里读出来，再用画图方式展示，免去了自己写上位机画图的工作。
7. 写在最后：调试经验和踩坑总结
老实说，TMS32F28P550的调试过程不算轻松，但每次解决一个棘手问题之后，对芯片和系统的理解都会明显加深一层。我总结一下这段时间调试下来最重要的几点经验：
电源时序和复位信号是所有调试前提的前提，连不上芯片时先查硬件，而不是反复折腾软件。JTAG/cJTAG模式、Boot引脚这些芯片特有的配置要提前确认，它们决定了仿真器和芯片之间最基本的通信基础。RAM调试和Flash调试是完全不同的环节，烧录选错CMD文件、忽略Flash等待状态配置、或者提前使能DCSM安全保护，都会导致看起来像是芯片损坏的问题。
SDI串口调试看似简单，但引脚复用、波特率偏差、链路方向三关卡住的人一茬又一茬。调试时先用回环测试验证MCU自身链路，再用HEX显示验证字节准确性，最后再进入协议层分析，能省去大量无谓的时间。
运行时的问题排查更讲究优先级：看门狗是否在背后反复复位、PIE中断向量表是否设置正确、JTAG引脚是否被GPIO代码污染，这三个都属于“不查不知道，一查吓一跳”的隐蔽问题。先把它们排查干净，再谈其它功能性调试。
对刚接触这颗芯片的朋友，我的建议是别急着在产品代码里调试，先把一个最小系统跑通：电源正常、仿真器连上、LED点灯、SCI自发自收、一个定时器中断。这五个能力打通之后，后续不管做什么开发，都有一块稳固的起点。很多人卡在后期调试上的根本原因，其实就是最底层的最小系统环境不够稳定，问题的时候连排查方向都找不到。
最后再分享一个我自己的习惯。每次调完一块F28P55x板子，我会顺手整理一份调试笔记，记录硬件连接方式、Boot模式设置、关键寄存器配置、踩过的坑和解决办法。过几个月再回头看，这些笔记比官方文档还能救人命。因为官方文档讲的是通用原理，而笔记里记录的是你在具体板子、具体场景、具体工具版本下真正遇到的东西。调试这个事，很多时候拼的不是智商，而是你是否愿意把每次踩坑的经验沉淀下来。下次再遇到，翻翻笔记就能少走很多弯路。
