USB EZ-PD™ Type-C Forum Discussions
We would like re-start the project to read TYPE-C cable E-marker IC VDM data, we would start develop FW on CY4532 power board(It is CYPD4126-40LQXI), the on handed CY4532 power board is REV07, what is the FW project for CY4532 power board? Is CYPD4126-40LQXI_notebook on EZ-PD CCGx SDK? or CYPD4126-40LQXI_notebook on EZ-PD CCGx Host SDK? We do not need Cypress HPI function, it is not fit for our application, we will define our own HPI spec. Please kindle reply my question.Show Less
I'm working on board bring-up of the type-c USB 3.0 hub with HDMI display output.
We have used CYPD3120 as Type-C port controller along with PS186 chip from parade for DP to HDMI conversion.
The main difference from the EZ-PD CCG3 reference design is the use of Multi-Fuction Display Port in order to provide 2 separate SS lines for USB hub data and 2 SS line for DP alternate mode. At this moment I have both PS186 and CYPD3120 configuration and programmed but no video out is present on HDMI out.
From AZ-PD analyzer I see that the DP initialization goes well untill SL#33 (see file attached) when the Status packet indicates "Neither DFP_D nor UFP_D is connected".
Is there a chance to get some to get some feedback/help on this error?
I'm having some issues with the DisplayPort alternate mode demo that is included in the EZ-PD CCGx SDK 3.0.2. I'm currently using PSoC Creator 3.3 Service Pack 2 (PSoC 4 refuses to compile the demo project).
I don't actually have the demo board, but I have a custom board that is very similar in operation. I decided to flash the demo project on to my board to see if the problem I'm observing persisted. It did. Other errors showed up in the EZ-PD Analyzer scans when using the demo program on my custom board, but I'm not sure if they are related or not.
I have tested this board and firmware on many different models of Apple Macbooks. Every Mac model with a USB-C or Thunderbolt 3 port has worked flawlessly, until the most recent MacbookPro 13" 2 TB3 ports (MacbookPro15,4) release. Here are the technical details of that model. I also have observed that the behavior I describe below only occurs on the MacbookPro15,4 and not the Macbook15,2 (which is the 13" 4 TB3 port model).
When negotiating for DisplayPort Alt mode, most Macbooks follow this sequence: `Enter`, `Status Update`, wait for hot plug, `Configure`, and DP AUX negotiations begin. On the MacbookPro15,4 the sequence I observe is `Enter`, `Status Update`, `Configure`, `NAK`.
It appears that the MacbookPro15,4 is attempting to set up the alt mode using pin assignment C and selecting configuration for USB instead of "Set configuration for UFP_U as UFP_D". What I'm actually expecting to happen is that the Macbook set up for pin assignment E since that's what the demo program is configured to do.
I have attached two EZ-PD Analyzer scans. `cypress-dp-demo-mbp14-3` is a scan on a 2017 MacbookPro 15" and acts similarly to many other Macbooks. `cypress-dp-demo-mbp15-4` is the 2019 MacbookPro 13" 2 TB3 Port model that is failing. In particular, lines 79 and 81 of the scan.
Is there some configuration setting that I can tweak to get this working for the Macbook15,4 model? If not, what is the most likely point of failure that is causing the Macbook to issue a pin C assignment instead of a pin E?
We have a need for our dock to ask the connecting device what VID and PID they have through a Discover Identity message. Problem is that as far as we can see (and think), the connecting laptop send a "DR_Swap" directly after the 20V voltage has been negotiated and then it is the laptop sending the Discover Identity to the dock instead to initiate the alt-mode communication. See analyzer log dump.
Is there way get the dock to send a Disocver Identity before the DR-role swap? Or any other way for the dock to get VID/PID of the connecting device.
Noticed the main:sln_pd_event_handler method that is used in the CCG4 Dock ref design:
Could something be done here? Or change some PD Configuration-settings in the configuration of the FW?
I've modified the Power SDK to work with a custom power delivery design. Our design uses an external processor acting as a master with some I2C voltage regulators attached to it. The processor continuously polls the CCG3PA (CYPD-3175) and if the CCG3PA stack requires a voltage to be delivered, it will respond to the poll with the desired voltage. This works most of the time but occasionally, I get a dropped packet or a duplicate packet.
I am using the I2C example for the CCG3PA and have tried both polling and interrupt modes. It is part of the main loop. I instrumented the packets with a sequence number and when the dpm/app tasks are not running, it works fine, i.e. packets are in sequence. When I start the DPM, it affects something in the I2C stack that causes the phenomena described above. Without any sources to the DPM, I can't tell if the dpm task call or the app call are causing some time delays that would affect the I2C. My loop is something like this:
main calls process loop
process loop pseudo code:
respond to master request
i2c read buffer gets data
return to main
Does the DPM or the APP task do any blocking or anything else that might cause an occasional delay? Are there any timing tricks that I can try to help alleviate this problem?Show Less
Hello i have 2 LDO with output of 3.3V for each CCG3PA should i use just one LDO for both ?
Their both on same PCB but work independently but communicate throughout I2C.Show Less
Hello Cypress Community and RajathB_01,
How to initiate APDO request using CCG3PA.
And As per PD Specification we need to continuously initiate request packet for every 15 Sec.
So once after initiating APDO request and successful AMS sequence, Is above sequence handled in CCG3PA FW or Do we need to handle it explicitly by initiating APDO for every 15Sec?
For reference I've attached the Screenshot.
HI RajathB_01/Cypress Community,
I am trying to test BC1.2 features of CCG3PA.
As per my requirement, I want to use CCG3PA as a Snk device and thereby test features of a connected Provider(DCP/SDP/CDP).
When I connected a provider to CCG3PA, its BC1.2 FSM is staying in OFF state (BC_FSM_OFF).
So Do CCG3PA act as BC1.2 Snk and will it be able test any BC1.2 supported Provider connected to TypeC port?
if so Do we need to enable any Enum in Firmware ?
Do we have any documents regarding this?
Thanks and Regards,
We are using CYPD3120 to implement HDMI over type C, in our design and needed clarifications on the below points.
1. We are supporting source function on USB type C and not sink(However, both host and device functionality is required) and not looking for battery charger function and hence, we have left VBUS pin of CYPD3120 floating. Is this fine ?
2. My understanding is , when HDMI sink is connected to the Type C connector(via type C to HDMI cable), CC pin detects it and the information can be carried to Application processor(HDMI source) and Super speed MUX via HPD of CYPD3120. Is my understanding correct?
3. We haven't planned to provide SWD connector, as I understand we can configure the CYPD3120 over I2C. Any comments?
I have attached the schematics pdf for your reference. Kindly let me know any points of concern in the schematics.
Thanks and regards,
Abhilash GShow Less