USB EZ-PD™ Type-C Forum Discussions
What is the process to revert a CY4500 USB-C Analyzer back to its original firmware, 1.0 that supports USB-C PD 2.0?
Only the original firmware, version 1.0 is compatible and with the original EZ-PD Analyzer Utility (No "Protocol" in the title of the original Utility).
Instructions to convert a CY4500
- FROM version 1.0 for USB-C PD 2.0 supported by EZ-PD Analyzer Utility
- TO version 3.10 for USB-C PD 3.0 supported by EZ-PD Protocol Analyzer Utility
are fairly straight forward. Is there any way to revert back to version 1.0 ?
After updating, I noticed more information is captured using the PD 3.0 compatible firmware. However, I'd like to attempt to recreate captures I'd make using the PD 2.0 compatible firmware. Alternatively, Is there a mode with the PD 3.0 firmware version 3.10 to create a capture similar to the PD 2.0 code?
First of, apologies if I've missed this as a FAQ, but haven't been able to find a similar query.
I'm looking into designing a multi-port rear seat charger with the CCG3PA. So far, I've not been able to find any design resources (such as datasheets and reference designs ...etc) on the Infineon website.
Am I missing something? is there a process to go through, in order to gain access?
Thanks in advance.
Pin 24, VCCD which is the output of an internal 1.8V regulator for internal logic, comes up to about .9V and slowly drains down to 0. Thus, the chip has no voltage to communicate with the USB C adapter.
Electrically, it looks like my layout and their Eval Kit (CY4533 EZ-PD) are the same.
Please see attachments.
Base on application note mention "The dead battery Rd resistors are disabled by the application firmware once the device is powered up."
But we want to disable as early as before power up.
Could you have any suggestion?Show Less
I have found some stock in a CCG4 part but there are some extra characters at the end of the part number. Does anybody know what these extra characters mean?
CYPD4225-40LQXI / FW: HTC AR 4
Any help is greatly appreciated.Show Less
We are working on a device that needs the ability to charge connected devices and if a data connection is present (at UFP) act as a hub. (while charging)
Following the Charge through dongle application, it seems this would be possible.
VBUS circuit not shown
For the CCG3, we have the CYPD3120 and the CYPD2122 for the CCG2
1) should the CCG3 and CCG2 be swapped? (in the diagram)
2) For the the HX3, CYUSB3302 we are unsure if the ACA-dock feature is necessary? or is there a better suited HUB chip?
3) The pass through dongle uses a DRP CCG3, (CYPD3123) because our application dose not require DRP could the CYPD3120 work in its place? (for a pass through application)
We are trying to get a design working with display port over USBC. We are using an adapter to attach the DP monitor and power our device. The firmware of the CCG3 is based on the Cypress notebook example. The DP HPD pin I've set to GPIO1 by defining HPD_P0_PORT_PIN and HPD_P1_PORT_PIN to be GPIO_PORT_1_PIN_1, the pin we want, in pdss_hal.h. This pin is tied to our display port controller's HPD pin. This pin is always low even with a monitor attached to the adapter. The CY4500 protocol analyzer shows DP negotiations taking place. The monitor also responds initially by coming out of standby but nothing ever displays with it eventually going back to sleep.
The implementation does not have USB2 or SBU tied to the CYPD3125. We have a separate, passive mux that handles orientation of the cable based on a CCG3 GPIO providing polarity (which does work fine). But two display port lanes are always on the USB superspeed lines and the AUX channel is always on SBU lines. CC pins are tied to the CCG3.
I'm not entirely sure where to start debugging the firmware, any help is appreciated.Show Less
I'm working on a custom board which is based on H3XPC EVK and replace the NCP81239 (2PD) to NCP81231(1PD), in this design, PD port only has 1 and I2C address changed, so how do I make my custom board work?
I modified the source code as,
In "stack_params.h", I updated "#define NO_OF_TYPEC_PORT (1u)"
In "power_control.h", I updated the I2C address from 0x74 to 0x77.
Then I used PSoC Creator 4.4 to build PD project, but very sad that it showed the error of
- prj.M0120:Build error: warning: type of 'gl_dpm_port_type' does not match original declaration
- prj.M0120: Build error: note: previously declared here
I have no idea how this error came out since it purely defined in "dpm.h" as
"extern port_type_t gl_dpm_port_type[NO_OF_TYPEC_PORTS]; /**< Current port type (DFP/UFP) for each PD port. */"
BTW, the SDK I used is "EZ-PD CCGx Dock SDK (Version 3.3, July 12, 2020)".Show Less
We have a design that is using the CYPD5225 with TGL and a burnside bridge retimer on each port, however after the system exits S4/S5 after the first boot we cannot enumerate usb3/DP alt mode/thunderbolt unless we physically unplug/replug.
This is based on the CYPD5225-96BZXI_notebook_tbt project based on sdk 3.4.0.
After some discussion, we have a workaround of issuing a port reset command based on the system power state changes written to SYS_PWR_STATE register from the EC. (This was disabled on the project due to BC1.2 being disabled due to size requirements.
So I shortened the callback handler for this in app.c app_update_sys_pwr_state to only trigger dpm_typec_command (i, DPM_CMD_TYPEC_ERR_RECOVERY, NULL);
This fixes the issue of devices not being recognized after resume, however it will reset power to the device - which we want to avoid, as we cannot resume/hibernate etc without the device resetting.
Is there a way to trigger only re-configuring the retimer/SOC on resume?
I have noticed the following:
It seems the SDK code monitors VSYS - and will trigger retimer_set_evt(param_1,RT_EVT_VSYS_ADDED); for each retimer when VSYS is restored. However in our design the retimer is on a different supply than the CCG5225 (which is always on). So I do not think this will get triggered.
I tried to manually call this from our power state transition handler:
retimer_set_evt(TYPEC_PORT_0_IDX,RT_EVT_VSYS_ADDED); and RT_EVT_VSYS_REMOVED when we would enter/exit S0 (using the EC command handler app_update_sys_pwr_state) for each port, however this does not seem to enable the alternate modes through the retimer.
I did some additional digging and thinking, and I also wondered if the PD controller needs to notify the SOC to configure alt modes as well? perhaps through the call ridge_force_status_update or some other method?