- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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