Verify USB-C Sink Startup with Every Local Rail Off

A USB-C powered board may work while connected to a debugger and fail when powered only through its intended port. The debugger can energize a controller or pullup that hides a startup dependency. Verify attachment and power-path behavior from a genuinely unpowered state, including the product’s supported battery conditions.

Trace the first available energy path

Identify which circuitry is alive before VBUS becomes available and how the port presents the required sink behavior. Determine whether the selected controller provides the necessary unpowered attachment functionality or requires external circuitry. Follow its reference design and current datasheet rather than adding resistors around an integrated function by assumption.

For example, the TPS25730 datasheet describes integrated dead-battery termination, a VBUS-powered startup path and configuration-dependent sink behavior. These are properties of that controller family. Other controllers may have different startup requirements and external component arrangements.

Draw the startup dependency chain

Write the sequence from cable attachment to controller operation, sink-path enable, system rail generation and host firmware execution. Look for a circular dependency: firmware cannot enable the path if the processor needs that same path to receive power. Check configuration straps or stored configuration used before the host becomes active.

Distinguish attachment detection from a USB Power Delivery contract. The system should not assume its preferred voltage or current is available simply because a cable is present. Define which loads may start at the initial available power and which must wait for the controller’s confirmed status.

Test orientations and depleted states

Disconnect the debugger and other interfaces that can provide power. Allow the intended rails to discharge under the product’s normal conditions. Test both connector orientations with representative supported sources and cables. Record the configuration-channel state, VBUS, controller supply, sink-path output and system reset timing where practical.

For battery-powered products, test the defined depleted, absent and charged battery cases using an appropriate controlled setup. A battery that supports the controller during development can conceal the failure mode that matters most when a user first connects a charger.

Investigate the earliest missing event

If startup fails, identify whether attachment, VBUS availability, controller startup, path enable or processor boot failed first. Repeatedly replacing the application firmware is unlikely to resolve a missing hardware attachment condition. Likewise, a valid power contract does not prove the downstream regulator started correctly.

Preserve the tested controller configuration, cable orientation and rail traces with the release record. Revisit cold startup after changes to configuration, power switches, startup loads or debug connections. A passing warm reconnect is useful evidence, but it does not substitute for the fully unpowered case.