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

Announcements

Live Webinar: USB-C adoption. Simple & Cost-efficient solutions | April 18th @9am or 5pm CEST. Register now !

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
aldr_3203566
Level 4
Level 4
First like received

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-fir...

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.

0 Likes
1 Solution

Hi Allan

The main reason for the issue was that the configuration table was being destroyed by the boot.

You can try using the standard boot loader from the SDK or remove the I2C boot from the project and give the Hex file attached in the previous response as a reference to the boot loader.

Regards

Yatheesh

View solution in original post

0 Likes
20 Replies
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Allan,

Can you please share the cc log file if you are using a protocol analyzer.

Best Regards

Yatheesh

0 Likes
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Allan,

Can you also please send the firmware hex file generated after building the project.

We are trying to reproduce the issue.

Best Regards

Yatheesh

0 Likes

Thank you for your reply and looking into this.

Here are the files requested.

(edited) powered_by_ac_after_usbc_connected_201902271953.ccgx

+ USBC is connected

+ AC adapter is connected to the Evaluation Kit

+ USER BUTTON is pressed and held down for a few seconds

+ USER BUTTON is released

(edited) powered_by_ac_before_usbc_connected_201902271952.ccgx

+ AC adapter is connected to the Evaluation Kit

+ USBC is then connected

+ USER BUTTON is pressed and held down for a few seconds

+ USER BUTTON is released

In order to reduce the folder size I removed the build result files.

I will rebuild the project and leave all files intact.

This should give you the full output if you look in the build folders Cortex0.

I will attach the files here individually as well.

The above analyzer output was created with this rebuilt project, to maintain consistency.

Analyzer used was the Cypress 4500 analyzer, I hope the data can be viewed correctly on your side.

0 Likes

Hello Allan,

The description given under "powered_by_ac_before_usbc_connected_201902271952.ccgx" and the respective cc log file is matching.

Below is the description.

When the USBC is connected to CCG2 EVK, the EVK behaves as a sink so the  VBUS_C_CTRL FET is on and VBUS_P_CTRL FET should be off (VBUS_C_CTRL and VBUS_P_CTRL FET are complimentary) as the board is powered by the USBC.

When the AC power adapter is connected to the EVK base board, the sink(EVK) initiates a power role swap and is accepted by the source(mobile). After PS_RDY by the EVK, VBUS_P_CTRL FET turns on and the VBUS_C_CTRL FET turns off. Now the EVK is the source.

When the button is pressed,as the EVK is already acting as the source, there will not be any PR_Swap.

When the button is released PR_Swap is initiated as the CCG2 is not the sink, this is accepted by the device and there is a PS_RDY by the CCG2. Here the VBUS_C_CTRL FET is on and the VBUS_P_CTRL FET goes off as the CCG2 is drawing power form the mobile.

Are the FET's working as mentioned above?

For different methods of connecting the power adapter and the USBC to the EVK mentioned in the previous reply, Can you please confirm if the file name is correct, or the description given below it is the right one as they both are contradicting.

Best Regards

Yatheesh

0 Likes

Yes, this is the observed behavior, however, the truth table on the schematic differs.

The truth table shows that both must be off for the consumer path to activate, both must be on for the provider path to activate.

Am I interpreting the truth table correctly?

I will copy the image here, this file is CY4521_Kit_Guide located at

https://www.cypress.com/documentation/development-kitsboards/cy4521-ez-pd-ccg2-evaluation-kit

スクリーンショット 2019-02-27 22.10.33.png

0 Likes

I am reposting the text, I am sorry I seem to have mixed up the description.

I will edit the original post to clear up confusion.

powered_by_ac_before_usbc_connected_201902271952.ccgx.zip

+ AC adapter is connected to the Evaluation Kit

+ USBC is then connected

+ USER BUTTON is pressed and held down for a few seconds

+ USER BUTTON is released

powered_by_ac_after_usbc_connected_201902271953.ccgx.zip

+ USBC is connected

+ AC adapter is connected to the Evaluation Kit

+ USER BUTTON is pressed and held down for a few seconds

+ USER BUTTON is released

0 Likes

EDITED

