UCPD 使用 Dead‑Battery 功能后 VBUS 不能稳定供电问题

Dead‑Battery（亏电电池）是 Type‑C Sink 设备非常实用的特性：MCU 整机没电时，外部 PD Source 依然可以识别 Sink 设备的 CC 下拉 Rd，输出 VBUS 给 MCU 上电启动。 在 STM32H5 使用 UCPD 外设实现该功能时，经常遇到一类迷惑故障：Type‑C 插上后 VBUS 周期性上电、掉电反复跳变，设备无法持续稳定供电。示波器可以看到 VDD 电压反复跌落，协议抓包反复出现EVENT_ATTACHED/EVENT_DETACHED事件。 很多开发者第一时间怀疑硬件原理图、线缆或者 PD 电源适配器，实际根源来自 HAL 库初始化函数执行时机，以及 Type‑C 规范对 CC 下拉电阻切换的时序约束。本文基于 LAT1691 官方故障复现实验，拆解硬件原理、故障根因、代码时序陷阱、完整落地流程与排错要点。

资料获取：实战经验 | LAT1691 UCPD使用Dead battery功能后Vbus不能稳定供电问题

1. Dead‑Battery 两种硬件实现方式

STM32H5 UCPD 支持两套实现亏电检测的硬件方案，二者硬件接线完全不同，选型需要参考 AN5225 拓扑框图。

1.1 外部 5.1kΩ 下拉电阻方案（NUCLEO‑H533 默认）

开发板默认在 CC1、CC2 引脚焊接外部 5.1kΩ 下拉电阻 Rd。

• 优点：MCU 完全掉电状态，依靠板载电阻对外呈现 Sink 下拉，Source 识别之后持续输出 VBUS；
• 注意：移除任意一路下拉电阻，就只能支持单方向插头插入；两个电阻全部移除，亏电状态下 Source 识别不到 Sink，无法上电。

该方案不需要使用 DBCC 引脚，属于纯硬件实现，不涉及 UCPD 内部 Dead‑Battery 逻辑。

1.2 UCPD 内部 Rd 下拉实现 Dead‑Battery（产品常用方案）

产品硬件去掉 CC 外部 5.1kΩ 电阻，DBCC1 与 CC1 直连、DBCC2 与 CC2 直连。 MCU 彻底断电时，硬件内部 NMOS 自动导通，在 CC 引脚生成等效 5.1kΩ 下拉电阻 Rd，让 PD Source 识别 Sink 设备并输出 VBUS。

关键点：必须 DBCCx 与 CCx 外部飞线直连，CC 链路上不能再并联其它下拉器件。

上电时序（AN5225 标准序列）

1. Step0：设备完全掉电，VDD=0V；DB 内部 Rd 生效；
2. Step1：Source 接入，输出 5V VBUS；
3. Step2：VBUS 给 MCU 供电，MCU 上电，VDD 上升至 3.3V，Dead‑Battery 内部 Rd 保持有效；
4. Step3：软件修改 ANAMODE 寄存器，切换 CC 线上 Rd，退出 Dead‑Battery 模式，移交 CC 控制给 UCPD 外设。

2. 故障现象与根因定位

2.1 故障现象

硬件采用内部 Rd 实现 Dead‑Battery，拔掉 ST‑LINK，仅依靠 Type‑C VBUS 供电。现象：

1. 插上 Type‑C，MCU 短暂上电，随后立刻掉电，不断循环；
2. 示波器观测：CC 引脚电平周期性跳变，MCU VDD 反复上电跌落；
3. STM32CubeMonitor‑UCPD 抓包大量重复：EVENT_ATTACHED→EVENT_DETACHED反复触发；
4. 适配器 Source 反复发送Source_Capabilities数据包，无法建立 PD 通信契约。

2.2 核心根因：HAL_Init 自动关闭 Dead‑Battery 下拉

HAL 库HAL_Init()内部调用HAL_MspInit()，而HAL_MspInit()内部默认执行HAL_PWREx_DisableUCPDDeadBattery()。 该函数会关闭 UCPD 硬件内部 Dead‑Battery 下拉 Rd。
时序问题：MCU 刚上电，UCPD 外设还没有初始化完成，HAL 就把 CC 内部 Rd 直接关闭。CC 引脚失去下拉电阻，PD Source 识别不到 Sink，随即关闭 VBUS 输出；VBUS 掉电之后 MCU 又掉电；再次插上线缆又重复整套循环。

临时验证手段：注释掉HAL_PWREx_DisableUCPD()调用，此时内部 Rd 持续保持打开，Source 持续识别 Sink，VBUS 可以稳定持续供电。 但仅仅注释该函数会带来第二个新问题：后续 PD 协议协商无法正常工作。

2.3 第二个时序陷阱：Rd 切换不能长时间悬空 CC

当准备正式进入 PD 通信，需要从 Dead‑Battery 内部 Rd 切换为 UCPD 外设管理的 CC Rd。 USB‑C Type‑C 协议明确约束：从 Dead‑Battery 模式切换到 VBUS 供电模式，CC 下拉电阻不能长时间进入完全悬空无下拉状态，仅允许极短瞬态超出规格（tRpValueChange）。
工程高频踩坑：系统时钟初始化耗时过长，从关闭 DB 下拉，到 UCPD 初始化接管 CC 引脚，中间间隔超时。CC 悬空时间超出规范允许窗口，PD Source 判定设备 Detach，直接切断 VBUS。

AN5225 标准时序要求：

