You are here

CyU3PUsbSendEP0Data with FX3 SDK Version 1.3.3 | Cypress Semiconductor

CyU3PUsbSendEP0Data with FX3 SDK Version 1.3.3

Summary: 2 Replies, Latest post by pj24 on 12 Nov 2016 02:34 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
pj24's picture
User
3 posts

Hi,

we recently switch from SDK Version 1.3.1 to 1.3.3 and found that our FX3 USB Device Application when connected at USB High Speed, each call to CyU3PUsbSendEP0Data() takes 20 ms which previously took well below 1 ms.

The device has two IN Data Endpoints (one Isochronous and one Interrupt) and we traced the problem down to a modification in the implementation of CyU3PUsbSendEP0Data()  which now makes a call to CyU3PUsbSuspendInEpChannels (), which tries to suspend all IN Endpoints before doing the DMA for Endpoint 0.

It seems the call to CyU3PDmaChannelSuspendUsbConsumer() with waitOption set to 10 always needs 10 ms to complete.

What can be done to prevent this problem? Is it really necessary to suspend Interrupt and Isochronous IN Endpoints while doing EP0 data transfers?

The Cypress EZ-USB FX3 SDK Release Notes Version 1.3.3 mentions one point: 

     Implemented a firmware solution to prevent data corruption due to concurrent BULK-IN and Control-IN transfers on a Hi-Speed link.

while the 1.3.3 firmware implementation in cyu3usb.c and cyu3channel.c suspends ALL IN endpoints, not just BULK.

Which kind of corruption can happen due to concurrent transfers?

What is the best workaround to make CyU3PUsbSendEP0Data() calls to work again as fast as before while having other IN Endpoints in an USB device? Would it be sufficient to suspend only BULK-IN endpoints?

Thanks for any help,

 

Peter

 

nisa's picture
Cypress Employee
85 posts

As you have read in the release note, the delay is due to channel suspend which the libraries are doing to avoid the data corruption. This happens on USB2 only (not on USB3.0). The data corruption can be because of the Bulk or Interrupt transfers. It is a preventive measure implemented so that you do not see any data corruption. However, if it is crucial for you to avoid this delay over USB 2, please create a technical support case, we can modify the libraries to remove this channel suspend feature. 

pj24's picture
User
3 posts

Thanks Nishant for your reply and the offer! Some more questions before we can decide on how to handle this:

Is the data corruption no issue on Isochronous IN Endpoints? Version 1.3.3 of the library also suspends isochronous endpoints.

Which data is potentially corrupted? The Endpoint 0 data or the data on the Bulk/Interrupt endpoints? Or both?

Looking at the source code of the library, it looks like the library is setting the suspend flag to each endpoint and than waits for up to 10 ms for the endpoints being suspended. So the 10 ms delay per endpoint we observe look like that the endpoint was not reporting being suspended yet, but the library rather time-outs after 10 ms waiting for the suspend to succeed. It this intended that way? 

Thanks for your help!

Log in to post new comments.