CY4532 EVK, Initiating PD Data message from CCG3PA

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
PrM_1403381
Level 4
Level 4
First like received First like given Welcome!

Hi All,

To Send Run time request after PD contract I am using "pd_prot_send_data_msg()" CCG3PA API,

I am able to populate request structure, send using the above mentioned api. Accept message also received from the DFP/Source, but after sending GoodCRC from CCG3PA within ~650uSec (from the EOP of GoodCRC) SoftReset is initiated.

Please find the attached CC-line sniffer captures. Let me know what is the additional configuration missing for getting the expected result in this case.

Request_SoftReset_Timing.jpgAccept(GoodCRC)_SoftReset_Timing.jpg

Thanks & Regards

Prasanna

0 Likes
1 Solution

Hi Rajaraman V,

As per our discussion on the threads https://community.cypress.com/thread/46846, we have to recommend you use dpm_pd_command() API to initiate Request message. As you know, the soft_reset is for recovery PD phy as per PD SPEC. And the Soft_reset is not caused by GOOD_CRC you mentioned which sent out in 650us. GOODCRC is auto ACK from CCGx end.

For your questions about: Is it possible to use dpm_pd_command() API to initiate Request message ?  If yes let me know, How it can be used ?

>> Answer is below:

Based on your application back ground is:

-----------

Consider an example. PD negotiation is successful with Source Device, after PD negotiation is complete if I want to send a Request message of my desired PDO at run time.  What is the suitable API available to achieve this requirement using CCG3PA API's exposed by library?

-----------

The safe way can be below:

  1. You can get all of SOURCE_CAP in the structure: const pd_packet_t* src_cap

You can see CCG3PA firmware evaluate this with eval_src_cap().

  1. You could copy those data to SINK_PDO and use below API:

ccg_status_t dpm_update_snk_cap(uint8_t port, uint8_t count, pd_do_t* pdo);

ccg_status_t dpm_update_snk_cap_mask(uint8_t port, uint8_t mask);

  1. After you update above information, the request will send out by CCG3PA firmware automatically.

If you insist to use pd_prot_send_data_msg() for request. I’d like to recommend you follow below process if it is possible.

>> SENT GET_SOURCE_CAP before send REQUEST.

Best Regards,

Lisa

View solution in original post

0 Likes
13 Replies
MuthuM_11
Employee
Employee
10 likes received 10 likes given 5 likes given

Hi Prasanna,

PS_RDY is missing from source after putting requested voltage on VBUS.

Regards,

Muthu

0 Likes

Hi Muthu,

Yes, PS_RDY is missing from the Source. But PD negotiation established successfully when the Source is attached to the CCG3PA.

This PS_RDY missing issue occurs when CCG3PA initiated request command using the available API "pd_prot_send_data_msg()" from CCG3PA API user guide.

As per the PD spec, The PSTransitionTimer is used by the Policy Engine to timeout on a PS_RDY Message. "tPSTransition" timer will be used by the sink to wait for the PS_RDY and if not received the PS_RDY after the expiry of "tPSTransition", It leads to the Hard Reset from the Sink.

tPSTransition will be calculated from the EOP of the Accept and SOP of the PS_RDY,

tPSTransition  450mSec (min) 550mSec(max). So Sink needs to wait for the min of 450 mSec for the PS_RDY from the Source, In our case Sink(CCG3PA) is initiating Soft_Reset within ~1.2 mSec from the EOP of the Accept message.

So the usage of API "pd_prot_send_data_msg" is causing the issue ? If so how we need to use the mentioned API.

---> If there is an issue in generating and sending the Request message, Accept wouldn't have received from the Source.

If you have any example for the usage of above mentioned API can share. It would be helpful.

Thanks & Regards

Prasanna

0 Likes

Hi Prasanna,

1. Soft_Reset is not interrupt currently negotiation. As per PD3.0 SPEC:

Protocol Errors are handled by a Soft_Reset Message issued by either Port Partner, that resets counters, timers and states, but does not change the negotiated voltage and current or the Port’s role (e.g. Source, DFP/UFP, VCONN Source) and does not cause an exit from Modal Operation.

2.  After SOURCE ACCEPT the request from SINK. It shall be go to PS_RDY states. From your negotiation trace, the DFP is begin to SOURCE_CAP again.

Regards,

Muthu

0 Likes

Hi Muthu,

Please find my comments below

