MPQ4242 PD controller (source) and Raspberry Pi 5

[mfolejewski]

I’m currently working on a commercial battery-backed power supply project. Its main functionality is to provide a USB-C output with a custom 5V/5A (25W) Power Delivery profile designed for use with a Raspberry Pi 5.

For development purposes, I’m using the following setup:

– Evaluation board EVQ4242-VE-00B
– MPS USB-to-I²C dongle (EVKT-USBI2C-02)
– Virtual Bench Pro 4.0 software

The problem I’ve encountered is as follows (see attached image):

The official 27W USB-C power supply for the Raspberry Pi, when connected to the Pi 5’s USB-C port, continues broadcasting PD Source_Capabilities messages on the CC lines for at least 5 seconds after power-on. After this period, the Pi 5 firmware is able to negotiate PD and successfully request the 5V/5A profile.

In contrast, the MPQ4242, in its default configuration, only transmits PD messages for about 2.6 seconds before entering sleep mode. Such a shorter timing prevents proper PD negotiation of the Pi 5 and it falls back to the default 5V/3A profile.

My question: How can I configure the MPQ4242 to extend its PD broadcast duration from the default ~2.6 seconds to at least 5.2 seconds?

The datasheet only mentions: “The USB PD engine can disable the clock and enter sleep mode if no PD command is detected.”
I’ve searched for references to an “extra delay” or “timer” setting, but found nothing so far.

The MPQ4242 is otherwise an excellent fit for my application: it’s standalone, requires no additional MCU, and integrates both a PD source controller and a regulated buck-boost converter. This makes it one of the most attractive solutions on the market for designs without firmware development.

So far, I also haven’t found yet any other MPS devices that support both standalone PD source mode and custom 5V/5A profiles while maintaining PD broadcasts for >5 seconds.

Any guidance would be greatly appreciated. Thanks in advance!

[mfolejewski]

In USB Power Delivery standard, the Source periodically advertises its power capabilities to an attached Sink by transmitting Source_Capabilities messages at intervals of tTypeCSendSourceCap (100–200 ms, typically 150 ms).

If the CapsCounter mechanism is implemented, once the Source detects that a Sink is attached, it continues sending these Source_Capabilities messages. After nCapsCount messages have been sent (nCapsCount = 50), if the Sink has not responded, the Source must assume that the Sink is non-responsive. At that point, the Source stops sending Source_Capabilities messages and disables Power Delivery communication.

Given the defined timing:

• tTypeCSendSourceCap = 100–200 ms (150 ms typical)

• nCapsCount = 50

The Source will advertise its capabilities for approximately 5–10 seconds (7.5 s typical) before giving up if no response is received.

As a practical example, a Raspberry Pi 5 responds to Source_Capabilities messages after about 5.2 seconds, which fits within the defined response window.

I observed that, unlike the Raspberry Pi 27 W power supply, the MPQ4242 controller transmits Source_Capabilities 17 times in groups of three messages, over a total duration of about 2.6 s. This behavior does not fully align with the USB Power Delivery specification, which defines capability broadcasts spaced by tTypeCSendSourceCap up to nCapsCount. Is there a way to extend the broadcasting period of Source_Capabilities to at least 5s, or does another comparable MPS device with an integrated PD controller meet this requirement?