CCG3PA is in not responding state

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
PrRe_3492461
Level 4
Level 4
First like received 50 sign-ins 50 replies posted

Hello all,

I'm using ccg3pa for my product development.

General working scenarios:

I configured ccg3pa as i2c slave, a GPIO has been configured for input interrupt and whenever that gpio triggers FW reads i2c data and performs respective operation based on received command.

Normally in our testcases we will only perform PD Detach, PD Attach, Change Port roles, Configure SrcCaps, Request initiation commands, and GET PDC information, Srccaps information, Attach/Detach events tracking from i2c Master.

Issue scenario:

Now all these above set of commands works and able to Get data required from dpm_status structure and perform required operations.

But only after running testcases for more than 2 days continuously, I'm seeing a strange issue that I'm unable to configure ccg3pa as Src/Sink/DRP or nor Attach works neither PDC happends.  I confirm this as there are no changes or No PDC observed in PD Sniffer whenever I send Change Mode commands from i2c Master.

So as part of debug I've added a Event logging mechanism where in which I'm reading certain return values of certain library functions. I see that "dpm_stop (port);"  is returning 0x0E that says "CCG_STAT_NOT_READY, /**< Operation failed due to device/stack not ready. */".

Example 1: (After testing for 2 days continuously)

1.In Issue state from master I will send a API to SET Tester Mode to SOURCE upon reception of this API in ccg3pa i will execute :

        case GRL_SRC_MODE:
           /**Have to detach first to change the port role, so go to disable state -> typecStop -> dmp_stop*/
           dpm_typec_command(G_PORT0, DPM_CMD_PORT_DISABLE,NULL);
            CyDelay(1);
            //TypeC and dmp stop
            typec_stop(G_PORT0);
            CyDelay(1);
            aRetStatus = dpm_stop (G_PORT0); //Pranay, This is returning error saying the system is busy.
           /**Changing the role here*/
            pd_typec_en_rp(0,CC_CHANNEL_1,RP_TERM_RP_CUR_3A);
            pd_typec_en_rp(0,CC_CHANNEL_2,RP_TERM_RP_CUR_3A);
            CyDelay(1);
            aRetstat = dpm_update_port_config (TYPEC_PORT_0_IDX, PRT_ROLE_SOURCE, PRT_ROLE_SOURCE, false, false);
            CyDelay(1);
            dpm_update_port_config (TYPEC_PORT_0_IDX, PRT_ROLE_SOURCE, PRT_ROLE_SOURCE, false, false);
       /**Attaching here*/
       typec_start(G_PORT0);
                CyDelay(2);
       aRetStatus = dpm_start (G_PORT0);
        break;

When I execute above statements normally when not in issue state I see CC lines reaching to Rp level but now when in issue state CC lines are not reaching Rp level But in both working and non-working cases after Sending SET command to ensure that mode has been set I will go and read below commands:

            /**Current DATA ROLE**/
            aBuffer[glogBufIndex++] = dpm_stat->cur_port_type;
            /**Current POWER Role*/
            aBuffer[glogBufIndex++] = dpm_stat->cur_port_role;
             /**< Port role: Sink, Source or Dual. */
            aBuffer[glogBufIndex++] = dpm_stat->port_role;

I see that above statements are returning values as expected and as per the Mode role set. I dont see a problem in executing commands. But Unfortunately even though the variables are returning expected values I dont see changes taking effect on physical Type C port lines. This is the issue.

 

Example 2: Our Other functionalities (QC2.0) in main while(1) loop

In our FW Application, we've other functionalities being used on basis of main while(1) loop, and I see that that respective functionalities are not working aswell when in issue state. So probably main while(1) is not running ? and if so dpm_task(port); app_task(port);  instrumentation_task();  wont work right ?

 

--> Also Do we any API to RESET ccg3pa controller and its state machines ? If required we want to make use of this functionality of resetting ccg3pa alone.

we've been using  ccg3pa since past 3 years now and it is deployed on field products and products are facing this issue while in rigorous testing by customers. We must to find a resolution for this.

 

Please let us know what can be in this case, if required we can always have a call for better understanding.

 

Thanks and regards,

Pranay

1 Solution
JaydenCai
Level 4
Level 4
25 replies posted First solution authored 25 sign-ins

Based on the information provided, it seems like there may be an issue with the CCG3PA device or the firmware running on it. The fact that the issue occurs after running test cases for more than 2 days continuously suggests a possible memory leak or other resource exhaustion problem.

Regarding your question about resetting the CCG3PA controller and its state machines, there is indeed an API provided by the firmware to reset the device. You can do this by calling the function dpm_init() with the appropriate parameters. This will reinitialize the device and its state machines, which may help resolve the issue you are facing.

