- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Pranava
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Pranava
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
/O
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Pranava
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Pranava
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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