1. Yes, I agree

2.  After SOURCE ACCEPT the request from SINK. It shall be go to PS_RDY states. From your negotiation trace, the DFP is begin to SOURCE_CAP again.

     Yes, Source should initiate the PS_RDY message. Sink is initiating the Soft_Reset before the tPSTransition  timer expiry, So here my question is what was the protocol error that is being detected in Sink (CCG3PA), Because Soft Reset is being used to recover from Protocol errors.

Source/DFP is initiating the Source cap again, because of the soft reset from the Sink(CCG3PA).

As per PD Spec 3.0, V1.2. Section 6.3.13 Soft Reset Message, It is mentioned that.

However after a Soft Reset has completed, an Explicit Contract negotiation occurs, in order to re-establish PD Communication.

Correct me If I am wrong.

This Soft Reset from the Sink(CCG3PA) occurs when I use the API "pd_prot_send_data_msg" to send the Request message from the CCG3PA, In Normal manual attach and detach of the Source using Type-C cable, Soft reset issue is not being observed.

So the usage of API "pd_prot_send_data_msg" is causing the issue ? If so how we need to use the mentioned API.

---> If there is an issue in generating and sending the Request message, Accept wouldn't have received from the Source.

If you have any example for the usage of above mentioned API can share. It would be helpful.

Thanks & Regards

Prasanna

0 Likes

Hi Prasanna,

Could you please let me know your requirements of firmware customizes? From your description, you could like to initial a request on CC line. You’d better to share more background to us to help you better. We could offer you a better way to initial a REQUEST and do not crush our PD stack state machine if it is possible.

Best Regards,

Lisa

0 Likes

Hi Lisa,

Thanks for the response,

I am using CCG3PA in my design, I have added I2C Slave device into the design using PSOC creator, Used Bridge control utility with miniprog3 to send commands via I2C, Based on the commands received from bridge control utility initiating the PD messages from Cypress CCG3PA.

I referred "CCGx_Power_SDK_API_Guide", for the API's available by Cypress. And I am able to initiate the PD Control messages and PD Data messages also using commands. We have just defined internal API's to initiate respective PD Commands.

May I know the better way to initiate the Request message from the CCG3PA?

Best Regards,

Prasanna

0 Likes

Hi Prasanna,

1. The API pd_prot_send_data_msg is not recommended in any actual production designs as it is intended for internal usage of the stack only.

2. The better way is change the function

ATTRIBUTES static bool is_src_acceptable_snk(uint8_t port, pd_do_t* pdo_src, uint8_t snk_pdo_idx)

and

ATTRIBUTES static pd_do_t form_rdo(uint8_t port, uint8_t pdo_no, bool capMisMatch, bool giveBack)

at file pdo.c.

3. As per your request, I am not sure what standard to input the value, but it is shall be according to the SOUREC_CAP or others. You can change above functions to achieve it.

Best Regards,

Lisa

0 Likes

Hi Lisa,

Thanks for the inputs, below are my comments.

1. The API pd_prot_send_data_msg is not recommended in any actual production designs as it is intended for internal usage of the stack only

          --->> So I can't use this API ? But It is available CCGx_Power_SDK_API_Guide !!

          --->>As per your comments and the description in section 2.2 Public API Summary section,

               I can use only API's which are mentioned in Section 2.2 Public API Summary

If Yes : API pd_prot_send_ctrl_msg, is not listed in the Public API summery section.

But still I am able to use pd_prot_send_ctrl_msg without any issues. I am facing the issue in using API pd_prot_send_data_msg.

In pd_prot_send_data_msg. I am not facing difficulty in initiating the Message, after receiving the Accept from DUT(Source),

Soft Reset getting initiated.

2. The better way is change the function

ATTRIBUTES static bool is_src_acceptable_snk(uint8_t port, pd_do_t* pdo_src, uint8_t snk_pdo_idx)

and

ATTRIBUTES static pd_do_t form_rdo(uint8_t port, uint8_t pdo_no, bool capMisMatch, bool giveBack) at file pdo.c

--->> At present we are using this method only to achieve our requirement.

In this case, we are configuring request message, and Initiating Get Source Capability message from CCG3PA using pd_prot_send_ctrl_msg.

So Once DUT(Source) Sends It's Source Capability, CCG3PA requests for the configured request message. This is working fine.

