CYPD4236 PR_SWAP fail

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.
MaLi_3529141
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

Hi there,

I just used CYPD4236 for Dock example code , call the API to do PR_SWAP:

pd_prot_send_ctrl_msg(0,SOP,CTRL_MSG_PR_SWAP);

However, UFP immediately issues Soft_Reset and aborts the action of PR_SWAP.

(Please refer to the attachment for CC Log.)

1. Why is soft_reset happening?

2. How to complete PR_SWAP?

thanks

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

Hi ,

1. The best way to initial PR_SWAP without interrupt PD stack machine is:

dpm_pd_command (US_TYPEC_PORT_IDX, DPM_CMD_SEND_PR_SWAP, NULL, NULL);

You can add callback function for this to make sure PR_SWAP is completed. For example, dpm_pd_command (US_TYPEC_PORT_IDX, DPM_CMD_SEND_PR_SWAP, NULL, us_pr_swap_cb) in CCG4 dock example code.

2. As per the CC log:

pastedImage_0.png

First, CCG4 initial PR_SWAP here (Refer #1 on above picture), CCG4 is UFP and SINK Role.

After DFP was "ACCEPT" PR_SWAP, CCG4 response with GOODCRC and then initial Soft_Reset(Refer #2 on above picture). As per PD3.0 SPEC, you can got below information:

pastedImage_1.png

The strange is the DFP is again to "ACCEPT" (Refer #3 on above picture) after Soft_Reset. And then advertise SOURCE_CAP. The right process shall be: PS_RDY from OLD SOURCE (set it power to vsafe0V) and then PS_RDY from OLD SINK mode.

pastedImage_2.png

The root cause is: DFP is not follow SPEC after Soft_reset message occurred.

Best Regards,

Lisa

View solution in original post

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

Hi ,

1. The best way to initial PR_SWAP without interrupt PD stack machine is:

dpm_pd_command (US_TYPEC_PORT_IDX, DPM_CMD_SEND_PR_SWAP, NULL, NULL);

You can add callback function for this to make sure PR_SWAP is completed. For example, dpm_pd_command (US_TYPEC_PORT_IDX, DPM_CMD_SEND_PR_SWAP, NULL, us_pr_swap_cb) in CCG4 dock example code.

2. As per the CC log:

pastedImage_0.png

First, CCG4 initial PR_SWAP here (Refer #1 on above picture), CCG4 is UFP and SINK Role.

After DFP was "ACCEPT" PR_SWAP, CCG4 response with GOODCRC and then initial Soft_Reset(Refer #2 on above picture). As per PD3.0 SPEC, you can got below information:

pastedImage_1.png

The strange is the DFP is again to "ACCEPT" (Refer #3 on above picture) after Soft_Reset. And then advertise SOURCE_CAP. The right process shall be: PS_RDY from OLD SOURCE (set it power to vsafe0V) and then PS_RDY from OLD SINK mode.

pastedImage_2.png

The root cause is: DFP is not follow SPEC after Soft_reset message occurred.

Best Regards,

Lisa

0 Likes

Hi Lisa,

   We modify config table, the soft reset does not happen again.

But the other problem is, why UFP send PR_SWAP and not reply PS_RDY.

error.JPG

0 Likes

Hi ,

You need to check whether the hardware on your end :

1. Whether the VBUS is discharged to <1.0V?

2. Whether the firmware have capabilities to control 5V source on your hardware end with VBUS_P_CTRL.

4. CCG4 have VBUS_MON pin to measure the voltage of VBUS via internal ADC.

Best Regards,

Lisa

0 Likes

Hi Lisa,

   I find problem about no PS_RDY, because i didn't VBUS_P_CTRL ON.

So the UFP success sent PS_RDY and provide 5v to laptop, but when I change to 19V, laptop is shot down.

My process is as follows;

1. VBUS_P_CTRL  OFF, and UFP send PR_SWAP.

2. get DFP PS_RDY than VBUS_P_CTRL  ON (safe 5v)

3. UFP send src_cap and laptop chose 19v

4. swap adopter to 19v (VBUS_P_CTRL still ON), than laptop shot down (i didn't see UFP send PS_RDY)

0 Likes

Hi ,

Can you please kindly check the time between 5V to 19V with scope? It seems timeout here to caused this. You may need rise slew rate of power.

Best Regards,

Lisa

0 Likes

Hi Lisa,

below is 5v to 20v time about 296ms

slope_3.jpg

0 Likes

Hi ,

Please kindly decrease the time to 200ms (Of course, smaller is better) from hardware side or regulator setting. Since 250ms will hit the time out of VBUS ENABLE timer.

Best Regards,

Lisa

0 Likes

Hi Lisa,

   i fixed this issue, is timing issue.

thank a lot of

0 Likes