1. 报错现场点下 Debug 之后卡住的那一秒发生了什么先复现一下这个错误常见的出场方式。IAR Embedded Workbench 里你按下 Download and Debug工程编译通过一切看起来都很正常。然后 C-SPY 的日志窗口开始滚动推到一半突然停住紧接着蹦出整段红色文字Fatal error: Failed to connect to the XDS emulator (Error -241 0x0:) Session aborted!注意这个细节报错文本里的 emlulator 拼写是 TI 那边调试驱动里的历史遗留笔误这么多年了一直没改别被它带偏它说的就是 XDS 仿真器本身。对于用 CC1310 做低功耗无线产品的朋友来说这个错误可以说是调试路上的常客尤其是当你把 LaunchPad 烧录器拆出来接自研板子、或者换了一台新电脑重新搭 IAR 环境的时候它出现的概率极高。要搞懂这个错误先得知道 IAR 点下调试按钮之后后台到底在干什么。整个下载流程其实可以拆成这么几步C-SPY 启动加载当前工程的调试配置。初始化 XDS 驱动库枚举电脑上已经连接的 XDS 系仿真器XDS110、XDS100v3 等。和仿真器建立 USB 通信读取仿真器固件版本、供电状态。仿真器按照你设定的接口模式JTAG 或 cJTAG向目标芯片发起扫描链通信读取芯片的 IDCODE。拿到 IDCODE 并且校验通过之后才开始配置扫描链、访问内存、下载程序。Error -241 每一步都有可能冒出来但绝大多数情况下它卡在的是第 4 步前后。日志里那句 0x0是调试驱动在访问地址 0x0 处的寄存器时超时的意思。地址 0x0 对 CC1310 这类 ARM Cortex-M3 内核的芯片来说是芯片内部总线的最初位置也是调试握手阶段必然要碰的地方。换句话说连最基本的握手都没完成后面自然什么都做不了。所以看到这个报错的第一个心理准备是它不等于你的芯片坏了也不等于你的工程代码有问题。它只是告诉你从电脑到芯片这条调试链路的某一个环节断了。2. Error -241 的底层逻辑超时以及超时背后真正的潜台词TI 的调试工具链里错误码一般分几个系列。像 -241 这种三位数的错误码属于 XDS 调试栈里的运行错误。它对应的官方解释翻译过来是在调试过程中目标芯片没有在预期时间内做出响应通俗点说就是超时。但超时是个结果不是原因。真正要把问题揪出来你得进一步问谁超时了在 Error -241 的场景下有两种完全不同的超时第一种是仿真器对电脑的 USB 通信超时。这种情况下IAR 连 XDS110 本身都没打通。可能的原因包括USB 线是充电线不是数据线、USB 口供电不足、驱动没装对、XDS110 的固件坏了或者仿真器被别的进程占用了。特征是报错出现得非常快几乎是点击 Debug 按钮的一瞬间就弹出来windows 设备管理器里你可能也看不到一个状态正常的 Texas Instruments Debug Probe (XDS110)。第二种是仿真器发出了调试时钟信号但目标芯片始终不应答。这种情况下USB 链路是好的驱动也是好的问题在仿真器和 CC1310 之间的那几根线上。报错通常不是瞬间出现而是会卡个一两秒像是在反复重试最后才报超时。这里面的原因就多了目标板没供电、JTAG/cJTAG 引脚没连对、TMS/TCK 信号线上有东西干扰、复位脚被拉死、调试接口时钟太快甚至芯片的 CCFG 配置里把调试口锁了。区分这两种超时是排障的第一个岔路口。别一上来就去检查代码或者换芯片先判断报错卡在 USB 段还是目标段。快速区分方法也很简单把 CC1310 从板上拆掉或者断开 JTAG 线再点一次 Debug。如果报错信息几乎没变化那大概率是仿真器自身链路的问题如果报错从Fast失败变成了反复超时甚至错误码变了那反而是个好迹象——说明仿真器和电脑已经正常通信问题出在线缆和芯片侧。这个区分动作看起来很土但真的能帮你节省一半的排障时间。我在帮同事看这个问题时发现很多人一看到 -241 就立刻怀疑工程配置来回改了半小时设置结果最后发现就是 USB 口接触不良。3. 从电源到芯片一条可复现的五层排查链路既然 -241 是这条链路上的任意一点断掉导致的最可靠的排查方式就是分层排查。我把这些年实际用过、验证过有效的排查顺序整理成五层每一层都有快速验证手段和典型的解决办法。遇到问题从第一层往下走不要跳否则容易在错误的方向上浪费更多时间。3.1 第一层XDS110 本身有没有被电脑正确识别优先检查 Windows 的设备管理器找到通用串行总线设备下的 Texas Instruments Debug Probe (XDS110)。正常状态下它应该没有黄色感叹号同时在端口里能看到两个 COM 口。这两个 COM 口是 XDS110 的 UART 背板通道平时用来打印日志它的存在可以侧面证明仿真器枚举成功了。如果看到一个带感叹号的设备或者干脆显示为 Unknown Device那就是 USB 通信层面出了问题。先换一根短一点的 USB 线——这里我要多说一句很多报 -241 的情况最后是栽在 USB 线上。调试器对线材质量比想象中敏感尤其是那种又细又长的充电线数据线上的时序稍微差一点就会导致枚举不稳定功耗稍大就掉线。换线之后还是不行可以打开 TI 官方的 XDS110 Firmware Update 工具重新刷一遍固件。就算你确认固件版本没问题也建议刷一次因为固件区的文件损坏是导致仿真器识别不到的隐藏原因之一重刷能一次性排除。3.2 第二层目标板供电与 VTREF 检测XDS110 作为一款现代仿真器上电之后会先检测目标板的电压。它通过 JTAG 连接器上的 VTREF 引脚来感知目标系统的电平以此决定调试引脚的电平标准。如果目标板没供电或者 VTREF 没有正确连到目标板的 3.3VXDS110 就会认为目标不存在接着就是连接超时。这一层的排查非常直白用万用表量一下目标板的 3.3V 电压是否稳定。CC1310 自研板常见的问题是 LDO 带载能力不足仿真器一加载电压就被拉下去了。还有一个经常被忽略的细节很多人的自研板只接了 TMS、TCK、TDO、TDI 和 GND没接 VTREF。调试器能枚举成功但就是连不上芯片就是这个原因。CC1310 LaunchPad 之所以开箱即用是因为板子在设计时就把 VTREF 接到了 3.3V 网络上。如果你用的是外接 XDS110 调试自研板务必确认连接器上有 VTREF 引脚的接线。如果板子没有引出 VTREF临时救急的做法是直接在调试连接器旁边飞一根线到 3.3V但飞线时注意要保证该路径上电压干净稳定。3.3 第三层复位电路与时钟源CC1310 的复位脚被拉死也会导致调试器无法完成握手。最常见的原因是目标板上 CC1310 的 NRST 引脚被一个外部看门狗、电机驱动电路或者按键电路长期拉低。另一个容易踩的坑是调试连接器上的复位信号没有真正接到 CC1310 的 NRST 引脚或者中间串了一个奇怪的元件。验证方法同样不复杂。用示波器或者万用表量一下 NRST 引脚电平正常工作状态下它应该保持高电平。如果发现一直被拉低切断外部电路再试。另外如果目标板是通过排针连接的插针氧化或接触不良也可能导致 NRST 悬空悬空状态的复位脚会非常容易受干扰调试器一发起连接反而把系统打挂了。时钟源的问题要稍微特殊一点。CC1310 内部有 RC 振荡器理论上不接外部晶振也能跑起来但调试器握手阶段对精确时钟的要求更高。如果板子上 24 MHz 晶振没有起振或者起振波形幅度不够仿真器可能读不到稳定的 IDCODE表现同样是超时。这个可以用示波器抓晶振引脚确认如果波形很弱检查晶振的负载电容是否匹配。3.4 第四层驱动与 IAR 版本的兼容性这一层很多人觉得没意义其实影响很大。IAR 自带的 XDS 驱动和 TI 官方驱动之间偶尔会打架。尤其是电脑上同时装了 CCS 和 IAR 的时候两套工具各自带着不同版本的 XDS 驱动库就可能出现 IAR 调用驱动时加载失败给你报 -241。处理方式是把 TI 官方最新的 XDS 驱动装一遍然后尽量保持 IAR 和 CCS 的版本不要太旧。我在实际工作中发现IAR for ARM 8.x 配 XDS110 是比较稳定的组合老版本 IAR比如 7.x 早期对 XDS110 的支持有些小问题遇到 XDS110 固件较新时会握手失败。这种情况直接升级 IAR 或者手动更新 XDS110 固件就能解决。3.5 第五层芯片状态是否允许调试访问如果前面四层都查过了问题还复现就要把注意力转到 CC1310 本身。芯片处于 Shutdown 低功耗模式时调试接口是不可用的。很多做低功耗产品的同学都会遇到程序里进入了 shutdown mode 之后下次再想连接调试器就报 -241。这是因为芯片在睡眠模式下根本不会响应调试时钟。解决办法是进入 BSL 模式串行启动加载程序。CC1310 内部 ROM 里固化了一段 bootloader通过特定的引脚组合触发后可以对 flash 进行擦除。擦掉那段会进入低功耗的程序之后调试口就重新开放了。具体触发方式在 CC1310 的 datasheet 和 LaunchPad 用户指南里有详细说明以 LAUNCHXL-CC1310 为例通常是按住某个按键再按复位。擦除操作在 TI 官方的 SmartRF Flash Programmer 2 里用 Erase 按钮就能完成。4. CC1310 专属陷阱cJTAG、引脚复用与 CCFG 安全位前面几个问题的排查思路不只适用于 CC1310很多 STM32 的 XDS 调试也通用。但 CC1310 有几个专属的坑需要单独拿出来讲。如果你已经做完五层排查还是一头雾水问题大概率就在这一节里。4.1 cJTAG 和 4 线 JTAG 选错会怎样CC1310 支持两种调试接口标准的 4 线 JTAGTMS、TCK、TDO、TDI和 2 线的 cJTAGIEEE 1149.7只用 TMS 和 TCK 两根线。在 IAR 的调试器设置里你可以在 cJTAG 和 JTAG 之间切换。这里的关键在于你的目标板实际用了几根线IAR 就必须配置成对应的模式。如果你板子上只连了 TMS 和 TCK 两根线但 IAR 里选的是JTAG仿真器会傻等着 TDI 和 TDO 上的响应等不到就报超时。反之接口模式选成 cJTAG 而板子实际接了四根线通常也能工作但有些信号完整性差的板子会不稳定。我在排查别人工程时经常发现有人用 LaunchPad 调得好好的移植到自研板就报 -241原因就是 IAR 工程里还保留着 LaunchPad 默认的 cJTAG 配置而他的自研板引出了完整 4 线 JTAG但板子上的 TDI 或 TDO 走线太长导致 cJTAG 和 JTAG 在电气表现上起了冲突。4.2 调试引脚被复用导致信号异常CC1310 的 JTAG 引脚和普通 GPIO 是复用的。这本来是个很灵活的设计——量产的产品可以把调试引脚释放出来当普通 IO 用减少成本。但反过来如果你的板子设计上动了这些引脚调试就会崩溃。常见的两种情况一是在 JTAG 引脚上挂了 LED、按键或者上拉/下拉电阻影响了信号的波形二是代码里把这些引脚配置成了输出并且持续驱动到错误电平。第二类问题很隐蔽因为你的程序可能上电后立刻就把 TMS 引脚配成了普通 GPIO 去控制外设之后调试器再想握手就怎么都握手不上了表现就是 -241。排查时可以先在程序里把 JTAG 相关的 pinmux 配置全部屏蔽掉或者用空工程烧录有时也能恢复如果恢复后能连上就说明是代码里的引脚复用配置问题。如果连烧录都没法完成那只能走 BSL 擦除的路线了。4.3 CCFG 把调试口锁了怎么办这可能是 CC1310 最阴的一个坑。CC1310 的 flash 里有一段称为 CCFGCustomer Configuration的区域里面有很多芯片运行时的配置项其中就包含是否允许外部调试器访问。如果你在 SmartRF Flash Programmer 2 里勾选过锁定调试或者产品代码里对 CCFG 的操作不小心改动了调试使能位芯片就会拒绝所有调试连接。注意一个重要区别CCFG 锁定调试时报的错不一定叫Security violation有时也表现为 -241 超时。因为锁定的机制让调试器根本探测不到目标你看到的就是目标无响应。遇到这种情况不要慌芯片没死。用 BSL 方式进入 bootloader在 SmartRF Flash Programmer 2 里执行一次全片擦除把 CCFG 一起擦掉芯片恢复出厂默认状态调试口就回来了。这个操作唯一要提醒的是擦除会清掉你的全部固件和数据如果片上有量产出厂的校准数据或序列号先备份。CC1310 的 BSL 擦除不会动到 TI 出厂固化的 ROM 区域所以不会让芯片变砖。5. IAR 工程选项逐项核对这些配置最容易忽略硬件链路都排查干净了接下来回到 IAR 本身。工程配置里头有几个选项一旦设置不对也能直接把你卡在 -241。而且这种软件型 -241往往最迷惑人因为硬件怎么查都是好的。5.1 调试器驱动选择与设备型号打开 Project Options Debugger左侧的 Driver 一栏一定得选成 Texas Instruments XDS而不是 Simulator 或者 J-Link。很多人从别的平台迁移工程过来忘了改这一项点下 Debug 后看到的却是莫名其妙的目标连接失败错误。同一窗口里还有一个 Device 下拉框要选对具体的芯片型号比如 CC1310F128。选错型号会让调试器拿着错误的 IDCODE 校验值去核对目标芯片自然就握手失败。我见过有人用 CC1310 的工程Device 里却留着 CC1352 的配置报的就是 -241。把型号改回来之后一切恢复正常。5.2 接口类型和时钟速率在 Debugger 下一级的 TI XDS 页面里你可以设置接口类型和调试时钟频率。接口类型对应前面说过的 cJTAG 和 JTAG需要按板子实际接线来选。当时钟频率这一项很多人是默认不管的但自研板通常不像 LaunchPad 那样把信号走线控制得那么好尤其当你用杜邦线、软排线连接调试器和目标板时默认的几兆赫兹调试时钟很容易超时。建议先把时钟降到 1 MHz 以下比如 500 kHz试一次。如果能连上就说明是信号完整性的问题此时可以选择接受慢速调试反正 CC1310 的 flash 不大慢点也就多等半秒钟也可以回头去优化 JTAG 走线长度和线径。这是一个百试百灵的排查技巧我在现场帮人解决 -241 时十次有八次靠降时钟就能临时突破。5.3 电源选项IAR 的 TI XDS 页面里还有一个目标电源相关的选项用来控制 XDS110 是否给目标板供电。XDS110 本身具备输出 3.3V 给目标板的能力但如果你目标板有自己的供电系统这个选项应该关闭。否则两边电源叠在一起轻则电压波动重则烧板子。如果目标板供电正常但你把 IAR 的目标电源设置成了由仿真器供电而仿真器的输出能力又扛不住你的整板功耗表现出来也是连接失败。这种错误很难从报错文本里看出来只能靠排查排除掉。我的习惯是自研板一律关闭仿真器供电只让 XDS110 做纯调试器。5.4 多实例冲突与残留进程最后一个容易忽略的软件因素是不是另一个调试会话还占着 XDS110。比如你之前开着 CCS 在调试没关干净就直接打开 IAR 再去连接或者 IAR 的调试会话异常退出但后台进程没死干净。XDS110 在被一个进程占用时其他进程去连接大概率就是超时。解决办法很简单把所有 IDE 都关掉调试器 USB 拔掉重插让 XDS110 彻底断电复位一次再打开 IAR 重新连接。Windows 上如果确认有残留进程占用了仿真器可以在任务管理器里把相关的调试进程结束后再试。这个操作虽然基础但我确实被它坑过一次当时排查到半夜才发现是之前 CCS 的调试进程没退干净。6. 一次真实排障复盘最终问题出在 TMS 线上的 1k 下拉电阻理论讲了不少最后分享一个我印象特别深的真实案例。客户那边有一块 CC1310 自研板板子是从成熟方案上改过来的测试固件原本烧录正常突然某一天之后IAR 调试就再也连不上了报错就是 Error -241 0x0。我当时接手的第一步是复现现场。确实一按 Debug日志卡了一会儿然后报超时。但不是瞬间报错所以基本判断 USB 链路没问题、目标板也是上电的。接着按照流程走了设备管理器检查设备状态正常VTREF 电压 3.3V 正常。我又把调试时钟从 5 MHz 一路降到 500 kHz结果依然连接失败。这就排除了单纯的走线质量因素说明目标侧有更硬的问题。然后我用 SmartRF Flash Programmer 2 尝试连接也是连不上。既然 SFP2 也不行至少说明不是 IAR 的配置问题。此时我怀疑要么是复位电路要么是引脚复用/CCFG 锁定。量 NRST高电平正常。于是决定走 BSL 模式做一次全片擦除看能不能恢复。结果擦除成功——这说明芯片是活的BSL 能响应串口链路没问题。擦除后马上用 IAR 再连居然还是 -241。这个时候我的表情大概和当时的客户一样一片空白。冷静下来重新看原理图最后发现一个细节板子的 TMS 引脚上除了一路接到调试连接器之外还并联了一根 1k 下拉电阻到 GND。这颗电阻的设计初衷是为了让某颗外部芯片在系统上电时的引脚状态稳定。问题在于cJTAG 的握手本身就是靠 TMS 信号线的高低电平时序来完成的CC1310 该引脚由芯片内部驱动但外部这颗 1k 下拉电阻等于在信号线上并联了一个不小的负载直接把关键时序压垮了。信号完整性不够调试器每次握手都失败于是反复超时最终报 -241。解决方案很简单把这颗 1k 下拉电阻从 TMS 线上摘掉。摘掉之后IAR 恢复默认时钟一把就连接成功。这个案例给我的教训有三点。第一不要在 JTAG/cJTAG 信号线上随便并联电阻或电容哪怕看似无害第二BSL 能连上不等于 JTAG 链路没问题两者走的是完全不同的引脚通道第三排查这种问题耐心和逻辑比折腾更重要按层排查虽然慢但最终不会漏掉真凶。7. 几个我后来养成的调试习惯经历的次数多了以后我现在遇到 -241 基本有一套固定动作。先把 USB 线拔插一次确认设备管理器识别正常然后量一下目标板 3.3V 和 VTREF接着把 IAR 调试时钟临时降到 500 kHz不行的话再用 SFP2 试连最后才考虑 BSL 擦除。这套动作走下来大多数情况下二十分钟内能定位问题。还有一个值得推荐的预防措施自研板设计阶段把 JTAG 信号线尽量短、走线平行、远离高频信号调试连接器附近不要放置大电感或大电容。另外强烈建议板子上保留一个 BSL 触发电路哪怕只是一个按键和跳线。CC1310 的调试口被锁或者固件跑飞时BSL 就是你的最后一根救命稻草没有它就只能整板报废。最后多说一句题外话如果你手上的工程以前调试一直正常某天突然报 -241优先从最近改了什么入手。换过电脑、换过 USB 口、焊过板子、改过原理图这些变动才是隐藏在深处的真实源头。解决好这一层比重新读一遍调试器手册要高效得多。