Step4：UCPD 初始化之前执行 DisableUCPDDeadBattery；并且整个切换操作必须在规定时间窗口内完成，不能让 CC 长时间悬空。

错误执行流程： MCU 上电 → HAL_Init（关闭 DB 下拉，CC 悬空）→ 耗时很长的系统时钟配置 → 再初始化 UCPD。 时钟初始化占用大量时间，CC 引脚悬空超时，Source 直接断开 VBUS。

正确执行流程： MCU 上电 → 保持 Dead‑Battery 内部 Rd 有效 → UCPD 外设初始化准备就绪 → 在极短时间窗口内调用HAL_PWREx_DisableUCPDDeadBattery()，立刻由 UCPD 接管 CC 引脚 Rd 控制。

3. 硬件与软件落地实施要点

3.1 硬件设计要点（内部 Dead‑Battery 方案）

1. 去掉 CC1、CC2 外部 5.1kΩ 下拉电阻；
2. DBCC1 外部直连 CC1；DBCC2 外部直连 CC2；
3. CC 链路禁止并联额外下拉器件；
4. 参考 AN5225 Figure16 Non‑protected sink 拓扑。

如果不需要 Dead‑Battery 功能，则 DBCC1、DBCC2 直接接地。

3.2 软件修改关键点

1. 不要在 HAL_MspInit/HAL_Init 阶段执行HAL_PWREx_DisableUCPDDeadBattery()，需要注释掉自动生成的这一处调用；
2. UCPD 外设初始化全部准备完成之后，在很短时间窗口内调用HAL_PWREx_DisableUCPDDeadBattery()，马上移交 CC 引脚给 UCPD 硬件管理；
3. 禁止把HAL_PWREx_DisableUCPDDeadBattery()放在系统时钟配置之后、UCPD 初始化之前，会造成 CC 悬空超时；
4. 完成切换之后，UCPD 才可以正常进行 PD Source‑Capabilities 交互，完成电压契约协商，请求 5V/9V/12V 等 PD 档位。

3.3 调试工具手段

1. 示波器同时抓取 CC1、CC2、MCU VDD 波形，观察上电阶段 CC 下拉是否消失；
2. 使用 STM32CubeMonitor‑UCPD 工具抓取 PD 协议事件，查看 Attach/Detach 反复跳变；
3. STM32G0‑DISCO / STM32GO Discovery USB‑C 分析仪可以监听 CC 上 BMC PD 数据包。

4. 故障排查清单

1. 现象：上电反复掉电，Attach/Detach 循环
   • 核查：HAL_Init内部是否自动执行HAL_PWREx_DisableUCPDDeadBattery()；若是，注释该调用；
   • 核查 DBCC 与 CC 硬件连线，确认直连，CC 没有额外外部下拉。
2. VBUS 供电稳定，但 PD 协议无法协商通信
   • 核查：关闭 Dead‑Battery 的时机，必须 UCPD 已经初始化就绪之后才调用 Disable 接口；
   • 核查：Disable 之后到 UCPD 接管 CC 之间，系统时钟初始化是否占用过长时间，造成 CC 引脚悬空超时。
3. 拔掉 ST‑LINK，仅 Type‑C 供电完全无法开机
   • 核查硬件：DBCCx 与 CCx 是否连接；确认没有保留外部下拉；
   • 确认芯片复位后 Dead‑Battery 硬件功能默认开启。
4. 外部电阻 Dead‑Battery 方案，上电异常
   • 检查 CC1/CC2 两颗 5.1kΩ 电阻焊接，任意一颗缺失，对应插入方向无法识别。

5. 小结

1. STM32H5 UCPD 内部 Dead‑Battery 功能依靠 DBCC 与 CC 直连，MCU 掉电时硬件自动生成 5.1kΩ 的 CC 下拉 Rd，实现亏电状态 PD Source 识别设备输出 VBUS。
2. 高频坑点：HAL 库HAL_Init()会在早期自动调用HAL_PWREx_DisableUCPDDeadBattery()，刚上电就关闭 CC 内部下拉，PD Source 识别不到 Sink，造成 VBUS 周期性通断。
3. 仅仅注释该函数只能实现持续供电，还必须遵守 Type‑C 时序：UCPD 初始化就绪之后，才在短时间窗口调用 Disable 接口，避免 CC 引脚长时间悬空，否则 PD 通信依然失败。
4. 两套硬件方案区分：外部 5.1kΩ 电阻方案（NUCLEO 板）；DBCC‑CC 直连内部 Rd 方案（量产产品），两套方案不可混用。

6. FAQ

Q：我使用外部 5.1kΩ 下拉实现 Dead‑Battery，还会遇到这个问题吗？

A：外部电阻方案 CC 下拉不依赖 UCPD 内部硬件，HAL_PWREx_DisableUCPDDeadBattery()不影响外部电阻，不会出现该周期性掉电故障。

Q：DBCC 引脚如果悬空，还能使用内部 Dead‑Battery 吗？

A：不能。必须 DBCC1 与 CC1、DBCC2 与 CC2 外部直连，内部 NMOS 通路才可以工作。不需要该功能时 DBCC 引脚直接接地。

Q：为什么 CubeMX 自动生成代码会把HAL_PWREx_DisableUCPDDeadBattery()放在 HAL_MspInit 里面？

A：HAL 默认假设产品不使用 Dead‑Battery，复位后关闭内部下拉；当项目需要开启 Dead‑Battery 特性，需要开发者手动修改调用时机。

免责声明：本文全部基于 ST 官方 LAT1691 文档，硬件和固件实现请以 AN5225、芯片参考手册为准。