在产线上摸爬滚打这么多年凡是跟“控制器”沾边的板卡测试方案从来都不是拍脑袋定出来的。System Controller系统控制器作为设备里的“大脑中枢”它的制造测试如果做不扎实后面的系统联调就是一场灾难。这篇Part 1我先讲清楚最核心的测试设计思路和环境搭建把地基打牢。1. 测试方案的整体设计与路径选型1.1 先搞清楚System Controller在产线上到底要测什么很多人一提到制造测试Manufacturing Test第一反应就是“上电看看能不能跑系统”。这个想法如果用在System Controller上大概率会翻车。System Controller在整机里扮演的角色通常不是单一功能单元而是承担着电源管理、通信总线调度、状态监控、外围设备控制等一系列任务。举个实际例子一个标准的System Controller板卡上往往同时存在电源转换电路、MCU/SoC主控、多路UART/I2C/SPI/CAN通信接口、GPIO控制逻辑甚至还有以太网PHY。在制造阶段做测试目标不是验证“设计功能是否完美”而是验证“焊接、贴片、装配、烧录这些制造工序有没有把板子搞坏”。所以测试项的设计逻辑应该是用最短的时间覆盖最高的故障检出率把良品和不良品清晰地区分开。换句话说制造测试的终极目标是“筛查”不是“研发验证”。基于这个逻辑我在规划System Controller的Manufacturing Test方案时通常会按照三个层级来拆分测试需求第一层是“能不能活”也就是电源和时钟。板子供电是否正常各路电压是否在规格范围内晶振是否起振复位时序是否正确。这一层过不了后面什么都不用谈。第二层是“能不能通”也就是通信接口的基本连通性。UART能否自发自收I2C能否枚举到设备CAN能否完成回环通信以太网PHY能否建立链路。第三层是“能不能控”也就是功能级验证。GPIO的输入输出逻辑是否正确看门狗是否能正常触发ADC采集通道的读数是否在合理范围。这里有个很容易踩的坑不要在制造测试阶段把所有功能都做成“全量回归测试”。研发阶段的测试用例动辄几百条如果全部搬到产线单板测试时间会拉得很长直接影响产能。制造测试的设计原则应该是“针对制造缺陷的高效筛查”而不是“功能完整性的全面验证”。1.2 为什么我选择“功能测试为主、边界扫描为辅”的组合策略在测试方案选型上行业里主要有两条技术路线一条是传统的FCTFunctional Circuit Test功能测试另一条是JTAG边界扫描测试Boundary Scan Test基于IEEE 1149.1标准。FCT的特点是直接、高效、贴近实际使用场景。通过测试夹具把板卡的真实对外接口引出来用测试上位机发送指令、读取响应验证板卡在“模拟实际工作”的状态下各项功能是否正常。它的优势是覆盖范围广只要是软件能访问到的资源都能测劣势是依赖板上固件或测试固件的配合如果板上的MCU没烧录程序或者程序跑飞了FCT就很难继续往下走。边界扫描测试的特点正好互补。它不依赖板上主控是否正常工作而是通过JTAG接口从外部“移位”控制芯片管脚的状态直接检测芯片之间的互连有没有断路、短路、桥接。对于BGA封装、DDR、高速连接器等无法用探针直接接触的节点边界扫描几乎是唯一有效的互联测试手段。但它的局限也很明显只能测到芯片边界测不到芯片内部的模拟功能。我个人的习惯是把两条路线结合起来先跑一遍快速的边界扫描测试用几秒钟时间排除焊接类故障然后进入FCT阶段做功能验证。这样既拿到了边界扫描对“物理连接”的高检出率又兼顾了FCT对“逻辑功能”的覆盖率。补充一个实际经验如果System Controller板卡上没有预留JTAG接口或者板上主控不支持边界扫描那也不要硬上边界扫描方案。FCT单独扛起制造测试的大旗完全可行很多量产项目就是这么干的关键是把测试用例设计得足够精准。2. 测试环境搭建与硬件准备2.1 测试夹具与探针选型别在这上面省钱测试夹具是整个Manufacturing Test的物理基础。System Controller板卡通常有多个对外连接器比如电源输入端子、调试串口、CAN接口、以太网口、扩展GPIO排针。测试夹具的设计目标就是让板卡快速装夹、快速连接、可靠接触。关于探针选型我踩过不少坑。排针类的连接器可以直接用弹簧针Pogo Pin顶住焊盘或测试点但要注意针尖形状的选择。平头针适合平面焊盘尖头针适合通孔或略凹的测试点。对于间距很小的测试点一定要选用细针同时考虑针管的绝缘层会不会发生干涉。另一个关键点是夹具的定位结构。System Controller板卡的安装孔位、板边、连接器位置都要有精确的定位销/定位柱来保证重复定位精度。否则同一批板子每块装上去的位置误差都不一样探针接触就会不稳定误测率会高到你怀疑人生。这里还要特别提醒一点做夹具设计之前先把板卡的Gerber文件、机构图、BOM清单要齐。尤其是在没有测试点的位置要提前和硬件工程师沟通在PCB设计阶段预留测试焊盘。等PCB都投出去了再发现没有测试点就只能用飞线效率和稳定性都会大打折扣。2.2 仪器仪表与供电方案的关键考量System Controller的测试会用到万用表、示波器、可编程直流电源以及通信接口转接工具比如USB转UART、USB转CAN。仪器的精度要求并不算特别高但稳定性很重要。尤其是在产线环境下设备24小时不间断运行仪器的温漂、老化都会影响测试结果。电源方案是我比较想强调的一点。System Controller板卡一般会有多路电源轨比如5V输入板内转3.3V、1.8V、1.2V等。测试时不仅要给板卡供电还要监测每路电压。这里推荐使用多通道可编程直流电源加上数据采集模块实现“供电电压巡检”一体化。我在实际项目里常用的是主电源用一台支持远端采样Remote Sense的可编程电源避免线缆压降导致板端电压偏低。电压巡检则用高精度ADC采集模块通过继电器矩阵切换测点依次测量各路电压。用继电器矩阵而不是直接把所有电压接进ADC是为了减少通道间干扰也方便扩展测试点数量。另外一个容易被忽略的点静电防护。产线环境静电问题非常突出尤其是在干燥季节。测试夹具的金属部分必须可靠接地操作台要配备防静电垫、防静电手环。System Controller板卡上有大量精密IC一次静电损伤可能不会立刻表现出来但在后续使用中会随机出现故障这种问题在产线上极难追溯。2.3 测试软件的框架设计指令交互是关键测试上位机软件的设计我把它拆成三个模块用例管理模块、执行引擎模块、报告输出模块。用例管理模块负责定义测试项目和参数执行引擎模块负责按顺序执行用例、采集数据、比对判定报告输出模块负责记录每台板卡的测试结果生成序列号追溯数据。很多人在写测试上位机的时候习惯把指令直接写在代码里今天加一个测试项就改一行代码明天调一个参数又改一行。这种做法在项目初期看起来很快但到了量产阶段就是灾难。测试用例和测试指令应该尽量做到数据驱动也就是把“测什么”和“怎么测”分离。关于测试指令的设计我倾向于使用自定义的ASCII命令协议。比如上位机发送一条“ADC? CH3\r\n”命令板卡返回“ADC,CH3,1.234V\r\n”。这种协议直观、易调试也方便在产线上用手动终端直接交互排查问题。当然如果板卡资源紧张也可以采用二进制协议但调试成本会高一些。测试软件还有一个很重要的功能自动重测和不良品标记。当某个测试项失败时软件应该自动记录失败原因、失败步骤和数据快照然后决定是立即终止测试还是继续测完剩余项目。我的建议是对“非致命性”的失败项继续测完这样在分析不良品时能够拿到完整的“体检报告”更快地定位故障来源。3. 核心测试项设计与实操过程3.1 上电自检流程电源、时钟、复位一个都不能少上电自检是每块System Controller进入功能测试前的必检项。这块要是没做好后面测出来的数据都是“薛定谔的测试结果”——你以为板子是好的其实它早就在崩溃边缘了。我先说一下我惯用的上电自检顺序首先是在板卡上电之前用万用表测量电源输入端是否短路。这一步非常关键能避免给有焊接短路的板卡上电造成二次损伤。然后是上电观察电流是否在正常范围。如果电流远超预期立即断电检查。上电之后的第一步是测量各路电压。这里要注意测量时机有些电源轨开启是有顺序的比如先3.3V再1.8V最后1.2V。直等到所有电源轨都稳定后再去读数。用数据采集模块依次测量各路电压值与规格上限、下限比对。第二步是检查时钟。System Controller上一般会有无源晶振或有源晶振给主控提供时钟。用示波器测量晶振引脚的波形频率是否在标称值附近。这里要留意探头的负载效应建议使用低电容探头比如10pF以下否则可能因为探头接入导致晶振停振。第三步是复位信号。检查复位引脚的时序是否符合主控芯片的要求。很多主控芯片需要复位信号在上电后保持一段时间的低电平然后再拉高。如果复位芯片的延迟时间不够主控可能启动失败。整个上电自检流程我建议控制在15秒以内。产线的节拍非常宝贵每块板子多花10秒一万块板子就是多花将近28小时。3.2 通信接口测试UART、I2C、CAN、以太网的分层验证System Controller作为系统的大脑通信接口是最核心的功能之一。在测试通信接口时我习惯遵循“先物理层、再协议层、后应用层”的分层验证原则。以UART为例物理层测试就是验证板卡的UART_TX和UART_RX引脚是否连通。实际操作中我会通过测试夹具把板卡的UART接口连接到USB转UART工具然后上位机发送一个测试字符串板卡回传一个应答字符串。最简单的回环测试就是板卡把收到的字符串原样返回。如果回传成功说明物理连接和基本收发路径没有问题。再往上是协议层测试。我会测试波特率、数据位、停止位、校验位在不同配置下的通信是否正常。这里要特别注意测试时必须先配置板卡的UART参数再发送数据顺序反了就会导致通信失败但板卡本身其实是好的。I2C测试的思路略有不同。I2C是多主多从的总线结构System Controller上通常会挂载一些外设芯片比如EEPROM、温度传感器、RTC等。测试I2C时我会先让主控去扫描总线地址看能否枚举出预期数量的设备地址。然后对EEPROM进行写读回环操作写入一包已知数据读出来比对是否一致。CAN接口的测试要稍微复杂一些。物理层上CAN总线需要正确的终端电阻。我一般会在测试夹具上预留120欧姆终端电阻的接入点测试标准CAN 2.0B的通信。以太网测试核心是先验证PHY芯片的链路状态。通过读取PHY寄存器的链路状态位确认与测试治具对端已建立物理链路。然后再做简单的网络层通信测试比如Ping通测试或UDP回环测试。3.3 GPIO与ADC测试逻辑功能与模拟精度的双重校验GPIO的测试看起来简单实际上有很多细节。System Controller的GPIO通常被用来做控制信号比如继电器的通断、LED的指示、外部设备的使能等。测试时上位机通过命令让主控把某个GPIO设置为输出高电平然后用数字IO采集模块读取对应引脚的电平是否在预期的高电平范围。GPIO测试的一大难点是“边界的判定”。TTL电平的标准是高于2.0V为高低于0.8V为低但在3.3V供电系统里GPIO输出高电平应该在3.0V以上才算是健康的。如果实测高电平只有2.3V虽然逻辑上还是高电平但驱动能力已经不足在恶劣环境下可能误触发。所以我在测试GPIO时除了测逻辑电平还会关注电平的绝对数值设置一个比规格书更严格的内部判定阈值。ADC测试则是对模拟采集通道的验证。System Controller上如果有ADC通常是用来采集电压、电流、温度等模拟量。测试时用高精度信号源给ADC通道输入一个已知电压然后读取ADC转换结果计算误差是否在允许范围内。这里要提醒一下ADC测试的精度验证不能只看一次读数。我会在同一电压点采集多次比如采集32次取平均然后看最大最小值之间的波动范围。如果波动过大可能说明ADC的参考电压不稳定或者PCB布局存在干扰。另外ADC测试的电压源一定要用低噪声、高精度的信号源否则很容易把“信号源的误差”误判成“板卡的故障”。3.4 边界扫描测试为焊接质量加一道保险如果板卡支持JTAG边界扫描我非常推荐在FCT之前加一道边界扫描测试。这个测试的定位是纯物理层检测主要检查芯片引脚和板级互连的焊接情况。边界扫描测试的执行逻辑是通过JTAG接口把测试数据“移位”进芯片的边界扫描单元然后“捕获”芯片引脚的实际电平状态再“移位”出来与预期值比对。比如检测BGA封装的主控与一块DDR芯片之间的连线是否短路或断路通过令主控引脚输出逻辑0或1然后从DDR引脚捕获对应电平。我在项目里使用的边界扫描测试工具支持自动生成测试向量但生成的质量与芯片BSDL文件Boundary Scan Description Language的完整性直接相关。所以拿到板卡原理图和PCB文件后我会先花时间仔细核对BSDL文件中引脚定义与实际网络的对应关系确保测试向量不会打到未连接的引脚或电源/地引脚上。边界扫描测试还有个好处可以检测到PCB制造过程中的隐性缺陷比如过孔开路、走线桥接等。这些缺陷在功能测试阶段可能不会被触发但在系统长期运行后就会出现间歇性故障。所以从品质角度讲边界扫描测试的投入产出比非常高。4. 产线测试中的常见问题与排查技巧4.1 通信测试偶发性失败先查接口时序和线缆质量在我的测试经验里通信接口偶发性失败是最让人头疼的问题之一。因为这种问题不是每块板子都会出现可能是测20块出现一次而且失败点还不固定今天UART失败明天CAN失败。排查这类问题时我会按照“先外部后内部”的顺序来。先检查测试夹具的线缆是否老化、接触是否可靠。产线线缆经常弯折屏蔽层容易断裂USB转串口工具的连接头也很容易松动。这些外部问题解决掉之后再分析板卡本身的原因。如果是板卡自身的原因首先要怀疑通信接口的时序问题。比如UART通信如果波特率误差偏大超过2%在传输较长数据帧时就会偶尔出错。用示波器精确测量板卡UART引脚的波特率与配置值比较。还有一个常见原因是串口工具或测试上位机的软缓冲问题。USB转串口芯片的驱动在Windows下的USB轮询延迟是不确定的如果上位机没有做好超时重试机制就会偶发地丢数据。我的解决方案是在测试软件里加入重试机制通信失败后连续重试3次如果还失败才判定为不良这样既保证了效率也有效过滤了外部干扰。4.2 误测率超标先检查夹具接触和判定阈值产线的直通率First Pass Yield如果低于预期但不良品返修后又是好的那大概率就是误测了。误测率超标的问题优先级甚至比漏测还高——漏测可能只影响个别坏板流出误测则会严重拖累产线效率。我遇到过的误测原因八成以上出在夹具接触上。Pogo Pin用久了针尖会氧化发黑接触电阻增大。接触电阻一旦增大低电平信号可能被抬高、高电平信号可能被拉低导致判定边缘化。加上System Controller板卡的信号电平本身只有3.3V或1.8V几个欧姆的接触电阻在信号完整性上就会被放大。解决方法是定期维护夹具比如每个班次开始前用无尘布蘸酒精清洁针尖每周做一次接触阻抗抽检。另外在判定阈值的设置上不要紧贴规格书的边界要给测试系统留出余量。比如规格书要求高电平大于2.0V即合格我会把判定阈值设定为2.5V低于2.5V就标记为NG。这样虽然会牺牲一点余量但能明显降低边缘误判的概率。4.3 测试项过多导致节拍过长学会做减法很多项目在导入Manufacturing Test的时候会陷入一个误区测试项写得越多越好恨不得把所有芯片的每个寄存器都验证一遍。但实际上制造测试的测试项选择和“二八定律”是一致的——80%的制造缺陷集中在20%的关键测试项上。我在设计测试用例时会先分析历史不良数据看看过去返修的主要原因是哪些。比如某款System Controller板卡的返修数据表明70%的不良集中在电源DC-DC焊接和DDR内存互连那测试方案就应该重点强化这两块。对于其他不太容易出问题、且功能复杂度高的项比如复杂的通信协议一致性测试可以放到系统联调阶段去覆盖。给产线做减法不是降低品质标准而是在充分理解产品特性和历史数据的基础上把测试资源集中在最有价值的地方。我在实操中会为每个测试项标注两个属性故障检出率和测试耗时。优先保留故障检出率高、测试耗时短的项把检出率低且耗时长的大项拆分或转移到下一阶段。5. 测试数据追溯与产线管理衔接5.1 序列号管理与SN-BOM追溯每块板卡都要有“身份证”做制造测试最怕的是“测完了不知道测的是哪块板子”。如果没有一套完整的序列号管理机制后面的维修、追溯、客诉分析都是无根之木。我的做法是每块System Controller板卡在贴片完成后就烧录一个唯一的序列号Serial Number并存放到主控的Flash特定区域。测试开始时测试上位机首先读取这个序列号作为本条测试记录的索引同时扫描板卡上的关键芯片批次信息把SN与物料批次关联起来。这样当某批次DC-DC芯片出现批次性不良时我可以通过测试数据库快速回溯找出所有使用该批次芯片的板卡序列号精准召回。如果SN和BOM批次没有绑定就只能大海捞针甚至整批报废。5.2 测试数据报表的关键字段与SPC预警测试数据记录下来不只是为了“留底”更重要的是用数据驱动质量改进。我的测试报告数据库中每一条测试记录会至少包含这些字段测试时间、产线工位号、SN序列号、测试软件版本、测试夹具编号、每个测试项的名称、实测值、上下限值、判定结果、失败原因代码、操作员账号。有了这些数据就能做SPC统计过程控制分析。比如电源电压的测试数据如果连续多块板卡的3.3V电压实测值都在3.28V左右虽然还没超下限但趋势是向下的这就说明某个环节正在发生漂移。通过SPC控制图提前捕捉这种趋势可以在不良品出现之前就介入纠正。我在实际项目里会设置一个简单规则如果连续5块板卡的同一测试项数据全部落在规格范围内但整体趋势是单向移动的就触发预警通知让工艺工程师检查回流焊温度曲线、物料批次变化、夹具状态等。这种做法确实帮我提前避免过两次批次性不良的发生。5.3 测试夹具与测试软件的定期校验机制Manufacturing Test系统本身也是一台“测量设备”既然是测量设备就必须有校验机制。否则测试结果可能每天都在变只是变化得比较缓慢不容易察觉。校验分为两个层面硬件的校验和软件的校验。硬件层面测试夹具里的Pogo Pin会有机械寿命通常几万次动作后就需要更换。仪表需要定期送计量保证精度在合格范围内。软件层面我会在每次批量测试开始前先用一片“标准板”做一次完整测试。标准板是经过严格功能验证、确认无误的“金板”如果标准板的测试结果出现异常说明测试系统本身有问题需要排查后才能开始量产。这里有个细节标准板也应该定期送第三方或研发部门复核防止标准板本身因为老化、存放不当等原因出现漂移。否则“坏的标准板”会把“好的测试系统”判成故障或者更糟把“坏的板子”判成良品。6. 个人经验总结与后续规划在System Controller制造测试这个方向上我最大的体会是测试方案的优劣不是由测试项的数量决定的而是由故障检出能力和产线效率的平衡决定的。一个好的制造测试方案是要让产线“跑得稳、跑得快、查得准”而不是一个面面俱到、华丽但笨重的验证工具。Part 1的内容我聚焦在整体方案设计、测试环境搭建和核心测试项的实操方法上。这个过程如果走得扎实后续往上升级就有底气。比如测试自动化率提升机械手臂自动上下料、基于AI的测试数据分析、云端测试数据管理等都要建立在“基础测试数据干净可靠”这个前提之上。最后分享一个实操建议无论你用的是自研测试框架还是商业测试平台测试代码里一定要保留详细的日志输出能力。生产环境没有那么多时间给你现场调试但一份完整的历史日志往往能在排查疑难杂症时帮你节省几个小时。这是我从一个“项目交付那晚产线红灯”的惨痛经历里换来的教训值得记在笔记本第一页。