1. CCS5.5 里的仿真配置文件到底管什么CCS5.5 这一代调试环境是不少做 DSP、MSP430 的老工程师最顺手的一版Eclipse 内核加上 TI 自己那一套 targetdb 数据库装完之后整个调试链路基本可以不开文档就跑起来。但真到换板子、换仿真器、或者同事拿走你的工程在另一台机器上打开的时候十有八九会卡在同一个地方——仿真配置文件。.ccxml这个后缀的小文件名字叫 Target Configuration File很多人的做法是能用就不动它等到连不上板子才开始翻资料那时候往往已经浪费了小半天。这篇东西想解决的问题很具体把 CCS5.5 里这份仿真配置文件讲透。它是什么、放在哪、怎么新建、Connection 和 Device 两个下拉框该怎么选、Test Connection 背后做了什么、JTAG 时钟和 GEL 脚本什么时候会咬你一口、以及那些真正会让人崩溃的报错怎么分层定位。适合刚上手 CCS5.5 的学生和转岗过来的嵌入式新人也适合用惯了新版本、被迫回来维护老工程的人。文中涉及的所有操作都以 CCS5.5 的实际界面为准个别小版本菜单文字可能有细微差别但逻辑是一样的。早期版本的 CCS 有一个特点就是配置和工程是相对解耦的两件事。工程只描述源码怎么编译、链接脚本在哪、优化等级多高而目标板的连接方式、用哪个仿真器、芯片型号、复位策略、初始化脚本全部落在仿真配置文件里。这种设计的好处是同一个工程可以配多份连接方案比如实验室里一份 XDS100v2 的、产线上烧写工位一份 XDS560 的切换的时候只需要换 Active 配置不用动源码一个字。坏处也很明显——新手第一次打开别人的工程往往只看到targetConfigs这个目录里躺着几个.ccxml完全不知道它们是干什么的然后在 Debug 的时候被找不到目标配置拦住。1.1 一个 .ccxml 就把整条连接链路描述完了把.ccxml用文本编辑器打开它本质就是 XML你会发现里面其实就三块内容连接Connection、器件Device以及挂在它们下面的属性Property。连接描述的是用什么工具去碰芯片比如 XDS100v2、XDS200、XDS510、XDS560 这些调试探针或者纯软件 Simulator器件描述的是碰的是哪颗芯片比如 TMS320F28035、TMS320C6748、MSP430F5529。属性则是这两者各自的可调项——JTAG 时钟、复位极性、超时时间、GEL 脚本路径、CPU 核、存储器映射等等。一份精简过的配置大概是这个形状我把它缩到只留关键节点方便理解?xml version1.0 encodingUTF-8 standaloneno? configurations XML_version1.2 idconfigurations_0 configuration XML_version1.2 idconfiguration_0 instance XML_version1.2 descTexas Instruments XDS100v2 USB Emulator hrefconnections/TIXDS100v2_Connection.xml idTexas Instruments XDS100v2 USB Emulator xmlTIXDS100v2_Connection.xml xmlpathconnections/ connection XML_version1.2 idTexas Instruments XDS100v2 USB Emulator instance XML_version1.2 hrefdrivers/tixds100v2cs.xml iddrivers xmltixds100v2cs.xml xmlpathdrivers/ instance XML_version1.2 hrefdrivers/tixds100v2dap.xml iddrivers xmltixds100v2dap.xml xmlpathdrivers/ property Typechoicelist Valuenothing idThe TCLK frequency is .../ /connection device XML_version1.2 descTMS320F28035 hrefdevices/f28035.xml idTMS320F28035 xmlf28035.xml xmlpathdevices/ /configuration /configurations这里面href指向的那些connections/和devices/文件并不在工程目录里而是在 CCS 安装目录的ccs_base/common/targetdb下。这就是为什么.ccxml通常体积很小——它只是一份引用清单真正的模型定义在 IDE 那边。理解这一点很重要如果换了一台机器、或者换了一个 CCS 大版本targetdb里的文件名或者 id 变了你那份.ccxml就会失效打开时提示找不到目标配置。这也是老工程跨版本迁移时最容易被忽略的一环。还有一点必须提前说清楚.ccxml只描述怎么连不描述连上以后干什么。加载哪个.out、跑不跑 GEL、断点打在哪、复位之后停在 main 还是停在 0x3F7FF6C2000 的 boot 入口这些属于 Debug Configuration 的职责。很多人排查连不上的时候去翻 Debug Configuration其实是找错了抽屉反过来有时候配置明明对但程序一加载就跑飞那问题又在 Debug Configuration 或者 GEL 里。把这两层的边界先划清楚后面排查会省很多时间。1.2 硬件仿真与软件仿真是两份完全不同的配置标题里带仿真两个字这里就有一个国内工程师经常混淆的点CCS 语境下的仿真既可能是接一块真实的板子、用仿真器去调试debug也可能是完全不接硬件、用软件模拟来跑代码simulate。这两种在 CCS5.5 里都叫目标配置但 Connection 选择完全不同能做的事也差得远。硬件调试这条路上Connection 下拉里出现的是具体探针名字比如Texas Instruments XDS100v2 USB Emulator、Texas Instruments XDS200 USB Emulator、Texas Instruments XDS510 USB Emulator。其中 XDS100v2 是那个年代最常见的选择LaunchPad 和一些入门开发板直接板载了它USB 插上就能用XDS560 属于高端探针支持更高速的实时数据交换价格也高一个数量级。选硬件探针之后Test Connection才有意义因为它会真的去敲 JTAG 口。纯软件仿真这条路上Connection 里会看到Texas Instruments Simulator、MSP430 Device Simulator之类的条目。它不碰任何硬件靠 PC 模拟 CPU 指令执行。好处是零成本、方便在没有板子的时候做算法验证坏处是外设行为往往不是周期精确的中断时序、ADC 采样、PWM 死区这些外设细节基本别指望它某些器件甚至根本没有 Simulator 支持。所以软件仿真适合验证纯算法逻辑比如滤波器系数、定点溢出、状态机跳转一旦代码里出现了对某个外设寄存器的轮询等待仿真环境大概率会卡死在那儿。我在实际项目里的做法是工程里同时留两份.ccxml一份命名成xxx_hw.ccxml一份叫xxx_sim.ccxml。没有板子的时候把 sim 那份设成 Active纯跑算法板子到手切回 hw 那份。这样切换成本几乎为零也不用担心误把 Simulator 配置提交到生产分支上——真要提交也会在 README 里写清楚哪份是给谁用的。2. 从零建一份能用的仿真配置文件理解了它是怎么回事接下来就是动手。新建.ccxml这个动作本身很简单难的是新建在哪个位置和下拉框该选哪一项。CCS5.5 的界面逻辑是目标配置属于某个工程或者属于 workspace即所谓的 User 配置二者在 Debug 时的优先级和生命周期完全不同。这一步选错了后面会连续踩坑。2.1 三个入口按场景挑CCS5.5 里进入目标配置界面的入口大概有三个用起来体验不太一样。第一个入口是菜单栏的File New Target Configuration File。这是最直白的一条路点了之后弹一个对话框让你填文件名、选存放位置。这里最关键的是那个Project 下拉框——如果你选了某个具体工程配置文件就会落在该工程根目录下的targetConfigs文件夹里跟着工程走进版本库同事拉下来就能用如果你选User或者留空它就会存到 workspace 的全局位置只对你这台机器的这个 workspace 有效别人拉代码是拿不到的。第二个入口是View Target Configurations视图。这个视图建议一直开着它会按工程分组列出当前 workspace 里所有能找到的.ccxml右键菜单里能直接新建、打开、设为 Active、测试连接、删除。用它做日常切换比翻菜单快得多。第三个入口其实在 Debug 的时候。如果你直接点 Debug而当前没有一个明确的 Active 配置CCS 会提示你选择或者自动创建一份默认配置。这个自动创建出来的东西Connection 和 Device 往往是猜的不一定是你要的我不太建议新手走这条路。稳妥的做法是进Run Debug Configurations在左侧Code Composer Studio - Device Debugging下面看已有的配置项打开它切到Target页签这里能看到当前这份 Debug 配置到底引用了哪份.ccxml。页签上通常有几个单选意思分别是用工程里的配置用 workspace 里的配置用文件系统里某个绝对路径的配置。如果发现它引用的是个你根本没见过的路径那就是被自动创建的默认配置坑了改成工程里那份即可。注意CCS5.5 各小版本在 Debug Configuration 的 Target 页签上控件排布略有差异有的版本会把 Connection 和 Device 做成两个下拉框直接放在这里用于临时覆盖。临时覆盖只在本次调试会话有效不会写回.ccxml重启 Debug 就没了别指望它做持久化。2.2 Connection 和 Device 的选型逻辑打开新建的.ccxml界面主体是两部分上半部分选 Connection下半部分选 Device。先说 Connection。选 Connection 的第一原则是看实物别看猜。板子上丝印写着 XDS100v2或者 USB 插上后设备管理器里多出了两路串口设备那基本就是 XDS100v2板载版本。如果用的是外置盒子看盒子上的标签。XDS100 系列还有 v1 和 v2 之分两者驱动和速度都不同选错通常表现为连不上或者连上就断。XDS200 是中间档速度比 XDS100 快价格比 XDS560 便宜XDS560v2 支持 System Trace属于高端货普通调试用不上。CS2000 系列调 C2000、C6000 时配 XDS100v2 已经够用了除非你要做实时数据交换RTDX或者大块内存搬运才需要考虑升级探针。第二原则是驱动状态要先确认。硬件探针在设备管理器里应该能正常枚举没有黄色感叹号。XDS100v2 会枚举出两道USB Serial Converter通道Channel A / Channel B这是它内部两颗 FTDI 芯片各占一路属于正常现象不要看到两个串口就以为是驱动装重了。如果设备管理器里压根找不到那.ccxml怎么配都没用先解决驱动。再说 Device。这一栏选的是目标芯片的准确型号不是系列名。比如板子上是 F28035就不能选 F2803x 或者 F28069因为不同型号的存储器大小、外设寄存器地址、GEL 初始化脚本都不一样。选错的典型症状是能连上、能读写部分内存但一跑 GEL 就报地址无效或者跑到一半进不了某个外设的中断。CCS 的器件列表是树形的先选家族比如TMS320F2803x再选具体的TMS320F28035。提示有些封装相同、Flash 大小不同的型号在调试层面可以互相兼容比如同一家族内的不同 Flash 容量版本但 GEL 里做 Flash 控制器配置时可能会出问题。如果板子是自制或者改过料的尽量按实际丝印选别按图纸选。2.3 保存、设为 Active 与路径管理配置选完Save一下回到Target Configurations视图右键这份.ccxml选Set as Active Target Configuration。设为 Active 之后图标上会有一个小小的标记之后点 Debug 默认就用它。这里有个很多人不知道的细节Active 状态是跟着 workspace 记录的不是跟着.ccxml文件本身。也就是说你把整个工程拷到另一台机器、换一个 workspace 打开Active 状态会丢需要重新设一次。所以团队协作时交接文档里要写明打开工程后先右键 targetConfigs 里的 xxx.ccxml 设为 Active这一句话能省掉新人半小时的困惑。路径管理上我的建议很明确能放工程里就放工程里。targetConfigs目录跟着工程走进 Git 或者 SVN谁拉下来都是同一份Connection 和 Device 也都对得上。只有一种情况适合放 workspace你手上有好几块完全不同的板子工程源码是同一套今天调 A 板明天调 B 板这时候在 workspace 层面维护多份配置、随用随切比反复改工程里的文件省事。另外如果你在配置的 Advanced 页签里手工指定过 GEL 脚本的绝对路径比如D:\ti\ccsv5\ccs_base\emulation\boards\...那这份.ccxml换台机器就废了。要么改用相对路径要么干脆不手工指定让器件描述文件自动带出默认 GEL。后面第 3 章会细说 GEL 的加载顺序。3. 关键参数与会拖后腿的细节新手建完配置、点一下 Test Connection 显示成功就觉得万事大吉了。实际项目里真正折磨人的往往是几个默认值不合适的参数。这一章挑三个最容易出问题的点JTAG 时钟、GEL 脚本、以及纯 Simulator 配置。3.1 JTAG 时钟与连接超时的取舍在.ccxml的 Connection 上点开会看到 Advanced 页签里面有一堆属性。改得最多的是TCLK 频率界面上通常显示成The TCLK frequency is ...这样的长句值可能是nothing自适应、1.0 MHz、500 kHz之类。默认的自适应模式在大部分情况下够用它会根据 JTAG 链路的信号质量自己往下降速。那什么时候需要手工固定两种情况。一种是线太长或者板子走线不好表现为连接时好时坏偶尔报错偶尔成功这时候把 TCLK 压到 1 MHz 甚至 500 kHz成功率会明显上升代价是下载速度变慢——但调试阶段的速度其实没人在意。另一种是掉电或者复位后连不上、重新插拔 USB 就好这通常是握手时序问题降速也有效。反过来说如果你在做产线批量烧写速度就是钱。JTAG 时钟能拉多高取决于板子和探针XDS100v2 在短线上跑到 5 MHz 是比较稳的再往上看运气。我的做法是研发阶段固定 1 MHz 图省心产线脚本里再按实测拉高并且写死一个固定值而不是自适应避免批次之间速度不一致导致节拍不好估算。还有个容易被忽略的属性是连接超时。默认值在某些慢速探针上偏短尤其是目标板刚上电、电源还没稳的时候。如果你遇到偶尔第一次连不上、再点一次就好了的现象先把超时调大一点试试比怀疑硬件划算。注意JTAG 相关的属性改动之后建议关掉当前 Debug 会话再重新 Launch。有些属性是连接建立时读取的改完不重启会话是看不到效果的然后你就会误以为是属性改错了。3.2 GEL 的加载顺序与覆盖关系GELGeneral Extension Language是 TI 那套脚本语言作用是在调试器接上芯片之后、加载程序之前把芯片初始化到一个可用状态。典型工作包括关看门狗、配置 PLL 倍频、设置外设时钟、初始化外部存储器控制器。C2000 上如果不跑 GELFlash 相关操作基本没法做因为 Flash 控制器的等待周期和电源配置都在 GEL 里。GEL 的来源有两条一是器件描述文件里默认关联的那份比如 F28035 对应的那份脚本你在 Advanced 页签里能看到GEL File(s)一栏默认状态下它是自动填充的二是你手工指定的比如项目专用的初始化脚本覆盖掉默认那份。加载顺序上一般是默认 GEL 先跑基础初始化再执行你在 Debug Configuration 里配置的脚本。但这套顺序在不同器件上不完全一致与其背规则不如直接看 Console 里 GEL 打印出来的信息——规范写法都会带GEL前缀执行到哪一步一目了然。实战里最常见的坑是GEL 覆盖冲突。比如项目里带了一份新的 GEL里面也做了 PLL 配置而器件默认 GEL 也配了一遍两边参数不一致结果就是时钟变了但外设又是按另一套时钟算的现象是串口波特率莫名其妙不对、或者定时器周期差了一倍。遇到这种逻辑没错但行为不对的怪现象第一反应应该是去 Console 里翻 GEL 执行记录而不是查代码。提示GEL 是脚本出错不一定会让连接失败。有时候 GEL 中间某一行报了个错、后面的语句照样往下跑最终程序能加载、能跑但某个外设初始化是缺的。所以养成习惯——每次 Launch 之后扫一眼 Console 的前二十行。3.3 纯 Simulator 配置的搭建要点前面提过Simulator 配置和硬件配置是两条路。真要用软件仿真有几个点必须提前知道否则会白折腾半天。第一器件支持范围有限。不是所有芯片都有对应的 Simulator 模型具体哪些有只能以你安装目录下targetdb里的器件列表为准。建配置的时候Connection 选成 Simulator 类再看 Device 下拉里还剩哪些选项剩下来的才是能仿的。如果某个型号在下拉里直接消失了那就是没模型别硬凑。第二CPU 版本和存储器配置要选对。某些器件在 Simulator 下会额外多出几个属性比如 CPU 内核版本、程序存储器大小、数据存储器大小。这些属性应与你工程里链接脚本.cmd文件的定义保持一致否则会出现代码段分配到不存在的地段这种诡异现象报错信息还特别含糊。第三中断和外设基本不可信。Simulator 通常只保证指令集层面的正确性中断响应延迟、外设寄存器行为、ADC 转换时间这些要么是理想值要么干脆不实现。如果你的代码里有while(!(Reg FLAG))这种等待外设置位的循环仿真环境下就是死循环。做算法验证时我的习惯是把外设相关的等待逻辑用宏包起来在 Simulator 编译配置里直接短路掉这样同一份源码能同时跑仿真和硬件。4. 一次完整的连接测试与下载记录配置写完接下来就是验证。很多人的习惯是直接点 Debug出错了再回头怀疑配置。更稳的顺序是先 Test Connection再 Launch最后 Load Program。这三步的职责不同分开了看问题出在哪一层立刻就能定位。4.1 Test Connection 到底做了什么在Target Configurations视图里右键.ccxml选Test Connection弹出一个对话框里面会有一行行的输出。它不是简单地ping 一下实际流程大致是加载探针驱动、初始化 USB 通道、复位 JTAG 链路、扫描并识别芯片 ID、读一下器件状态、然后视选项而定做一次复位。所以看到它成功说明物理链路和芯片识别这两层都是通的这是很有价值的信心。对话框里通常有一句Test Connection 会复位目标之类的说明。这一点要特别留神如果你的板子上跑着别的程序、或者有外设在驱动电机、继电器这类执行机构Test Connection 的复位会真的把它们停掉。我见过有人在带电机的板子上随手点了测试结果机械臂突然失去使能往下掉虽然没出安全事故但当时一屋子人都吓一跳。所以带执行机构的场景测试之前先确认机械部分处于安全状态。如果 Test Connection 失败输出的错误信息通常会带一个Error -xxx 0x0的形式。这个数字就是你分层的依据后面第 5 章会展开说。这里先记住一个判断原则报错里出现 USB、FTDI、driver 这类词问题在本机驱动层出现 JTAG、TCLK、scan chain、device not responding 这类词问题在链路或目标板层。4.2 从 Launch 到烧写的完整流程Test Connection 通过之后就可以进真正的调试了。CCS5.5 里的标准动作我整理成一张表每一步的目的和常见卡点都列出来照着走基本不会绕路。步骤操作位置目的常见卡点1Target Configurations 视图右键 .ccxml设为 Active忘了这一步Debug 用的是旧配置2.ccxml 右键 Test Connection验证链路与芯片识别目标板未上电、JTAG 排线松动3Run Debug Configurations确认引用的 .ccxml 与待加载程序引用了自动生成的默认配置4Target 页签设置复位策略、GEL、加载选项复位策略选错导致程序停在 boot5点 Debug建立会话、执行 GEL、加载 .outGEL 报错、内存段冲突6Debug 视图工具栏运行、单步、断点断点打在上电初始化代码里被跳过7右键工程 Make Target 或调试内烧写把程序固化进 FlashFlash 等待周期、GEL 未跑第 4 步的复位策略值得单独说一下。Target 页签里通常有类似加载程序时是否复位目标的选项一般三档复位到芯片的 boot 入口、复位后直接跳到程序入口、或者什么都不做。选什么都不做在开发后期很常见因为不想每次加载都把已经初始化好的外设打断但在调试初期选复位到 boot更有利于重现问题因为每次起点都干净。我个人的习惯是白天快速迭代时用不复位一旦出现难以复现的异常立刻切回每次都复位很多偶发问题会因此变成必现问题。第 7 步烧 Flash 的时候要特别注意 GEL 是否真的跑了。C2000 的 Flash 控制器需要先配等待周期和电源状态这些都在 GEL 里GEL 没跑就去写 Flash轻则报错重则写进去的内容校验不过。判断方法很简单烧写之前先在 Console 里确认能看到 GEL 的输出没看到就先解决 GEL。5. 报错排查与避坑速查真到了连不上这一步最怕的是东试一下西试一下今天调好了明天又坏问题根本没定位到。我的做法是按链路分层从最靠近 PC 的一层开始一层层往外查每一层只回答一个是非问题。这样即使最后没解决至少知道问题不在哪一层。5.1 按链路分层定位故障第一层驱动与设备枚举。打开设备管理器看探针有没有正常出现。XDS100v2 板载版本会出两个 USB Serial Converter外置盒子还可能多出更复杂的组合设备。有黄色感叹号、或者设备列表里根本没有问题就在这一层跟.ccxml一点关系都没有。处理方式无非是重装驱动、换 USB 口优先机箱后面的原生口、换一根质量好点的数据线。这里有个反直觉的经验很多偶尔连不上其实是 USB 线的问题尤其是那种又细又长的杂牌线供电和信号都吃亏换根粗短线往往就好了。第二层JTAG 链路与目标板。驱动正常但 Test Connection 报链路类错误要查的依次是目标板有没有上电这个听起来废话但确实是最常见的、JTAG 排线有没有插反或者接触不良、板子上的 JTAG 复位引脚是否被拉死、以及目标芯片有没有被某种低功耗模式锁住。如果是自己画的板子还要确认 JTAG 那几根线的上拉电阻有没有漏焊——漏了上拉链路在不插探针的时候电平是飘的插上之后时好时坏。第三层器件与配置匹配。链路通了但一识别就报器件 ID 不对或者识别出来了却是另一个型号。这时候回去核对你选的具体型号以及.ccxml里 Device 那一栏。还有一种情况是多核芯片只识别到一颗核那通常是.ccxml里少配了核或者 Debug Configuration 里没把要调的核勾上。第四层GEL 与程序加载。前面三层都过卡在加载阶段。看 Console 里的 GEL 输出看链接脚本里的内存分布是否和实际器件一致看优化等级是不是开太高把某个变量优化没了这个现象最迷惑人Debug 里看变量值永远是 0其实是编译器把它优化进寄存器了跟仿真配置完全无关。按这四层走绝大多数问题在十分钟内能缩小到某一层。比起随机重启 IDE、重装 CCS效率高一个数量级。5.2 版本管理与多人协作里的坑.ccxml是纯文本天然适合进版本库但有几个坑得提前知道。坑一跨 CCS 大版本不通用。CCS5.5 里 Connection 的 id 是Texas Instruments XDS100v2 USB Emulator这种写法到了更新的版本可能会变。所以拿 CCS5.5 的.ccxml直接丢进新版本打开很可能打开是空白的、或者 Connection 栏显示未知。正确做法是在新版本里重新建一份而不是拷贝。坑二GEL 绝对路径。前面说过手工指定的 GEL 路径如果是绝对路径别人机器上就是无效的。团队规范里应该明确.ccxml里不出现盘符路径需要自定义 GEL 就放进工程目录用相对路径引用。坑三Active 状态不进版本库。这个已经说过但因为太容易忘还是再强调一遍。新人第一次打开工程让他先看一眼Target Configurations视图确认图标上有 Active 标记再 Debug。坑四多份配置的命名。工程里同时存在xxx_hw.ccxml和xxx_sim.ccxml的时候光看名字容易搞混谁是谁。建议在文件开头加注释XML 注释是合法的写清楚用途、适用板子型号、维护人半年后回来还能看懂。5.3 一份能贴在工位上的速查表最后把常见现象和第一处置动作整理成表出问题的时候对着扫一眼比翻文档快。现象最可能的原因第一处置动作设备管理器里找不到探针驱动未装或 USB 线问题换 USB 口与线重装驱动时报错时正常链路报错JTAG 信号质量或排线接触降 TCLK 到 1 MHz 重试提示找不到目标配置Active 未设或 workspace 变更右键 .ccxml 设为 Active能连上但加载报内存段错误链接脚本与器件不符核对 .cmd 与器件型号加载后立刻跑飞复位策略或 GEL 未执行查看 Console 的 GEL 输出需重新插拔 USB 才能连上握手超时或电源不稳调大连接超时检查板子供电换机器后配置打不开跨 CCS 版本或路径失效重新建一份目标配置变量在 Debug 里恒为 0编译器优化掉了降优化等级或加 volatile写到这里我个人的体会是CCS5.5 这套仿真配置的设计其实相当清晰一个文件对应一条链路分层明确、可复用。之所以很多人觉得麻烦多半是因为踩坑的时候没有按层次拆开看把驱动问题当成配置问题、把配置问题当成代码问题。把手上的.ccxml打开读一遍把那几个下拉框和属性挨个过一遍心里对每一层管什么有数了后面再遇到连不上基本就是按表查一遍的事。另外提醒一句如果工程要长期维护把targetConfigs目录单独做一份说明文档放在工程根目录下写清楚每份配置对应哪块板子、用哪个探针、GEL 在哪——这个动作花十分钟能给后面接手的人省掉不止十个小时。