cancel
Showing results for 
Search instead for 
Did you mean: 

USB EZ-PD Type-C

MaLi_3529141
New Contributor

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
Reply
1 Solution
ShifangZ_26
Moderator
Moderator

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
Reply
8 Replies
ShifangZ_26
Moderator
Moderator

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
Reply
falu_294486
New Contributor

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
Reply
ShifangZ_26
Moderator
Moderator

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
Reply
falu_294486
New Contributor

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
Reply
ShifangZ_26
Moderator
Moderator

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
Reply
falu_294486
New Contributor

Hi Lisa,

below is 5v to 20v time about 296ms

slope_3.jpg

0 Likes
Reply
ShifangZ_26
Moderator
Moderator

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
Reply
falu_294486
New Contributor

Hi Lisa,

   i fixed this issue, is timing issue.

thank a lot of

0 Likes
Reply