 测试程序跑完一颗芯片，换下一颗。你确定下一颗芯片的初始状态是干净的吗？——不一定。如果上一颗芯片测试过程中把某个寄存器设成了特殊模式，或者电源没有完全放电，下一颗芯片上电时可能还残留着上一颗的状态。 这就是为什么“复位”处理很重要。 今天聊聊测试程序中几种常见的复位场景和处理方法。  一、硬件复位 vs 软件复位 先区分两个概念。 硬件复位：通过芯片的复位引脚（nRST、POR等）拉低再拉高，强制芯片恢复到初始状态。这是最彻底、最可靠的复位方式。 软件复位：通过写寄存器或发送命令，让芯片内部的逻辑复位。不涉及复位引脚。软件复位不一定能恢复所有状态，有些寄存器可能保持原值。 能接复位引脚的，尽量用硬件复位。没有复位引脚的才考虑软件复位。 二、测试程序中的复位场景 场景一：上电后的首次复位 芯片上电后，内部状态是不确定的。虽然大多数芯片有上电复位电路，但POR的阈值电压、响应时间不一定可靠。建议在电源稳定后，主动做一次硬件复位。 顺序：上电→ 等待电源稳定 → 拉低复位引脚（保持几微秒） → 拉高 → 等待芯片退出复位状态→ 开始配置寄存器。 场景二：每颗芯片测试前的复位 这是最常见的场景。换一颗新芯片，测试前先复位一次，确保每颗芯片从同一个起点开始测试。 如果测试程序中用了硬件复位，这一步可以替代场景一的上电复位。 场景三：测试项之间的局部复位 某些测试项之间需要复位。比如测完高速模式后，要切回正常模式。用软件复位比重新下电更快，也更省时间。 场景四：异常恢复时的复位 测试过程中出现异常（比如芯片无响应、通信超时），先尝试软件复位。不行再硬件复位。硬件复位还不行，就判Fail，换下一颗。 场景五：测试结束后的复位 测试完成后，在断电前做一次复位，把芯片恢复到安全状态。避免芯片在异常状态下断电导致的潜在损伤。 三、复位时序的几个关键点 复位脉宽：复位引脚拉低的时间不能太短。芯片内部需要足够的时间检测到复位信号并执行复位操作。数据手册上会写最小复位脉宽，比如1微秒、10微秒、1毫秒。程序里的延时至少要达到这个值。 复位后的等待时间：复位引脚拉高后，芯片不会立即工作。内部振荡器启动、PLL锁定、寄存器初始化，都需要时间。数据手册上会写“复位释放后等待X微秒再操作”。 上下电顺序：如果用了硬件复位，断电时先拉低复位引脚，再切断电源。上电时先上电，再释放复位引脚。这样可以防止芯片在电压不稳时进入错误状态。 四、常见错误及解决 错误一：复位脉宽太短 程序里写了reset_low(); wait(1); reset_high();但单位是微秒还是毫秒没搞清楚。实际只有1微秒，芯片没来得及复位。 解决方法：查数据手册确认最小脉宽，加50%余量。用示波器量一下复位引脚的实际波形。 错误二：复位后没有等待 复位释放后立即去写寄存器，芯片还没准备好，写入失败。 解决方法：在释放复位和第一次操作之间加延时，按数据手册的建议值设。 错误三：只做软件复位，不做硬件复位 软件复位不彻底，某些寄存器保留之前的值。下一颗芯片用同一个程序，配置不对。 解决方法：优先用硬件复位。确实没有复位引脚，软件复位后加一个验证步骤，检查关键寄存器是否恢复到了默认值。 错误四：复位移到了不该动的地方 把复位操作放在了一个会被多次执行的循环里。每测一个参数就复位一次，每颗芯片被复位了几十次，浪费时间。 解决方法：复位只在必要的地方做。每颗芯片一次，或者每个大的测试段一次。 复位不是拉低再拉高就完事了。 脉宽够不够、之后等没等、复位的是硬件还是软件、每颗芯片测前有没有复位，都会影响测试结果的可重复性。 几个要点再记一下： 有复位引脚就用硬件复位 每颗芯片测前至少做一次复位 脉宽和复位后的等待时间按数据手册来，再加余量 结束前复位，避免状态“传染“ 下次写测试程序，把复位当成一个独立章节来设计，别随手放几行代码了事。  |