In non-working scenario CCG3PA initiating Soft Reset, could be because of Protocol Error, Since the Request message initiated by using the API is not registered in the protocol log.

As soon as Accept is received, CCG3PA considering this as as a protocol violation, and initiating Soft Reset.

Correct me if I am wrong ?

3. As per your request, I am not sure what standard to input the value, but it is shall be according to the SOUREC_CAP or others. You can change above functions to achieve it.

--->>You are asking about the commands that I mentioned in mail ?

If Yes : It is I2C command you can send from the Bridge control Panel. Where (w 08 00 03 02 01 D0 00 D0 00 p)

08 00 03 02 (Byte 0 to Byte 3) : Is Constant, No need to change.

01 (Byte 4) : Represents the PDO Number, Which PD we need to request in the Source Capability message

0xD0 0x00 (Byte 5 : Byte 6) : Operating Current in 10 mA/ Unit , Example I have mentioned 0xD0 means 208 x 10 2080 mA, In request message we are requesting for 2080 mA as Operating current, Same thing is applicable for Max Operating current. This value You can change according the DUT(Source) Capability that you ar using to reproduce

--->>Our Request message should be as per the DUT(Source)'s Source capabilities.

Waiting for the response, at the earliest.

Thanks & Best Regards

Prasanna

0 Likes

Hi Prasanna,

As per your comments, you have confirmed that the way we have been suggested is working, but the API pd_prot_send_data_msg will caused Soft_reset. We have to recommend you use the way continue on, and we cannot share more details about the API pd_prot_send_data_msg. Thank you for your understanding.

For my comments #3, the purpose is for help you out as soon as possible, may be share a example code for you based on your requirements and show the demonstrate of the way we suggested in #2. As per your response, the way of #2 is help you out.

Please do not use API pd_prot_send_ctrl_msg also, we have a better way to replace the API.

When you using either API pd_prot_send_ctrl_msg or  pd_prot_send_data_msg , you may interrupt PD stack we have been pre-builded as library.

Thank you for your understanding.

Best Regards,

Lisa

0 Likes

Hi Lisa,

Thanks for your inputs.

I understand your concerns regarding your PD stack and pre-build library.

My basic requirement is explained as below:

     Consider an example. PD negotiation is successful with Source Device, after PD negotiation is complete if I want to send a Request message of my desired PDO at run time.  What is the suitable API available to achieve this requirement using CCG3PA API's exposed by library?

As I mentioned in my previous comment, I am following the Option #2 itself, but in this case we are changing the PDO and asking for Source capability from the Source device by initiating Get_Source_Capabilities PD message from CCG3PA using pd_prot_send_dat_msg.

Is it possible initiate Request message from CCG3PA run time, If any option or API is available please let me know ?

[Lisa] - Please do not use API pd_prot_send_ctrl_msg also, we have a better way to replace the API.

[Prasanna] - What is the better way to replace this API ?

                           If the better way you are going to suggest is to replace API pd_prot_send_ctrl_msg with dpm_pd_command() then, from the document "EZ-PDTM CCGx Firmware Stack API Reference Guide Version 3.3.0" by looking at the section 6.24.4.11 dpm_pd_cmd_t,  It does not cover all PD control messages as per PD Spec. correct me if I am wrong, if you have any other API in your mind please let us know.

If "dpm_pd_command()" covers all the PD control messages. How can I initiate Get_Sink_Cap_Extended message and Get_Country_Codes using this API.

Is it possible to use dpm_pd_command() API to initiate Request message ?  If yes let me know, How it can be used ?

We have contacted sales team to get the library source but no response. If possible share the PD stack library source code.

Your timely response is highly appreciated.

Thanks & Best Regards

Prasanna

0 Likes

Hi Rajaraman V,

As per our discussion on the threads https://community.cypress.com/thread/46846, we have to recommend you use dpm_pd_command() API to initiate Request message. As you know, the soft_reset is for recovery PD phy as per PD SPEC. And the Soft_reset is not caused by GOOD_CRC you mentioned which sent out in 650us. GOODCRC is auto ACK from CCGx end.

For your questions about: Is it possible to use dpm_pd_command() API to initiate Request message ?  If yes let me know, How it can be used ?

>> Answer is below:

Based on your application back ground is:

-----------

Consider an example. PD negotiation is successful with Source Device, after PD negotiation is complete if I want to send a Request message of my desired PDO at run time.  What is the suitable API available to achieve this requirement using CCG3PA API's exposed by library?

