Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

USB superspeed peripherals

SaGi_4116301
Level 2
10 replies posted 10 sign-ins 5 replies posted
Level 2

Hi,

I have built a UVC video application on the CYUSB3KIT-003 (which has a  CYUSB3014 device if I am not mistaking).

It uses control endpoint communication with vendor requests to program sensor registers “on the fly”. It also uses winusb.sys driver on host PC, so not the Cypress drivers. In USB3 mode all works well; in USB2 mode I get random issues with control endpoint transfers; the program sometimes simply stalls.

I found these discussions:

https://community.cypress.com/t5/USB-Superspeed-Peripherals/CYUSB3014-How-to-speed-up-operate-contro...

and 

https://community.cypress.com/t5/USB-Superspeed-Peripherals/CYUSB3013-low-control-read-performance-w...

Apparently there is s silicon bug on some FX3 devices, related to control endpoint data corruption in USB2.0 mode.

This corruption occurs as a result of the use of "DMA data pre-fetching", which was implemented in SDK versions 1.3.2 and higher to solve yet another data corruption error: see comments with CyU3PUsbEnableEPPrefetch in cyu3usb.h.

Bottom line: the control endpoint data corruption in USB2 mode is fixed apparently in the SDK with a work around where all other BULK IN endpoints are suspended for a while. The price to pay is apparently a slow control endpoint transfer in USB2 mode. Indeed, in the SDK source code of CyU3PUsbSendEP0Data I see a call to CyU3PUsbSuspendInEpChannels for non-superspeed connection.

My suspicion is that my control endpoint transfer issues in USB2 mode are related to its slow response, caused by the CyU3PUsbSuspendInEpChannels somehow.

I have the following questions:

1) Does the CYUSB3014 on the CYUSB3KIT-003 have the silicon bug that requires the use of  CyU3PUsbSuspendInEpChannels during control endpoint transfers in USB2 mode?

2) If the CYUSB3014 does not have the silicon bug: is it possible to remove the CyU3PUsbSuspendInEpChannels call inside the CyU3PUsbSendEP0Data function definition? Does that require hacking SDK code or is there a more elegant way?

3) In the aforementioned discussions it is suggested to replace the CyU3PUsbSendEP0Data calls in USB2 mode with a custom function that does not do a CyU3PUsbSuspendInEpChannel, to speed up control endpoint transfer in USB2.
In my UVC application, would I then have to manually suspend the BULK video EP temporarily each time I do a control endpoint transfer? How do I suspend a BULK video EP with the least amount of delays in my control endpoint transfers?

4) Does the host PC driver require special provisions to deal with a very slow responding control endpoint transfer?
Since I observe these "hangups" in USB2 mode irregularly, when I do control endpoint transfers.
Do the host PC cypress drivers have built-in special provisions for this that the winusb.sys driver does not have?

Thanks

0 Likes
1 Solution
AliAsgar
Moderator
Moderator 500 replies posted 250 replies posted 250 sign-ins
Moderator

Hi Sander,

Replying to one of your previous interaction, Yes, The CYUSB3014 on the CYUSB3KIT-003 has a silicon bug that requires the use of  CyU3PUsbSuspendInEpChannels during control endpoint transfers in USB2 mode.

Use of CyU3PUsbSetEpSuspDisableMask is preferred over the workaround provided in the thread you have shared, as there is a dedicated and tested API to do so.

The order of EP numbering in the mask is LSB is for EP0 and MSB is for EP15.

Best Regards,
AliAsgar

View solution in original post

0 Likes
5 Replies
AliAsgar
Moderator
Moderator 500 replies posted 250 replies posted 250 sign-ins
Moderator

Hi,

1. Could you let us know what are the exact issues you are facing at the control endpoint? 

2. Which SDK version is being used?

3. If possible, kindly provide us with the traces when the issue is seen.

Best Regards,
AliAsgar.

0 Likes
SaGi_4116301
Level 2
10 replies posted 10 sign-ins 5 replies posted
Level 2

Hi,

I use SDK version 1.3.4.

I have issues in USB2 (high speed) mode, with a vendor request, initiated through the control endpoint while the FX3 is streaming video, that in turn initiates a CyU3PUsbSendEP0Data.

This vendor works fine in USB3 mode, but in USB2 mode the vendor request results sometimes

(randomly) in a hang-up on the PC side.

If I add the following lines before the CyU3PUsbSendEP0Data the problem seems to disappear:

 if (usbSpeed == CY_U3P_HIGH_SPEED)
{
     CyU3PUsbSetEpSuspDisableMask(0xFFFF);

Best regards

Sander

 

0 Likes
AliAsgar
Moderator
Moderator 500 replies posted 250 replies posted 250 sign-ins
Moderator

Hi  Sander,

1. Could you let me know if there is any data corruption during the control IN transfer while adding the lines you have mentioned above?

2. Is the workaround mentioned in the thread : https://community.cypress.com/t5/USB-Superspeed-Peripherals/CYUSB3014-How-to-speed-up-operate-contro... also working for you?

By working I mean even the video data should be streaming properly and the control IN transfer must also occur without any issues or corruption.

Best Regards,
AliAsgar

0 Likes
SaGi_4116301
Level 2
10 replies posted 10 sign-ins 5 replies posted
Level 2

Hi,

To answer you questio:

2) I have tried that, and it also "works"

1) about the definition of working: 

typically whenever I send this vendor command that I mentioned, I pause the PC host
application's post-processing of video frames for a while. So I don't display the actual video frames on the PC screen. However, internally, the host application keeps grabbing the raw frames, I just don't look at them. If video data would be corrupted, I guess that
could also corrupt UVC headers etc? And cause a permanent video freeze? That is not what I see, at least with the limited testing I did.

I will let the sensor send out test patterns and grab and store all frames to disk to check if anything gets corrupted.

In the meantime: is there any difference between the workaround you mentioned and the use of   CyU3PUsbSetEpSuspDisableMask in terms of expected robustness/likelihood of occurrence of remaining data corruption? Which method would be preferred?

Btw: about the mask definition for CyU3PUsbSetEpSuspDisableMask:
what is the order of EP numbering in that mask?

Thanks,

Sander

0 Likes
AliAsgar
Moderator
Moderator 500 replies posted 250 replies posted 250 sign-ins
Moderator

Hi Sander,

Replying to one of your previous interaction, Yes, The CYUSB3014 on the CYUSB3KIT-003 has a silicon bug that requires the use of  CyU3PUsbSuspendInEpChannels during control endpoint transfers in USB2 mode.

Use of CyU3PUsbSetEpSuspDisableMask is preferred over the workaround provided in the thread you have shared, as there is a dedicated and tested API to do so.

The order of EP numbering in the mask is LSB is for EP0 and MSB is for EP15.

Best Regards,
AliAsgar

0 Likes