去年冬天一条产线在量产爬坡阶段被一批能开机但功能异常的板子卡住了。问题出在一颗 0402 的 4.7k 上拉电阻虚焊肉眼和 AOI 都没抓到——引脚吃到了锡但焊盘下方的润湿面积极小常温下导通到了低温环境就间歇性开路。后来复盘时测试工程师说了一句话我记到现在如果这块板的 JTAG 链能连上这个问题在五分钟内就会暴露。这就是 IST也就是 In-System-Test在系统测试一个被很多人当成调试接口顺带的副产品却在量产测试里能实打实兜住几百万损失的技术手段。它不靠治具上的探针去扎点而是让板子上本来就有的芯片伸出自己的手去摸自己的邻居。接下来我把这几年在 IST 上踩过的坑、算过的数、写过的脚本尽量完整地摊开讲一遍——从原理到 DfT 设计从覆盖率计算到产线整合适合刚接手测试工序的朋友也适合做了几年 ICT 想往系统级测试方向转的同行。1. IST 到底是什么把探针从治具里搬进芯片1.1 一个典型场景贴错一颗电阻谁来兜底先把这个概念落到地上。假设你手上有一块 8 层板上面有一颗 BGA 封装的 MCU、一颗 FPGA、几颗 DDR、一堆电源和分立器件。传统做法是做一套针床治具ICT用几百根探针去扎板子上的测试点逐网测开短路、逐器件测值。这种方式很直接但有两个绕不开的麻烦一是测试点占布局面积高密度板根本放不下二是 BGA 下方的焊球探针扎不到只能靠 X-Ray 抽检。IST 换了个思路。支持 IEEE 1149.1 的器件通常说的 JTAG 器件内部每一个 I/O 引脚上都挂着一个边界扫描单元这个单元可以在不影响内核逻辑的前提下直接驱动引脚输出、也能直接读取引脚上的电平。换句话说芯片自己就带了一套寄生探针阵列。IST 做的事情就是把这些探针组织起来让器件 A 通过自己的引脚把某个网络拉高同时让器件 B 通过自己的引脚去读这条网络是高还是低从而判断两个焊点之间的连线是否完好。所以 IST 的定位很清楚它不是万能的但它在互连测试interconnect test这个细分领域几乎是无敌的。1.2 IST、ICT、FCT、ISP 四者的分工与重叠这四个词在产线上经常被混着用我先用一张表把它们掰开。项目测什么靠什么实现典型耗时主要短板ICT在电路测试器件值、开短路、极性针床/飞针物理接触20–60 s需要测试点BGA 覆盖差IST在系统测试网络互连、引脚级开短路、部分逻辑器件自身边界扫描链路2–20 s需可扫描器件模拟域弱ISP在系统编程往 Flash/CPLD/FPGA 里写程序JTAG/SWD 等调试接口5–120 s只写不测除非带校验FCT功能测试整机功能是否正常激励测量跑业务逻辑30 s–10 min故障定位能力弱只能判好/坏这里有个很关键的认知IST 和 ISP 用的是同一套物理接口但干的是两件完全不同的事。ISP 是往芯片里灌数据IST 是从板级网络里读数据。产线上最经济的做法是把 ISP 和 IST 放在同一个工位、同一套治具里跑完——因为两者都需要 JTAG 链路连接切换成本几乎为零。我做过一个统计把 ISP 从独立工位挪到 IST 工位后单板工序流转时间减少了 40 秒左右同时少了一套测试治具的投入。另外要强调的是IST 并不能替代 ICT。板子上的电源网络、晶体振荡器、模拟前端、大容量电容边界扫描全都摸不到。IST 的价值在于补 ICT 摸不到的那块盲区BGA 底下的互连、密集排线的差分对、以及那些细到放不下测试点的网络。1.3 什么样的板子适合上 IST不是所有板子都值得上 IST。我的判断标准就三条第一条可扫描器件的引脚占比。这个数字决定覆盖率的上限。如果一颗 MCU 有 144 个引脚其中 120 个是 GPIO 且支持边界扫描那这 120 个引脚能覆盖的网络就有很大的操作空间。反之如果主控是颗没有 JTAG 的低价 MCU整条链路都建不起来IST 基本无从谈起。第二条连接器密度和 BGA 数量。板子越大、连接器越多、BGA 越密ICT 治具的成本和难度就越高这时候 IST 的性价比就凸显出来。我见过一块 16 层的通信板ICT 治具报价接近六位数最后改成 IST 局部 FCT 的组合方案硬件投入直接砍掉三分之二。第三条产量。IST 的向量开发是需要人力的一次性投入大概在几周到一两个月之间。如果是小批量打样直接用飞针测试更划算只有进入量产、单板测试成本被摊薄到足够低的时候IST 的经济性才会显现。经验值是年产五千块以上就值得认真评估了。2. 核心原理拆解边界扫描是怎么看见每一根引脚的2.1 TAP 控制器与 16 个状态机状态要理解 IST必须先理解 TAPTest Access Port控制器。它是每个 1149.1 器件内部的一个小状态机由四根有时五根信号线驱动TCK测试时钟所有状态翻转的节拍器TMS模式选择在每个 TCK 上升沿采样决定下一个状态去哪TDI数据输入串行移入TDO数据输出串行移出TRST可选异步复位低有效TMS 在 TCK 上升沿上的电平序列把状态机在 16 个状态之间推来推去。这 16 个状态分成两组对称的路径一组操作数据寄存器DR一组操作指令寄存器IR。每一组都遵循Select → Capture → Shift → Exit1 → Update的基本节奏中间还夹着 Pause 和 Exit2 用来做多设备暂停。理解这个状态机的意义在哪在于知道每一步操作会产生什么副作用。比如想让器件驱动引脚必须走完Capture-DR → Shift-DR把数据移进去→ Exit1-DR → Update-DR真正生效的瞬间是 Update-DR 那一个 TCK 边沿。这就是为什么在写测试向量时Update 之后必须插入一段等待时间让网络电平稳定下来否则你读到的可能是上一拍的残留值——这个坑我在早期调试时踩过整整两天。2.2 边界扫描单元一根引脚上的三件套每个支持扫描的 I/O 引脚上都有一个边界扫描单元BSC。它内部其实有两个触发器和一个多路选择器捕获触发器Capture FF负责看在 Capture-DR 状态把引脚上的实际电平锁进来更新触发器Update FF负责动在 Update-DR 状态把移入的数据推到引脚上输出多路器选择引脚到底是由内核逻辑驱动还是由更新触发器驱动这三个部件配合就实现了观察和驱动两种能力。所有引脚的捕获/更新触发器首尾相接形成一条移位寄存器链就是通常说的边界扫描寄存器BSR。这里有个很容易被忽略的细节BSR 的长度等于器件所有扫描单元的位数之和而不是引脚数。有些引脚比如纯电源脚没有扫描单元有些双向引脚会有两个单元有些器件的内部控制信号也会占用位数。所以链上每个器件的 BSR 长度必须以 BSDL 文件里声明的为准不能靠数引脚。我第一次手工估算链长的时候把只读引脚也算进去了结果移位出来的数据整体错位IDCODE 读出来是对的但互连测试全乱——因为这个错误只影响 BSR 长度不影响 IDCODE 寄存器。2.3 EXTEST、SAMPLE、INTEST、RUNBIST 各自干什么TAP 状态机决定怎么移指令寄存器决定移进去干什么。常用的标准指令有这么几条指令作用在 IST 中的角色BYPASS器件在链上只占 1 位直通缩短链长加速非必要器件IDCODE读出 32 位器件标识链路连通性自检、防错料SAMPLE/PRELOAD采样引脚状态 / 预载数据读实时引脚、准备驱动数据EXTEST引脚脱离内核由 BSR 驱动和采样互连测试的主力INTEST测试器件内核逻辑板级很少用一般给芯片厂RUNBIST触发内建自测部分器件支持用于芯片级自检CLAMP引脚输出固定值但不移位给周边非扫描器件提供稳定电平HIGHZ所有输出引脚置高阻避免总线争夺调试利器实际做互连测试时的标准动作序列是这样的先给所有器件加载EXTEST指令然后通过SAMPLE/PRELOAD把一个测试模式预载到所有器件的更新寄存器里再切到EXTEST并执行 Update-DR让所有器件同时按照预载的数据驱动引脚。之后经过一段稳定时间再走一次Capture-DR把各引脚实际读到的电平捕获下来最后通过Shift-DR移出、比对。这个预载—更新—采样的三段式结构是整个 IST 的骨架。所有商业工具生成的向量本质上都是这个序列的变体。2.4 从 BSDL 到互连测试向量开短路是怎么被判出来的互连测试的核心判据只有两条开路判据驱动端把网络拉到某个电平接收端读到的却是相反的值。这里有个前提——网络上必须有上下拉电阻提供确定的默认电平。如果一条网络既没有上下拉又是开路的那么接收端引脚会浮空读到的值是不确定的可能一会儿高一会儿低。这就是为什么设计阶段必须刻意给关键网络加上拉或下拉它不只是电气需求更是可测性需求。短路判据两条本该独立的网络被焊锡连在一起。这时候如果驱动端让网络 A 输出高、网络 B 输出低而 A 上的接收端读到低、B 上的接收端读到高就说明两者被短接了。有些工具会专门生成短路检测向量——让相邻网络输出互补值一次就能抓到一大片。生成的向量模式主要有三种Walking-1 / Walking-0一次只有一个引脚为活跃值能精确定位到具体是哪根引脚出问题但向量数等于引脚数非常慢True/Complement全 0 一次、全 1 一次最快但定位能力差计数模式Counting折中方案用较少的向量覆盖较多引脚是目前生产上最常用的我一般在工程验证阶段用 Walking 模式定位问题确认板子没问题后再切到 Counting 模式跑量产单板测试时间能压缩 60% 以上。3. 设计阶段就得埋好的伏笔DfT 与测试点规划3.1 菊花链拓扑顺序、长度与走线约束JTAG 链路是菊花链结构调试器 TDI → 器件1 TDI器件1 TDO → 器件2 TDI …… → 器件N TDO → 调试器 TDO。TCK 和 TMS 是并联到所有器件的。物理布线顺序和配置文件里的器件顺序必须严格一致。这一点听起来废话但我见过至少三次因为原理图改版时调换了器件位置、而测试配置文件没同步更新导致产线整批误判的案例。我的做法是在 PCB 上给每个器件丝印一个链序号比如JTAG-01、JTAG-02配置文件和丝印一一对应任何人改板子都能一眼看出来。链长也需要控制。TCK 到每个器件的走线长度差异会造成时钟偏斜偏斜太大会导致部分器件在错误的边沿采样。经验数据是整条链的 TCK 走线长度差控制在 5 cm 以内比较稳妥如果超过 10 cm就老老实实把 TCK 频率降到 1 MHz 以下。另外TCK 走线尽量走内层、参考完整地平面避免跨分割否则反射和串扰会让链路变得非常不稳。还有一个容易被忽略的点不要把链拉得太长。一条链上挂十几个器件累计 BSR 位数可能上万每次移位都要几千个 TCK测试时间会线性膨胀。合理的做法是拆成两到三条独立的链用多路复用器切换或者用多通道调试器并行跑。我做过一次对比把一个 12000 位的长链拆成三条 4000 位的短链并行测试单板测试时间从 8.2 秒降到 2.7 秒。3.2 测试点、上下拉与串联电阻的取舍虽然 IST 不像 ICT 那样需要大量测试点但电源轨的测试点还是要留的。原因很简单边界扫描管不到电源而电源异常是产线上最常见的故障之一。我会建议在每一路主要电源的输出端留一个直径 1.0 mm 以上的测试焊盘方便调试器和 FCT 工位测量。JTAG 信号线本身的上下拉配置是个典型的多一分浪费、少一分出事的问题TMS必须上拉典型 4.7 kΩ 到 10 kΩ。原因是 TMS 连续保持高电平 5 个 TCK 就会把 TAP 推入 Test-Logic-Reset 状态这是唯一可靠的强制归位手段。如果 TMS 悬空调试器没插的时候状态机可能在任意状态乱跳。TCK建议下拉。TCK 悬空时如果被干扰产生毛刺会把状态机推走。TDI建议上拉让它有个确定空闲电平。TDO不要上下拉它由器件驱动加了反而增加负载。TRST如果是低有效建议下拉到地但如果器件支持用 TMS 复位TRST 也可以不接。串联电阻方面我通常在 TCK 和 TMS 靠近源端的位置串 22 Ω 到 33 Ω 的电阻。这不是必须的但在链路较长或者有分支的板子上它能明显压住过冲和振铃把 TCK 的可用频率往上提一档。代价是会引入几纳秒的额外延时对大多数应用来说可以忽略。3.3 电源域、电平转换与链内外的坑这是 DfT 里最容易出事的地方。JTAG 信号有自己的参考电压VTref通常是 I/O 电源。如果一条链上既有 1.8V 域的器件又有 3.3V 域的器件直接串起来就是灾难——3.3V 器件的 TDO 打到 1.8V 器件的 TDI 上长期运行会损伤输入级。有三种处理方式我按推荐度排序第一种分链。1.8V 域一条链3.3V 域一条链用两路调试器或者多路复用器切换。最干净也最省事缺点是接口资源占用多。第二种加电平转换器。在跨域的两个器件之间插入双向电平转换芯片。注意转换器会引入额外延时而且 TDO 方向的转换必须支持足够高的速率否则 TCK 频率上不去。第三种统一电压域。设计时就让 JTAG 相关引脚全部使用同一个 I/O 电源从根上避免问题。这是最好的方案但需要硬件工程师在早期就配合。还有一个特别隐蔽的坑上电时其他器件正在驱动网络。比如一颗非扫描的 Flash 芯片上电后如果 CS 被拉低它会开始输出数据跟你的 EXTEST 驱动打架。轻则测试失败重则两个驱动器同时输出相反电平产生大电流长期下来可能损伤器件。我的处理原则是做 IST 时把所有非扫描器件都置于安全状态——能复位的就复位有输出使能的就关掉实在不行就在测试时用 CLAMP 把相关扫描引脚固定住让它们不参与活动。4. 从零搭一条 IST 流程环境、配置与实跑4.1 工具链选型与最小环境清单搭建 IST 需要的东西不多但每一样都得齐组件作用选型要点边界扫描控制器产生 TCK/TMS/TDI采集 TDO确认支持的最高 TCK 频率和链数向量生成软件解析网表BSDL生成测试向量覆盖率报告质量是核心BSDL 文件库每个扫描器件的描述文件必须与器件型号、封装、版本完全匹配板级网表描述网络连接关系从 CAD 导出注意格式兼容性治具/连接器把控制器接到板上接触可靠性是头号杀手这里我要重点说一下BSDL 文件。它是一份纯文本描述内容包括器件的引脚映射、扫描单元在引脚上的分布、寄存器长度、指令寄存器的操作码等。厂商官网一般都能下到但版本必须和实际用料一致。我遇到过一批板子主控芯片因为缺料换了个同系列但不同封装的型号BSDL 没换结果 IDCODE 能读出来因为 IDCODE 由厂家固定编码但互连测试全错——因为引脚映射变了。注意换料时如果封装或版本号后缀有变化务必确认 BSDL 是否同步更新。这个动作只需要五分钟但漏掉可能要花两天排查。4.2 网表 BSDL覆盖率是怎么算出来的覆盖率计算是 IST 项目里最需要动手写工具的部分。商业软件会给报告但你需要理解它是怎么算的才能在覆盖率不够时知道该往哪个方向补。基本逻辑是这样的遍历网表里的每一条网络检查这条网络连接了哪些引脚再遍历每个引脚的 BSDL 描述判断该引脚是否拥有边界扫描单元。如果一条网络上至少有一个可驱动的扫描引脚和一个可采样的扫描引脚这条网络就是可测的。我写过一个简化版的覆盖率统计脚本思路可以直接抄from dataclasses import dataclass, field dataclass class Net: name: str pins: list field(default_factorylist) # [(ref_des, pin_name), ...] dataclass class ScanPin: ref_des: str pin_name: str direction: str # in / out / bidir / none def load_bsdl_pins(bsdl_index: dict) - dict: bsdl_index: {ref_des: {pin_name: direction}} return bsdl_index def calc_coverage(nets: list, scan_pins: dict) - dict: total len(nets) covered, drivable, observable 0, 0, 0 uncovered_list [] for net in nets: has_drive, has_sense False, False for ref, pin in net.pins: info scan_pins.get(ref) if not info: continue direction info.get(pin, none) if direction in (out, bidir): has_drive True if direction in (in, bidir): has_sense True if has_drive and has_sense: covered 1 drivable 1 observable 1 else: uncovered_list.append(net.name) return { net_total: total, net_covered: covered, net_coverage: round(covered / total * 100, 2) if total else 0.0, uncovered: uncovered_list, } # 使用示意 scan_index { U1: {PA0: bidir, PA1: bidir, PB5: in}, U2: {A1: out, A2: out, B7: bidir}, } nets [ Net(NET_CLK, [(U1, PB5), (U2, A1)]), Net(NET_DATA, [(U1, PA0), (U2, B7)]), Net(NET_PWR, [(U1, VDD), (U2, VCC)]), ] report calc_coverage(nets, scan_index) print(f网络覆盖率: {report[net_coverage]}%) print(f未覆盖网络: {report[uncovered]})这段代码跑出来NET_PWR会被列进未覆盖清单因为电源引脚没有扫描单元。这就是你需要人工介入的地方——要么加测试点交给 ICT要么用其他手段覆盖。实际项目里网络覆盖率能做到 85% 到 92% 就比较理想了。剩下的部分主要是电源、地、模拟信号、以及那些只连了一个器件的悬空网络。如果覆盖率低于 75%我会回头检查三件事是不是有器件的 BSDL 没有正确加载是不是有些器件被误判为非扫描器件是不是网表导出的引脚命名和 BSDL 里的命名规则不一致比如P1.0和P1_0的差别。4.3 实跑调试向量加载、IDCODE 检测与故障定位第一次把调试器接到新板子上我一般按这个顺序来做第一步确认 VTref 和地。调试器必须能检测到目标板的参考电压如果这一步就报错说明板子根本没上电或者 JTAG 接口的地没接好。别急着怀疑链路先量电压。第二步读 IDCODE。把链里所有器件都按顺序配好执行 IDCODE 扫描。这一步的期望结果是每个位置读出的 32 位值与 BSDL 里声明的 IDCODE 一致。如果不一致有三个可能链序错了读出来的值整体错位、器件型号不对、或者某个器件的 TDO/TDI 断了。判断错位有个技巧把所有器件设成 BYPASS让链上只剩 1 位每器件然后移入一串1000...的图案观察从哪一位开始出现异常。异常位的位置基本就对应断点所在的器件。第三步跑互连测试。建议先用 Walking-1 模式小范围跑一遍只勾选几个关键网络确认判据逻辑正确。我通常先挑时钟线、复位线和数据总线这几类因为它们最容易出问题也最容易观察。第四步逐步全量 提速。确认逻辑正确后扩大到全网然后逐步提高 TCK 频率。我的做法是从 1 MHz 起步每次翻倍直到出现偶发失败然后退回上一档并留 30% 的裕量。举个例子如果在 8 MHz 开始偶发失败那么量产频率就定在 4 MHz 或者 5 MHz。第五步与产线整合。这一步要处理的不是技术问题而是节拍问题。IST 的测试时间必须和产线的单板节拍匹配如果 IST 需要 15 秒而产线节拍是 10 秒那就得考虑并行测试或者拆分工位。4.4 与 ICT/FCT 并站整合把 IST 和 ICT 放在同一个工位是很多产线的常规做法因为两者都需要治具合并能省一套夹具和一次上下板。整合时要注意几件事。首先是测试顺序一般先跑 ICT 的开短路速度快能快速筛掉明显坏的板子再跑 IST 的互连测试最后跑 ISP 和 FCT。如果前面某一项失败后面的就没必要跑这样能显著缩短平均测试时间。其次是电气隔离。ICT 的针床可能会在某些网络上施加电压或电流这些动作必须保证不会影响 JTAG 链的状态。我的做法是在 ICT 测试完成后主动执行一次 TAP 复位TMS 连续拉高 5 个 TCK再开始 IST避免状态机残留在奇怪的位置。最后是结果合并。两个工位的测试结果要合并成一条记录包含失败的网络名、失败的引脚、失败时的实际读数。这些数据是做良率分析的基础缺了就只能靠猜。5. 参数与时序TCK 该跑多快覆盖多少算够5.1 覆盖率口径与目标值设定覆盖率不是单一数字好几种口径会打架。我通常关注这四个网络覆盖率有扫描引脚参与的网络 / 总网络数引脚覆盖率有扫描单元的引脚 / 有电气连接的非电源引脚总数器件覆盖率能被完整覆盖的器件 / 总器件数可驱动-可采样对覆盖率同时存在驱动端和采样端的网络 / 总网络数其中最有意义的是最后一个。因为一条网络如果只有一个可驱动的引脚、没有采样端那它只能被推不能被看测了也不知道对不对。目标值我一般这样定数字互联部分的网络覆盖率要做到 90% 以上整体含电源、模拟覆盖率达到 70% 以上就算及格如果低于 60%说明这块板子的 DfT 设计有比较大的问题值得推动硬件改版。要特别提醒的是覆盖率报告要定期复核。我见过一个项目初版报告是 91%量产半年后换了一颗物料覆盖率掉到 84%但因为没人重新跑报告一直没发现。补充一句把覆盖率检查加进物料变更流程是个成本极低收益极高的动作。5.2 时序参数TCK 频率、稳定延时与去抖次数含计算时序参数里最重要的三个是 TCK 周期、Update 后的稳定延时、以及读采样的去抖次数。TCK 周期的下限由链上最慢的路径决定。粗略计算方式是TCK 从源端到达链上最后一个器件的走线延时加上该器件的 TDO 输出有效延时再加上信号回到调试器的走线延时这三者之和必须小于 TCK 周期。以常见的 FR-4 内层走线为例信号传播速度大约是 15 cm/ns即每厘米约 0.067 ns。假设链上最后一个器件距离调试器 25 cm路径延时约 1.7 ns器件 TDO 输出有效延时按数据手册取 8 ns回程走线 15 cm约 1.0 ns。总延时约 10.7 ns。理论上 TCK 周期只要大于 21.4 ns约 46 MHz就能工作。但这个理论值毫无意义因为实际瓶颈是时钟偏斜和信号完整性。TCK 到不同器件的走线长度差异导致的偏斜通常远大于上述延时。实用的做法是先按 5 cm 的偏斜上限估算。5 cm 走线差异对应约 0.33 ns 的偏斜这本身不算大但加上驱动能力差异、容性负载差异实际偏斜可能是理论值的 5 到 10 倍。所以我给出的工程经验是初始频率 1 MHz量产频率 2 到 5 MHz超过 10 MHz 需要专门做信号完整性仿真验证。稳定延时是 Update-DR 之后、Capture-DR 之前的等待时间。它的作用是让网络电平从驱动状态稳定到最终值。这个时间由网络的 RC 时间常数决定。假设网络上有个 10 kΩ 上拉走线加引脚电容合计 25 pF时间常数 τ 10 kΩ × 25 pF 250 ns。工程上取 5 倍 τ 即可认为稳定也就是 1.25 μs。所以稳定延时的公式可以写为T_settle ≥ 5 × R_pull × C_net如果网络上的负载电容比较大比如挂在总线上的十几个引脚总电容 100 pF那稳定时间就要拉到 5 μs。这个参数是可以配置的我一般先给一个保守值10 μs跑通之后再逐档往下调观察误判率有没有上升。去抖次数是指对同一条网络的采样做多次并取多数。在不增加硬件成本的前提下这是对抗偶发干扰最有效的手段。做三次采样取多数能显著降低单次干扰导致的误判。代价是测试时间增加因为每次采样都要走一轮完整的 Capture-Shift。我的经验是对于时钟、复位这类关键网络做三次采样其他网络做一次就够了。顺便算一下测试时间让大家有个量化的概念。假设链上累计 BSR 位数是 1200 位采用 Counting 模式需要 300 条向量单次移位时间 1200 bit / 5 MHz 240 μs 单条向量时间 ≈ 移位时间 指令开销 稳定延时 ≈ 240 μs 50 μs 3 μs ≈ 293 μs 总时间 300 条 × 293 μs ≈ 88 ms看起来很快对吧但别忘了还有 IDCODE 检测、链路初始化、ISP 编程、以及治具上下板的机械时间。实际的 IST 纯测试部分通常在 1 到 3 秒加上 ISP 编程可能要拉到 15 秒以上。5.3 误杀率与漏杀率的平衡产线上有个经典的矛盾阈值设严了误杀率上升好板子被判坏返修成本高阈值设松了漏杀率上升坏板子流到客户手里损失更大。降低误杀率的手段主要有三招第一招是增加重测次数。第一次判失败的网络不要立即判死而是针对这条网络重跑一次。很多误判是接触不良或者环境干扰导致的重测一次通常就能恢复正常。我的经验是重测能把误杀率降低一半以上。第二招是记录实际读数。判据不要只存通过/失败还要存下驱动值、期望值、实测值。当出现误判时有实际读数才能快速定位是驱动端的问题还是采样端的问题。第三招是统计分析。定期统计每条网络的失败率如果某条网络长期有 0.5% 的失败率而其他网络都是 0那大概率不是随机干扰而是这条网络本身存在设计或工艺上的薄弱点需要专项处理。降低漏杀率则要靠提高覆盖率和增加测试模式。Counting 模式虽然快但它的定位能力弱某些特定组合的短路可能漏检。我的做法是量产用 Counting 模式但每天首件用 Walking 模式跑一遍全量作为抽检手段。6. 常见故障与排查速查表6.1 链路类故障链路连不上是新手最常遇到的问题。我把遇到过的按概率排了个序。现象可能原因排查方法读不到 VTref板子没上电 / 地线断 / 接口反接万用表量电压和通断IDCODE 全 0TDO 未接通 / 器件无电示波器看 TDO 有无波形IDCODE 全 1TDI 被上拉 / 链断断开链尾器件再试IDCODE 部分正确链序错误 / 某器件 BSDL 版本不符逐器件 BYPASS 定位断点链路时通时断接触不良 / TCK 频率过高降频到 1 MHz 重试换板后必失败治具探针磨损 / 排线松动检查治具更换弹簧针排查链路的黄金法则是降频、减链、逐器件。先把 TCK 降到 1 MHz把所有器件设成 BYPASS 缩短链长然后一个一个往链上加器件每加一个读一次 IDCODE。这样能精确定位到是哪个环节出问题。6.2 判据类故障误判/漏判这类故障比链路故障更麻烦因为链路是通的报错信息却是某条网络开路但实际上网络是好的。我遇到过最典型的一次某条 SPI 数据线反复报开路重测有时通过有时失败。排查后发现这条网络挂在两个器件上一个在测试时被复位保持在高阻另一个是扫描器件。问题是复位的时机——复位信号释放后非扫描器件会有个短暂的输出窗口正好和 EXTEST 的采样窗口重叠产生冲突。解决方法是在 IST 期间把复位信号用 CLAMP 固定在有效电平让非扫描器件始终保持在复位状态。另一类误判来自上下拉电阻的缺失。前面说过开路检测依赖上下拉提供确定的默认电平。如果一条网络没有上下拉开路时采样端会浮空读到的值不确定就会产生随机误判。遇到这种网络我一般直接在报告里标注不可测让它由 ICT 覆盖。漏判则通常来自向量模式选择不当。Counting 模式对两条相邻网络同时短接到同一个第三网络这种情况不敏感因为它的模式组合有限。所以关键的总线网络我会要求用 Walking 模式单独跑一遍。6.3 治具与接触类故障治具问题的特点是症状随机、复现困难、批量出现。同一批板子前 20 块全过第 21 块开始连续报错换一个治具又好了。我的几个经验性做法弹簧针定期更换。按插拔次数而不是按时间更换一般 5 万次到 10 万次就该换了。这一点很多小厂会忽略针尖氧化后接触电阻上升链路还能连上但采样电平会漂。JTAG 接口单独做冗余接触。关键的 TCK、TMS 两根线治具上多布一根冗余针。这两根线一断整条链就全废了。记录每块板的失败网络。如果发现失败集中在某几个位置那大概率是治具问题而不是板子问题。这个判断能帮你省下大量误返修成本。接口排线不要太长。排线长度超过 30 cmTCK 上的反射就会明显起来尤其在频率较高时。能缩短就缩短。7. 一些没写进手册的经验做了这些年真正让我印象深刻的不是某个技术难点而是几个原来如此的时刻。第一个是关于测试覆盖率的心态。我刚入行时总追求把覆盖率做到接近 100%后来才明白剩下那 10% 拿去堆测试向量边际收益极低而同样的时间投在 ICT 和 AOI 上整体缺陷拦截率提升更明显。测试是个组合拳IST 再好也只是其中一拳。所以现在我做方案时先算整体缺陷拦截率再决定每道工序投多少资源而不是单看某一项的覆盖率数字。第二个是关于BSDL 文件管理。这东西看起来是个静态资源实际上会随着器件版本、封装变更而变。我现在的做法是建立一个内部仓库把所有在用的 BSDL 文件按型号-封装-版本命名归档每次物料变更都强制触发一次覆盖率重算结果记入变更评审记录。这个流程建立起来之后因 BSDL 不匹配导致的产线事故再没发生过。第三个是关于CLAMP 指令的使用。这个指令在标准里存在感很低但在实际调试中非常好用。它的作用是让某个引脚输出固定值同时不参与移位相当于把这些引脚从链上摘出去了。当你想缩短链长做快速定位或者想让某些输出保持稳定而其他部分继续测试时CLAMP 是最省事的手段。我见过很多工程师不知道有这个指令用 EXTEST 硬扛徒增调试复杂度。第四个是一个很小的技巧在板上留一个独立的 JTAG 头不要只靠治具的针去接触。原因在于首次调试、故障返修、以及产线的日常校验都需要一个稳定的连接手段。治具探针适合量产但做工程分析时插一个标准的排针更可靠。多花的那点板面空间在实际运维阶段能省下大量时间。最后一个体会是关于数据。IST 相比 ICT 有个天然优势它能记录每一根引脚的实测电平。这些数据如果只是通过/失败价值有限但如果全部留存下来就能做趋势分析。我们曾经靠这个数据发现了一批板子在某个温度区间下特定网络的电平会缓慢漂移追查下去是一颗器件的输入阈值批次差异。这个问题在常规的通过/失败判据下要等到批量失效才会暴露靠趋势数据提前了两周发现。所以我现在做方案一定会要求把原始电平数据落盘哪怕存储成本高一点也值得。