- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
We have a CX3 camera design using a USB-C connector and a multiplexer as described here (and are using the firmware from the article to control the multiplexer'
When the plug is connected with the default select orientation, that is to say the mux select pin is in the correct state, the device connects as a super-speed device and all is well. When the USB-C plug is in the other orientation, firmware detects it and signals (via the debug serial port) that it is setting the select signal high. After enumeration, the CX3's CyU3PUsbGetSpeed() function returns CY_U3P_SUPER_SPEED but Cypress USB Control center doesn't show the superspeed header information as shown here:
With the plug in the other orientation the PC recognizes a superspeed device:
Here's the debug (serial port printout) for the non-superspeed orientation:
I have attached CyCx3UvcApplnInit() containing the mux gpio control logic.
Any thoughts most appreciated.
Thanks,
Scott
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Scott,
I have modified the gpif to usb example of the sdk with the functionality mentioned in KBA
The device is enumerating as Super speed device at my end. Please try this example with your hardware
You can refer tot he attached results
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Scott,
Please confirm that you are check for CY_U3P_USB_EVENT_SS_COMP_ENTRY and CY_U3P_USB_EVENT_USB3_LNKFAIL.
when these event occur you need to set the U3_TRUE variable to CyFalse
Also let me know why are you using CyU3PThreadSleep( 100 ) after initio( PORT2, true, true );
Can you try with the same snippet code in the KBA (the delays) and let me know the results.
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
I am working my through the MUX control code now and am going to need a fundamental description of what the code was attempting to do.
To code I've implemented maintains the two variables U3_EVENT and U3_TRUE. They are initially cleared. U3_EVENT is simply set in the USB callback routine. U3_TRUE is set when either a CY_U3P_USB_EVENT_SS_COMP_ENTRY or CY_U3P_USB_EVENT_USB3_LNKFAIL event is detected. I am expecting that when the USB-C plug is plugged in to match the state of the multiplexer SEL signal there will be neither of these error events and when the plug is reversed, there will be a CY_U3P_USB_EVENT_USB3_LNKFAIL event.
Best,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
I have made progress on the MUX control code, but still can't get SS enumeration in the reverse plug direction. In the forward direction, the device enumerates as a SS device and is fully functional. When plugged in backward, firmware detects that it must flip SEL and does. I see the streamer device appear twice in fairly rapid succession. I assume the first time as a SS device, then as not a SS device (Control Center doesn't show any SS fields). But to make things more confusing, firmware reports it has connected as a SS device (CyU3PUsbGetSpeed returns 3).
I've attached my code.
Thanks for your help,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Scott,
Please confirm that you initialize the U3_EVENT and U3_TRUE variables
U3_EVENT = CyFalse;
U3_TRUE = CyTrue;
and on getting these CY_U3P_USB_EVENT_SS_COMP_ENTRY and CY_U3P_USB_EVENT_USB3_LNKFAIL. events the state of these variables will be
U3_EVENT = CyTrue;
U3_TRUE = CyFalse;
Also check that the API for setting the GPIO value is passing successfully
Please probe the USB lines and share the usb traces (.pcap file). You can use wireshark for that.
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
The U3_EVENT and U3_TRUE flags, as I am controlling them are correctly signaling when the cable is plugged in "forward" or "reversed". Bu this I mean, I can tell if the cable is plugged in to match the multiplexer's SEL setting or if SEL needs to be flipped.
The part of the code that doesn't work is what is done if SEL needs to be flipped.
As requested, I have attached two wire shark pcap captures. forward.pcapng shows a successful SS connection when the plug is inserted in the forward direction, e.g. when the MUX SEL signal is initially correct. reverse.pcapng shows a failed connection when the plug is reversed.
Thanks,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Scott,
I have modified the gpif to usb example of the sdk with the functionality mentioned in KBA
The device is enumerating as Super speed device at my end. Please try this example with your hardware
You can refer tot he attached results
Regards,
Rashi
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
I think I am beginning to understand why I am having issues with this.
My CyFxApplnInit() routine is lots longer and slower than yours because I am waiting 500 ms for a component in our system to initialize. In fact, even the logic to detect a reversed plug in the code you sent me does not work. After implementing your code, but using my reversed plug detection code there was one thing that did change: after SEL is flipped, the CX3 is initially fooled into believing it has a SS connection (CyU3PUsbGetSpeed=3), but later in the application idle loop, it now detects there is no SS connection (it first detects speed 1 then speed 2).
Tomorrow I am going to experiment moving these long initialization routines to the application idle routine (CyFxAppThread_Entry), to see if it makes enumeration more reliable. I'll let you know how that goes.
Thanks for your help,
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rashi,
My Hunch was right. I had quite a lot of initialization code added to CyFxApplnInit. Once I moved code not related to USB initialization to the CyFxAppThread_Entry routine (just before the call to CyFxApplnInit) things fell into place. I had to change the reversed plug detection code to match your example to function properly. Prior to rearranging, the example plug reverse detection code didn't work for me.
The code now correctly detects reversed plugs and connects as a SS device in both directions.
Thanks for your help.
Scott