CYUSB3014 - How to speed up operate control endpoint IN for USB highspeed

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

cross mob
VlSh_3188636
Level 1
Level 1

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.

0 Likes
1 Solution

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

View solution in original post

0 Likes
12 Replies
YashwantK_46
Moderator
Moderator
Moderator
100 solutions authored 50 solutions authored 50 likes received

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

0 Likes

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.

0 Likes

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

0 Likes

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.

0 Likes

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

0 Likes

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.

0 Likes

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

0 Likes

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.

0 Likes

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

0 Likes

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

0 Likes

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

0 Likes

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

0 Likes