1 2 Previous Next 20 Replies Latest reply on Mar 4, 2019 9:32 PM by aldr_3203566

    Confirmation of VBUS_P_CTRL and VBUS_C_CTRL control logic in CCG2 CYPD2122-24LQXIT-notebook sample code

    aldr_3203566

      Confirmation of VBUS_P_CTRL and VBUS_C_CTRL control logic in CCG2 CYPD2122-24LQXIT-notebook sample code

       

      I would like to confirm a couple behaviors observed with this sample code, sorry to bring this discussion up with sample code that was created such a long time ago.

       

      I hope you have a CCG2 CY4521 Evaluation Kit and USBC smart phone (or other device) available.

       

      Using the CCG2 CY4521 Evaluation Kit.

      Program the CCG2 CY4521 Evaluation Kit with the attached code with a MiniProg3.

      Disconnect the MiniProg3 from the Evaluation Kit.

       

      Remove the jumper next to the USER BUTTON (SW1) jumper J11.

      After programming, set jumpers on the daughter card.

      J2 (V3P3 connect to VDDD)

      J3 (V3P3 connect to VDDIO)

       

      The attached code is the same as the below code with the addition of a button (SW1, USER SWITCH) to initiate a PR role swap.

       

      Simple CCG2 example firmware for power bank

      https://community.cypress.com/community/usb/ez-pd-type-c-usb/blog/2018/03/20/simple-ccg2-example-firmware-for-power-bank

       

       

       

       

       

       

      The first behavior that I would like to confirm.

       

      At first, be sure the USBC connection is disconnected.

      Power the CCG2 CY4521 Evaluation Kit with the AC adapter.

      Next plug in a USBC device, a Samsung Galaxy S8 was used for test.

       

      The USER BUTTON has the following logic programmed.  Interrupt on both falling and rising edges.

      When the button is PRESSED and held, PR role swap is initiated if the CCG2 is not the PR SOURCE.

      + This changes the CCG2 into the PR SOURCE.

      + The CCG2 will remain the PR SOURCE as long as the button is PRESSED.

       

      When the button is RELEASED, PR role swap is initiated if the CCG2 is not the PR SINK.

      + This changes the CCG2 into the PR SINK.

       

      Observe the correct behavior in this situation, DR role swap appears to work correctly but VBUS_C_CTRL FET is not being turned off to enable the CONSUMER path.  VBUS_P_CTRL FET is being turned off, however.

       

      Can you confirm the above behavior and if it is correct?

       

       

       

       

       

       

       

       

      The next behavior that I want to confirm.

       

      Disconnect the USBC and the AC adapter.  The Evaluation Kit should now be unpowered.

      Connect the USBC smart phone to the Evaluation Kit.  The Evaluation Kit is now powered from the USBC smart phone.

       

      Next, plug in the AC adapter for the CCG2 Evaluation Kit.

      The CCG2 Evaluation Kit is now powered by the AC adapter and it should be possible to role swap the CCG2 from SINK to SOURCE.  This should also charge the attached smart phone.

       

      Press and hold the USER BUTTON down.  The button must be held down.

      A PR role swap is initiated, and PS_RDY is also replied by the CCG2, but the FETs are not switched correctly.  The VBUS_P_CTRL FET is switched on, but the VBUS_C_CTRL FET is not switched on.

       

      While the Evaluation Kit does not have LED indicators to show the status of the FETs, the development PCB that I created for this project does, I can see that when a PR role swap is requested, and PS_RDY is replied and the VBUS_P_CTRL FET is switched on, but the VBUS_C_CTRL FET is not switched on.

       

      My assumption is that the CCG2 turns on the VBUS_P_CTRL FET to turn on VBUS, then checks VBUS_MON.  It sees VBUS has not risen to the required voltage and then attempts to switch the VBUS_P_CTRL FET off, then back on to retry.  This loop does not stop until the CCG2 is reset.

       

      In order for the PROVIDER FETs to be in the correct setting, the VBUS_C_CTRL FET also needs to be turned on, but this is not occurring after the PR swap.

       

      Can you confirm the above behavior and if it is correct?

       

       

       

       

       

       

       

       

      I believe the use case of using PR SWAP may not have been considered with this sample firmware.  Can you recommend the best way to resolve these issues, if this is not intended behavior?

       

      If this behavior is intended then I will investigate a corse of action to proceed.

        1 2 Previous Next