程序能够正常下载到目标板里，可每次运行几秒钟之后调试器就突然不受控制了，或者单步执行刚走到某个位置会话便直接断开，这种麻烦在实际调试中经常能碰到，背后常常是目标板的供电不够稳定、调试接口的参数选得不太合适、复位信号出现了异常，或者是看门狗还在后台跑着。在处理这类问题时，不能一上来就反复去改代码，而是应该先把整个连接链路拆开来一项一项地检查，这样才能更快地找到根子。

　　一、TASKING调试连接总是中断怎么办

　　当调试会话断开以后，最好先分清楚究竟是刚一连接就失败，还是程序已经跑起来了才失去控制，这两种情况虽然看起来结果差不多，但排查的方向却有很大区别。

　　1、重新上电并且做一次CPU复位

　　先把当前的调试会话关掉，然后把目标板和调试器两端的电源都断开，等重新连接好之后再执行一次CPU复位，不要急着马上把程序下载进去。按照TASKING知识库里的建议，通过复位操作可以先把问题的范围缩小一些：要是连复位都不成功，那就需要重点检查一下连接链路上的硬件；如果复位能够顺利完成，但下载过程却一直出错，那么接下来就该去查Flash存储和程序加载这一块了。

　　2、仔细查看探针、转接板以及它们的方向

　　需要确认手头的BlueBox型号、Debug Adapter的类型和目标板上的接口是否匹配，同时检查转接板上Pin 1的位置有没有对齐；有些接口从外观上看起来一模一样，但它们的功能定义可能完全不同，要是插错了目标端的连接器，不但会导致初始的连接失败，还可能让运行过程中出现时断时连的现象。

　　3、把调试接口的速率适当降低

　　可以进入菜单【Hardware】→【CPU Options】→【JTAG】，把JTAG扫描的时钟频率往下调一调；当连接用的线缆比较长、板级信号的质量本来就不算理想，或者目标板上的噪声比较大的时候，调试时钟如果跑得太快，往往会让原本就脆弱的问题更容易暴露出来。在TASKING的官方排查说明里面，也把调低JTAG速率放进了常用的处理手段里面，属于比较容易见效的一招。

　　4、确认好目标板上的供电情况

　　不要只盯着板卡上那几盏指示灯，最好是拿起万用表实际量一下微控制器的供电电压，还有调试参考电压是不是达标；有时候供电会瞬间跌落，参考电压出现大幅漂移，或者接地回路不可靠，这些都可能让调试接口在程序运行的过程中一下子就断开。TASKING的知识库里面也明确建议，供电这块必须靠实际测量才能下结论，光凭眼睛看是不可靠的。

　　二、TASKING调试会话不稳定时先排查什么

　　当调试会话已经建立起来了，但跑了一阵子之后还是会掉线，这个时候就应该优先去看一看看门狗的状况、复位信号的状态，还有程序是不是在无意中改写了跟调试有关的那些寄存器配置。

　　1、优先排查内部和外部的看门狗

　　如果看门狗一直没有好好喂狗，它就可能在程序正常跑着的时候，或者在CPU暂停下来的时候突然触发一次复位，复位之后调试器自然就跟着丢掉了控制权。根据TASKING的相关说明，这类现象经常会表现为Flash操作中断、芯片初始化过程失败，或者是应用跑起来之后BlueBox不再能控制CPU，表现跟单纯掉线很相似。

　　2、在初始化阶段暂时把看门狗关掉

　　可以进入【Hardware】→【CPU Options】→【Reset】这个菜单，检查一下有没有提供内部看门狗的关闭选项；对于部分器件，还可以通过【Hardware】→【Scripts】→【WDOG Disable】去加载一段脚本，用这种方法临时禁用看门狗。需要注意的是，这只是调试期间为了方便排查问题而做的临时处理，可别把量产版本里的安全保护逻辑也一块儿弄丢了，调试完成之后还是得把它恢复回去。

　　3、留神观察复位信号的变化

　　如果在调试日志里面出现了Reset ACTIVE或者Reset INACTIVE这样的提示，就要结合时间点去判断一下信号到底是从哪里冒出来的；复位信号的来源可能有很多种，可能是芯片内部发起的，也可能是外部的看门狗动作，还可能是板子上被人按下了复位键，或者干脆是外部的干扰信号触发了误动作。假如程序每次都是跑到同一个固定的位置之后掉线，那就要重点怀疑它是不是遭遇了周期性复位，然后顺着这个思路往下查。

　　4、核对待使用的复位方式以及芯片型号

　　点击【Debug】→【Configure session】→【SoCs】，先确认里面选的芯片型号是不是跟实物一致；然后再进到【Hardware】→【CPU Options】→【Reset】里面，仔细查看一下当前的复位方法有没有选对。按照TASKING的资料说明，一旦复位方式选得跟目标芯片不匹配，调试器很可能就没办法重新拿到目标的控制权，看上去像连接断掉，其实是控制逻辑出了岔子。

　　三、TASKING调试中断怎样留下复核依据

　　像这种偶发性的掉线问题，单靠一次两次的操作是很难判断清楚的，所以比较推荐的做法是把日志、触发的具体位置和当时板卡的整体状态都一五一十地记录下来，然后再结合这些信息来缩小排查的范围。

　　1、把Progress信息和调试日志都保存下来

　　每次会话中断之后，可以把Progress窗口里的所有内容，还有调试日志都存好，同时顺手记下掉线前最后一条信息是什么、程序从启动到中断大概运行了多久、当时的复位状态是怎样的，以及用的是哪一种调试接口。如果这个问题只在某一块特定的板子上才出现，那么最好也把这块板子的编号和给它供电的具体条件一并记录下来，这样后面复现和分析的时候就容易得多。

　　2、在启动代码里打上断点

　　要是怀疑程序在运行过程中发生了复位，就可以在启动代码的入口位置放一个执行断点；针对TriCore系列的芯片，TASKING的说明里提到过，即使发生过复位，这个断点依然可以命中，再结合RCU_RSTSTAT寄存器里的数值，就能大致判断出复位是从哪里发出来的。对于其他类型的芯片，也可以用类似的思路去查，只是具体的寄存器名称还是要以对应芯片的手册为准。

　　3、逐步把调试条件恢复回来

　　能够先用较低的JTAG速率、关掉看门狗、用固定的供电电压，并且简化掉初始化脚本后面那些复杂的操作，先让系统稳定地跑起来，然后再一样一样地往回加那些设置；每次只改动一个条件，才能比较清楚地看出中断到底是哪一项重新被加回来的时候才出现的，这样定位就会很直接。

　　总结

　　所以，要面对TASKING调试连接总是中断的问题，或者调试会话不稳定的时候该从哪里下手，排查的顺序大致可以这样来安排：先做一轮复位测试、再仔细检查调试接口、把时钟速率适当降下来、实际测量一下目标板的供电、重点排查看门狗是否有动作、核对待用的复位方式和芯片型号对不对，最后再把日志和复现的条件完整地保存下来。如果一开始连接就失败，那就要重点去查硬件链路；如果是跑起来以后才掉线，那就要优先去查复位信号和看门狗。只要把日志和当时的复现条件都保留下來，后面定位问题的过程就会直接很多。