-----------

The safe way can be below:

  1. You can get all of SOURCE_CAP in the structure: const pd_packet_t* src_cap

You can see CCG3PA firmware evaluate this with eval_src_cap().

  1. You could copy those data to SINK_PDO and use below API:

ccg_status_t dpm_update_snk_cap(uint8_t port, uint8_t count, pd_do_t* pdo);

ccg_status_t dpm_update_snk_cap_mask(uint8_t port, uint8_t mask);

  1. After you update above information, the request will send out by CCG3PA firmware automatically.

If you insist to use pd_prot_send_data_msg() for request. I’d like to recommend you follow below process if it is possible.

>> SENT GET_SOURCE_CAP before send REQUEST.

Best Regards,

Lisa

0 Likes

Hi Lisa,

Please find my inline comments.

As per our discussion on the threads https://community.cypress.com/thread/46846, we have to recommend you use dpm_pd_command() API to initiate Request message. As you know, the soft_reset is for recovery PD phy as per PD SPEC. And the Soft_reset is not caused by GOOD_CRC you mentioned which sent out in 650us. GOODCRC is auto ACK from CCGx end.

[Prasanna] - In Cypress community in my Comment#1, I have mentioned the time between GOODCRC and the Soft Reset, also I have attached the capture which shows the time between Request and Soft Reset.

I did not mentioned that Soft Reset is caused due to GoodCRC. (Since GoodCRC is just an acknowledge message from the PD message receiving port).

As per PD Spec, a Soft_Reset Message is used for recover from Protocol Layer errors (Protocol Errors are any unexpected Message during an AMS). Since CCG3PA initiating Soft Reset so it is trying to recover from any protocol error even though the request packet sent properly.

By looking at the CC line trace, No unexpected messages are present before the Soft Reset,  because of this my concern is why CCG3PA is initiating Soft Reset ?

As per my understanding from the Cypress API document and as well as from the CCG3PA's project CYPD3171-24LQXQ_pb FW Source code,

we can Initiate PD messages run time by using API's like, dpm_pd_command(), pd_prot_send_ctrl_msg(), and pd_prot_send_data_msg().

And from the FW source code, when source capability is received from the DUT,

"ATTRIBUTES void eval_src_cap(uint8_t port, const pd_packet_t* src_cap, app_resp_cbk_t app_resp_handler)" is being called from CCG3PA PD stack. Here it will evaluates for the Sink capabilities configured and compare with received Source capability of the DUT, if any matching PDO is available CCG3PA will form the request data object using "ATTRIBUTES static pd_do_t form_rdo(uint8_t port, uint8_t pdo_no, bool capMisMatch, bool giveBack)". If no matching PDO is available, it will request default PDO 1. Correct me If my understanding is wrong ?

I tried above above functions to request PDO's w.r.t DUT's source capability. Below is the procedure i followed for requesting PDO's.

I will come to know DUT Capability from structure const pd_packet_t* src_cap and Each time I will modify the RDO data and Initiate Get Source Capability Message from CCG3PA by using API pd_prot_send_ctrl_msg().

For this DUT will send Source cap message and CCGx will initiate already configured Request packet. By using this method I am not having any problem with changing the request packet for different PDO's.

My Only concern is in this method I am following two steps to change the request PDO and they are

    1. Need to configure rdo

    2. Need to initiate Get_Source_Capability PD message either by using pd_prot_send_ctrl_msg() / (dpm_pd_command() by passing  dpm_pd_cmd_t DPM_CMD_GET_SRC_CAP).

I want to achieve this in one step by initiating Request message by using pd_prot_send_data_msg() and Request message sending from this API works fine, but as explianed above stack is sending SoftReset.

Do you have any other function or API which we can use for this purpose?

For your questions about: Is it possible to use dpm_pd_command() API to initiate Request message ?  If yes let me know, How it can be used ?

[Prasanna] - Regarding this Question. The usage of dpm_pd_cmd() is mentioned in section 6.23.2.18 dpm_pd_command(). where 2nd parameter is the cmd type. The message types that can be initiated at run time by using this API is mentioned in section 6.24.4.11 dpm_pd_cmd_t.

I have referred the Alan hawse Lesson 5 on Type-C 101 videos. where he is using push button as an interrupt to call the API dpm_pd_cmd(), In my case I am using 12c command from bridge control utility to call this API. In same way I am using pd_prot_send_ctrl_msg(), and pd_prot_send_data_msg().

