Custom board with I2C regulator - PSRC EN timer keeps triggering UVP condition

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
phock
Level 3
Level 3
10 replies posted 25 sign-ins 5 questions asked

In my application, I am using an MPQ8875A regulator (controlled via I2C) as the regulator for USB PD with the CYPD3171.

Here are some relevant lines from config.h showing how I have hooked the I2C control of the regulator into the PD stack:

/*******************************************************************************
 * PSOURCE controls for PD port 1.
 ******************************************************************************/
#define REGULATOR_REQUIRE_STABLE_ON_TIME           (1)
#define REGULATOR_ENABLE(port)                      mpq8875a_output_enable(true)//BUCK_BOOST_EN_C_Write(0)
#define REGULATOR_DISABLE(port)                     mpq8875a_output_enable(false)//BUCK_BOOST_EN_C_Write(1)

#define REGULATOR_STATUS(port)                      mpq8875a_is_enabled()//(!BUCK_BOOST_EN_C_Read())

#define REGULATOR_TURN_ON_DELAY                     (50)

#define APP_VBUS_SRC_FET_ON_P1()                    \
{                                                   \
    pd_internal_pfet_on(0, false);                  \
    REGULATOR_ENABLE(0);                            \
}

#define APP_VBUS_SET_VOLT_P1(volt_mV)               mpq8875a_set_voltage(volt_mV)//vbus_ctrl_fb_set_volt(TYPEC_PORT_0_IDX, volt_mV)

#define APP_VBUS_SRC_FET_OFF_P1()                   \
{                                                   \
    REGULATOR_DISABLE(0);                           \
    pd_internal_pfet_off(0, false);                 \
}

 

I've monitored calls to pd_hal_measure_vbus() via SWD and I see that when the regulator puts out 5V on VBUS, the CYPD3171 can see this and measures 5V (I assume through VBUS_C_MON_DSG which is connected to VBUS on the output side of the provider FET).

 

The behavior I see is that the Cypress chip enables the regulator, then 140 ms later, sets the voltage to 5V engages the provider FET. 250 ms later, the Cypress disables the regulator because the APP_PSOURCE_EN_TIMER (250 ms timer) goes off and the software determines that VBUS never rose to the required level (although it clearly has, and the CYPD3171 can see the 5V on the VBUS_C_MON pin). So I end up here in psource.c line 470:

 

