1 2 Previous Next 15 Replies Latest reply on Dec 5, 2018 6:14 AM by mamic_3349671

    CCG5 sink fet enabling

    mamic_3349671

      Hi,
      we are working with CCG5 (CYPD5225-96BZXI) and SDK 3.2.1.
      We have found the following anomaly (or at least we think it may be an anomaly): when our device works as SINK and we connect a USBC source device (without any other power supply), we can observe that pin VBUS_C_CTRL_P1 (or VBUS_C_CTRL_P2), initially Hi-Z (when we insert USBC cable), goes low (psink_enable function is called by DPR library that we don't have source code) before PD profile matching analysis is realized.
      Then, if a matched PD profile is found, the pin remains low otherwise it retuns Hi-Z after about 65ms (psink_disable function is called by DPR library that we don't have source code).
      In this way, we find sink fet enabled for 65ms also in case of not matching PD profile and this could be a problem for our system.
      Is possible to avoid psink_enable before PD profile matching analysis?

       

      Best regards,
      MM

        • 1. Re: CCG5 sink fet enabling
          RajathB_01

          Hi, are you using a custom board or one of our evaluation boards?

           

          Regards,

          Rajath

          • 2. Re: CCG5 sink fet enabling
            RajathB_01

            Hi,

             

            What is the voltage on VBUS when sink FET is turned on before PD negotitation (and during 65ms) ?

            Can you send the CC log between the power adapter and CCG5?

             

            Regards,

            Rajath

            • 3. Re: CCG5 sink fet enabling
              ShifangZ_26

              Hi MM,

               

              If you could like to enable VBUS_C_CTRL (dessert to LOW) after CC negotiation completed, you could try to use below way to implement it.

               

              make the following change in config.h:

              /* Turn C-FET on only when PD contract is in place. */

              #define APP_VBUS_SNK_FET_ON_P1() \

              { \

              if (dpm_get_info(0)->contract_exist) \

              pd_internal_cfet_on(0, 0); \

              }

               

              #define APP_VBUS_SNK_FET_ON_P2() \

              { \

              if (dpm_get_info(1)->contract_exist) \

              pd_internal_cfet_on(0, 0); \

              }

               

              Best Regards,

              Lisa

              • 4. Re: CCG5 sink fet enabling
                mamic_3349671

                Hi Rajath, hi Lisz,
                we are using our custom board.
                The board is not powerd at the beginning so the VBUS is zero, then, when we connect USBC power supply (in not matching profile is a USBC monitor) we see VBUS to 5V for 65ms.
                Using the code suggested by Lisz the problem with fet opening seems solved.
                We observe also that (same behavior with and without modification) after PD negotiation, source device (power supply) ask for a DR_Swap accepted by sink (our board) and this is followed by a Hard_reset that triggers a cyclic sequence (log in attach).
                Is this sequence correct?
                The only way to avoid Hard_reset is to set "DR_Swap response" as REJECT in port configuration but in this way nothing works (DP and USB3) in case of PD profile matching.

                 

                BR

                MM

                • 5. Re: CCG5 sink fet enabling
                  RajathB_01

                  MM,

                   

                  It can be seen that Hard Reset is being issued after the acceptance of a VCONN_Swap message.

                  What is the DFP device being used? Is it also USB/DP host/source?

                   

                  Regards,

                  Rajath

                  • 6. Re: CCG5 sink fet enabling
                    mamic_3349671

                    In this case we are connecting a USBC monitor (it assume DFP role) that is USB and source device but I don't think it is DP host (what do you mean with "DP host"?).

                    This device is connected with our PC board with CCG5 that could be source/sink and USB host.

                     

                    BR

                    MM

                    • 7. Re: CCG5 sink fet enabling
                      RajathB_01

                      Hi,

                       

                      I meant USB host / DP source. Anyway, the monitor is issuing VCONN_Swap.

                      CCG5 is accepting it before Hard Reset appears.

                      Can you set VCONN_Swap response to 'Not supported' ?

                      Keep DR_Swap response to 'accept'.

                       

                      Regards,

                      Rajath

                      • 8. Re: CCG5 sink fet enabling
                        mamic_3349671

                        Hi,

                        changing VCONN_Swap in 'Not_Supported", it has the same behavior:

                        PD negotiation

                        DR_Swap -> accept

                        VCONN_Swap -> Accept

                        Hard_reset

                         

                        This, working with Lisz modification and connecting USBC power supply with not matching profile (and VCONN_Swap in 'Not_Supported").

                         

                        Not only:

                        Without Lisz modification, connecting USBC power supply with matching profile I obtain (Test04_F.ccgx):

                        PD negotiation

                        DR_Swap -> accept

                        VCONN_Swap -> Accept

                        Soft_reset

                         

                        With Lisz modification, connecting USBC power supply with matching profile I obtain (Test08_F.ccgx):

                        PD negotiation

                        DR_Swap -> accept

                        VCONN_Swap -> Accept

                        Hard_reset

                         

                        MM

                        • 9. Re: CCG5 sink fet enabling
                          mamic_3349671

                          Hi,

                          after other investigations, we have hypothesized the reasons for cyclical reset issue caused by 'Hard Reset'. It would seem due to the fact that in case of sink device (powered only by USBC), after a failed negotiation, after taking 5V profile with Capability Mismatch (our device requires at least 20V@3A and this profile is set as higher capability), and after accepting a DR_Swap requested by the source, on its own initiative, the sink requires a VCONN_Swap to the source and after that, a hard reset is generated.
                          Probably hard reset is due to the fact that the sink does not have enough power to start the board and therefore is not able to generate the voltage for the VCONN.

                           

                          The hard reset occurs in case of PD non-matching (without or with Lisz modification) because when VCONN_Swap request is done, the board is powered by a 5V, insufficient to generate VCONN voltage, and also in case of PD matching (with modification) because when VCONN_Swap request is done, the board is not powered at all (the preactivation was not done due to Lisz modification) so that it is not possible to generate the VCONN voltage.

                           

                          How can we prevent, our device in non-matching PD condition, from requiring VCONN_Swap?

                           

                          BR

                          MM

                          • 10. Re: CCG5 sink fet enabling
                            RajathB_01

                            Hi MM,

                             

                            The CCG5 will require VCONN to do the alt mode negotiation. That cannot be disabled.

                            The Hard Reset will be sent as per the PD spec since the source is not sending 'PS_RDY' message for sourcing VCONN.

                            The only way to solve this issue will be to have the source (monitor) send 'PS_RDY' and source VCONN correctly.

                             

                            Regards,

                            Rajath

                            • 11. Re: CCG5 sink fet enabling
                              mamic_3349671

                              Hi Rajath,

                              thank you for your answer.

                              Is not clear for me when you write that:

                               

                              "The Hard Reset will be sent as per the PD spec since the source is not sending 'PS_RDY' message for sourcing VCONN"

                               

                              I'm thinking that since VCONN_Swap message was sent by CCG5 (in sink status and not externally powered) and the monitor (in source status) ACCEPT it, is CCG5 task to send PS_RDY message.

                              PS_RDY messege will never arrive because is not possible for our board (in sink status) to provide VCONN voltage.

                              Is this analysis correct?

                               

                              Is correct that CCG5 in sink status requires VCONN_Swap to the source?

                               

                              BR

                              • 12. Re: CCG5 sink fet enabling
                                RajathB_01

                                Hi MM,

                                 

                                Can I know if the supply for V5V_Px pins on CCG5 is being generated on the board?

                                You are right that CCG5 should be sending PS_RDY.

                                If V5V_Px is not generated, we can suggest a workaround as below:

                                in source file pdss_mx_hal.c

                                Under function pd_vconn_enable(  )

                                 

                                Comment out the section:

                                 

                                /* If V5V is not present, return error. */

                                    if ((pd->intr1_status & PDSS_INTR1_STATUS_V5V_STATUS) == 0)

                                        return CCG_STAT_FAILURE;

                                 

                                Let us see if this works.

                                Also please confirm with a monitor that can source higher power to further corner this issue.

                                 

                                 

                                Regards,

                                Rajath

                                • 13. Re: CCG5 sink fet enabling
                                  mamic_3349671

                                  Hi Rajath,

                                  sorry for late in response but I haven't had the board until now.

                                  Introducing your workaround it seems work in fact connecting our sink device to a source device without any matching PD profile, it request a "VCONN_Swap" and after it we can see a Softreset instead HardReset as before.

                                  This is good for us but I have some doubts about the fact that instead of avoiding making the function fail, I thought it was more correct to prevent the sink from calling VCONN_SWAP. Is this correct for you?

                                  Do you think that workaround can have side effects on PD behavior?

                                   

                                  Thank you

                                  Massimo

                                  • 14. Re: CCG5 sink fet enabling
                                    RajathB_01

                                    Hi MM,

                                     

                                    When I previously discussed with the FW engineers, they were of the opinion that preventing the VCONN_Swap call would have some side effects on the PD. Hence to prevent violating the PD spec to the maximum possible extent, disabling VCONN detection error was the concluding workaround.

                                     

                                    Regards,

                                    Rajath

                                    1 2 Previous Next