The description given under "powered_by_ac_before_usbc_connected_201902271952.ccgx" and the respective cc log file is matching.

Below is the description.

When the USBC is connected to CCG2 EVK, the EVK behaves as a sink so the  VBUS_C_CTRL FET is on and VBUS_P_CTRL FET should be off (VBUS_C_CTRL and VBUS_P_CTRL FET are complimentary) as the board is powered by the USBC.

When the AC power adapter is connected to the EVK base board, the sink(EVK) initiates a power role swap and is accepted by the source(mobile). After PS_RDY by the EVK, VBUS_P_CTRL FET turns on and the VBUS_C_CTRL FET turns off. Now the EVK is the source.

When the button is pressed,as the EVK is already acting as the source, there will not be any PR_Swap.

When the button is released PR_Swap is initiated as the CCG2 is not the sink, this is accepted by the device and there is a PS_RDY by the CCG2. Here the VBUS_C_CTRL FET is on and the VBUS_P_CTRL FET goes off as the CCG2 is drawing power form the mobile.

Are the FET's working as mentioned above?

>> Let me repost the description below...

The description given under "powered_by_ac_before_usbc_connected_201902271952.ccgx" and the respective cc log file is matching.

Below is the description.

>> I am going to rewrite the description below and correct some parts from what was observed here.

At first the AC adapter is connected to the CCG2 EVK, therefore the CCG2 is powered.

At this time VBUS_C_CTRL is HIGH, VBUS_P_CTRL is LOW.  This does not enable either path.

USBC is connected.

VBUS_P_CTRL is switched HIGH, VBUS_C_CTRL remain HIGH, this enables the PROVIDER path.

CCG2 is now a SOURCE.

The button is pressed and held, since we are in SOURCE mode, no change is expected.

The button is released and VBUS_P_CTRL is switched LOW, VBUS_C_CTRL remains HIGH.

The consumer path is not enabled, but VBUS is HIGH since the connected device was instructed to do a PD swap, and it completed.

VBUS_MON shows VBUS has 5V on it, but the CONSUMER FETs are not both switched on.

I believe both VBUS_C_CTRL and VBUS_P_CTRL must be low for the CONSUMER path to be enabled.

0 Likes

powered_by_ac_after_usbc_connected_201902271953.ccgx

Below is the description.

No AC adapter is initially connected to the CCG2 EVK

The USBC is connected to the CCG2 and both VBUS_C_CTRL and VBUS_P_CTRL remain LOW, enabling the CONSUMER path.  This functions as I expect.

The AC adapter is connected to the CCG2 EVK.

When the button is pressed (and held) to initiate PR swap, VBUS_P_CTRL will be on for a second, and then turn off, and then turn on again and then off again.

This cycle happens indefinitely until the CCG2 is reset.

Can you confirm and reproduce the above behavior?

I assume VBUS_MON does not see VBUS rise to expected voltage and times out, and then attempts again.

I believe VBUS_P_CTRL and VBUS_C_CTRL must both be HIGH for the PROVIDER path to be enabled.

0 Likes

Some parts to the post #9 above were edited adding observations.

0 Likes

I am uploading the cycad files as requested.

This file should be in the CYPD2122-24LQXI-notebook_button_201902271949.zip under the Cortex0 folder, but will upload it, and related files as to be complete.

0 Likes

Hello Allan

We programed the cyacd file to our CCG2 board but the issue could not be reproduced as PR_Swaps were not initiated when button pressed or released.

Do try changing the user button ISR code as mentioned below and see if there is any improvement.

CY_ISR(UserButtonInt_ISR)

{

    static bool firsttimesink = true;

    static bool firsttimesrc = true;

    #define PORT_0 (0)

    UserButton_ClearInterrupt();

   

    if(UserButton_Read() == true)

    {

        if( (get_current_port_role() == PRT_ROLE_SOURCE) && (firsttimesrc))

        {

           if( handle_pd_command(DPM_CMD_PR_SWAP, NULL, NULL))

        {

            firsttimesrc = false;

        }

       

        }

    } else {

        if(( get_current_port_role() == PRT_ROLE_SINK) && (firsttimesink))

        {

            if (handle_pd_command(DPM_CMD_PR_SWAP, NULL, NULL))

            {

                firsttimesink = false;

            }

        }

    }

}