My question : Is it possible to use dpm_pd_command() API to initiate request message ?

By passing parameter 2 as DPM_CMD_GET_SRC_CAP, and 3, 4 as NULL this API will initiate Get_Source_Capabilities message in run time. So my question is that Is there any way to initiate Request message similar to this ?

Since in API sheet it has a provision to send Extended message but no provision for Data message, Request message comes under Data message.

Do you have any info that we can use dpm_pd_command() to send Request message. If possible let us know.

>> Answer is below:

Based on your application back ground is:

-----------

Consider an example. PD negotiation is successful with Source Device, after PD negotiation is complete if I want to send a Request message of my desired PDO at run time.  What is the suitable API available to achieve this requirement using CCG3PA API's exposed by library?

-----------

The safe way can be below:

1. You can get all of SOURCE_CAP in the structure: const pd_packet_t* src_cap

[Prasanna] -  I am able to get the received source capability details with out any issue. I don't have any concern regarding this.

You can see CCG3PA firmware evaluate this with eval_src_cap().

[Prasanna] - Yes, This will evaluates the configured sink capabilities of the CCG3PA with the received Source capabilities for each PDO, If Matching PDO is available wrto Sink capability, CCG3PA will form the respective rdo and sends request to DUT.

2. You could copy those data to SINK_PDO and use below API:

ccg_status_t dpm_update_snk_cap(uint8_t port, uint8_t count, pd_do_t* pdo);

ccg_status_t dpm_update_snk_cap_mask(uint8_t port, uint8_t mask);

[Prasanna] - Yes, This we can use to modify the sink capability of the CCG3PA Device. Before sending Get Source Capability from CCG3PA. We need to modify the Sink capability in such a way that it should request for the desired PDO object from the received source capabilities.

In Above methods requesting for different PDO's is of two step process. Need to change the Sink capability of the CCG3PA and need to ask for Get Source Capability from DUT. When Source capability is received from the DUT our configured PDO request message will be sent from CCG3PA.

I am not facing problem in changing the PDO request. modified the logic in "eval_src_cap()" and "form_rdo()" to change the request message. Get_Source_Capability message Initiated from CCG3PA and it works fine.

3. After you update above information, the request will send out by CCG3PA firmware automatically.

[Prasanna] - After updating above information, CCG3PA need to Initiate Get_Source_Capability PD message. SO that DUT responds with Source_Capability message then our configured request will take effect. Correct me if I am wrong ?

If you insist to use pd_prot_send_data_msg() for request. I’d like to recommend you follow below process if it is possible.

>> SENT GET_SOURCE_CAP before send REQUEST.

[Prasanna] - Since I need to use pd_proto_send_data_msg, I no need to send Get_Source_Capability message from the CCG3AP. Because by using pd_proto_send_data_msg() API itself I can able to send a request message properly.

As per my understanding. We need to Initiate Get_Source_Capability from CCG3PA when we followed below two methods :

1. Modify eval_src_cap(), and form_rdo() functions as per our requirements to change the PDO objects and ask for Get_Source_Capability

2. Modify and update the Sink capabilities of the CCG3PA and send Get_Source_Capabilities from CCG3PA. So that upon receiving Source

Capability from the DUT. In eval_src_cap() function request packet will be formed as per the configured sink capability of the CCG3PA.

We are using method 1, to achieve my requirement of requesting the different PDO's of the received source capability without any issue.

But I need to use pd_proto_send_data_msg(), Since it can initiate a request message of my desired PDO,  am able to use the API and send request packet at run time, also sending soft reset.

So let me know what is causing the CCG3PA to send Soft Reset. Refer My Response#4 in https://community.cypress.com/thread/46846.

As per my response #8 in https://community.cypress.com/thread/46846. In non-working scenario CCG3PA initiating Soft Reset, could be because of Protocol Error, suspect that the Request message initiated by using the API is not registered in the protocol stack. so as soon as Accept is received, CCG3PA considering this as as a protocol violation and initiating Soft Reset.

If this is the reason for initiating the soft reset from CCG3PA. How to overcome this issue ?

Please share the Library source code for us to know the internals of stack and detail understanding of API's.

Thanks in advance.

Best Regards

Prasanna.

0 Likes

This threads was address in E-mail with local team.

0 Likes