Announcements
IMPORTANT: Cypress Developer Community is transitioning on October 20th. To learn more and be prepared for this change, check out our latest announcement.
cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

Anonymous
Not applicable

Block Diagram.png

Hi, I have been working with two FX3 devices integrated in an USB 3.0 Hub (TUSB8043RGCT).

A MUX(PI3USB302-AZBEX) is used to select the 3.0 lines of the Type C port, as shown in the block diagram.

When the Type C cable was inserted in direct connection, the CyU3PUsbGetSpeed() API returns 3 (denoting USB 3.0 connection).

When the Type C cable was connected inversely, initially it should be enumerated as USB 2.0 device and further upon switching the MUX, it should be convert into USB 3.0 device.

But in the inverted type C connection, the CyU3PUsbGetSpeed() API returns 0 (denoting no USB device connected).

Can anyone help me with this issue?

0 Likes
1 Solution
Hemanth
Moderator
Moderator

Hi Sitharthan Raja,

Please look at the implementation of firmware logic which is implemented in the following forum post:

Type C connector enumeration issue

Refer to the section "Code changes if above steps are followed:" in the correct answer.

If the logic is implemented in the way mentioned above, then in the beginning, USB2 Phy is switched off and USB3 connection is tried. If it is unsuccessful, then the mux is controlled. Before this mux control and after the failed attempt of 3.0 connection, if you call getSpeed() API it may return not connected since the USB2 Phy is disabled.

So, please check the implementation.

Regards,

Hemanth.

Hemanth

View solution in original post

0 Likes
9 Replies
Hemanth
Moderator
Moderator

Hi Sitharthan Raja,

Please look at the implementation of firmware logic which is implemented in the following forum post:

Type C connector enumeration issue

Refer to the section "Code changes if above steps are followed:" in the correct answer.

If the logic is implemented in the way mentioned above, then in the beginning, USB2 Phy is switched off and USB3 connection is tried. If it is unsuccessful, then the mux is controlled. Before this mux control and after the failed attempt of 3.0 connection, if you call getSpeed() API it may return not connected since the USB2 Phy is disabled.

So, please check the implementation.

Regards,

Hemanth.

Hemanth

View solution in original post

0 Likes
Anonymous
Not applicable

Hi hman,

Actually my problem is not with the CyU3PUsbGetSpeed() API, my device itself is not enumerating as USB 2.0 device whem USB 3.0 wa enabled in CyU3PConnectState API.

I have tried both Method 1 and Method 2 mentioned below to check for speed and switch the MUX. But my device enumerates as USB 2.0 device, only when I disable the USB 3.0 connection in CyU3PConnectState() API.

Method 1:

status = CyU3PConnectState(CyTrue, CyTrue);

if(CyU3PUsbGetSpeed() != CY_U3P_SUPER_SPEED) /*Checks whether 3.0 connection is established in the default Tx1,Rx1 pair*/

{

status = CyU3PConnectState(CyFalse, CyFalse);

/*First attempt failed*/

/* Check in other orientation */

CyU3PGpioSetValue(TYPEC_MUX_GPIO, CyFalse); /*Swiches the mux to the Tx2,Rx2 pair*/

status = CyU3PUsbControlUsb2Support (CyTrue);

status = CyU3PConnectState(CyTrue, CyTrue); /*Re establish connection through Tx2, Rx2 pair*/

if (status != CY_U3P_SUCCESS)

     {

       CyU3PDebugPrint(4, "\n\rUSB Connect 2 failed, Error code = %d", status);

     }

}

Method 2:

status = CyU3PUsbControlUsb2Support(CyFalse);

  if (status != CY_U3P_SUCCESS)

       {

      CyU3PDebugPrint(4,"\r\nDisabling USB2 failed. Stopping Execution");

  while(1);

  }

  CyU3PThreadSleep(20);

  status = CyU3PConnectState(CyTrue, CyTrue);

  CyU3PThreadSleep(50);

  for(int i =0 ; (i<100 && !U3_EVENT); i++ )

  CyU3PThreadSleep(5);

  if(!U3_TRUE)

  {

  CyU3PDebugPrint(5,"\r\nNot Super speed enumeration with MUX_SEL low. Flipping Mux to try again");

   CyU3PConnectState(CyFalse, CyFalse);

CyU3PGpioSetValue(SS_MUX_SEL_GPIO22,CyTrue);

CyU3PUsbControlUsb2Support(CyTrue);

  CyU3PThreadSleep(20);

  status = CyU3PConnectState(CyTrue, CyTrue);

  CyU3PThreadSleep(50);

  if (status != CY_U3P_SUCCESS)

  {

  CyU3PDebugPrint (4, "\n\rAppInit:ConnectState Err = 0x%x", status);

CyCx3UvcAppErrorHandler(status);

  }

  }

  else

  {

  CyU3PDebugPrint(5,"\r\nSuper speed enumeration with MUX_SEL low");

  }

  So in both the above mentioned methods the device is not enumerating as USB 2.o device.

  In Method 1 the speed was returned as 0 , while in method 2 I did not get any event.

  Method 3:

