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