最近拿一块CC1310 LaunchPad调一个低功耗无线透传的例程，IAR里刚点下Download，还没等进度条走起来，就直接弹了一条红色的Fatal error：Failed to connect to the XDS emulator (Error -241 @ 0x0)。这条报错在TI的CC13xx、CC26xx系列上用IAR调试时实在太常见了，尤其是板载XDS110的LaunchPad，新环境第一次连板子，十个里面有三四个会撞上它。
我当时卡在这个错误上差不多一个下午，换线、重装驱动、升级固件、强制擦除芯片全试了一遍，才把整个排查路径理顺。这篇文章就按我当时的实际操作顺序，把Error -241的成因、排查步骤和最终解决手段全部拆开讲清楚。如果你也是Windows环境下用IAR调CC1310，连接XDS100/XDS110/XDS200的时候碰到这条报错，这篇基本能覆盖你八成以上的情况。用CCS或者J-Link的朋友也可以参考排查思路，但具体操作上会略有差异。
1. 这条错误信息到底在说什么
1.1 Error -241本质上是哪一层的错误
XDS仿真器这条调试链路，我习惯把它拆成两段：主机通过USB和仿真器通信，仿真器再通过cJTAG或SWD去访问目标芯片。调试的时候，IAR会调用TI的调试服务器组件，这套组件负责把IAR的调试请求翻译成XDS能理解的指令，再通过USB发给仿真器。Error -241这类的负数错误码，就是TI调试服务器在某个环节失败后返回的错误代号。
-241对应的文字描述是Failed to connect to the XDS emulator，意思是主机没能和仿真器建立正常通信，或者仿真器没能和目标芯片建立调试会话。但这里有个容易被忽略的细节：仿真器插入USB后，设备管理器里可能显示正常，主机也确实识别到了仿真器，但仿真器去访问目标芯片的时候没有得到应有的回应，同样会把-241抛出来。所以这个错误码不能简单理解成“仿真器坏了”，它更像是整条链路里某个环节中断的通用告警。
1.2 为什么CC1310加IAR这个组合特别容易触发
CC1310是TI SimpleLink系列里的Sub-1GHz无线MCU，核心是ARM Cortex-M3，官方主推的开发板是LaunchPad，板载了XDS110仿真器。XDS110本身是个USB调试探针，它还可以同时提供虚拟串口、功耗测量这些功能，在CCS下体验很顺滑。但到了IAR里，情况就稍微复杂了。
问题出在环境依赖上。IAR对TI XDS的支持是借助TI提供的调试驱动完成的，而TI的一套工具链组件（CCS、UniFlash、SmartRF Studio等）都会各自携带不同版本的XDS驱动或固件。很多人的电脑上这些软件混着装，安装顺序又不一样，结果就是驱动版本互相覆盖，固件版本和驱动版本不匹配，于是IAR一连接就翻车。
另外一个和CC1310本身有关的点是：它默认的调试接口是cJTAG，不是传统四线JTAG，也不是ARM的SWD。IAR工程配置里如果选错了接口类型，同样会报-241。这个后面专门讲。
1.3 报错信息里@ 0x0这个地址能告诉你什么
错误文本最后会跟一个地址，比如Error -241 @ 0x0。这个地址是仿真器尝试访问目标芯片时的寄存器或内存地址。0x0通常是芯片的Flash起始区域或中断向量表位置，也是调试连接时主机获取芯片状态、准备进入调试模式的必经位置。
如果报错地址稳定出现在0x0，说明仿真器连芯片的第一次握手都没成功，拿不到任何有效数据。这种情况优先怀疑的是物理链路和芯片状态，而不是驱动或IAR设置。反过来，如果地址是一个随机变化的值，或者偶尔成功偶尔失败，那更像是时序、供电或干扰问题。这个细节看起来很小，但对判断排查方向很有帮助。
2. 按概率排序的六个排查方向
2.1 驱动识别异常，十个里面四个是这个原因
先说概率最高的：驱动程序。XDS110插上Windows后，正常情况设备管理器里应该能看到两个设备，一个叫XDS110 Class Debugger，另一个叫XDS110 Application/UART，后者是虚拟串口。如果你看到的设备带黄色感叹号，或者直接被识别成Unknown Device，那基本就是驱动问题。
遇到这种情况，先把USB重新插拔一次，等Windows完成枚举，再打开设备管理器确认状态。如果确实有感叹号，就手动更新驱动。驱动不一定要去TI官网单独下载，很多情况下你机器上已经装了CCS或IAR，驱动就在他们目录里。常见的路径有这么几个：
- CCS安装目录：
C:\ti\ccs_base\emulation\drivers\xds110_drivers - IAR安装目录：
C:\Program Files (x86)\IAR Systems\Embedded Workbench x.x\arm\drivers\TI-XDS
更新驱动的操作是右键那个出问题的设备，选“更新驱动程序”，再选“浏览我的电脑以查找驱动程序”，手动指定上面目录。装完拔掉USB重新插一次，看设备是否恢复正常。
这里还遇到过一种特殊情况：Windows的驱动强制签名机制把TI的低版本驱动拦截了。手动安装时如果提示签名问题，需要先进入高级启动选项，禁用驱动强制签名后再装一次。装完之后不要再随便更新Windows补丁，否则有可能又给顶回去。
2.2 USB物理链路和供电，最容易被忽略的一环
驱动正常了，设备管理器里也看不到异常，但还是连不上，那就该怀疑USB物理链路了。LaunchPad板子上通常会有一个或两个USB口，分别对应XDS110调试功能和板子自身的USB转串口功能。插错口看起来有点好笑，但我还真见过不止一次有人把调试线插到了目标板上、却没有连接XDS仿真器的USB口，自然连不上。
另外USB线本身是个大坑。现在很多线看着差不多，实际上里面只有充电的电源线，没有数据线。这种线插上后设备管理器毛都看不到。建议先换一根确定正经能传数据的线，最好直接插到主机后置USB口，不要经过hub。USB hub如果质量不好，供电差、信号衰减严重，也可能导致连接不稳定。
供电问题也要单独说。XDS110的调试逻辑是通过USB取电的，同时它会为目标MCU提供电源。如果目标板或扩展模块的电流需求太大，USB端口供电不足，仿真器可能只初始化到一半就挂了。判断方法很简单：插上USB后看板上的电源指示灯，如果LED亮度很低、时亮时灭，十有八九是供电不足。解决办法是换一个带外部电源的USB口，或者给板子单独供电。
2.3 仿真器固件版本过旧或损坏
XDS110本身带一段固件，负责把USB命令翻译成调试时序。如果固件版本太老，跟新版IAR的调试驱动不匹配，连接过程就会异常退出。这种情况最典型的场景是：之前用CCS调得好好的，或者老版本IAR能用，换成新版本IAR之后突然连不上了，报错还是固定的-241。
XDS110固件升级最方便的工具是TI的UniFlash。打开UniFlash之后选择XDS110相关的升级入口，它会自动识别仿真器并执行固件更新。如果机器上没装UniFlash，装一个CCS也可以，CCS里自带升级XDS固件的功能。升级过程中绝对不能拔线或者断电，否则仿真器直接变砖，后面只能靠更底层的恢复方法救。
更新完固件后，拔掉USB重新插一次，再进IAR试连接。我见过不少“换了个新版本IDE之后仿真器就废了”的案例，其实刷一遍固件就好。这个操作是六项排查里成本最低、收益最直接的一步，不要跳过。
2.4 目标板供电、复位和时钟状态
仿真器能被识别、固件也是新的，还是报-241，那问题很可能出在目标芯片那一侧。CC1310调试时必须要有正常的电源、复位和时钟。板载LaunchPad一般不用管，因为XDS110接上后会自动给MCU供电，但如果你用的是外部目标板，这三个方面都要逐一确认。
复位引脚是个高频坑。有些外部板子在复位脚上接了比较大的电容，或者额外的下拉、上拉电阻，导致复位信号一直处于异常状态，仿真器连接目标芯片时对方根本没从复位中释放出来。遇到这种情况，可以先按住板上的复位键，在按下复位键的同一瞬间点IAR的下载按钮，如果此时能连上，就说明复位电路设计有问题。这个“跟复位抢时间”的操作可以当一个快速诊断手段。
时钟方面，CC1310内部有RC振荡器，上电后即使外部晶振不工作，芯片通常也能跑起来，所以外部晶振问题不一定导致连接失败。但如果是外部晶振虚焊、或者负载电容选得离谱，导致系统时钟异常稳定，仿真器进行初次寄存器访问时也可能超时。这种时候优先检查外部晶振附近的焊点，或者直接换一块板子做对照测试。
2.5 CC1310调试引脚被复用导致芯片锁死
这个坑值得单独拿一节说，因为它是CC1310特有的，而且一旦遇到，常规手段基本都无效。CC1310的调试接口引脚同时是普通GPIO，具体是TMS对应DIO10，TCK对应DIO11。如果你的代码里把这两个引脚配置成了普通GPIO用途，还把配置写进了Flash，那下次上电后芯片的调试接口就废了。仿真器怎么发指令它都不理，IAR稳定复现-241。
判断是不是锁死有一个简单的方法：换一块全新的芯片（或者拿一块Never烧过类似代码的板子），如果新板能正常连接，那旧板就是被锁死了。这里不建议一上来就舍弃旧板，强制擦除是可以救回来的。
TI官方保留了通过XDS仿真器发送特殊cJTAG序列来强制擦除Flash的机制。最常用的操作是在UniFlash里选择Force Recovery或者Mass Erase。打开UniFlash，选择CC1310，进入设置界面，找到强制恢复或擦除相关按钮，点下去后UniFlash会通过仿真器往芯片发恢复命令，把Flash整体擦掉。擦完之后芯片恢复到出厂状态，调试接口恢复可用。
但要注意，Mass Erase会把Flash里所有数据清空，包括CC1310出厂时的RF校准值。如果芯片之前用在正式项目里，擦除前一定要想清楚。RF校准值丢了之后，理论上可以通过SmartRF Studio重新校准，但操作比较麻烦，而且最终效果不一定能和出厂值完全一致。所以擦除前多留个心眼。
还有一个小技巧：CC1310有bootloader启动引脚配置，如果能把芯片引导到bootloader模式，调试接口也能恢复可用。但具体哪个引脚、什么电平组合，要查对应数据手册里的bootloader entry章节。实际工作中我多数还是直接Mass Erase，bootloader方式更多用在需要保留Flash数据的场合。
2.6 IAR工程配置出错，别小看这几项
最后看软件配置。IAR里关于XDS连接的几个关键选项，任何一个不对，都会导致连接失败。重点检查下面四项：
- 调试器类型要选“Texas Instruments XDS”，不能是默认的Simulator或者其他仿真器。
- 仿真器具体型号要选对，XDS110不能选成XDS100。
- 接口类型要选cJTAG，不要选JTAG或SWD。这是CC1310默认的调试接口，选错必报错。
- 连接速率不要图快，第一次调试建议1MHz或2MHz，调稳了再往上提。
在IAR里的操作路径是Project -> Options -> Debugger，左侧选择TI XDS。原理看多了容易晕，实际操作就是这几项。很多时候别人报错你看着神奇，其实只是型号或者接口下拉框选错了一个。
注意在这个设置页面里，还有一个和电源控制相关的选项。板载XDS110和LaunchPad共用一个电源系统，如果你IAR里的配置要求仿真器连接前主动给目标板供电，或者主动控制目标板复位，可能和LaunchPad的电源设计冲突。建议设置成不控制电源，让板子自己上电，只让仿真器做纯调试。我见过有人在这里开了一个电源选项后就开始报-241，关掉就好。
3. 实操：一套完整的排查流程
前面把六个方向讲了一遍，但实际动手时建议按照下面这条流水线走，能少走很多弯路。这也是我当时排坑用的顺序，基本可以收敛问题。
3.1 先统一环境版本
第一步别急着插线，先确认自己IAR的版本。IAR Embedded Workbench for ARM太老的版本对XDS110支持非常差，我建议至少用8.20以上版本，新一点的8.50、9.x都行。如果版本太老，先升级IAR。这一步能避免花半天排查一个先天不兼容的问题。
同时把CCS、UniFlash、SmartRF Studio这些工具列一下，看有没有和IAR共存的。如果有多个TI工具混装，最好确认一下XDS驱动是不是最新的那个，或者干脆在能卸的情况下把不需要的旧版本卸掉，减少驱动互相覆盖的概率。
3.2 检查硬件链路
把XDS110和目标板之间的排线或杜邦线拔掉，重新插一次，确保接线牢固，方向没有搞反。如果是外部目标板，检查调试线序是否和CC1310的JTAG引脚定义一致，尤其要注意TMS和TCK有没有接反。
USB线换成一根确定能传数据的线，直接插到主机后置USB口。观察板载LED状态，确认仿真器已完成枚举。如果LED明显不够亮，考虑供电问题，换一个带外部电源的方案。
3.3 设备管理器确认驱动状态
打开设备管理器，展开端口和USB设备两个分类，找XDS110相关的设备。如果两个设备都正常显示、没有感叹号，说明驱动环节过了。如果有一个设备带感叹号，按前面说的方法手动指定驱动目录更新。
更新完成后不要急着进IAR，先重复一下插拔，确认设备状态稳定。这里一个小技巧是：每次改变硬件或驱动后，都重新枚举一次再试连接，不要偷懒。
3.4 用TI官方工具做一次交叉验证
这一步极其关键。打开UniFlash或者CCS，看它们能不能识别到XDS110和CC1310。交叉验证的意义在于判断问题边界：
- UniFlash里能看到设备、能正常连接芯片，说明仿真器和硬件链路没问题，问题出在IAR这一侧。
- UniFlash里看不到设备，说明驱动或仿真器本身有问题。
- UniFlash里能看到设备但连不上芯片，说明目标芯片状态异常，大概率是锁死。
这个判断能帮你把问题快速收敛到某一个环节，省得在IAR里反复瞎试。
3.5 在IAR里重新配置并复现
创建一个最简测试工程，或者打开TI官方例程，检查Debugger设置里的仿真器型号、接口、速率这三项。确认设置无误后点击下载。如果还是报-241，这时把错误信息完整记录下来，特别留意错误码后跟着的地址。
如果这个阶段的错误信息和一开始一样，都是固定的0x0地址，那就说明前面几个非破坏性手段都没起作用，该上强制恢复手段了。
3.6 最后的手段：强制擦除恢复芯片
到了这一步，我默认你已经排除了驱动、USB、供电、固件和IAR配置这几项常规因素。接下来就是UniFlash里的Force Recovery或Mass Erase。操作前把USB重新插拔一次，确认仿真器被正常识别，打开UniFlash，选CC1310，进入恢复界面执行强制擦除。
擦除完成后芯片会回到出厂状态，调试接口恢复可用。正常情况下，回到IAR里重新连接，之前怎么都绕不过去的-241就消失了。这一步做完还不行，那我建议检查是不是芯片本身硬件损坏，可以换一片芯片试试。
4. 问题速查表与几条独家经验
4.1 快速定位对照表
我把排查过程中最常用的判断点和对应处理方法整理成一张速查表，遇到问题直接对着查：
| 现象 | 优先排查 | 处理方法 |
|---|---|---|
| 设备管理器有黄色感叹号 | 驱动版本不对 | 手动指定TI驱动目录更新 |
| 设备管理器完全看不到XDS设备 | USB线/口问题或硬件损坏 | 换数据线、换USB口，检查硬件 |
| 设备正常但UniFlash也连不上 | XDS110固件过旧 | 升级XDS110固件 |
| 换板子能连，原板子连不上 | 芯片调试引脚被复用 | UniFlash Force Recovery/Mass Erase |
| 只改过IAR配置后开始失败 | 接口类型或仿真器型号选错 | 改为cJTAG，选对XDS型号 |
| 高速率时偶发失败，低速率正常 | 时序和布线问题 | 降低连接速率 |
| 手按复位键能连上，松开不能 | 复位电路设计问题 | 检查复位电容/上拉/下拉 |
这张表不保证覆盖所有情况，但90%以上的Error -241都能在某一行里找到对应解法。
4.2 几条不写在文档里的细节经验
连接前把所有占用串口的软件关掉。XDS110的虚拟串口如果被串口助手或SmartRF Studio占用，某些情况下调试连接会异常。虽然看起来不相关，但我遇到过两次，关掉串口工具后问题消失。
板载XDS110的LaunchPad如果同时开了CCS的实时调试会话，再开IAR去连，两个会话会打架，报错也是-241。CCS和IAR不要同时调试同一块板子。
如果电脑上有多个XDS仿真器同时插着（比如同时插了两块LaunchPad），IAR有可能连到了错误的仿真器。检查设备管理器里哪块板子是XDS110 Class Debugger，拔掉多余的一块再试。
使用外部目标板时，检测电压不匹配也会导致-241。XDS110的参考电压通常是3.3V，如果你的板子是1.8V或5V逻辑，电平不匹配时仿真器和芯片根本无法握手。这种情况不是改软件配置能解决的，需要加电平转换电路。
当所有手段都用过、芯片也强制擦除了，还是连不上，这时候换个USB口或者换台电脑试一下。有时问题出在主板USB控制器的兼容性上，尤其是老的USB 2.0驱动在Windows 10/11上偶尔会有诡异表现。
最后说点实际的
我在这个错误上耗掉的那几个小时，复盘下来，真正直接解决问题的是两步：先升级了XDS110固件，然后用UniFlash做了强制擦除。但前面那些看似无效的检查（换线、换USB口、查设备管理器、交叉验证）并不是白做，它们帮我确认了链路里每一段的健康状况，最后才敢放心执行破坏性的Mass Erase。
这里也想提醒一句，拿到新板或者新环境，第一次连仿真器报错别急着怀疑硬件坏了。XDS仿真器、TI工具链和IAR三方混一起，环境的坑远大于硬件的坑。今天这篇提到的排查顺序，按概率从高到低排过一遍，多数情况下在固件升级那一步就已经能解决问题。真走到强制擦除那一步，基本就是芯片被之前的代码锁了，属于CC1310这类复用调试引脚的片子避不开的宿命，擦一次以后也就长记性了。
