多路电源上电时序控制实战：一块”启动看运气”的板子，逼我把上电顺序当成正式设计项来做

2026年9月20日 0 By admin

上一期写 SDRAM 布线的时候在文末留了个话头：比布线更隐蔽、更容易被忽略的，是上电时序。这期就来填这个坑——一块 FPGA + DDR3 + MCU 的三电源板子，样品阶段十次上电能有一次半启动成功，全靠”再按一次复位”续命。最后把上电顺序当成正式设计项重做了一遍，才算彻底解决。

现象：启动看运气，复位看心情

板子是典型的”三件套”架构：

3.3V：IO 电源、外设供电
1.8V：DDR3 接口电源（VDDQ）
1.0V：FPGA 内核电源（VCCINT）

故障现象很典型：上电后大约 3~4 次里有一次，FPGA 配置失败（DONE 脚拉不起来），或者 DDR3 校准（read leveling）失败直接卡在初始化里。按一下复位键，十有八九就好了。

“复位能救”本身就是最大的线索——说明不是硬件损坏，而是上电过程中某个环节的先后顺序或时序裕量出了问题。

为什么上电顺序是个”正式设计项”

很多人（包括当年的我）默认”电全上齐了就行”，但多电源系统里，上电顺序直接踩中三个雷区：

1. 闩锁（Latch-up）风险。CMOS 结构里存在寄生可控硅，当 IO 电源先于内核/衬底电源建立、IO 引脚电压超过 VDD + 0.3V 时，可能触发闩锁——轻则电流暴涨，重则烧片。数据手册里的”上电顺序要求”章节不是建议，是红线。

2. 复位释放顺序。复位必须最后释放，而且要在所有电源稳定之后再保持一段时间。如果 1.0V 内核还没稳，复位监控芯片就把复位释放了，FPGA/ MCU 就会在”半血状态”下开始跑代码，表现为偶发跑飞。

3. 初始化依赖。DDR3 的 VDDQ 和 VTT、FPGA 的配置 Flash、MCU 的 Bank 供电之间有隐式的依赖关系：配置 Flash 用 3.3V，FPGA 内核用 1.0V——内核没起来之前，配置时钟（CCLK）根本跑不动。

第一步：把数据手册的时序要求抄成一张表

这次我学乖了：先不画电路，先把三颗主芯片数据手册里所有带 “power sequencing” 字样的章节翻出来，抄成一张需求表。

电源轨	目标芯片	上电要求	掉电要求	关键参数
1.0V 内核	FPGA VCCINT	先于或同时于 3.3V IO	最后掉	VCCINT 达 90% 后才允许 IO 上电
1.8V VDDQ	DDR3	与 1.0V 无强依赖，但 VTT 须跟随	与 VDDQ 同掉	上电斜率 ≤ 5V/ms，VTT 须跟踪
3.3V IO	FPGA / Flash	在 VCCINT 90% 之后建立	最先掉	—
全部	MCU	3.3V 稳定后复位释放至少 50ms	—	复位监控阈值 2.93V

提示：FPGA 厂商（Xilinx/Intel）都有专门的 Power Sequencing 应用笔记，里面通常给出”推荐的顺序 + 每级最大延时”，直接照抄比自己推导快得多。

抄完这张表，结论就清晰了：需要的顺序是 1.0V → 1.8V → 3.3V，复位最后释放。

方案选型：三条路，我选了”级联使能 + 复位监控”

实现上电时序的路子基本就三条：

EN 级联（PGOOD 链）：每颗 DCDC 的使能脚由上一级的 Power Good 信号驱动，形成硬连线的顺序链。零软件参与，可靠，成本几乎为零。
专用时序控制器 / PMIC：一颗芯片管所有电源轨，可配置顺序和延时，还有监控和掉电保护。适合电源轨多、有复杂掉电需求的产品，代价是 BOM 和调试成本。
软件控制：GPIO 拉各路 EN，代码里按顺序延时使能。灵活，但依赖软件活着——复位跑飞、程序卡死的瞬间，时序约束就失效了，只适合对时序要求宽松的场合。

我的选择是 方案 1 打底 + 方案 3 做微调：

DCDC1（1.0V）EN 直连使能；
DCDC1 的 PGOOD → DCDC2（1.8V）的 EN；
DCDC2 的 PGOOD → LDO_EN（3.3V 使能，延迟用 RC 拉出 5ms 余量）；
复位监控芯片（TPS3823-33，阈值 2.93V，带 200ms 上电复位延时）监控 3.3V，输出接所有数字芯片的复位。

这样即使软件一行代码没跑，时序链也是成立的——这是我在这件事之后定下的原则：时序约束不允许只依赖软件。

关键细节：PGOOD、复位延时和掉电顺序

原理图看着简单，坑全在细节里，这几个是我实际踩过或差点踩的：

PGOOD 是开漏输出。必须外接上拉电阻到正确的电压域——我第一次直接上拉到 3.3V，结果 1.0V 的 PGOOD 信号在 3.3V 还没建立时处于悬空状态。正确做法是上拉到被驱动那级 EN 所需的电压域，并且确认 EN 阈值（大多数 DCDC 的 EN 引脚阈值在 1.2V 左右，上拉到 1.8V~3.3V 都可行）。