CyU3PConnectState(CyTrue, CyFalse);

Status = CyU3PUsbControlUsb2Support (CyTrue);

ConnectionSpeed = CyU3PUsbGetSpeed();

So only by disabling USB 3.0 connection as mentioned in method 3, I can get the device to enumerate as USB 2.0 device.

Please give me your opinion on this issue.

Thanks & Regards

Sitharthan R

0 Likes
Hemanth
Moderator
Moderator

Hello Sitharthan,

The method 2 you mentioned above is recommended one.

But if you go through the post I have pointed before, the method 2 you mentioned requires 2 changes. One change you have mentioned here. But the other change please refer to Change 2 mentioned in the post. Let me know if you have already done that.

And also for that you need to do the following too (see the last comment in that thread):

Define: CyBool_t U3_EVENT = CyFalse,U3_TRUE=CyTrue; in the start of your firmware.

Regards,

Hemanth

Hemanth
0 Likes
Anonymous
Not applicable

Hi Hemanth,

Yes I have added all those changes to my code.

I have defined these variables - CyBool_t U3_EVENT = CyFalse,U3_TRUE=CyTrue; as global variables.

And also checked for CY_U3P_USB_EVENT_SS_COMP_ENTRY and CY_U3P_USB_EVENT_USB3_LNKFAIL events along with the other events in EsUVCApplnUSBEventCB() as shown below.

static void EsUVCApplnUSBEventCB (CyU3PUsbEventType_t lEventCBType, uint16_t lEventCBData)

{

     switch (lEventCBType)

     {

     case  CY_U3P_USB_EVENT_USB3_LNKFAIL:

          U3_EVENT = CyTrue;

          U3_TRUE = CyFalse;

          CyU3PDebugPrint(ES_DEBUG_PRIORITY, "\rUSB3_LINKFAIL_EVNET\r\n");

          break;

     case  CY_U3P_USB_EVENT_SS_COMP_ENTRY:

          U3_EVENT = CyTrue;

          U3_TRUE = CyFalse;

          CyU3PDebugPrint(ES_DEBUG_PRIORITY, "\n\rSS_COMP_ENTRY Event Occured");

          break;

     default:

          break;   

     }

}

Even then none of these events occurred and I couldn't get my device as a USB 2.0 device.

Thanks & Regards

Sitharthan R

0 Likes
Hemanth
Moderator
Moderator

Hi Sitharthan,

You had made the below comment in your first post - "When the Type C cable was connected inversely, initially it should be enumerated as USB 2.0 device and further upon switching the MUX, it should be convert into USB 3.0 device."

Let me comment on the above:

Let's say you have connected the cable invertedly then,