/*Timer Callback*/
void app_psrc_tmr_cbk(uint8_t port, timer_id_t id)
{
    app_status_t* app_stat = app_get_status(port);

    switch(id)
    {
        case APP_PSOURCE_EN_TIMER:
            /* Supply did not reach expected level. Turn off power and do error recovery. */
            timer_stop_range(port, APP_PSOURCE_EN_MONITOR_TIMER, APP_PSOURCE_EN_HYS_TIMER);
            app_stat->psrc_volt_old = VSAFE_0V;
            psrc_shutdown(port, true);

#if (VBUS_UVP_ENABLE)
            /*
             *If the VBUS does not reach VSAFE5V, then we need to treat this as an
             * under voltage condition. Since the UVP hardware detection cannot be
             * enabled when turning on the VBUS, this has to be manually triggered
             * from here by invoking the callback directly. Do this only if UVP is
             * enabled from the configuration table.
             */
            if (get_pd_port_config(port)->protection_enable & CFG_TABLE_UVP_EN_MASK)
            {
                app_psrc_vbus_ovp_cbk(port, false);
            }
#endif /* (VBUS_UVP_ENABLE) */

 

My question is, what could be the cause of this timer never being stopped? The regulator is enabled successfully, the 5V (which is the voltage requested) comes up in a matter of about 7 ms after being enabled which is well within the 250 ms given for VBUS to come up. As far as I can tell, the Cypress chip sees the 5V it is looking for.

 

Because of this error condition, power to the USB bus is cycled 3 times before the CYPD3171 gives up. I don't see any PD negotiation occurring between the CYPD3171 and the test device, Just 3 VBUS power cycles followed by 0V until the CYPD3171 is power cycled.

0 Likes
5 Replies
Wang_Fred
Moderator
Moderator
Moderator
5 questions asked 100 solutions authored 250 sign-ins

Hello,

May I know which firmware you get started, is it CYPD3171-24LQXQ_cla or CYPD3171-24LQXQ_pb from CCGx Power SDK 3.5?

For your specific issue, in psrc_enable(), the below timer is always started after PSource FET turned on.

timer_start(port, APP_PSOURCE_EN_TIMER, APP_PSOURCE_EN_TIMER_PERIOD, app_psrc_tmr_cbk);

If the period APP_PSOURCE_EN_TIMER_PERIOD expires, UVP would be triggered.  The action which could stop this timer is that also in psrc_enable() after REGULATOR_ENABLE(port):

timer_start(port, APP_PSOURCE_EN_MONITOR_TIMER, REGULATOR_TURN_ON_DELAY , app_psrc_tmr_cbk);

in which, APP_PSOURCE_EN_HYS_TIMER is triggered to stop that:

case APP_PSOURCE_EN_MONITOR_TIMER:
if (vbus_ctrl_set_is_idle(port))
{
/* Start Source enable hysteresis Timer */
timer_start(port, APP_PSOURCE_EN_HYS_TIMER,
APP_PSOURCE_EN_HYS_TIMER_PERIOD, app_psrc_tmr_cbk);
}

case APP_PSOURCE_EN_HYS_TIMER:
#if REGULATOR_REQUIRE_STABLE_ON_TIME
if (timer_is_running(port, APP_PSOURCE_EN_MONITOR_TIMER))
{
return;
}
#endif /* REGULATOR_REQUIRE_STABLE_ON_TIME */
timer_stop(port, APP_PSOURCE_EN_TIMER);

 

I assume this issue may be caused by below judgement is false - 

if (vbus_ctrl_set_is_idle(port))

You can double check if it's the cause.

 

Thanks,

Fred

 

0 Likes

Fred,

Modifying that function to return true doesn't solve the problem. I set breakpoints for the APP_PSOURCE_EN_MONITOR_TIMER as well as the APP_PSOURCE_EN_HYS_TIMER in the timer callback, both of which should be set before the PSOURCE_EN timer goes off and both have shorter periods. Neither of these timers went off. It seems like the direct feedback state machine in vbus_ctrl_fb_set_volt and its associated callback are tied in with psrc_en. The feedback pin in my design is unused and floating (NC). I was able to work around my issue by calling BOTH the I2C voltage set function as well as vbus_ctrl_fb_set_volt, as follows:

 

(from config.h)

#define APP_VBUS_SET_VOLT_P1(volt_mV)               mpq8875a_set_voltage(volt_mV);vbus_ctrl_fb_set_volt(TYPEC_PORT_0_IDX, volt_mV)

 

This is a bit of a hack - it would be nice to separate the dependency on the feedback pin for setting the voltage.

 

Thanks,

Patrick

0 Likes
Wang_Fred
Moderator
Moderator
Moderator
5 questions asked 100 solutions authored 250 sign-ins

HI Patrick,

You may need to do 2 things else - 

1. set the macro #define VBUS_CTRL_TYPE_P1 in stack_params.h to VBUS_CTRL_NONE;

2. using EZ-PD Configuration Utility to read the programming image generated after above action and modify the config file Port 0 -> Power Settings -> Feedback type to 'No feedback', then re-config the programming file.

Wang_Fred_0-1676513107090.png

Thanks,

Fred

0 Likes

When I chance VBUS_CTRL_TYPE_P1 to VBUS_CTRL_NONE, the device no longer negotiates any PD. In that case, I can't use the EZ-PD configuration utility to program the device. I haven't debugged this yet. I also have a separate issue, where my application works with the workaround I posted above, but I cannot read the configuration from the device using the configuration utility, or flash firmware over the CC lines. I suspect the bootloader from the PSOC creator project does not have the custom I2C/gpio control of the regulator and that could have something to do with why it doesn't work.

0 Likes
Wang_Fred
Moderator
Moderator
Moderator
5 questions asked 100 solutions authored 250 sign-ins

Hello,

May I know which firmware you get started, is it CYPD3171-24LQXQ_cla or CYPD3171-24LQXQ_pb from CCGx Power SDK 3.5?

Since you use VBUS_C_MON to detect VBUS voltage, your design should match the cla project.  If you are using the cla project, please take a try to disable below macro in config.h

#define REGULATOR_REQUIRE_STABLE_ON_TIME (0)

 

If it's still invalid, can you also attach the waveforms of VBUS_C_MON voltage / Mosfet control pin/cc pins for further debug.

 

Thanks,

Fred

0 Likes