How to not respond to other SVIDs?

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
lock attach
Attachments are accessible only for community members.
MaLi_3529141
Level 3
Level 3
25 replies posted 25 sign-ins 10 replies posted

Dear,

I encountered some problems when making HUB project using CYPD4236 of CCG4.

When I connected the notebook, I received SVID=0x17EF and responded to NAK, and it would enter an infinite loop.

(Refer to the attachment Fail Log.ccgx)

pastedImage_3.png

I refer to other hubs, if SVID=0x17EF responds with NACK, it will not fall into an infinite loop.

(Refer to the attachment PASS Log.ccgx)

pastedImage_4.png

Q1: How can I modify the code so that it does not respond to the SVID of 0x17EF?

Q2: Is there any other solution that does not fall into an infinite loop?

Thanks.

0 Likes
1 Solution
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

From the logs, I see that in the pass case with other hubs, the VDM with SVID 0x17EF is sent only once to which there is no response, and following that, notebook sends VDMs with standard SVID 0xFF00 to which the hub responds normally and enters display port mode. However, in the fail case, the VDM with SVID 0x17EF is sent multiple times, even after standard SVID 0xFF00 is sent and CCG4 is able to respond normally and enter display port mode.

As per the USB PD specification, if a UFP receives a structured VDM for a SVID it doesnt support, it shall respond with a Responder NAK command and the handling of the NAK is left to the Initiator. So, I think CCG4 is correctly responding here but the notebook keeps retrying.

-Please check on the notebook side as to why the the VDMs are sent multiple times in case of CCG4 but not other hubs.

-You could also add support for CCG4 to not respond for that SVID in the code as shown in the example below and check if it helps change the behavior.

File: vdm.c

Function: void eval_vdm(uint8_t port, const pd_packet_t *vdm, vdm_resp_cbk_t vdm_resp_handler)

switch(vdm->dat[VDM_HEADER_IDX].std_vdm_hdr.cmd)

                {

                    case 0x12: //as per the reserved command value in VDM

                    if(vdm->dat[VDM_HEADER_IDX].std_vdm_hdr.svid ==  0x17EF)   

                    {

                        app_stat->vdm_resp.no_resp = VDM_AMS_RESP_NOT_REQ;

                    }

Best Regards,
Sananya

View solution in original post

0 Likes
1 Reply
Sananya_14
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hello,

From the logs, I see that in the pass case with other hubs, the VDM with SVID 0x17EF is sent only once to which there is no response, and following that, notebook sends VDMs with standard SVID 0xFF00 to which the hub responds normally and enters display port mode. However, in the fail case, the VDM with SVID 0x17EF is sent multiple times, even after standard SVID 0xFF00 is sent and CCG4 is able to respond normally and enter display port mode.

As per the USB PD specification, if a UFP receives a structured VDM for a SVID it doesnt support, it shall respond with a Responder NAK command and the handling of the NAK is left to the Initiator. So, I think CCG4 is correctly responding here but the notebook keeps retrying.

-Please check on the notebook side as to why the the VDMs are sent multiple times in case of CCG4 but not other hubs.

-You could also add support for CCG4 to not respond for that SVID in the code as shown in the example below and check if it helps change the behavior.

File: vdm.c

Function: void eval_vdm(uint8_t port, const pd_packet_t *vdm, vdm_resp_cbk_t vdm_resp_handler)

switch(vdm->dat[VDM_HEADER_IDX].std_vdm_hdr.cmd)

                {

                    case 0x12: //as per the reserved command value in VDM

                    if(vdm->dat[VDM_HEADER_IDX].std_vdm_hdr.svid ==  0x17EF)   

                    {

                        app_stat->vdm_resp.no_resp = VDM_AMS_RESP_NOT_REQ;

                    }

Best Regards,
Sananya

0 Likes