First enumeration after reset takes very long time

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
lock attach
Attachments are accessible only for community members.
widget
Level 1
Level 1
5 sign-ins First reply posted First question asked

I am working with a CYPD6125, using the CYPD6125-40LQXI_notebook project from CCGx Host SDK as a starting point.  I am acting as the power source, and have a design that is mostly functional.  However, I've noticed some very strange behavior that is causing severe problems with my devices.  When my CYPD6125 first comes out of reset, there is a ~11 second delay between when the first device is plugged into it and when enumeration begins.

I am using a CCG EVK base board with a CY4531 CCG Daughter Card as my sink device, and providing power from my design (the DC power to the EVK is disconnected).  Using a CY4500 EZ-PD protocol analyzer, I do not see any traffic when the device is first plugged in.  11 seconds after being plugged in, I see the PD protocol traffic that I would expect to see.  I attached a logic analyzer to CC1 and CC2, and have attached the results to this post as ccg6_PD_Delay.png.

The transition from GND to 3.3V happens when I power on my design (DUT).  Two seconds later, I plug in the EVK and see the CC1 line transition to 1.5V and the CC2 line go to ground.  After the EVK is plugged in, I see CC2 going up to 5V, which I believe is my design using CC2 to act as VCONN while CC1 acts as CC.  However, 2 mS later CC1 goes down to 0.5 V, then starts to drain down to GND while CC2 is deasserted (ccg6_PD_Delay_badPulse.png).  This pattern repeats 11 times, once per second, at which time I see CC2 staying high for 70 mS, at which time PD negotiation messages being (ccg6_PD_Delay_goodPulse.png)

I only see this behavior the first time a device is connected after my DUT comes out of reset, and only when my DUT is providing power.  I see the same behavior when attaching any USB C device that does not have its own power source.  If I plug in the DC power to the EVK, PD negotiation occurs immediately after the cable is plugged in.  If I plug the EVK in with no DC power and wait the 11 seconds for it to finish PD negotiation, I can unplug it from my DUT, immediately plug it back in, and see PD negotiation begin and complete immediately (ccg6_PD_No_Delay.png).

I have copied the initialization portion of my code as main_init.c in the attached code.zip.  When using a debugger, after invoking dpm_get_info I see I see dpm_stat->attach have a value of true each time CC2 goes to 5V, then being set to false when CC2 goes back to ground.  The dpm_stat->attach variable continues to fluctuate between true and false until the 11th iteration of the CC2 line pulsing, at which point the value remains true and the connection appears stable.  I have also copied my config.h into code.zip, in case the answer lies there.

Is there an initial piece of functionality I need to perform in order to properly initialize my design?  If not, do you have any recommendations on what next steps I can take to try and determine why the PD negotiation process is taking so long to start?

Thank you in advance.

0 Likes
1 Solution
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hello ,

Could you please kindly confirm if the VBUS have been enabled 5V or not with the PD delay case? From the Delay or bad Pulse case, it seems the Hard reset have issued on CC line before Source Cap is issued. 

The Correct/expect actions from Source behaver is:

5V shall be enabled on VBUS to power on sink after CC voltage have valid value with vrd = ~1.68V with 3A capabilities. The CC denounce time out is ~275ms, otherwise, the Type-C will be reset and re-attach again. 

 

Best Regards,

Lisa 

 

View solution in original post

0 Likes
1 Reply
ShifangZ_26
Moderator
Moderator
Moderator
10 likes given 250 sign-ins 1000 replies posted

Hello ,

Could you please kindly confirm if the VBUS have been enabled 5V or not with the PD delay case? From the Delay or bad Pulse case, it seems the Hard reset have issued on CC line before Source Cap is issued. 

The Correct/expect actions from Source behaver is:

5V shall be enabled on VBUS to power on sink after CC voltage have valid value with vrd = ~1.68V with 3A capabilities. The CC denounce time out is ~275ms, otherwise, the Type-C will be reset and re-attach again. 

 

Best Regards,

Lisa 

 

0 Likes