Modifications to Charge through dongle application

[joa_4818671]

Hi 

We are building a product based on the Charge through dongle application.

I have hit a snag, we need some specific functionality on the input pdo selection. My first thought was to customize the CCG2 firmware, but not only is the example code not available, it seems the toolchain is falling out of support. (I could be wrong here)

So my question is, can I get the below behavior to work on the CCG3 while using the pre-compiled hex file for the CCG2?

- Our device dose not contain any data or display ports, so they need to be removed from the project

       +EDDIT: I have changed settings in config.h but need to use some of the controlling pins, still getting an error when reassigning them

- subtract 5W from the charge through power when separate device when activated

- when power is disconnected, the device will provide back up power, so the PDO needs to be swapped to 5V3A PDO, then stopped when battery is drained 

- no PDO higher then 12V 

Any help pointing me to the right areas would be greatly appreciated, I am relatively new to the PSOC and EZ-PD system

Thanks for your time

[Pranava_YN]

Hi,

I couldn't quite understand your system. If you are not using USB Data or DP ports, may I know the reason you chose CCG3 Charge through Dongle as a base project?

Regarding this question: - subtract 5W from the charge through power when separate device when activated

What do you mean by a separate device? Does this mean a Power Sink in the UFP?

PDOs can be configured using Configuration Utility that we have - https://www.infineon.com/cms/en/design-support/tools/configuration/usb-ez-pd-configuration-utility/

Please elaborate on your design so that I can help you better.

[joa_4818671 · Accepted solution]

Maybe using CCG was an error on my part, we originally looked at using ccg3pa, but we wanted the ability to add a usb hub (HX3) to the device in a future version, and thought that the example code would help speed up development.

For the 5W device, it is attached via a second usb, because the device draws a maximum of 900mW, resistors are used on the D+/- line. The question is can it dynamically be added to the total charge through power budget? When not needed the 5V regulator feeding the port is disabled by the CCG3, so full power can be sent to the main charge through port. (CCG3)

The design uses the same circuitry as the charge through dongle application, it just doesn't have any of the USB hub, HDMI, or ethernet ports. It does have a battery charger between the ccg2 sink port and the ccg source port. The battery charger will only use the power remaining as the main devices use less, it handles this internally.

So the functionality we are looking to get is for the ccg2 to negotiate the highest PDO with the correct voltage. So say the device connected to the ccg3 source port, it would ask for 9V, so the ccg3 would set the ccg2 to get the highest power 9V PDO. The CCG3 can then offer a PDO at that voltage with a slightly reduced current. It would open the FET switch to provide the "pass through" voltage. Then when the main device (connected to the ccg3 port )asks to step down to a 5V PDO, rather then setting a lower PDO on the ccg2, a 5V regulator is switched into the power path to provide 5V to the ccg3 port while still allowing The CCG2 input to stay at the higher voltage PDO. This will allow the excess power to be consumed by the battery charger.

It looks like this is very close to the current functionality of the charge through adapter. The things I can sse from here that need to be done

- remove usb hub, hdmi, and Ethernet code (I think that can be done in the config.h file)

- add the 5W power draw of the external device to the power budget when active

- make it so ccg2 dose not downgrade to 5V PDO when CCG3 does

- when ccg2 cable is removed, switch ccg3 to run off battery power

Let me know if this makes senesce, or if you think I have miss

[Pranava_YN]

Hi,

Apologies for the delay in responding. The implementation you have explained is possible by modifying the source code of CCG3. You will have to modify functions in ctd_us_solution.c file.

Please check ctd_us_task() function for the entire CTD negotiation flow. 

[joa_4818671]

All good, I also missed the notification

Things are starting to make sense on the CCG3 side, I think I have almost removed all of the other port (HDMI, USB-A, ETH) code, no build errors from that.

Two snags on our end, it looks like the CCG3 that is populated is the CYPD3125, from the data sheet it looks like the only difference is it is I2C boot loaded and does not come with application firmware prepopulated.

The second issue might be more tricky, the ccg2 was implemented strictly as a sink with no FET on VBUS, do you know if this can be configured with the utility, or would the design need to be amended?

[Pranava_YN]

Two snags on our end, it looks like the CCG3 that is populated is the CYPD3125, from the data sheet it looks like the only difference is it is I2C boot loaded and does not come with application firmware prepopulated.

>> Yes, you can either port your current bootloader and bootloadable projects to CYPD3125 or use CYPD3123 part directly.

The second issue might be more tricky, the ccg2 was implemented strictly as a sink with no FET on VBUS, do you know if this can be configured with the utility, or would the design need to be amended?

>> It is highly recommended to use the reference design as close as possible. This setting will not be possible in Configuration Utility. Even in the design CCG2 is strictly a Sink.