3 Replies Latest reply on Feb 9, 2020 6:45 PM by ShifangZ_26

    CCG3PA Implementation Questions

    DaSa_4627446

      Hello,

       

      We were settling on CCG3PA in a new design which is a Type C/Type A dual port charging only, with fixed 5V supply. I had a few more questions about the implementation I was hoping to get answered:

       

      - Does Cypress have a design/schematic check service?

       

      - There seems to be GPIO that is preferred for certain functions in design examples (i.e. external VCONN FET enable, Type A current sensing etc.) - is there a definitive listing of these? Can this all be changed in firmware?

       

      - There appears to be no RCP (Reverse Current Protection) on the CCG3PA - is this possible using an external current sensor (into an ADC pin) and modifying the firmware (for both Type A and Type C ports)?

       

      - I've read in a notice and in the forums that the FW was closed source - what does this mean? Is it possible to get full access under NDA if we run into issues when we customise the higher level code?

       

      - For CSP connection - is there a way to make this Kelvin connection? Is Pin 22 the -ve input of the current sense amplifier or is this just a general ground? Any recommendations here?

       

      - Is there a schematic of internal PFET drivers? How does the internal pull-up on the VBUS_P_CTRL path function if VBUS_IN_DIS is used in the configuration shown here (CCG3PA Power Adapter/Car Charger (1C+1A) single chip solution hardware design tips) for a Type C/Type A port - what is it pulling up to? In this case do we need an external pull-up?

       

      - With respect to the PFET drivers again - are they able to continuously sink current if shorted to VBUS = 20V while trying to pull-down? It would seem that with an internal pull-down of 3kΩ max the dissipation is a minimum of 133mW - can we add external resistor in series with the pin to reduce dissipation in this instance? Also noticed there is difference in sink currents vs drive strengths given (Table 32. Gate Driver DC Specifications) is there a firmware control aspect here too? I think a schematic of how this works might clarify things for me.

       

      - Is it possible to disable FW upgrade over CC pins after an initial FW update?

       

      - We eventually want to extend this to control an external supply up to 20V/5A - this will be over an I2C/UART comms port instead of direct feedback. Is there any device that is preferred to implement this between CYPD3171-24LQXQ, CYPD3174-24LQXQ and CYPD3175-24LQXQ? Are there any application examples of firmware/hardware modified to support digitally controlled power supply via I2C/UART/SPI?

       

      Regards

       

      djs

        • 1. Re: CCG3PA Implementation Questions
          ShifangZ_26

          Hi djs,

           

          Kindly refer my comments as below:

          - Does Cypress have a design/schematic check service?

          >> Yes, Cypress have worldwide design technical support team,  you can get the contract from your local FAE if you are not going to use the community (you are using community now.) for schematic review.

           

          - There seems to be GPIO that is preferred for certain functions in design examples (i.e. external VCONN FET enable, Type A current sensing etc.) - is there a definitive listing of these? Can this all be changed in firmware?

          >> The CCG3PA datasheet of pin-out have define of each pin of CCG3PA. If the GPIO can be working as GPIO, it is can be changed in firmware.

           

          - There appears to be no RCP (Reverse Current Protection) on the CCG3PA - is this possible using an external current sensor (into an ADC pin) and modifying the firmware (for both Type A and Type C ports)?

          >> Correct, there is no RCP on the CCG3PA. It is possible to use an external current sensor and modify the firmware. And the implement is very easy if you have been installed CCG3PA SDK.

           

          - I've read in a notice and in the forums that the FW was closed source - what does this mean? Is it possible to get full access under NDA if we run into issues when we customise the higher level code?

          >> Could you please kindly specified the thread you are referring to?

          >> Our CCGx SDK have opened almost firmware on websites, the disclose part is power delivery state machine. This part is follow Type-C and power delivery SPEC and updated timely as per the SPEC updates.

           

          - For CSP connection - is there a way to make this Kelvin connection? Is Pin 22 the -ve input of the current sense amplifier or is this just a general ground? Any recommendations here?

          >> The recommendation is listed in the KBA: Rsense Design Considerations On CCG3PA Applications – KBA229013

           

          - Is there a schematic of internal PFET drivers? How does the internal pull-up on the VBUS_P_CTRL path function if VBUS_IN_DIS is used in the configuration shown here (CCG3PA Power Adapter/Car Charger (1C+1A) single chip solution hardware design tips) for a Type C/Type A port - what is it pulling up to? In this case do we need an external pull-up?

          >> Yes, there need a external pull-up. You can refer a KBA for this question: Using the CCGx Power SDK, How Can VBUS_P_CTRL Pin of CCG3PA Be Used as a GPIO – KBA228399

           

          - With respect to the PFET drivers again - are they able to continuously sink current if shorted to VBUS = 20V while trying to pull-down? It would seem that with an internal pull-down of 3kΩ max the dissipation is a minimum of 133mW - can we add external resistor in series with the pin to reduce dissipation in this instance? Also noticed there is difference in sink currents vs drive strengths given (Table 32. Gate Driver DC Specifications) is there a firmware control aspect here too? I think a schematic of how this works might clarify things for me.

          >> There is no need to do this, since CCG3PA VBUS_P/C_CTRL is high current/voltage capabilities. And the discharge path is not go through the VBUS_P/C_CTRL pin, there are two VBUS discharge pin on CCG3PA and the CCG3PA shall be make sure one of them wire to VBUS directly. The pin name is VBUS_C_MONITOR/DICHARGE and VBUS_IN_DISCHARGE. And both of them have internal pull-down resistors and can be changed the resistor's value.

           

          - Is it possible to disable FW upgrade over CC pins after an initial FW update?

          >> You can use the FW locked function, the firmware will be locked and cannot be updated anymore. This is not the normal way and do not recommended.

           

          - We eventually want to extend this to control an external supply up to 20V/5A - this will be over an I2C/UART comms port instead of direct feedback. Is there any device that is preferred to implement this between CYPD3171-24LQXQ, CYPD3174-24LQXQ and CYPD3175-24LQXQ? Are there any application examples of firmware/hardware modified to support digitally controlled power supply via I2C/UART/SPI?

          >> Since the advantage of CYPD3171 is using directly feedback for controlling power supply, if you want to change to digital controlled, you can modify the firmware to achieve it. Currently, we the reference can be refer is CCG3PA Charger design and CCG4 dock design, which is using I2C controlled. 

          CCG3PA charger design: https://www.cypress.com/documentation/reference-designs/ez-pd-ccg3pa-usb-cpps-power-bank-solution-using-qorvo-formerly

          https://www.cypress.com/documentation/reference-designs/ez-pd-ccg3pa-usb-cpps-power-bank-solution-using-qorvo

          CCG4 dock design: https://www.cypress.com/documentation/reference-designs/ez-pd-ccg4-usb-type-c-monitordock-solution

           

          Best Regards,

          Lisa

          • 2. Re: CCG3PA Implementation Questions
            DaSa_4627446

            Hi Lisa,

             

            Thanks for your reply, this helps a lot.

             

            With respect to the closed source comment, you are correct, it was only for the PD stack which should be okay for our customisation.

             

            I am a bit confused by the page here Using the CCGx Power SDK, How Can VBUS_P_CTRL Pin of CCG3PA Be Used as a GPIO – KBA228399, specifically:

             

            "For power source only projects, the only design consideration is that it is a must to have VBUS_IN_DISCHARGE powered by a Type-A VBUS source."

             

            The example here CCG3PA Power Adapter/Car Charger (1C+1A) single chip solution hardware design tips has VBUS_IN_DIS connected to the Type C port and VBUS_C_MON connected to the Type A port. Which example is correct to follow for design with both Type A and Type C charging ports? Why must VBUS_IN_DISCHARGE be connected to the Type-A port for power source only applications?

             

            Regards

             

            David.

            • 3. Re: CCG3PA Implementation Questions
              ShifangZ_26

              Hi David,

               

              Good catch for this question before CCG3PA design, please kindly let me clarify it as below:

              The reason is:

              1. The VBUS_IN_DISCHARGE and VBUS_C_MON can be exchanged. (This is one note of the Example you have been mentioned above.).

              2.In general, the CCGx Power SDK can be classified to two types – power source only and dual role power. The following example firmware projects are CCG3PA applications as a power source only:

               

              • CYPD3171-24LQXQ_cla
              • CYPD3174-24LQXQ_pa_opto_fb
              • CYPD3175-24LQXQ_pa_direct_fb

               

              On the other hand, the example firmware project CYPD3171-24LQXQ_pb is for CCG3PA applications for dual role power.

              So that, if you are power source only design, the firmware use VBUS_C_MON for VBUS monitoring, you could use VBUS_IN_DISCHARGE for Type-A VBUS monitor, with this case, the firmware design is minimum. If your hardware design have swapped both, there is no problem to achieve the functions, the more efforts on firmware is need.

               

              Best Regards,

              Lisa