CCS5.5 仿真配置文件 .ccxml 详解：JTAG、GEL 与连接排查

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 version="1.0" encoding="UTF-8" standalone="no"?> <configurations XML_version="1.2" id="configurations_0"> <configuration XML_version="1.2" id="configuration_0"> <instance XML_version="1.2" desc="Texas Instruments XDS100v2 USB Emulator" href="connections/TIXDS100v2_Connection.xml" id="Texas Instruments XDS100v2 USB Emulator" xml="TIXDS100v2_Connection.xml" xmlpath="connections"/> <connection XML_version="1.2" id="Texas Instruments XDS100v2 USB Emulator"> <instance XML_version="1.2" href="drivers/tixds100v2cs.xml" id="drivers" xml="tixds100v2cs.xml" xmlpath="drivers"/> <instance XML_version="1.2" href="drivers/tixds100v2dap.xml" id="drivers" xml="tixds100v2dap.xml" xmlpath="drivers"/> <property Type="choicelist" Value="nothing" id="The TCLK frequency is ..."/> </connection> <device XML_version="1.2" desc="TMS320F28035" href="devices/f28035.xml" id="TMS320F28035" xml="f28035.xml" xmlpath="devices"/> </configuration> </configurations>

这里面href指向的那些connections/和devices/文件并不在工程目录里，而是在 CCS 安装目录的ccs_base/common/targetdb下。这就是为什么.ccxml通常体积很小——它只是一份"引用清单"，真正的模型定义在 IDE 那边。理解这一点很重要：如果换了一台机器、或者换了一个 CCS 大版本，targetdb里的文件名或者 id 变了，你那份.ccxml就会失效，打开时提示找不到目标配置。这也是老工程跨版本迁移时最容易被忽略的一环。

还有一点必须提前说清楚：.ccxml只描述怎么连，不描述连上以后干什么。加载哪个.out、跑不跑 GEL、断点打在哪、复位之后停在 main 还是停在 0x3F7FF6（C2000 的 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 的加载顺序与覆盖关系

GEL（General Extension Language）是 TI 那套脚本语言，作用是在调试器接上芯片之后、加载程序之前，把芯片初始化到一个可用状态。典型工作包括：关看门狗、配置 PLL 倍频、设置外设时钟、初始化外部存储器控制器。C2000 上如果不跑 GEL，Flash 相关操作基本没法做，因为 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 里的标准动作我整理成一张表，每一步的目的和常见卡点都列出来，照着走基本不会绕路。

第 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 一份能贴在工位上的速查表

最后把常见现象和第一处置动作整理成表，出问题的时候对着扫一眼，比翻文档快。

写到这里，我个人的体会是：CCS5.5 这套仿真配置的设计其实相当清晰，一个文件对应一条链路，分层明确、可复用。之所以很多人觉得麻烦，多半是因为踩坑的时候没有按层次拆开看，把驱动问题当成配置问题、把配置问题当成代码问题。把手上的.ccxml打开读一遍，把那几个下拉框和属性挨个过一遍，心里对每一层管什么有数了，后面再遇到连不上，基本就是按表查一遍的事。另外提醒一句，如果工程要长期维护，把targetConfigs目录单独做一份说明文档放在工程根目录下，写清楚每份配置对应哪块板子、用哪个探针、GEL 在哪——这个动作花十分钟，能给后面接手的人省掉不止十个小时。