Non-PD Connections

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.
JoLo_4180566
Level 2
Level 2

I would like to detect when a non-pd device has been plugged in and what the APP Event sequence should be in the app event handler (Power SDK). The attachment shows what I see some of the time. At other times, I simply see:

APP_EVT_TYPEC_STARTED

APP_EVT_TYPEC_ATTACH_WAIT

APP_EVT_PORT_DISABLE

And other times I see:

APP_EVT_TYPEC_STARTED

APP_EVT_TYPEC_ATTACH_WAIT

APP_EVT_TYPEC_ATTACH_WAIT_TO_UNATTACHED

I am assuming that I need the device policy manager running and it will detect an attach and attempt a connection. I don't always see the stack attempting a connection.

What is the correct sequence for a non-pd connection? I basically created an event logger to be able to capture the sequences in the app_event_handler so that I could see these the order of the events firing. There isn't much of an explanation of these events in the documentation.

I would appreciate any information on the expected order when a non-pd device is attached.

Thanks

0 Likes
1 Solution
YiZ_31
Moderator
Moderator
Moderator
1000 replies posted 750 replies posted 500 replies posted

Hi John,

According to PD spec:

2.7.7 Interactions between Non-PD, BC and PD devices

USB Power Delivery only operates when two USB Power Delivery devices are directly connected. When a Device finds itself a mixed environment, where the other device does not support the USB Power Delivery Specification, the existing rules on supplying vSafe5V as defined in the [USB 2.0], [USB 3.2], [USBBC 1.2] or [USB Type-C 1.3] specifications are applied.

There are two primary cases to consider:

• The Host (DFP/Source) is non-PD and as such will not send any advertisements. An Attached PD capable Device will not see any advertisements and operates using the rules defined in the [USB 2.0], [USB 3.2], [USBBC 1.2] or [USB Type-C 1.3] specifications.

• The Device (UFP/Sink) is non-PD and as such will not see any advertisements and therefore will not respond. The Host (DFP/Source) will continue to supply vSafe5V to VBUS as specified in the [USB 2.0], [USB 3.2], [USBBC 1.2] or [USB Type-C 1.3] specifications.

If CCG3PA acts as a source, the NON-PD device with Rd is a sink. At attach,CCG3PA detects the Rd, then it sets VBUS to vSafe5V. CCG3PA will keep sending Source_Cap before timeout. So the app event you recorded is correct. In APP_EVT_TYPEC_ATTACH_WAIT, CCG3PA set VBUS to 5V. Then it enters APP_EVT_PE_DISABLED state and stops sending Source_Cap.

Regards,

Eddie

View solution in original post

0 Likes
1 Reply
YiZ_31
Moderator
Moderator
Moderator
1000 replies posted 750 replies posted 500 replies posted

Hi John,

According to PD spec:

2.7.7 Interactions between Non-PD, BC and PD devices

USB Power Delivery only operates when two USB Power Delivery devices are directly connected. When a Device finds itself a mixed environment, where the other device does not support the USB Power Delivery Specification, the existing rules on supplying vSafe5V as defined in the [USB 2.0], [USB 3.2], [USBBC 1.2] or [USB Type-C 1.3] specifications are applied.

There are two primary cases to consider:

• The Host (DFP/Source) is non-PD and as such will not send any advertisements. An Attached PD capable Device will not see any advertisements and operates using the rules defined in the [USB 2.0], [USB 3.2], [USBBC 1.2] or [USB Type-C 1.3] specifications.

• The Device (UFP/Sink) is non-PD and as such will not see any advertisements and therefore will not respond. The Host (DFP/Source) will continue to supply vSafe5V to VBUS as specified in the [USB 2.0], [USB 3.2], [USBBC 1.2] or [USB Type-C 1.3] specifications.

If CCG3PA acts as a source, the NON-PD device with Rd is a sink. At attach,CCG3PA detects the Rd, then it sets VBUS to vSafe5V. CCG3PA will keep sending Source_Cap before timeout. So the app event you recorded is correct. In APP_EVT_TYPEC_ATTACH_WAIT, CCG3PA set VBUS to 5V. Then it enters APP_EVT_PE_DISABLED state and stops sending Source_Cap.

Regards,

Eddie

0 Likes