复位延时必须比”最后一轨稳定时间”长。TPS3823 标配 200ms 上电复位延时，足够覆盖我们的电源爬坡（实测最后一级从使能到稳定约 20ms）。如果用 RC 复位，注意 RC 的”稳定时间”取决于阈值电压，不是 0.7×RC 那么简单，且没有迟滞——复位监控芯片比 RC 电路可靠一个量级，差价几毛钱，别省。

掉电顺序同样有要求。数据手册要求的掉电顺序通常是上电的逆序（IO 先掉、内核最后掉）。我们板上 3.3V 是负载最重的一路，放电自然最快，1.0V 靠 DCDC 输出电容维持到最后，实测顺序天然符合要求——但这是”测出来符合”，不是”设计出来的符合”。若负载分布不同，就需要在掉电路径上加主动放电（如输出并一个由 PGOOD 反相控制的 MOS 放电管）。

软件侧的配合：给时序链留”重新上电”的能力

虽然硬连线保证了底线，软件侧我仍然留了一个后手——通过 GPIO 可以整体关断再重新使能电源链，实现真正意义的”重新上电”，而不是软复位：

/* 全局电源重启：顺序与硬件时序链一致，仅用于致命故障恢复 */
void power_cycle_device(void)
{
    /* 1. 拉低全局使能（切断 PGOOD 链的源头） */
    HAL_GPIO_WritePin(EN_ALL_GPIO_Port, EN_ALL_Pin, GPIO_PIN_RESET);
    HAL_Delay(100);                       /* 等所有轨彻底放电 */

    /* 2. 重新使能，硬件链自动完成 1.0V -> 1.8V -> 3.3V */
    HAL_GPIO_WritePin(EN_ALL_GPIO_Port, EN_ALL_Pin, GPIO_PIN_SET);
    HAL_Delay(250);                       /* 覆盖最长爬坡 + 200ms 复位延时 */

    /* 3. 走到不了这里：3.3V 复位监控会复位整个 MCU */
    NVIC_SystemReset();
}

注意第 3 步其实”到不了”——3.3V 重新上电会触发 TPS3823 复位整个 MCU。这段代码的价值在于把恢复动作收敛到”一次干净的重新上电”，避免故障态的设备靠反复软复位吊命。

调试方法：四通道示波器一次抓全上电过程

改完板子，验证不能靠”多上电几次没坏”，要直接看波形。我的标准姿势：

四个通道分别挂 1.0V、1.8V、3.3V、复位信号（探针地就近接地过孔）；
触发设置在 1.0V 爬坡沿（边沿触发，1.0V 通道，阈值 0.5V）；
时基放到 10ms/div，单次触发抓整个上电过程；
逐项核对：顺序是否正确、每级建立时间、PGOOD 翻转时机、复位释放点相对 3.3V 稳定点的裕量。

那次实测抓到的波形里还顺带发现一个问题：3.3V 建立后有约 8ms 的轻微下探（硬盘/网口负载突增），距离复位阈值只有 100mV 余量。后来把 3.3V 的输出电容加大了一档，余量拉开到 400mV 以上。这种”差一点就误触发复位”的问题，看万用表是永远发现不了的。

常见坑清单

这次经历踩到/差点踩到的坑，集中列一下：

复位用 RC 电路，无迟滞、阈值模糊，电源缓升时 MCU 复位释放过早；
PGOOD 开漏输出忘了上拉，或上拉到了错误的电压域；
只管上电顺序、不管掉电顺序，热插拔/异常掉电场景暴露问题；
上电复位延时（如 200ms）与电源爬坡时间没做裕量核算；
DCDC 的 soft-start 与 PGOOD 翻转点没核对，导致后级使能抢跑；
用软件 GPIO 时序替代硬件时序链，复位/死机后时序约束失效；
板子验证只做”上电成功”，没有用示波器看过一次真实上电波形。

上电时序设计自查清单

☑ 逐颗芯片抄录数据手册的 power sequencing 要求，形成需求表

☑ 确定上电顺序与掉电顺序（掉电通常为逆序）

☑ 时序链用硬连线实现（PGOOD 级联 EN），不依赖软件

☑ PGOOD 上拉到正确电压域，EN 阈值已核对

☑ 复位监控芯片替代 RC 复位，阈值与延时留足裕量

☑ 复位释放时间 > 最后一轨稳定时间 + 数据手册要求的保持时间

☑ 掉电路径验证过（异常掉电、热插拔场景）

☑ 示波器四通道实测上电波形，顺序/建立时间/复位释放点逐项核对

☑ 电源稳定后的电压下探距复位阈值 ≥ 200mV

☑ 软件保留”干净重新上电”的恢复路径

写在最后

上电时序这件事的教训，和上一期 SDRAM 布线的教训其实是同一句话：数字工程师最容易栽在”模拟世界的先后顺序”上。布线看的是空间，时序看的是时间，都不写在代码里，但都写在数据手册里。

下一期预告：换个方向，聊聊软件侧的坑——《FreeRTOS 队列与信号量使用陷阱：从”队列满了丢数据”到”优先级继承没生效”，那些文档里一笔带过、实战里天天见的坑》。

Category嵌入式硬件