- Given that you have implemented method 2 indicated above, FX3 first tries to establish 3.0 connection on the wrong pair of 3.0 lines. When it is trying this, USB2 Phy is disabled. (Reason being: In normal operation, if 3.0 connection fails, device falls back to 2.0 - which we don't desire here)

- Now since the 3.0 connection failed, you should be seeing CY_U3P_USB_EVENT_USB3_LNKFAIL event.

- When firmware sees this event, 1) it changes the mux sel 2) Enables 2.0 Phy and lastly 3) Tries for 3.0 connection. If 3.0 connection fails here, then device falls back to 2.0 (Now, once it falls back to 2.0 here, there is some problem with establishing 3.0 - to find the reason you need to take an USB trace and see what's going on)

So, when you insert invertedly, once again check whether you are getting the CY_U3P_USB_EVENT_USB3_LNKFAIL event.

Regards,

Hemanth

Hemanth
0 Likes
Anonymous
Not applicable

Hi Hemanth,

As you mentioned in your previous comment

" Let's say you have connected the cable invertedly then,

- Given that you have implemented method 2 indicated above, FX3 first tries to establish 3.0 connection on the wrong pair of 3.0 lines. When it is trying this, USB2 Phy is disabled. (Reason being: In normal operation, if 3.0 connection fails, device falls back to 2.0 - which we don't desire here)

- Now since the 3.0 connection failed, you should be seeing CY_U3P_USB_EVENT_USB3_LNKFAIL event.

- When firmware sees this event, 1) it changes the mux sel 2) Enables 2.0 Phy and lastly 3) Tries for 3.0 connection. If 3.0 connection fails here, then device falls back to 2.0 (Now, once it falls back to 2.0 here, there is some problem with establishing 3.0 - to find the reason you need to take an USB trace and see what's going on) "

I have implemented your method to detect the USB speed( Type C connector enumeration issue​) into the static frames examples given along with the FX3_SDK_Windows_v1.3.3 - cyfxuvcinmem_bulk. I have attached the main file of the example.

I have connected my device in the wrong pair of USB 3.0 connection but CY_U3P_USB_EVENT_USB3_LNKFAIL doesn't occurs.

Even when connected in USB 2.0 port the CY_U3P_USB_EVENT_USB3_LNKFAIL doesn't occurs. In both the cases it neither enumerates as USB 3.0 device nor falls back to USB 2.0 connection.

I have connected the device in USB 3.0 (both the orientations) and also in USB 2.0 and the UART debug logs were captured.

Those logs were as below,

USB 3.0 Direct Connection

Event Type -> 11.

CY_U3P_USB_EVENT_VBUS_VALID

Event Type -> 0.

Y_U3P_USB_EVENT_CONNECT

Mux Not Flipped. U3_TRUE = 1

USB 3.0 Inverted Connection

Event Type -> 11.

CY_U3P_USB_EVENT_VBUS_VALID

Mux Not Flipped. U3_TRUE = 1

USB 2.0 Connection

Event Type -> 11.

CY_U3P_USB_EVENT_VBUS_VALID

Mux Not Flipped. U3_TRUE = 1

Thanks & Regards

Sitharthan R

0 Likes
Hemanth
Moderator
Moderator

Hello Sitharthan,

Your code looks correct.

Can you please do the following:

1. Take the 'cyfxbulksrcsink' project from the following location:

C:\Program Files (x86)\Cypress\EZ-USB FX3 SDK\1.3\firmware\basic_examples\cyfxbulksrcsink

2. Make the changes necessary for type C connection (exactly as you did for your project)

3. Then collect the UART prints. (You can collect the uart logs when you connect the cable inverted - since the problem is with that)

From this firmware we can know different events which are occurring.

Please note that the LPP mode in BulkSrcSink firmware is UART_ONLY. The uart info comes in different pins. Either you can collect the prints in those pins OR you can change the mode to LPP_DEFAULT.

Please let me know if there are any questions.

Regards,

Hemanth

Hemanth
0 Likes
Anonymous
Not applicable

Hi Hemanth,

I have implemented the Type C connection changes in the cyfxbulksrcsink example and captured the log using UART by connecting the device in USB 3.0 port (both the orientations) and also in USB 2.0 port. I have also attached the main file of the cyfxbulksrcsink example for your reference.

Log:

USB 3.0 Straight connection

debug initialized

USB EVENT: 11 0

CY_U3P_USB_EVENT_VBUS_VALID

About to connect to USB host

Mux Not Flipped. U3_TRUE = 1

CyFxBulkSrcSinkApplnInit complete

USB LOG: 6

USB LOG: 11

USB 3.0 inverted connection

debug initialized

USB EVENT: 11 0

CY_U3P_USB_EVENT_VBUS_VALID

About to connect to USB host

USB EVENT: 0 1

Mux Not Flipped. U3_TRUE = 1

CyFxBulkSrcSinkApplnInit complete

USB LOG: 6

USB LOG: 12

USB LOG: 25

USB LOG: 26

USB EVENT: 8 0

USB EVENT: 5 1

USB 2.0 Connection

debug initialized

USB EVENT: 11 0

CY_U3P_USB_EVENT_VBUS_VALID

About to connect to USB host

Mux Not Flipped. U3_TRUE = 1

CyFxBulkSrcSinkApplnInit complete

USB LOG: 6

USB LOG: 11

Can you create a private Technical Support Ticket for me? There I could share you our schematics for better analysis of the issue.

Please give me your opinion on it.

Thanks & Regards

Sitharthan R

0 Likes
Hemanth
Moderator
Moderator

Hi Sitharthan,

- I think the logs for the straight connection and inverted connection are swapped in the above response. Please confirm.

We can try the following:

- After CyU3PUsbControlUsb2Support(), there is Threadsleep, CyU3PThreadSleep(20). Increase this and check the behavior.

- In for(int i =0 ; (i<100 && !U3_EVENT); i++ ), increase the value 100 and test the behavior.

Regards,

Hemanth

Hemanth
0 Likes