1. 系统控制器制造测试到底在测什么先搞清楚边界制造业里有一句话流传很久设计验证测的是产品能不能用制造测试测的是这批货能不能交。System Controller系统控制器这类产品尤其典型。它不像一颗简单的电源芯片测几组电压电流就能判断好坏也不像纯模拟板卡扫一遍频率响应就基本放心。系统控制器通常集成了处理器、内存、各种总线接口、电源管理单元、监控逻辑甚至运行着精简的实时固件。你面对的不只是一块电路板而是一个裸机状态下就得证明自己健康的微型系统。我在产线调试阶段踩过不少坑最深刻的一条是制造测试的方案设计往往在项目立项时就应该启动而不是等硬件从贴片厂回来再想。因为测试策略决定了治具怎么设计、测试程序怎么写、测试工位放几台、产出节拍怎么定这一连串东西全都牵一发动全身。这篇先讲整体框架也就是Part 1的内容制造测试的分层逻辑、核心测试项的设计思路、以及搭建测试工装时必须想清楚的那些事。后续Part 2再深入具体的软件框架、日志解析、数据回传和良率分析。在展开之前先给还没接触过制造测试的读者划个范围。System Controller的制造测试目标不是验证设计是否正确而是验证制造是否成功。举个例子CPU内核的逻辑功能早在芯片设计阶段就验证过千万遍产线上根本不需要也不应该去跑复杂的Benchmark但CPU供电的DC-DC电感有没有焊好、滤波电容有没有贴反、晶振起振是否稳定这些才是制造测试真正关心的。这听起来简单实际做起来牵扯的东西非常多。2. 测试层级一个都不能乱从晶圆到整机系统控制器卡在哪一层2.1 制造测试的经典金字塔模型半导体和电子制造行业有一套通用的测试层级划分系统控制器的测试设计一定要先搞清楚自己站在金字塔的哪一级否则很容易出现抢了上一级的活却没有覆盖住本级该管的事这种尴尬局面测试层级执行阶段主要覆盖缺陷典型设备/方法晶圆级测试CP晶圆加工完成芯片本身制造缺陷探针台、测试机封装级测试FT封装完成后封装、键合、打线缺陷分选机、测试机板级测试PCBA测试SMT贴片完成后焊接缺陷、错料、极性、开路短路ICT、飞针、AOI系统级测试System Test整机装配/模块组装后接口互连、固件加载、系统交互、环境适应功能测试台、老化台System Controller通常以板卡或模块形态交付它的测试落在板级测试和系统级测试这两层之间。注意这一层恰恰是最容易混乱的。板级测试的黄金法则是尽早发现、尽早修复。一块刚贴片完成的PCBA如果能在ICT阶段把焊接问题抓出来维修成本就是返修一个焊点的事如果漏到系统级测试发现内存通道不稳定那就要面临拆屏蔽罩、热风枪吹芯片、甚至报废整板的风险。所以测试层级之间的覆盖策略本质是成本和效率的博弈。2.2 System Controller的特殊性它是一个带固件的复杂节点和普通数字板卡相比System Controller在测试设计上有个很大的不同——它自带固件而且固件本身会成为测试的一部分。我见过的系统控制器大多承担着监控、管理、调度类职责。比如服务器里的管理控制器负责采集温度、电压、风扇转速还要提供远程管理接口工业设备里的主控板负责逻辑控制、通信协议处理和IO扩展。这类板卡的共同特征是不上电跑固件很多硬件故障根本测不出来。比如一颗LDO低压差线性稳压器的输出电压精度静态测量可能完全正常但当处理器满负荷运行、瞬时电流拉高时LDO可能因为相位裕度不足而产生振荡这时候用万用表量平均电压根本发现不了得靠示波器配合负载跳变才能抓到。这就是为什么系统控制器的测试往往需要动态跑起来而不是单纯地静态量一通。但跑起来也会带来新的麻烦如果固件本身就是坏的、或者烧录版本不对硬件测试项再完美板子依然无法交付。所以系统控制器的制造测试必须在测硬件和测固件加载之间找到一套合理的并行策略。最常见的做法是把固件烧录作为一个独立测试站先烧录、再运行硬件自检程序最后进入系统功能测试。这个流程顺序几乎没有讨论余地烧录和测试混在一个工位只会拖慢节拍。2.3 测试覆盖率的取舍原则工程上有个现实问题测试项不是越多越好。每增加一个测试项就意味着增加测试时间、增加治具复杂度、增加误报率。理想状态下测试覆盖率是100%但现实中你要在覆盖率和成本之间做取舍。我的经验分三个优先梯队第一梯队必测项电源是否短路、各电压轨是否正常、时钟是否起振、复位时序是否正确、JTAG/SWD链路是否畅通。这些如果不测后续任何测试都无法进行。第二梯队重点项DDR读写、Flash读写、关键通信接口I2C、SPI、UART回环、GPIO读写、ADC采集精度。这些是系统控制器的主干功能直接影响产品能否交付。第三梯队抽测/出厂项极端温度下的老化测试、长时间稳定性跑机、EMI预扫。这部分通常不是全检而是按照比例抽检或首批全检具体看客户要求和产品等级。有人可能会问程序烧录之后的CRC校验算不算测试项当然算而且应该放在第一梯队。固件烧录错误是最低级的错误但也是最常见的漏网之鱼一旦漏出去客户上电发现设备完全无法启动这是最拉低信任感的事故。3. 治具与硬件设计测试方案的物理基础3.1 四种治具结构怎么选测试治具是制造测试方案的物理载体治具设计不合理后面全盘皆输。系统控制器板卡形态差异很大从一张信用卡大小的核心板到半张A4纸大小的主板都有治具方案必须跟着产品走。我梳理一下常用的四类结构标准针床治具通过探针直接接触PCBA上的测试点适合板面规则、测试点设计规范的批量板卡。优点是测试稳定、误报率低缺点是对PCBA的测试点设计要求高治具造价不菲改版一次就是一笔成本。飞针测试机用机械臂带动探针逐点移动测试适合小批量多品种、测试点没来得及预留给针床的情况。优点是柔性好不需要专用治具缺点是速度慢只适合抽测或小批量不适合高速产线。边界扫描加功能接口通过JTAG链路和板卡对外接口完成信号注入与采集不需要接触内部测试点。这是System Controller特别合适的方案因为板卡通常带有标准调试接口边扫覆盖率足够覆盖大部分互连问题。自动化功能测试台模拟系统控制器的实际工作环境接入外部负载、通信对手端设备通过真实数据交互来验证功能。这是最接近用户使用场景的测试也是治具成本最高的方案。我的建议是量产项目要以ICT 或 边界扫描 功能测试组合为主针床和功能测试台结合既能保证焊装缺陷的高效拦截又能覆盖系统级功能。飞针和纯手工测量只适合工程验证阶段。3.2 探针选型与测试点设计经验关于治具探针有三条经验值得写出来。第一条探针不是越尖越好。很多人觉得针尖细接触更精确但太尖的探针穿透氧化层能力差而且容易在测试点上留下压痕。对于一般焊盘类测试点建议用三点尖或者皇冠头探针接触稳定寿命也够长。第二条测试点的间距和位置要在PCB布局阶段就给制造测试预留。很多硬件工程师画板时没考虑测试探针空间结果做治具时发现测试点被高元件遮挡只能放弃非常可惜。我的建议是测试点最好放在板边5mm以内直径做到1.0mm以上间距保持2.54mm的标准网格方便治具孔位加工。表面处理尽量选沉金或OSP不要选裸铜裸铜长期存放氧化严重探针接触不良的误报率会明显上升。第三条电源测试点必须加宽。如果是测量大电流通路的电压降单靠一个标准测试点接触会产生接触电阻误差建议采用开尔文四线测量方式。治具上用两根探针一根给激励电流一根测电压消除接触电阻的影响。3.3 电源控制和上电时序的考虑治具硬件里最容易忽略的部分是电源控制和上电时序。System Controller板卡上通常不止一路电源处理器核心供电、IO供电、内存供电、备份电池供电各路上电时序在规格书里都有严格要求。测试治具不能简单粗暴地一上电就把所有电压轨直接拉起来——处理器和内存的时序不满足要求轻则启动失败重则损坏芯片。实际工程中测试治具要给PCBA提供干净、可控制的电源同时在治具里实现时序逻辑。一种做法是用多通道可编程电源通过软件控制上电顺序并在每路输出加延时另一种做法是在治具板上做一个简易的时序控制电路用CPLD或者逻辑门实现硬时序。对于量产测试来说我更倾向于硬件时序控制因为它不依赖上位机的实时性上电瞬间的安全更有保障。还有一个小细节治具上的电源线不能太细。系统控制器虽然功耗不算大但处理器瞬间抓取电流可能达到好几安培如果电源线太细线路压降会导致板端电压跌落造成误判电源故障。治具内部尽量用粗短线连接并在板端放置足够的去耦电容。4. 核心测试项详解我建议从短路到功能分层推进4.1 短路/开路测试最基础也最关键的一关短路测试通常放在整个测试流程的最前头为什么因为如果板子上有电源对地短路贸然上电轻则保险丝烧断重则把处理器或者昂贵的电源模块直接打坏。做法是在PCBA上电前用测试治具对所有电源轨测量对地阻抗。常见的BMC类控制器核心电源轨对地阻抗一般在几欧姆到几十欧姆之间因为有大量去耦电容并联IO电源轨在几百欧姆如果是纯粹的电源输入端口应该在千欧级甚至更高。当然具体数值取决于电路设计要以设计工程师给出的范围为准。这里要特别提醒一句不要用是否为零来判断短路。因为大容量去耦电容在测量瞬间表现为低阻抗让万用表看到几乎短路的假象。正确的方法是给测试点施加一个恒定的低电压比如100mV测量实际流过的电流然后换算成等效电阻与规格值比较。这样能从容地评估阻抗又不会触发板上的半导体器件导通。还有一个容易被忽略的点短路测试要区分电源轨之间的钳位二极管影响。有些系统控制器会在不同电源轨之间放TVS管或钳位二极管二极管在反向偏置时测得的阻抗会随测量电压变化。所以短路测试的激励电压必须足够低100mV级别确保半导体器件完全不导通测到的才是纯电阻特性。4.2 电压与时钟验证别只看精度还要看稳定性上电之后第一个动作通常是检查各路电源电压是否在规格范围内。但这个测试的精度要求往往没有大家想的那么高万用表四位半就已经绰绰有余因为电源模块的输出精度本身就有2%~5%的容差。真正关键的是时钟信号的验证。系统控制器通常需要外部晶振或晶振模块提供参考时钟时钟不起振、频率偏了、或者波形幅度异常都会导致处理器无法运行甚至固件跑飞。量时钟有两种方式。一种是频域方式用频率计直接测频率值效率高但看不到波形质量另一种是时域方式用示波器看波形的上升沿、过冲和幅度。量产测试建议以频率计为主配合示波器抽测。原因是示波器量时钟的效率太低探头加载还会影响高速钟的波形容易产生误判。只有在设计方案变更或批量故障排查时才需要专门用示波器仔细分析时钟质量。4.3 边界扫描系统控制器最值得投资的测试手段边界扫描Boundary Scan符合IEEE 1149.1标准是利用芯片内部的分立扫描单元来测试引脚互连的一种方法。对于System Controller这种BGA封装密集、测试点开挖困难的板卡边界扫描几乎是效率最高的互连测试方案。它的原理不复杂芯片的每个引脚都串联了一个移位寄存器单元测试时通过JTAG接口把一串测试向量移入芯片让引脚输出已知的电平然后在相邻芯片的引脚上捕获响应再把结果移出来对比。通过这种方式可以精确判断板上的走线是否存在开路、桥连或对电源短路。实际使用中边界扫描还有两个进阶功能。第一个是串行向量功能SVF通过JTAG接口向板上的CPLD/FPGA下载配置或者向Flash写入测试数据不需要专门的烧录器这在产线上能省不少设备成本。第二个是内置自检配合BIST比如内存的March算法测试就属于这类。如果系统控制器的处理器支持DDR控制器BIST通过JTAG触发BIST运行然后读取结果就能在不上电跑完整Linux系统的情况下验证DDR通道的物理链路。这个功能对内存虚焊、数据线短路的筛查效果非常好。当然边界扫描也有测不到的地方它只能测到扫描链覆盖的信号如果某个引脚没有接入扫描单元或者某个器件不支持1149.1协议这部分互连就测不了。这就是为什么边界扫描通常和后面的功能测试配合使用各管一段。4.4 功能测试从接口回环到协议握手功能测试的目标是证明数据能从这个接口出去绕一圈回来还是对的。对System Controller来说最常用的功能测试手段是回环测试。比如UART接口把TX和RX短接通过治具上的跳线或继电器切换向串口发送一组已知数据接收端若收到相同数据则链路基本没问题。类似的还有I2C、SPI、CAN、Ethernet等。但这里有个细节回环测试要区分芯片级回环和板级回环。有些控制器的外设支持内部回环模式即在芯片内部将发送数据直接传回接收路径这种模式测不出PCB走线问题。所以制造测试必须使用板级外置回环在连接器端把发送和接收短接起来这样信号经过PCB走线、连接器和治具线缆才能真正验证整个物理链路。功能测试阶段还经常需要模拟对端设备。比如系统控制器通过I2C总线去读取一个温度传感器测试时治具上要接一个模拟的传感器设备或者用一块带有I2C从机逻辑的小板子来响应控制器的读取请求。对于复杂的工业协议如Modbus、CANopen直接用真实的对手端设备是最靠谱的用虚拟软件模拟往往会在后续联调时暴露问题。4.5 老化与可靠性测试是否全检取决于产品定位老化测试Burn-in Test在System Controller制造测试中占多大比重很大程度上取决于产品用在哪里。消费类产品通常只做抽检或者干脆只做常温短时功能测试工业级产品大多要求全检至少做高温环境下数小时的老化车规级或高可靠应用则可能要求温度循环加电压拉偏的强应力筛选。老化测试不做全检的原因很简单时间成本太高。一块板子老化工位占好几个小时等于把整个产线的节拍拉长到不可思议的程度。所以工程上的折中方案是分站老化板卡在生产线上先把所有功能测试做完再进老化房批量处理最后做一次快速复测确认老化过程中没有出现劣化。另一个值得注意的点是老化测试方案不是简单地给板子通电放那摆着。合理的做法是在老化过程中让板子持续运行自检程序把错误日志记录下来。如果板子只通电但不工作很多间歇性故障是无法暴露的。自检负载越接近实际应用场景老化的筛选效果越好。5. 测试软件与数据采集产线可追溯性的关键5.1 测试执行框架的选择逻辑测试软件的架构决定了产线调试和后续维护时你的痛苦程度。我在项目里见过两种典型的测试程序风格一种是大一统的流水账式脚本从头到尾执行几百个测试步骤任何一步失败就停止另一种是模块化的测试框架每个功能独立成一个测试项有独立的ID、独立的判定标准可以单独执行也可以批量跑。量产测试强烈建议后者。理由不用多说产线上最常干的事就是某个测试项老误报想单独跑一百遍看看稳定不稳定如果你用的是流水账式脚本每次都要从头跑到尾光等待时间就让人崩溃。测试程序语言方面一种是直接用LabVIEW这类图形化平台优点是仪器驱动生态好适合快速搭建另一种是用Python配合pyvisa、pyserial这类库做软硬件交互优点是代码维护方便和MES系统对接简单。近几年我越来越多地看到Python方案原因大概是团队里会写代码的人越来越多而Python在数据处理和报表生成方面的优势太明显了。测试程序一定要把日志当成一等公民对待。每个测试项开始和结束都要有时间戳每一条测量值、每一个判定结果要写入结构化日志。别怕日志太多占空间一个稳健的产线每天产生的日志量也就是几个GB级别任何存储系统都能扛住但一旦出现批量性问题没有日志你就只能对着故障板发愁。5.2 判定标准的制定规格边界要留生产余量测试软件里最重要的一条逻辑不是怎么测而是测完拿什么标准判断。电性能参数通常有一个设计规格范围Datasheet规格但产线判定标准不能直接照抄规格值。因为仪器有测量误差、治具接触电阻有波动、环境温度还会有影响如果你把合格线定在规格的绝对边界上必然会出现一批在规格内但实际已经处于边缘的产品这批产品流到用户手里在恶劣环境下很可能出问题。正确做法是设定生产判定限一般比规格范围收窄20%~30%。比如某路电源规格是3.3V±5%3.135V~3.465V产线判定范围就设在3.2V~3.4V。超过3.4V但没有超过3.465V的产品不算不合格但要单独标记可能是元件批次偏移的早期信号。另外测试系统还要考虑测量不确定度。如果你用的万用表精度为±0.5%测试线缆还会引入额外误差这时候生产判定限如果不做补偿测试系统本身的误差就吃掉了生产余量。专业点做法是定期用校准过的标准源或标准板做仪器的量值溯源把整个测试系统的测量偏差标定出来再体现在判定软件里。5.3 测试数据回传MES从单板合格到批次受控现代制造测试的终点不是产线上亮绿灯而是数据安全地进入MES系统制造执行系统。没有数据回传的测试等于白测——因为你无法跟踪每块板的测试历史也无法做批次级别的趋势分析。数据回传有两个层面。第一层面是结果数据每块板的序列号、每个测试项的测量值、判定结果、测试时间、操作员信息、测试工位编号。这些数据用于追溯单板质量处理客户投诉时能快速定位是哪一批次、哪块板的哪个环节出了问题。第二层面是原始数据特别是射频类、高速信号类的波形或眼图数据这部分数据量大通常不会全量上送MES而是按需保存本地定期归档。别看原始数据平时用不上一旦客户反馈偶发异常这些数据可能就是唯一能还原故障现场的东西。MES对接的接口形式各异企业里最常见的还是数据库直写或者HTTP API上报。在测试软件里要处理好离线缓存的情况——万一网络闪断测试数据不能丢本地要做好排队重发机制。这个细节听起来简单但我在产线现场见过不少因为断网导致数据漏记的案例最后客户追溯时完全对不上账非常麻烦。6. 量产爬坡阶段的典型问题从试产到稳定量产的调试经验6.1 误报率高先排查测试系统本身别急着怪产品试产阶段最让人头疼的问题就是昨天测十块板全过今天测十块板挂了五块也就是误报率高。遇到这种情况我的排查顺序基本固定先看治具接触再看测试软件配置然后是探针和线缆状态最后才怀疑产品本身有变化。治具接触问题占据
系统控制器制造测试实战：分层策略、治具设计与测试项详解
1. 系统控制器制造测试到底在测什么先搞清楚边界制造业里有一句话流传很久设计验证测的是产品能不能用制造测试测的是这批货能不能交。System Controller系统控制器这类产品尤其典型。它不像一颗简单的电源芯片测几组电压电流就能判断好坏也不像纯模拟板卡扫一遍频率响应就基本放心。系统控制器通常集成了处理器、内存、各种总线接口、电源管理单元、监控逻辑甚至运行着精简的实时固件。你面对的不只是一块电路板而是一个裸机状态下就得证明自己健康的微型系统。我在产线调试阶段踩过不少坑最深刻的一条是制造测试的方案设计往往在项目立项时就应该启动而不是等硬件从贴片厂回来再想。因为测试策略决定了治具怎么设计、测试程序怎么写、测试工位放几台、产出节拍怎么定这一连串东西全都牵一发动全身。这篇先讲整体框架也就是Part 1的内容制造测试的分层逻辑、核心测试项的设计思路、以及搭建测试工装时必须想清楚的那些事。后续Part 2再深入具体的软件框架、日志解析、数据回传和良率分析。在展开之前先给还没接触过制造测试的读者划个范围。System Controller的制造测试目标不是验证设计是否正确而是验证制造是否成功。举个例子CPU内核的逻辑功能早在芯片设计阶段就验证过千万遍产线上根本不需要也不应该去跑复杂的Benchmark但CPU供电的DC-DC电感有没有焊好、滤波电容有没有贴反、晶振起振是否稳定这些才是制造测试真正关心的。这听起来简单实际做起来牵扯的东西非常多。2. 测试层级一个都不能乱从晶圆到整机系统控制器卡在哪一层2.1 制造测试的经典金字塔模型半导体和电子制造行业有一套通用的测试层级划分系统控制器的测试设计一定要先搞清楚自己站在金字塔的哪一级否则很容易出现抢了上一级的活却没有覆盖住本级该管的事这种尴尬局面测试层级执行阶段主要覆盖缺陷典型设备/方法晶圆级测试CP晶圆加工完成芯片本身制造缺陷探针台、测试机封装级测试FT封装完成后封装、键合、打线缺陷分选机、测试机板级测试PCBA测试SMT贴片完成后焊接缺陷、错料、极性、开路短路ICT、飞针、AOI系统级测试System Test整机装配/模块组装后接口互连、固件加载、系统交互、环境适应功能测试台、老化台System Controller通常以板卡或模块形态交付它的测试落在板级测试和系统级测试这两层之间。注意这一层恰恰是最容易混乱的。板级测试的黄金法则是尽早发现、尽早修复。一块刚贴片完成的PCBA如果能在ICT阶段把焊接问题抓出来维修成本就是返修一个焊点的事如果漏到系统级测试发现内存通道不稳定那就要面临拆屏蔽罩、热风枪吹芯片、甚至报废整板的风险。所以测试层级之间的覆盖策略本质是成本和效率的博弈。2.2 System Controller的特殊性它是一个带固件的复杂节点和普通数字板卡相比System Controller在测试设计上有个很大的不同——它自带固件而且固件本身会成为测试的一部分。我见过的系统控制器大多承担着监控、管理、调度类职责。比如服务器里的管理控制器负责采集温度、电压、风扇转速还要提供远程管理接口工业设备里的主控板负责逻辑控制、通信协议处理和IO扩展。这类板卡的共同特征是不上电跑固件很多硬件故障根本测不出来。比如一颗LDO低压差线性稳压器的输出电压精度静态测量可能完全正常但当处理器满负荷运行、瞬时电流拉高时LDO可能因为相位裕度不足而产生振荡这时候用万用表量平均电压根本发现不了得靠示波器配合负载跳变才能抓到。这就是为什么系统控制器的测试往往需要动态跑起来而不是单纯地静态量一通。但跑起来也会带来新的麻烦如果固件本身就是坏的、或者烧录版本不对硬件测试项再完美板子依然无法交付。所以系统控制器的制造测试必须在测硬件和测固件加载之间找到一套合理的并行策略。最常见的做法是把固件烧录作为一个独立测试站先烧录、再运行硬件自检程序最后进入系统功能测试。这个流程顺序几乎没有讨论余地烧录和测试混在一个工位只会拖慢节拍。2.3 测试覆盖率的取舍原则工程上有个现实问题测试项不是越多越好。每增加一个测试项就意味着增加测试时间、增加治具复杂度、增加误报率。理想状态下测试覆盖率是100%但现实中你要在覆盖率和成本之间做取舍。我的经验分三个优先梯队第一梯队必测项电源是否短路、各电压轨是否正常、时钟是否起振、复位时序是否正确、JTAG/SWD链路是否畅通。这些如果不测后续任何测试都无法进行。第二梯队重点项DDR读写、Flash读写、关键通信接口I2C、SPI、UART回环、GPIO读写、ADC采集精度。这些是系统控制器的主干功能直接影响产品能否交付。第三梯队抽测/出厂项极端温度下的老化测试、长时间稳定性跑机、EMI预扫。这部分通常不是全检而是按照比例抽检或首批全检具体看客户要求和产品等级。有人可能会问程序烧录之后的CRC校验算不算测试项当然算而且应该放在第一梯队。固件烧录错误是最低级的错误但也是最常见的漏网之鱼一旦漏出去客户上电发现设备完全无法启动这是最拉低信任感的事故。3. 治具与硬件设计测试方案的物理基础3.1 四种治具结构怎么选测试治具是制造测试方案的物理载体治具设计不合理后面全盘皆输。系统控制器板卡形态差异很大从一张信用卡大小的核心板到半张A4纸大小的主板都有治具方案必须跟着产品走。我梳理一下常用的四类结构标准针床治具通过探针直接接触PCBA上的测试点适合板面规则、测试点设计规范的批量板卡。优点是测试稳定、误报率低缺点是对PCBA的测试点设计要求高治具造价不菲改版一次就是一笔成本。飞针测试机用机械臂带动探针逐点移动测试适合小批量多品种、测试点没来得及预留给针床的情况。优点是柔性好不需要专用治具缺点是速度慢只适合抽测或小批量不适合高速产线。边界扫描加功能接口通过JTAG链路和板卡对外接口完成信号注入与采集不需要接触内部测试点。这是System Controller特别合适的方案因为板卡通常带有标准调试接口边扫覆盖率足够覆盖大部分互连问题。自动化功能测试台模拟系统控制器的实际工作环境接入外部负载、通信对手端设备通过真实数据交互来验证功能。这是最接近用户使用场景的测试也是治具成本最高的方案。我的建议是量产项目要以ICT 或 边界扫描 功能测试组合为主针床和功能测试台结合既能保证焊装缺陷的高效拦截又能覆盖系统级功能。飞针和纯手工测量只适合工程验证阶段。3.2 探针选型与测试点设计经验关于治具探针有三条经验值得写出来。第一条探针不是越尖越好。很多人觉得针尖细接触更精确但太尖的探针穿透氧化层能力差而且容易在测试点上留下压痕。对于一般焊盘类测试点建议用三点尖或者皇冠头探针接触稳定寿命也够长。第二条测试点的间距和位置要在PCB布局阶段就给制造测试预留。很多硬件工程师画板时没考虑测试探针空间结果做治具时发现测试点被高元件遮挡只能放弃非常可惜。我的建议是测试点最好放在板边5mm以内直径做到1.0mm以上间距保持2.54mm的标准网格方便治具孔位加工。表面处理尽量选沉金或OSP不要选裸铜裸铜长期存放氧化严重探针接触不良的误报率会明显上升。第三条电源测试点必须加宽。如果是测量大电流通路的电压降单靠一个标准测试点接触会产生接触电阻误差建议采用开尔文四线测量方式。治具上用两根探针一根给激励电流一根测电压消除接触电阻的影响。3.3 电源控制和上电时序的考虑治具硬件里最容易忽略的部分是电源控制和上电时序。System Controller板卡上通常不止一路电源处理器核心供电、IO供电、内存供电、备份电池供电各路上电时序在规格书里都有严格要求。测试治具不能简单粗暴地一上电就把所有电压轨直接拉起来——处理器和内存的时序不满足要求轻则启动失败重则损坏芯片。实际工程中测试治具要给PCBA提供干净、可控制的电源同时在治具里实现时序逻辑。一种做法是用多通道可编程电源通过软件控制上电顺序并在每路输出加延时另一种做法是在治具板上做一个简易的时序控制电路用CPLD或者逻辑门实现硬时序。对于量产测试来说我更倾向于硬件时序控制因为它不依赖上位机的实时性上电瞬间的安全更有保障。还有一个小细节治具上的电源线不能太细。系统控制器虽然功耗不算大但处理器瞬间抓取电流可能达到好几安培如果电源线太细线路压降会导致板端电压跌落造成误判电源故障。治具内部尽量用粗短线连接并在板端放置足够的去耦电容。4. 核心测试项详解我建议从短路到功能分层推进4.1 短路/开路测试最基础也最关键的一关短路测试通常放在整个测试流程的最前头为什么因为如果板子上有电源对地短路贸然上电轻则保险丝烧断重则把处理器或者昂贵的电源模块直接打坏。做法是在PCBA上电前用测试治具对所有电源轨测量对地阻抗。常见的BMC类控制器核心电源轨对地阻抗一般在几欧姆到几十欧姆之间因为有大量去耦电容并联IO电源轨在几百欧姆如果是纯粹的电源输入端口应该在千欧级甚至更高。当然具体数值取决于电路设计要以设计工程师给出的范围为准。这里要特别提醒一句不要用是否为零来判断短路。因为大容量去耦电容在测量瞬间表现为低阻抗让万用表看到几乎短路的假象。正确的方法是给测试点施加一个恒定的低电压比如100mV测量实际流过的电流然后换算成等效电阻与规格值比较。这样能从容地评估阻抗又不会触发板上的半导体器件导通。还有一个容易被忽略的点短路测试要区分电源轨之间的钳位二极管影响。有些系统控制器会在不同电源轨之间放TVS管或钳位二极管二极管在反向偏置时测得的阻抗会随测量电压变化。所以短路测试的激励电压必须足够低100mV级别确保半导体器件完全不导通测到的才是纯电阻特性。4.2 电压与时钟验证别只看精度还要看稳定性上电之后第一个动作通常是检查各路电源电压是否在规格范围内。但这个测试的精度要求往往没有大家想的那么高万用表四位半就已经绰绰有余因为电源模块的输出精度本身就有2%~5%的容差。真正关键的是时钟信号的验证。系统控制器通常需要外部晶振或晶振模块提供参考时钟时钟不起振、频率偏了、或者波形幅度异常都会导致处理器无法运行甚至固件跑飞。量时钟有两种方式。一种是频域方式用频率计直接测频率值效率高但看不到波形质量另一种是时域方式用示波器看波形的上升沿、过冲和幅度。量产测试建议以频率计为主配合示波器抽测。原因是示波器量时钟的效率太低探头加载还会影响高速钟的波形容易产生误判。只有在设计方案变更或批量故障排查时才需要专门用示波器仔细分析时钟质量。4.3 边界扫描系统控制器最值得投资的测试手段边界扫描Boundary Scan符合IEEE 1149.1标准是利用芯片内部的分立扫描单元来测试引脚互连的一种方法。对于System Controller这种BGA封装密集、测试点开挖困难的板卡边界扫描几乎是效率最高的互连测试方案。它的原理不复杂芯片的每个引脚都串联了一个移位寄存器单元测试时通过JTAG接口把一串测试向量移入芯片让引脚输出已知的电平然后在相邻芯片的引脚上捕获响应再把结果移出来对比。通过这种方式可以精确判断板上的走线是否存在开路、桥连或对电源短路。实际使用中边界扫描还有两个进阶功能。第一个是串行向量功能SVF通过JTAG接口向板上的CPLD/FPGA下载配置或者向Flash写入测试数据不需要专门的烧录器这在产线上能省不少设备成本。第二个是内置自检配合BIST比如内存的March算法测试就属于这类。如果系统控制器的处理器支持DDR控制器BIST通过JTAG触发BIST运行然后读取结果就能在不上电跑完整Linux系统的情况下验证DDR通道的物理链路。这个功能对内存虚焊、数据线短路的筛查效果非常好。当然边界扫描也有测不到的地方它只能测到扫描链覆盖的信号如果某个引脚没有接入扫描单元或者某个器件不支持1149.1协议这部分互连就测不了。这就是为什么边界扫描通常和后面的功能测试配合使用各管一段。4.4 功能测试从接口回环到协议握手功能测试的目标是证明数据能从这个接口出去绕一圈回来还是对的。对System Controller来说最常用的功能测试手段是回环测试。比如UART接口把TX和RX短接通过治具上的跳线或继电器切换向串口发送一组已知数据接收端若收到相同数据则链路基本没问题。类似的还有I2C、SPI、CAN、Ethernet等。但这里有个细节回环测试要区分芯片级回环和板级回环。有些控制器的外设支持内部回环模式即在芯片内部将发送数据直接传回接收路径这种模式测不出PCB走线问题。所以制造测试必须使用板级外置回环在连接器端把发送和接收短接起来这样信号经过PCB走线、连接器和治具线缆才能真正验证整个物理链路。功能测试阶段还经常需要模拟对端设备。比如系统控制器通过I2C总线去读取一个温度传感器测试时治具上要接一个模拟的传感器设备或者用一块带有I2C从机逻辑的小板子来响应控制器的读取请求。对于复杂的工业协议如Modbus、CANopen直接用真实的对手端设备是最靠谱的用虚拟软件模拟往往会在后续联调时暴露问题。4.5 老化与可靠性测试是否全检取决于产品定位老化测试Burn-in Test在System Controller制造测试中占多大比重很大程度上取决于产品用在哪里。消费类产品通常只做抽检或者干脆只做常温短时功能测试工业级产品大多要求全检至少做高温环境下数小时的老化车规级或高可靠应用则可能要求温度循环加电压拉偏的强应力筛选。老化测试不做全检的原因很简单时间成本太高。一块板子老化工位占好几个小时等于把整个产线的节拍拉长到不可思议的程度。所以工程上的折中方案是分站老化板卡在生产线上先把所有功能测试做完再进老化房批量处理最后做一次快速复测确认老化过程中没有出现劣化。另一个值得注意的点是老化测试方案不是简单地给板子通电放那摆着。合理的做法是在老化过程中让板子持续运行自检程序把错误日志记录下来。如果板子只通电但不工作很多间歇性故障是无法暴露的。自检负载越接近实际应用场景老化的筛选效果越好。5. 测试软件与数据采集产线可追溯性的关键5.1 测试执行框架的选择逻辑测试软件的架构决定了产线调试和后续维护时你的痛苦程度。我在项目里见过两种典型的测试程序风格一种是大一统的流水账式脚本从头到尾执行几百个测试步骤任何一步失败就停止另一种是模块化的测试框架每个功能独立成一个测试项有独立的ID、独立的判定标准可以单独执行也可以批量跑。量产测试强烈建议后者。理由不用多说产线上最常干的事就是某个测试项老误报想单独跑一百遍看看稳定不稳定如果你用的是流水账式脚本每次都要从头跑到尾光等待时间就让人崩溃。测试程序语言方面一种是直接用LabVIEW这类图形化平台优点是仪器驱动生态好适合快速搭建另一种是用Python配合pyvisa、pyserial这类库做软硬件交互优点是代码维护方便和MES系统对接简单。近几年我越来越多地看到Python方案原因大概是团队里会写代码的人越来越多而Python在数据处理和报表生成方面的优势太明显了。测试程序一定要把日志当成一等公民对待。每个测试项开始和结束都要有时间戳每一条测量值、每一个判定结果要写入结构化日志。别怕日志太多占空间一个稳健的产线每天产生的日志量也就是几个GB级别任何存储系统都能扛住但一旦出现批量性问题没有日志你就只能对着故障板发愁。5.2 判定标准的制定规格边界要留生产余量测试软件里最重要的一条逻辑不是怎么测而是测完拿什么标准判断。电性能参数通常有一个设计规格范围Datasheet规格但产线判定标准不能直接照抄规格值。因为仪器有测量误差、治具接触电阻有波动、环境温度还会有影响如果你把合格线定在规格的绝对边界上必然会出现一批在规格内但实际已经处于边缘的产品这批产品流到用户手里在恶劣环境下很可能出问题。正确做法是设定生产判定限一般比规格范围收窄20%~30%。比如某路电源规格是3.3V±5%3.135V~3.465V产线判定范围就设在3.2V~3.4V。超过3.4V但没有超过3.465V的产品不算不合格但要单独标记可能是元件批次偏移的早期信号。另外测试系统还要考虑测量不确定度。如果你用的万用表精度为±0.5%测试线缆还会引入额外误差这时候生产判定限如果不做补偿测试系统本身的误差就吃掉了生产余量。专业点做法是定期用校准过的标准源或标准板做仪器的量值溯源把整个测试系统的测量偏差标定出来再体现在判定软件里。5.3 测试数据回传MES从单板合格到批次受控现代制造测试的终点不是产线上亮绿灯而是数据安全地进入MES系统制造执行系统。没有数据回传的测试等于白测——因为你无法跟踪每块板的测试历史也无法做批次级别的趋势分析。数据回传有两个层面。第一层面是结果数据每块板的序列号、每个测试项的测量值、判定结果、测试时间、操作员信息、测试工位编号。这些数据用于追溯单板质量处理客户投诉时能快速定位是哪一批次、哪块板的哪个环节出了问题。第二层面是原始数据特别是射频类、高速信号类的波形或眼图数据这部分数据量大通常不会全量上送MES而是按需保存本地定期归档。别看原始数据平时用不上一旦客户反馈偶发异常这些数据可能就是唯一能还原故障现场的东西。MES对接的接口形式各异企业里最常见的还是数据库直写或者HTTP API上报。在测试软件里要处理好离线缓存的情况——万一网络闪断测试数据不能丢本地要做好排队重发机制。这个细节听起来简单但我在产线现场见过不少因为断网导致数据漏记的案例最后客户追溯时完全对不上账非常麻烦。6. 量产爬坡阶段的典型问题从试产到稳定量产的调试经验6.1 误报率高先排查测试系统本身别急着怪产品试产阶段最让人头疼的问题就是昨天测十块板全过今天测十块板挂了五块也就是误报率高。遇到这种情况我的排查顺序基本固定先看治具接触再看测试软件配置然后是探针和线缆状态最后才怀疑产品本身有变化。治具接触问题占据