- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My application uses a vendor request to periodically set parameters. I noticed that requests are processed very slowly, on the order of 30 ms. On another processor (CY7C68013A), these same requests are processed 3 ms. How to change request processing speed.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
As described in FX3_SDK_TroubleShooting_Guide provided with the FX3 SDK, Section 2.3, Part IV.
The low performance of the CyU3PUsbSendEP0Data() is because, the other IN (BULK,ISO, INTERRUPT) endpoints need to be suspended so that the the data over the control endpoint doesn't get corrupted due to premature data fetching from the DMA channel and was included from SDK version 1.3.2 onwards.
As a workaround you could implement the following snippet of code instead of CyU3PUsbSendEP0Data():
extern CyU3PDmaChannel glUibChHandle; /* In channel handle for ep0 */
extern CyU3PReturnStatus_t /* declaration of DmaChannelSendData */
CyU3PDmaChannelSendData (
CyU3PDmaChannel *handle,
uint8_t *buffer,
uint16_t count);
In the vendor command that you are using, replace CyU3PUsbSendEP0Data() with the below two lines:
CyU3PDmaChannelSendData (&glUibChHandle, glEp0Buffer, wLength); /* use instead of CyU3PUsbSendEP0Data*/
CyU3PUsbAckSetup (); /*important to ack the request from host*/
NOTE: The above workaround is a way to match the control endpoint performance to that of SDK 1.3.1 but it should be taken care in the firmware that there is no BULK-IN transaction while EP0-IN transaction is going on as it will lead to the control read data getting corrupted.
Also, the above workaround is only provided to you and will not be added to the future releases of SDK as there are the above mentioned problems with it. So, in future releases, you will have to take care of the workaround in the application by yourself.
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
May i know how you are able to get the processing time?
Is it displayed on the host side or over the UART terminal?
Also, are both the devices being tested under same conditions?
Can you please be a bit more elaborate about the process of getting these timings?
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
It is displayed on the host side in Visual Studio, and seen with GPIO switching inserts that function CyU3PUsbGetEP0Data() runs about 3ms and CyU3PUsbSendEP0Data() runs about 30 ms regardless of the amount of data. UART terminal is off.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Can you please confirm that your application is working in USB 2.0?
Also, is there a feasibility for you to migrate the application to USB 3.0 and then test the same?
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, Yashwant!
I confirm that my application is working in USB 2.0 because my device only supports hardware USB2.0
At the moment, I can not migratethe application to USB 3.0 and then test same.
I used to compare applications in USB 2.0 and in USB 3.0 and observe a similar phenomenon, but then it was not critical. You have a document FX3_SDK_TroubleShooting_Guide (2.3 IV) that describes the problems and it refers to the delay of endpoints, I think these problems are related.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
As you have already gone through the FX3_SDK_TroubleShooting_Guide which describes the issue of the BULK-IN endpoint suspend when an EP0-IN transaction is being handled.
When CyU3PUsbSendEP0Data() API is called, it calls another API (CyU3PUsbSuspendInEpChannels()) which suspends the BULK-IN endpoints for a minimum of 50us (micro-seconds) and a maximum of 10ms for each endpoint.
You can go through the CyU3PUsbSendEP0Data() API src from the FX3 library src for a depper insight.
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Yashwant!
I've already watched all this and know how to disable this stop for BULK-IN endpoint et cetera. But it seems that the exchange is also suspended at the EP0, but I want to get work around this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Can you point to the code which shows that EP0 is being suspended?
The process of suspensions only happens for BULK-IN endpoints when CyU3PUsbSendEP0Data() API is called.
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, dear Yashwant!
I do not understand your actions.
If you know how to increase the speed of EP0, then explain how. If you don’t know, say so.
Conduct a simple experiment - measure the execution time of calls CyU3PUsbSendEP0Data() and CyU3PUsbGetEP0Data() and you show difference. For example in USBBulkSourceSinkLED in vendor requests 0x78 and 0x80.
Not only BULK-IN request is suspend, but also other IN requests (ISO and INTERRUPT) when API is called.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I tried the above method and found the results that you have found.
The number of transactions changes with the number of IN (BULK, ISO, INTERRUPT) endpoints other than EP0 that are being used in the application.
Unfortunately, there is no way to make these control read transfers faster.
The amount of delay and the number of transfers, totally, depend upon the number of IN-endpoints that are being used in the application.
If the host application can request an IN-request every 125us and there are no IN-endpoints, the device can achieve a count of 8000 op/s.
I have tested and verified this by using USBI2cRegmode example in USB 2.0 and took traces while using the host application and found the above results.
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
As described in FX3_SDK_TroubleShooting_Guide provided with the FX3 SDK, Section 2.3, Part IV.
The low performance of the CyU3PUsbSendEP0Data() is because, the other IN (BULK,ISO, INTERRUPT) endpoints need to be suspended so that the the data over the control endpoint doesn't get corrupted due to premature data fetching from the DMA channel and was included from SDK version 1.3.2 onwards.
As a workaround you could implement the following snippet of code instead of CyU3PUsbSendEP0Data():
extern CyU3PDmaChannel glUibChHandle; /* In channel handle for ep0 */
extern CyU3PReturnStatus_t /* declaration of DmaChannelSendData */
CyU3PDmaChannelSendData (
CyU3PDmaChannel *handle,
uint8_t *buffer,
uint16_t count);
In the vendor command that you are using, replace CyU3PUsbSendEP0Data() with the below two lines:
CyU3PDmaChannelSendData (&glUibChHandle, glEp0Buffer, wLength); /* use instead of CyU3PUsbSendEP0Data*/
CyU3PUsbAckSetup (); /*important to ack the request from host*/
NOTE: The above workaround is a way to match the control endpoint performance to that of SDK 1.3.1 but it should be taken care in the firmware that there is no BULK-IN transaction while EP0-IN transaction is going on as it will lead to the control read data getting corrupted.
Also, the above workaround is only provided to you and will not be added to the future releases of SDK as there are the above mentioned problems with it. So, in future releases, you will have to take care of the workaround in the application by yourself.
Regards,
Yashwant
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thank you for help. I will definitely try your solution and let you know the results. In my project, BULK-IN is not used, but used ISO-IN and INTERRUPT-IN endpoints. They can affect to the control read data getting corrupted?
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Vladimir,
The issue is not only limited to BULK as you already described in your previous interactions.
There is a pre-mature data fetching from other other IN-endpoint channels when doing ep0-IN transactions.
Can you please try the above method and then share the results?
Regards,
Yashwant