Best Regards

Yatheesh

0 Likes

I have changed the code to your recommendation, and the button press only works once now, however, the FET logic is the same.

I am going to upload two movie files, I hope you can view them.

Also uploading several image files of the PCB jumper configuration.

Do you see similar results on your EVK?

IMG_5747.JPG

IMG_5748.JPG

IMG_5749.JPG

IMG_5750.JPG

0 Likes

Hello Allan

We are able to successfully reproduce the issue. We will look into it and respond soon.

Regards

Yatheesh

0 Likes

Thank you very much for your support and I am glad you could reproduce the issue.

I look forward to the results.

0 Likes

As a suggestion, it may help to attach LED indicators onto the VBUS_C_CTRL and VBUS_P_CTRL pins, if you have parts available.

This is how I initially noticed the issue that I was experiencing.  I will attempt to do the same on my side and attach LEDs to the DEBUG_CONNECTOR on the correct pins and reply with the results.

0 Likes

With LEDs connected to the DEBUG_CONNECTOR, I can confirm the same behavior FET control on the Evaluation Kit.

The LEDs are connected to the these three lines for monitoring.

+ VBUS_C_CTRL

+ VBUS_P_CTRL

+ VBUS_DISCHARGE

0 Likes
YatheeshD_36
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello Allan

Program the i2c boot loader provided in the SDK or program the hex file attached to this response(CYPD2122-24LQXI_notebook_i2c_boot-nb_1_0_0_699_0_0_0_nb.hex) from the latest version of PSOC Programmer through the SWD to the CCG2 and update your user_button firmware(.cyacd file) through the EZ-PD configuration utility.

This should solve the issue. It is observed that the user button operation is not completely efficient, do retry pressing and releasing the user button again if it doesn't work the first time. The FET's are also working properly.

Please follow the above method and let us know if you are still facing the same issue.

Best Regards

Yatheesh

0 Likes

Hi Yatheesh,

Thank you for your reply.

This does indeed resolve the issue, can you explain the theory as to why?

The FETs are working properly, and the button pressing, as you stated is not completely efficient, but it does send the PD role swap request.

The button press method was simply a way to initiate a PD role swap to resolve the FET issue at first.

Unfortunately I will have trouble programming a CYPD2122-20FNXI using this method as I don't have pins set aside for the i2c interface.

If this is the only option I can try to set aside some pins for initial programming using the i2c programming method.

Do you have a recommendation as how to correct the code created in PSoC Creator to allow direct programming through the SWD interface?

Sincerely,

Allan

0 Likes

Hi Allan

The main reason for the issue was that the configuration table was being destroyed by the boot.

You can try using the standard boot loader from the SDK or remove the I2C boot from the project and give the Hex file attached in the previous response as a reference to the boot loader.

Regards

Yatheesh

0 Likes

Hi Yatheesh,

I believe I have located the problem, it was in the i2c_boot-nb.cydsn folder.  Some items must have been out of date/sync.

After updating these files with those in the latest SDK it appears to have resolved the issue.

I am not completely sure why it does, as the boot loader passes control over to the main program, but it does appear to have resolved the issue.

With this issue resolved, I seem to be able to program over SWD without issue now and the FETs function as expected.

Thank you very much for your support!

I am attaching the files from the latest build for your reference, as it may help others with the same issue.

It should be noted that the gcc-arm-none-eabi-4_9-2015q1-20150306-win32 toolchain (easy to find and download) will be required to build the items in the i2c_boot-nb.cydsn folder.

I am attaching the original source with the fixed i2c_boot-nb.cydsn folder and also the source where I am implemented the button to issue the PD swap request.

Also to note, the i2c pins are not mapped in these files so the EZ-PD Configuration Utility will not be able to connect to program through the i2c pins, this is expected.

This is essentially a repost of the code located at the below link, updated for PSoC Creator 4.2.

Updating that topic with this code (or providing a link) may be a good idea so others don't have the same trouble I did at first.

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-fir...

Sincerely,

Allan

0 Likes