CCG3 resetting after dpm_start()

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
NiMc_4245981
Level 3
Level 3
10 replies posted 10 questions asked 5 replies posted

I'm having trouble with the CCG3 resetting during startup.  I used a GPIO (pin 28) and oscilloscope to track it down and VDDD (pin 17) drops about 1 V about 3 ms after the call to dpm_start(0) returns.  At this point in time, VDDD is provided by the internal LDO from VBUS (pin 31).  VBUS is 5 V and I don't see any drop.  dpm_start(0) is called in the main function before the task loop.  I added a delay, so nothing else was running in software at this time.

I tried cutting traces until the problem went away and it was VBUS_C_CTRL (pins 29, 30) that caused the problem to go away.  So, it seems like the FET drivers might be part of the problem.

I didn't have any problems until the latest boards we built.  Was there a change in the chip to either the internal LDO or the FET drivers?  Should I be using a different FET?  Any idea what might be the problem?

I'm using a CYPD3120-40LQXI.  My FETs are DMN3018SSD-13.  My schematic is very similar to Figure 15 in the datasheet (002-03288_EX-PD_CCG3).

I have 10 μF on VBUS, 1.2 μF on VDDD.  VDDIO is connected to VDDD.  I have 10 MΩ to ground on pins 29 and 30.

0 Likes
1 Solution
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

Thanks for the update. Yes, from the graph it looks like its due to switching from VBUS to VSYS since VSYS is given higher priority over VBUS by default when both are present. 

Yes, it can be used to disable VSYS, please refer to the example usage below from pd_hal_init() function (Host SDK 3.4). You could also try disabling the macro VBUS_TO_VSYS_SWITCH_ENABLE.

tmp = pd->vreg_vsys_ctrl;
tmp |= PDSS_VREG_VSYS_CTRL_VREG20_EN;
tmp &= ~(PDSS_VREG_VSYS_CTRL_ENABLE_VDDD_SWITCH | PDSS_VREG_VSYS_CTRL_VREG20_ONOFF_CNTR_MASK);
pd->vreg_vsys_ctrl = tmp;

Please try it and let us know if it helps resolve the issue.

Best Regards,
Sananya

View solution in original post

3 Replies
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

As per your description, you are powering CCG3 primarily from a Type-C VBUS i.e. with CCG3 as a PD sink. If that is true, I hope dead battery is enabled in the configuration. Please provide a snippet of your schematic showing the CCG3 connections. The FETs you are using as same as recommended part in our datasheet, and you mentioned VBUS is at 5V at the VBUS pin so I dont think they would be causing a problem.

-If VDDD is lower than 2.7V, the device would be likely to reset. Could you please try adding a larger capacitor on the VDDD pin? 

-Please let us know how VSYS pin is connected? 

-What is the firmware being used in the current boards and is the USB block used? Please test with the Host SDK 3.4 firmware and let us know if the issue still occurs.

Best Regards,

Sananya

NiMc_4245981
Level 3
Level 3
10 replies posted 10 questions asked 5 replies posted

I did some more testing today.  My VSYS pin is connected to a 3.3 V supply that is not powered until the consumer FETs are turned on.  In the image below, the bottom channel is VSYS.  The top channel is VDDD.   So, it looks like the LDO is turning off as the 3.3 V supply ramps up, but isn't high enough yet to take over.

I noticed there is a register called PDSS_VREG_VSYS_CTRL.  Can this be used to disable the VSYS input?  Is there an example of how to do this?  If so, I will disable it until 4 ms after the consumer FETs are turned on.  That should avoid the dip.

Yes, this is a device powered only by the Type-C VBUS as a PD Sink, there is no battery.  Dead battery is enabled in the configuration.  I have tried adding capacitance to VDDD, up to 8.8 μF and the voltage drop only improved to 0.9 V.

 

NiMc_4245981_1-1613057239743.png

 

0 Likes
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

Thanks for the update. Yes, from the graph it looks like its due to switching from VBUS to VSYS since VSYS is given higher priority over VBUS by default when both are present. 

Yes, it can be used to disable VSYS, please refer to the example usage below from pd_hal_init() function (Host SDK 3.4). You could also try disabling the macro VBUS_TO_VSYS_SWITCH_ENABLE.

tmp = pd->vreg_vsys_ctrl;
tmp |= PDSS_VREG_VSYS_CTRL_VREG20_EN;
tmp &= ~(PDSS_VREG_VSYS_CTRL_ENABLE_VDDD_SWITCH | PDSS_VREG_VSYS_CTRL_VREG20_ONOFF_CNTR_MASK);
pd->vreg_vsys_ctrl = tmp;

Please try it and let us know if it helps resolve the issue.

Best Regards,
Sananya