CCG5 sink fet enabling

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
mamic_3349671
Level 1
Level 1

Hi,
we are working with CCG5 (CYPD5225-96BZXI) and SDK 3.2.1.
We have found the following anomaly (or at least we think it may be an anomaly): when our device works as SINK and we connect a USBC source device (without any other power supply), we can observe that pin VBUS_C_CTRL_P1 (or VBUS_C_CTRL_P2), initially Hi-Z (when we insert USBC cable), goes low (psink_enable function is called by DPR library that we don't have source code) before PD profile matching analysis is realized.
Then, if a matched PD profile is found, the pin remains low otherwise it retuns Hi-Z after about 65ms (psink_disable function is called by DPR library that we don't have source code).
In this way, we find sink fet enabled for 65ms also in case of not matching PD profile and this could be a problem for our system.
Is possible to avoid psink_enable before PD profile matching analysis?

Best regards,
MM

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

Hi MM,

If you could like to enable VBUS_C_CTRL (dessert to LOW) after CC negotiation completed, you could try to use below way to implement it.

make the following change in config.h:

/* Turn C-FET on only when PD contract is in place. */

#define APP_VBUS_SNK_FET_ON_P1() \

{ \

if (dpm_get_info(0)->contract_exist) \

pd_internal_cfet_on(0, 0); \

}

#define APP_VBUS_SNK_FET_ON_P2() \

{ \

if (dpm_get_info(1)->contract_exist) \

pd_internal_cfet_on(0, 0); \

}

Best Regards,

Lisa

View solution in original post

0 Likes
15 Replies
RajathB_01
Moderator
Moderator
Moderator
250 replies posted 100 replies posted 50 replies posted

Hi, are you using a custom board or one of our evaluation boards?

Regards,

Rajath

0 Likes
RajathB_01
Moderator
Moderator
Moderator
250 replies posted 100 replies posted 50 replies posted

Hi,

What is the voltage on VBUS when sink FET is turned on before PD negotitation (and during 65ms) ?

Can you send the CC log between the power adapter and CCG5?

Regards,

Rajath

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

Hi MM,

If you could like to enable VBUS_C_CTRL (dessert to LOW) after CC negotiation completed, you could try to use below way to implement it.

make the following change in config.h:

/* Turn C-FET on only when PD contract is in place. */

#define APP_VBUS_SNK_FET_ON_P1() \

{ \

if (dpm_get_info(0)->contract_exist) \

pd_internal_cfet_on(0, 0); \

}

#define APP_VBUS_SNK_FET_ON_P2() \

{ \

if (dpm_get_info(1)->contract_exist) \

pd_internal_cfet_on(0, 0); \

}

Best Regards,

Lisa

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rajath, hi Lisz,
we are using our custom board.
The board is not powerd at the beginning so the VBUS is zero, then, when we connect USBC power supply (in not matching profile is a USBC monitor) we see VBUS to 5V for 65ms.
Using the code suggested by Lisz the problem with fet opening seems solved.
We observe also that (same behavior with and without modification) after PD negotiation, source device (power supply) ask for a DR_Swap accepted by sink (our board) and this is followed by a Hard_reset that triggers a cyclic sequence (log in attach).
Is this sequence correct?
The only way to avoid Hard_reset is to set "DR_Swap response" as REJECT in port configuration but in this way nothing works (DP and USB3) in case of PD profile matching.

BR

MM

0 Likes

MM,

It can be seen that Hard Reset is being issued after the acceptance of a VCONN_Swap message.

What is the DFP device being used? Is it also USB/DP host/source?

Regards,

Rajath

0 Likes

In this case we are connecting a USBC monitor (it assume DFP role) that is USB and source device but I don't think it is DP host (what do you mean with "DP host"?).

This device is connected with our PC board with CCG5 that could be source/sink and USB host.

BR

MM

0 Likes

Hi,

I meant USB host / DP source. Anyway, the monitor is issuing VCONN_Swap.

CCG5 is accepting it before Hard Reset appears.

Can you set VCONN_Swap response to 'Not supported' ?

Keep DR_Swap response to 'accept'.

Regards,

Rajath

0 Likes
lock attach
Attachments are accessible only for community members.

Hi,

changing VCONN_Swap in 'Not_Supported", it has the same behavior:

PD negotiation

DR_Swap -> accept

VCONN_Swap -> Accept

Hard_reset

This, working with Lisz modification and connecting USBC power supply with not matching profile (and VCONN_Swap in 'Not_Supported").

Not only:

Without Lisz modification, connecting USBC power supply with matching profile I obtain (Test04_F.ccgx):

PD negotiation

DR_Swap -> accept

VCONN_Swap -> Accept

Soft_reset

With Lisz modification, connecting USBC power supply with matching profile I obtain (Test08_F.ccgx):

PD negotiation

DR_Swap -> accept

VCONN_Swap -> Accept

Hard_reset

MM

0 Likes

Hi,

after other investigations, we have hypothesized the reasons for cyclical reset issue caused by 'Hard Reset'. It would seem due to the fact that in case of sink device (powered only by USBC), after a failed negotiation, after taking 5V profile with Capability Mismatch (our device requires at least 20V@3A and this profile is set as higher capability), and after accepting a DR_Swap requested by the source, on its own initiative, the sink requires a VCONN_Swap to the source and after that, a hard reset is generated.
Probably hard reset is due to the fact that the sink does not have enough power to start the board and therefore is not able to generate the voltage for the VCONN.

The hard reset occurs in case of PD non-matching (without or with Lisz modification) because when VCONN_Swap request is done, the board is powered by a 5V, insufficient to generate VCONN voltage, and also in case of PD matching (with modification) because when VCONN_Swap request is done, the board is not powered at all (the preactivation was not done due to Lisz modification) so that it is not possible to generate the VCONN voltage.

How can we prevent, our device in non-matching PD condition, from requiring VCONN_Swap?

BR

MM

0 Likes

Hi MM,

The CCG5 will require VCONN to do the alt mode negotiation. That cannot be disabled.

The Hard Reset will be sent as per the PD spec since the source is not sending 'PS_RDY' message for sourcing VCONN.

The only way to solve this issue will be to have the source (monitor) send 'PS_RDY' and source VCONN correctly.

Regards,

Rajath

0 Likes

Hi Rajath,

thank you for your answer.

Is not clear for me when you write that:

"The Hard Reset will be sent as per the PD spec since the source is not sending 'PS_RDY' message for sourcing VCONN"

I'm thinking that since VCONN_Swap message was sent by CCG5 (in sink status and not externally powered) and the monitor (in source status) ACCEPT it, is CCG5 task to send PS_RDY message.

PS_RDY messege will never arrive because is not possible for our board (in sink status) to provide VCONN voltage.

Is this analysis correct?

Is correct that CCG5 in sink status requires VCONN_Swap to the source?

BR

0 Likes

Hi MM,

Can I know if the supply for V5V_Px pins on CCG5 is being generated on the board?

You are right that CCG5 should be sending PS_RDY.

If V5V_Px is not generated, we can suggest a workaround as below:

in source file pdss_mx_hal.c

Under function pd_vconn_enable(  )

Comment out the section:

/* If V5V is not present, return error. */

    if ((pd->intr1_status & PDSS_INTR1_STATUS_V5V_STATUS) == 0)

        return CCG_STAT_FAILURE;

Let us see if this works.

Also please confirm with a monitor that can source higher power to further corner this issue.

Regards,

Rajath

0 Likes

Hi Rajath,

sorry for late in response but I haven't had the board until now.

Introducing your workaround it seems work in fact connecting our sink device to a source device without any matching PD profile, it request a "VCONN_Swap" and after it we can see a Softreset instead HardReset as before.

This is good for us but I have some doubts about the fact that instead of avoiding making the function fail, I thought it was more correct to prevent the sink from calling VCONN_SWAP. Is this correct for you?

Do you think that workaround can have side effects on PD behavior?

Thank you

Massimo

0 Likes

Hi MM,

When I previously discussed with the FW engineers, they were of the opinion that preventing the VCONN_Swap call would have some side effects on the PD. Hence to prevent violating the PD spec to the maximum possible extent, disabling VCONN detection error was the concluding workaround.

Regards,

Rajath

0 Likes

Ok, thanks, we will use suggested workaround.

Regards,

MM

0 Likes