No 5A PDO after power swap

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.
OlEr_1999891
Level 5
Level 5
50 replies posted 25 replies posted 25 sign-ins

Hi!

In our docking station we have support for 100W / 5A power source and the Source PDO has 5000mA configured.  Originally, we had the Port Role configured as Source and later Dual Port + Default Port Role = Source. When we had like this, the system exposed 20V / 5A PDO to the laptops so they charged with 100W when supported. 

However, we noticed that some laptops didnt initiate DP-alt mode and/or USB-communication 100% of the time and if we changed to Dual Role, Default port role = Sink so that dock initially sink 5V and then we trigger a PR_Swap to initiate 20V charging we got much better compatibility with tricky laptops.

But, problem is that the PDO that is communicated to the laptop after this PR_Swap is made, only max current 3A is added in the response with the result that some laptops (e.g. Macbooks) will not move up to 5A charging. Looks like the 5A support is somehow "filtered" out?

How do we solve this? Have attached Analyzer dump and config-file.

Cheers

Olof

 

OlEr_1999891_1-1645629678831.png

 

OlEr_1999891_0-1645629468686.png

 

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

Hi Pranava!

Ok, so we introduced an VCONN_SWAP before triggering the PR_SWAP:

dpm_pd_command (port, DPM_CMD_SEND_VCONN_SWAP , NULL, us_pr_swap_cb);

And that seems to work. After the PR_SWAP, a SOFT RESET is automatically trigged (not sure if from laptop or dock?) which triggers a new Discover Identity of the cable EMCA and then we get source_cap with 5A PDOs included.

We have tested on a range of laptops but we are still unsure if this behaviour is within the standard and that don't get problem with some device.

Could you check the associated trace and get back with comment if this is ok approach or if we should try something different?

Cheers

Olof

 

OlEr_1999891_0-1646048735223.png

 

View solution in original post

0 Likes
9 Replies
Pranava_YN
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi,

3A is advertised even when you have set the Source PDO to be 5A when cable supports only up to 3A. Please check if you are using a valid USB-IF 5A certified cable and see if the advertised PDOs contain 5A. 

 

Best regards,
Pranava
0 Likes

Hi!

The cable is certified and it supports 5A and when we run the dock as default Power Source and there is no PR_SWAP involved the PDOs shows 5A. Could it be that the VCONN power is not correctly handled so that the EMCA chip is not powered? Could you please take a look at the PD log that was included and see if you can see where the problem is? Line 45 is where you have the 3A PDOs. Attached is also the config-files. You have the initial cable discovery in the beginning, but not any after that.

Cheers

Olof

0 Likes

Hi Olof,

Not handling VCONN power might be a possible case. As per spec, only VCONN Source can send SOP_PRIME messages. Can you please try the following,

void dpm_update_def_cable_cap(500);   Can you please call this before dpm_init function in main.c. This is just a test to see if Cable capacity is the blockage for not advertising 5A PDOs.

After doing this if you find that the 5A PDOs are advertised. Please check the VCONN handling during the PR_SWAP. 

Set "Vconn retain on" parameter to Yes in Port Information section of Configuration Table.

Please let me know the outcome of these.

Best regards,
Pranava
0 Likes

Hi!

Thanks for getting back. We will try your proposal there. Is the code where the 5A PDOs are filtered available as source-code or they are in the binary part?

But just so I understand, the SOP_PRIME message is initially sent when the laptop is VCONN Source. Then later there is a PR_SWAP but there is no VCONN_Swap (at least not always, a bit unclear). But does the PD controller "remember" the original SOP_PRIME message after the PR_SWAP or we should try to get a new (by doing a VCONN_Swap?) after the PR_SWAP?

We use the concept from the CCG4 Dock example for the handling the swaps:

OlEr_1999891_0-1645693974215.png

 

/O

0 Likes

Hi,

The code to filter out is present in the DPM side which is provided in binary format. 

PD controller should initialize a VCONN_SWAP to become VCONN Source and get cable capabilities. It will not remember the cable capabilities earlier received by laptop.

Best regards,
Pranava
0 Likes

Hi!

Ok, maybe the problem is there somewhere. Maybe you would like to take a look into the EZ-PD CCG4 Dock ref design project and see how that was solved (or not) there. We will investigate and get back.

Cheers

Olof

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

Hi Pranava!

Ok, so we introduced an VCONN_SWAP before triggering the PR_SWAP:

dpm_pd_command (port, DPM_CMD_SEND_VCONN_SWAP , NULL, us_pr_swap_cb);

And that seems to work. After the PR_SWAP, a SOFT RESET is automatically trigged (not sure if from laptop or dock?) which triggers a new Discover Identity of the cable EMCA and then we get source_cap with 5A PDOs included.

We have tested on a range of laptops but we are still unsure if this behaviour is within the standard and that don't get problem with some device.

Could you check the associated trace and get back with comment if this is ok approach or if we should try something different?

Cheers

Olof

 

OlEr_1999891_0-1646048735223.png

 

0 Likes
Pranava_YN
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi Olof,

 

Sorry for replying late. I made a comment earlier but due to some issue at my end it is not posted.

Using VCONN_SWAP and sending Discover ID to cable to know its capabilities before sourcing is the right way.

Best regards,
Pranava
0 Likes

HI Pranava!

Yes, after more testing it seems to be a robust solution. You might consider implementing something similar in the CCG4 Dock Ref design project for future customers that wants 5A on their docks.

Cheers

Olof

0 Likes