在产线上待过几年的人大概都遇到过这种场面一块单板在ICT针床上跑完全部测试项开路、短路、器件值全部pass报表干净得挑不出毛病可一装进整机、上电、跑业务就是不启动或者跑几分钟偶发死机。这时候你会发现前面那套测试其实只回答了一个问题——这块板上该连的地方连上了、不该连的地方没连上至于那些器件凑在一起能不能正常工作它一个字都没说。ISTIn-System Test在系统测试要补的就是这道缺口让板子自己带着处理器、内存、总线和外设在真实工作状态下把自己的各个子系统挨个点一遍名。这篇内容我会从IST到底测什么、有哪几种落地形态、怎么搭一套能长期维护的框架、实测里最容易踩的坑以及产线和售后怎么把它排进流程这几个角度把这件事讲透适合做硬件测试、单板调试和产线工艺的同行参考。1. IST到底在测什么ICT测全pass却整机不启动的那道缺口1.1 ICT的物理边界它只能证明焊住了、没短路ICTIn-Circuit Test的原理很朴素用针床或飞针把探针压到网络节点上量电阻、量电压、量电容判开短路。它擅长的是静态连接性焊点有没有虚焊、相邻引脚有没有桥连、器件有没有贴反或漏贴。代价是它需要探针能接触到每一个被测节点双面高密度板经常得做双面针床治具成本不低。它的局限同样来自这个原理。ICT基本上是在不给器件加真实工作条件的前提下测量的板子没跑起来处理器没取指DDR没训练时钟没起振。换句话说ICT测的是躯体解剖结构正常不是这个人能不能跑起来。一个典型的例子是去耦电容容量衰减、电源纹波偏大、时钟抖动超标这类问题ICT测不出来因为它们只在动态工作时才暴露。这就是IST存在的第一层理由。它不跟ICT抢活它接的是ICT交棒之后那段板子已经会自己动的阶段。1.2 IST的定义边界把整块板当成一个能自己开口说话的系统IST最本质的特征是测试逻辑运行在被测系统自身的资源上。被测板上的处理器执行测试固件或测试程序通过片内控制器去驱动、读取、比对它自己的各个子系统。测试的判据来自被测对象自身的反馈而不是外部仪器。这个定义划出了几条清晰的边界它需要板子至少能启动到一个可执行测试逻辑的状态哪怕是最小系统级别的启动它测试的是子系统功能和互连关系覆盖电源轨电压、时钟频率、存储器读写、总线枚举、外设通信回环等它可以不需要额外治具但通常需要一个通信通道串口、网口、USB、调试口把结果打出来。这里有个常被混淆的点IST和烧录后跑个闪灯程序看亮不亮不是一回事。闪灯只证明了处理器能从Flash取指、GPIO能翻转是把整条链路压缩成了一次二值判断。IST要做的是可定位、可量化、可重复的测试失败了能告诉你是DDR的某条地址线有问题而不是不亮。1.3 谁最需要IST三类典型场景第一类是研发阶段的单板调试。板子第一次打样回来电源、时钟、复位、启动这条链路上的问题最多。用IST思路做一个最小自检固件能在没有完整业务软件的情况下快速定位是硬件问题还是软件问题省下大量扯皮时间。第二类是产线终检FCT之前的板级验证。ICT过了之后加一道IST把动态功能和互连关系补上能拦下一批ICT放行但实际有隐患的板子比如内存颗粒批次差异导致的时序临界、网络变压器轻微不良。第三类是售后返修与现场诊断。客户返回的板子先跑一遍IST自检能快速区分确实硬件坏了和客户使用环境问题返修效率提升非常明显。提示IST不是要取代ICT或FCT它是嵌在两者中间的一层。把它当成板子自己会做的体检就对了。2. IST的三种落地形态与选型逻辑2.1 固件主导的处理器自检这是最通用、也最接近IST本意的形态。核心思路是让处理器跑一段专门的测试程序按顺序初始化并验证各子系统。落地位置通常有三种BootROM或启动加载器内置自检命令。很多芯片在启动早期就提供了内存初始化、时钟校验的钩子可以直接扩展成一组自检命令。优点是启动链路最短能在业务系统起来之前就发现问题。独立的测试固件镜像。产线烧一个专用测试镜像跑完自检再烧正式固件。好处是测试逻辑和业务逻辑完全隔离不会互相干扰测试项可以写得很激进比如反复擦写Flash。业务系统内的诊断模块。把自检做成一组可通过调试命令触发的子程序售后现场直接调用校准和诊断不用重新烧录。选哪种取决于你的场景。研发调试用第二种最干净因为你不希望测试代码和半成品业务代码纠缠在一起。产线终检可以考虑第一种加快速通道减少烧录次数。售后我更推荐第三种现场不可能让客户配合烧镜像。固件自检的技术含量主要在测试项的覆盖和互不干扰上。电源轨要在上电后按顺序量、时钟要在PLL锁定后再测、DDR要等训练完成后再跑pattern。顺序错了测出来的全是假失败。2.2 边界扫描IEEE 1149.1驱动的互连测试边界扫描是IST里非常特殊的一支。它通过芯片上每个引脚内置的边界扫描单元把引脚的电平串成一条移位链从而在不加探针的情况下检测引脚之间的互连。BGA封装、细间距器件、板子背面没法下探针的场合边界扫描几乎是唯一选择。它的典型用法是互连测试Interconnect Test在发送端芯片的引脚上驱动一个电平在接收端芯片的引脚上读回来比对是否符合预期。只要两个芯片都支持边界扫描并且它们之间的网络连通就能判定这条互连是好的。但有三个现实约束得提前想清楚链路上每个器件都要支持且被正确串联。如果中间有一块不支持边界扫描的芯片或者扫描链被PCB走线打断整条链就废了。需要生成测试向量。互连测试不是插上就能跑的要根据网表生成激励向量这块通常依赖EDA工具或专门的边界扫描软件。向量质量直接决定覆盖率。有些网络测不到。比如只连到无源器件的网络、上拉电阻主导的网络、多驱动冲突的网络边界扫描覆盖不了这部分还得靠ICT兜底。2.3 治具辅助的半自动IST还有一种介于ICT和纯IST之间的形态板子仍然跑自检固件但结果和激励通过外部治具配合。比如用治具给板子提供标准电源、模拟负载、对接环回插头、控制环境的温箱让IST在可控条件下跑。这种形态在需要一致性的产线场景最有用。板子自己测自己读数会受板子上电源质量影响用外部标准源供电能把板子问题和电源问题分开。温度也一样消费级产品常温跑车规或工业级产品需要在高温和低温下都跑一遍自检看参数是否还在窗口内。选型上我一般的判断是研发验证选固件自检高密度板互连补边界扫描产线和可靠性验证上治具辅助。三者不冲突组合用效果最好。2.4 三种形态的对比与组合策略维度固件自检边界扫描治具辅助IST是否需要探针不需要不需要部分需要覆盖重点功能与子系统引脚级互连功能加环境一致性对器件要求处理器可启动器件支持1149.1同固件自检加外部源定位精度中能到子系统高能到引脚中高产线节拍快中慢典型场景研发、售后高密度板互连可靠性、量产终检实际项目中比较常见的组合是ICT先做静态连接检查边界扫描补高密度互连最后固件自检做动态功能验证产线抽检或可靠性验证时再加治具辅助。分工清楚才不会重复投入。3. 搭一套能长期维护的IST框架分层与描述表设计3.1 按资源分层电源轨、时钟、存储、总线、外设一个能维护的自检框架最忌讳把所有测试项写成一坨顺序代码。我的做法是按资源类型分层每层有独立的初始化、测试、清理逻辑。电源层读取各电源轨的ADC采样值判断是否在窗口内对可调电源做上下限测试。时钟层测量主时钟和派生时钟频率判断PLL是否锁定、偏差是否在容差内。存储层对DDR、SRAM、Flash分别做不同强度的pattern测试DDR用地址线行走、数据线行走、全空间读写Flash做擦除写入校验。总线层用I2C、SPI、CAN等总线枚举挂载的设备比对ID和预期一致。外设层网口做内部环回、USB做枚举、串口做自发自收、传感器读一次原始值看是否在物理合理范围。分层的价值在于失败可归因。电源层先过说明供电基础没问题后面如果存储挂了排查方向就很明确。如果混在一起一个失败你根本不知道从哪查起。每一层内部还要注意依赖顺序。时钟没起振就跑不了总线总线没起来就枚举不到外设所以层与层之间是有严格先后的这个顺序要在框架里固化不能靠人记。3.2 测试描述表让加一条用例不用改代码框架能不能活下去取决于加测试项的门槛。如果每加一条用例都要改C代码、重新编译、重新验证框架本身那这套东西两三个月就没人维护了。我的经验是引入一张测试描述表可以是编译进固件的结构体数组也可以是外部配置文件。每条记录描述一个测试项测试ID、所属层、依赖的前置项、执行函数指针、参数地址范围、期望值、容差、失败级别致命/警告/信息。这样加一条用例大多数时候只是加一行数据复用的执行函数直接从参数取值。比如内存测试函数是通用的参数里给地址段和pattern类型就够了。描述表还带来两个额外好处一是可以按需裁剪产线只跑致命项售后跑全部项同一套固件不同配置二是报告格式统一每条记录都有ID输出直接对齐。注意描述表别设计得过度灵活搞成一个小型脚本引擎就本末倒置了。参数够用就行逻辑复杂的测试项老老实实写函数。3.3 判定阈值和结果上报怎么定阈值是IST最容易埋雷的地方。定太松缺陷漏出去了定太紧良品被误杀产线天天吵架。我的原则是阈值来自数据不来自想象。具体做法先拿一批已知良好的板子跑收集每个测试项的实测分布取分布的合理分位比如均值加减若干倍标准差或直接取实测范围再留余量作为初始阈值再拿一批已知有缺陷的板子验证看能不能拦住。这样定出来的阈值有依据说服力强。结果上报要把三件事说清楚原始值、判定结果、上下文。原始值让你事后复核阈值是否合理判定结果让产线直接判上下文固件版本、板号、温度、电压让你在复盘偶发问题时能还原现场。只报一个pass/fail的IST用起来会很痛苦。上报通道按场景选研发用串口产线用网口或专用协议对接MES售后用本地存储加按键触发。别指望一个通道通吃。4. 实测踩坑IST误判与漏判的几个真实来源4.1 上电时序没对齐电源测试先失败我第一次把电源测试塞进自检框架时遇到一批电源轨电压偏低的失败。查了半天硬件没问题最后发现是测试执行太早某个LDO的软启动还没完成ADC采到的是斜坡中间的值。这类问题的根因是测试逻辑没有等待系统进入稳态。修法有两种一是在测试项里加明确的等待条件比如轮询某个电源好信号或等待固定稳定时间二是把电源测试放到整个自检流程的后段等其他子系统都初始化完了再回头量。我更倾向第一种因为它把依赖关系显式写出来了不依赖执行顺序的巧合。但要注意等待不能是死等得加超时否则一旦电源真的坏了自检会卡死在那里反而掩盖了问题。4.2 复用引脚与上下拉冲突引脚复用是IST的经典坑。一个引脚在启动阶段是调试口切到应用模式后变成GPIO或某个外设信号。如果你在自检里按一种模式配置了引脚又去测另一种模式下的功能结果必然对不上。更隐蔽的是上下拉冲突。板子上有个外部上拉芯片内部也开了一个下拉静态看起来是高电平但驱动能力互相拉扯动态测试时波形边缘变缓边界扫描或回环测试就可能误判。这种问题ICT测不出来因为ICT量的是静态电阻/电压看不到驱动冲突。处理办法是在测试描述里明确每个测试项对引脚模式的前置要求框架在执行前统一配置。加一条测试项时同时声明它需要哪些引脚处在什么模式而不是假设当前状态是对的。4.3 DDR与Flash测试里的数据残留和cache陷阱存储测试有两个高频坑。第一个是数据残留。Flash擦除不彻底或之前写过测试数据直接读出来和期望值比对就可能通过或失败得莫名其妙。正确做法是测试前先明确擦除或写入一个已知模式再验证。第二个是cache一致性。处理器写了一段数据到内存cache里是新的物理内存还是旧的或者反过来读的时候走了cache拿到了旧值测试就误判。做内存测试时通常要把被测区域配置成非cache或写完显式清理cache再读具体看芯片的cache管理方式。这块不处理干净测试结果完全不可信而且表现为偶发失败最难查。DDR本身还有训练问题。上电后DDR控制器要做一次读写训练找到合适的时序参数训练没完成就跑pattern失败率极高。自检流程里DDR测试必须排在训练完成之后这个依赖要写死。4.4 温漂和电压边界下的偶发通过IST最麻烦的一类问题是边界条件。常温常压跑一百遍都过一到高温或低压就偶发失败。这类问题往往不是功能坏了是时序余量不够。比如某个接口在高温下建立时间变短或者低压下驱动能力下降刚好卡在临界点上。要抓这类问题IST的测试强度得够。我的做法是在可靠性验证阶段扫边界把温度拉到规格上下限把电压拉到容差边界在这个组合下跑自检看有没有项变红。这比在常温下跑一万遍有用得多。还有一种是测试本身引入的干扰。自检程序跑得满负荷处理器功耗上去板上电源纹波变大反过来影响被测信号。这时候要区分是被测对象有问题还是测试方法有问题常见的验证手段是降低测试强度或错峰执行看问题是否消失。5. 产线与售后怎么排布IST5.1 ICT、FCT、IST的分工与顺序这三者的顺序不是随便排的遵循一个原则从静态到动态从便宜到贵从快到慢。环节测试内容耗时量级治具成本ICT静态开短路、器件值秒级高针床IST动态功能、互连、子系统十秒到分钟级低到中FCT整机功能、接口、性能分钟级中到高典型排布是ICT先做把焊接缺陷拦掉避免带着硬伤往下走然后IST做板级动态验证确认这块板本身是活的最后FCT整机验证。这样每一道都能定位到自己的责任范围返修归属清晰。如果IST放在ICT前面一块虚焊的板子跑自检会得到一堆难以解读的失败反而干扰判断。5.2 覆盖率与时间成本的平衡产线最关心节拍。IST全套跑下来可能要几分钟这在量产线上是不可接受的。解决办法是分层执行产线终检只跑致命项子集把最容易出问题、最能反映板级健康的项挑出来控制在几十秒内那些慢的、深入的项放到抽检或可靠性验证里。致命项怎么挑按两个维度排优先级失效概率和失效后果。失效概率高的比如连接器、内存、电源必跑失效后果严重的比如安全相关信号必跑剩下的按时间预算补。这里有个反直觉的点不是覆盖项越多越好。项多了单板测试时间上去了产线会想办法跳过或放水实际效果反而差。选对关键项、保证它们真的被执行比堆一长串没人看的项更有价值。5.3 返修与现场诊断中的二次利用IST在售后场景的价值经常被低估。客户返回的板子第一件事跑一遍自检能快速分类自检全过大概率是使用环境或外围问题自检某项红直接锁定返修方向维修人员不用从头查。更进一步把IST结果和维修记录关联起来时间长了能看出哪一类失效最集中反向推动设计改进。比如某个电源轨的测试项在返修板上出现频率明显偏高那可能是这条轨的余量设计偏紧值得复查。现场诊断时IST最好能脱机跑、结果能掉电保留或通过最简单的方式读出。让现场工程师装一堆上位机软件是不现实的能在串口上打印关键几行结果就够了。我自己做这套东西最大的体会是框架的价值在于能活不在于能测。见过太多自检程序写的时候功能很全半年后没人敢改因为一改就崩、一崩就要重新调一整套环境。让加测试项变成加一行数据、让阈值有数据支撑、让失败可归因这三件事做到位这套东西才能一直用下去。另外分享一个小技巧自检固件里留一个单项执行的调试入口能单独调用任意一条测试项并按ID运行排查问题时省的时间难以估算我当时就是靠它把一批偶发失败定位到DDR训练的边界条件上。
