板子电源都正常，CPU/FPGA为什么还是不启动？

板子第一次上电，所有DC电源用万用表量都“有”：0.8 V、1.1 V、1.8 V、3.3 V，一个不少。可CPU没有串口日志，FPGA不DONE，JTAG也连不上。团队最容易出现的下一步是：换芯片、重焊BGA、怀疑软件、怀疑DDR、怀疑焊接。问题是，这些动作的信息增益都很低。Bring-up真正应该先做的，是按系统依赖关系建立证据链。

上电电源与复位时序示波器截图 — 图1｜真实上电时序截图：多个电源rail与RESET必须放到同一时间轴上看。万用表测到“每路电压都对”并不能证明CPU/FPGA看到的上电顺序正确。

原则：前一级没有证据，后一级的异常往往只是结果。JTAG连不上，不等于JTAG本身有问题；CPU没有日志，也不等于软件没跑。

一、“电压都对”只证明静态值，不证明上电条件成立

对SoC/FPGA这类器件，关键不是某一时刻电压读数，而是上电顺序、斜率、Power Good门限、掉电次序，以及复位什么时候释放。万用表会把这些时间维度全部平均掉。最直接的方法是把关键rail、PGOOD和RESET_N同时接到示波器，用单次触发抓完整上电。

如果核心电压上升太慢、某路PGOOD抖动、复位在时钟稳定前提前释放，芯片可能进入未定义状态。更麻烦的是，这类问题断电重启后可能偶发恢复，于是很容易被误判为软件或BGA焊接问题。

二、RESET_N一直低：不要只在这个点上盯电平

复位是一个“汇总结果”。外部Supervisor、PMIC PGOOD、SoC内部POR、看门狗、JTAG调试器甚至某个外围电源监控都可能参与复位链。看到RESET_N为低，下一步应该问“谁在拉低它”，而不是直接换复位芯片。

建议同步测RESET_N、关键PGOOD和参考时钟。如果PGOOD先抖，RESET_N随后跟着低，根因优先在电源链；如果PGOOD稳定、时钟正常，但RESET_N周期性拉低，则进一步看内部Watchdog、Boot失败后的自动复位策略或调试器行为。

三、复位释放、时钟正常以后，看芯片有没有“尝试启动”

这一步的目标不是立刻证明软件正确，而是证明CPU/FPGA已经执行到启动介质访问阶段。对SPI/QSPI启动，逻辑分析仪或示波器抓CS#、CLK、MOSI、MISO；对eMMC看CMD/CLK/DAT；如果有ROM UART日志，也应把它作为第一手证据。

如果完全没有片选，说明芯片还没走到访问Flash这一步，继续查strap、boot mode、reset和clock；如果有时钟但读回全FF，查Flash供电、片选、焊接和IO电平；如果反复读取同一地址，可能是镜像、校验或启动头失败；如果Boot正常后才死，则再进入DDR初始化和高速总线阶段。这样每一步都有可证伪的假设。

还要特别留意strap采样窗口。很多SoC在复位释放附近只在一个有限窗口读取Boot Mode脚；如果外部上拉/下拉被其他器件、测试点电容或电平转换器拖慢，静态测量最终电平完全正确，启动模式仍可能被采错。因此“复位释放前后”的动态电平比上电一分钟后的万用表读数更有价值。

四、为什么“先接JTAG”有时反而降低定位效率

JTAG本身依赖目标IO电源、参考电压、reset状态、TCK信号质量和器件安全配置。它连不上时，原因可以来自整条前置链路。Intel的System Console文档也把检查系统时钟、复位状态以及简单读写事务作为board bring-up的重要手段。换句话说，调试器是工具，不是系统生命体征的替代品。

时钟也不能只用频率计回答“有/没有”。差分参考时钟要看幅度、共模、电源噪声耦合、启动时间和抖动；单端晶振要确认是否因为探头电容而被测量动作本身拉停。Bring-up里的每个测量都要问一句：我的探测手段会不会改变被测对象？

现象	不要先做	优先证据
无任何启动日志	反复烧固件	抓电源时序、RESET、CLK
JTAG连接失败	立即怀疑CPU损坏	确认目标IO电压、RESET、TCK/TMS是否真的到芯片
反复复位	先改软件延时	把PGOOD、RESET、电流波形叠起来
偶发能启动	归因“焊接不稳定”	扫上电斜率、温度、输入电压和掉电间隔
启动后卡死	直接替换DDR	先确认Boot介质读完，再进入DDR训练证据