However, I would recommend first trying to identify the root cause of the issue before resorting to resetting the device. You mentioned that you have added event logging to help with debugging. Have you reviewed the logs to see if they provide any clues as to what might be causing the issue? Additionally, have you considered using a memory profiling tool to monitor the memory usage of the firmware during testing?

It's also worth noting that CCG3PA devices have a built-in watchdog timer that can be used to automatically reset the device if it becomes unresponsive. This may be another option to consider if the issue persists even after resetting the device.

Overall, I would recommend further investigation into the root cause of the issue before attempting to reset the device or take other drastic measures. If you are still unable to resolve the issue, it may be worth reaching out to the manufacturer of the CCG3PA device or consulting with a firmware expert to get additional support.

View solution in original post

5 Replies
JaydenCai
Level 4
Level 4
25 replies posted First solution authored 25 sign-ins

Based on the information provided, it seems like there may be an issue with the CCG3PA device or the firmware running on it. The fact that the issue occurs after running test cases for more than 2 days continuously suggests a possible memory leak or other resource exhaustion problem.

Regarding your question about resetting the CCG3PA controller and its state machines, there is indeed an API provided by the firmware to reset the device. You can do this by calling the function dpm_init() with the appropriate parameters. This will reinitialize the device and its state machines, which may help resolve the issue you are facing.

However, I would recommend first trying to identify the root cause of the issue before resorting to resetting the device. You mentioned that you have added event logging to help with debugging. Have you reviewed the logs to see if they provide any clues as to what might be causing the issue? Additionally, have you considered using a memory profiling tool to monitor the memory usage of the firmware during testing?

It's also worth noting that CCG3PA devices have a built-in watchdog timer that can be used to automatically reset the device if it becomes unresponsive. This may be another option to consider if the issue persists even after resetting the device.

Overall, I would recommend further investigation into the root cause of the issue before attempting to reset the device or take other drastic measures. If you are still unable to resolve the issue, it may be worth reaching out to the manufacturer of the CCG3PA device or consulting with a firmware expert to get additional support.

Hi Pranava and Jaydencai,

I have been trying to reproduce issue and see if there is any consistency. But I was unsuccessful in reproducing issue more than once. Been testing continuously but unable observe issue.


@JaydenCai wrote:

You mentioned that you have added event logging to help with debugging. Have you reviewed the logs to see if they provide any clues as to what might be causing the issue?  

 

 Event logging is added only to the limited parts to find out our code flow. So cant track or get some clues.


@JaydenCai wrote:

Additionally, have you considered using a memory profiling tool to monitor the memory usage of the firmware during testing?

It's also worth noting that CCG3PA devices have a built-in watchdog timer that can be used to automatically reset the device if it becomes unresponsive. This may be another option to consider if the issue persists even after resetting the device.

I'm not aware of any Memory profiling tool, Can you suggest me any such tools or how do I monitor the memory usage during FW testing ? Our custom product doesn't have UART interfaced to add some UART prints and check, Is there any other method that you suggest ?

Please suggest me how and what memory profiling tool to use to monitor the memory usage.

Also Any examples to implement WD timer ?

Thanks and regards,

Pranay

Hi Pranay,

If you can reproduce the issue, then you can use a debugger to get that call stack and the stack pointer. If you are not able to reproduce the issue, then it will be harder to understand the cause of the issue.

We do have a WD timer implemented with  750ms timer to reset the controller. You can check the configuration in config.h or stackparams.h file. 

Best regards,
Pranava
Pranava_YN
Moderator
Moderator
Moderator
100 likes received 500 replies posted 250 solutions authored

Hi @PrRe_3492461 ,

Did you check the suggestions provided by @JaydenCai ?  Do you still face the same issue?

Best regards,
Pranava
35_Engineering
Level 4
Level 4
First like received 10 sign-ins 10 questions asked

Hi Pranay!

Sounds like an interesting bug my friend...  Sorry you are going through this!  If it is any consolation, I've been where you are and it is quite satisfying when you finally get to the root cause!  🙂   

 

Sounds like you indeed have a slow memory leak, your intuition sounds spot on to me.

 

If I were to attempt to get to the bottom of this, I would create a "debug" image of your code (if you don't already have one).   ....and then I'd jump on a Micrium's uC/Probe....   first you need to hack up the board so that you have access to SWD, then you can connect miniprog over SWD, and write code to simulate sleep in all areas where you might put the device to sleep....

 

Good news is that Micrium now offers this thing for free:
https://weston-embedded.com/micrium/17-micrium/67-micrium-uc-probe

 

You should really have it in your arsenal, whether or not it solves this mystery...  a really superlative tool for embedded development....

 

You can use the probe tool to set up pretty complex breakpoints and monitor with real-time graphs, etc...  to develop your hypothesis...

 

...and give me a ring if you want me to show you directly...   I'm happy to help out a fellow ez-pd'er...

0 Likes