cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

ScGr_289066
Contributor II

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:

pastedImage_7.png

With the plug in the other orientation the PC recognizes a superspeed device:

pastedImage_8.png

Here's the debug (serial port printout) for the non-superspeed orientation:

pastedImage_9.png

I have attached CyCx3UvcApplnInit() containing the mux gpio control logic.

Any thoughts most appreciated.

Thanks,

Scott

0 Likes
1 Solution
Rashi_Vatsa
Moderator
Moderator

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

Regards,
Rashi

View solution in original post

0 Likes
8 Replies
Rashi_Vatsa
Moderator
Moderator

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

Regards,
Rashi
0 Likes
ScGr_289066
Contributor II

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

0 Likes
ScGr_289066
Contributor II

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

0 Likes
Rashi_Vatsa
Moderator
Moderator

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

Regards,
Rashi
0 Likes
ScGr_289066
Contributor II

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

0 Likes
Rashi_Vatsa
Moderator
Moderator

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

Regards,
Rashi

View solution in original post

0 Likes
ScGr_289066
Contributor II

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

0 Likes
ScGr_289066
Contributor II

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

0 Likes