cancel
Showing results for 
Search instead for 
Did you mean: 

USB Superspeed Peripherals

leda_289486
New Contributor II

CyU3PUsbSendEP0Data fail on Timeout 

Hi there,

I reactive this post because with CX3 and 1.3.4 SDK I still encounter the problem. Here is the situation. We have IN transfers superspeed nearly at maximum data rate of CX3. Typically, it is more than 2 Gbits/s. we use the EP0 for (vendor) commands and thus IN transfer. These IN transfers  on EP0 are very small, typically only 2 bytes returned as IN.

At a point, we get timeout code as result of CyU3PUsbSendEP0 function and after that there is NO way to retrieve the correct behavior even when IN superspeed transfers ends. I find this totally weird. There is no mean to reset this situation ?

On parallel OUT EP0 is still working, exactly as described in this post.

I tried to use the "suspend" code here described but this doesn't work because the suspend operation is not reliable and most of the time doesn't operate any suspend in DMA transfers : the gChannelSuspended variable doesn't commute to suspended state and timeout variable comes to zero itself. "Sometimes" the suspend arises but most of the time it doesn't. By the way we use auto Many to One transfers operations for the superspeed IN high data rate endpoint.

I also didn't find where the GpifToUSB code can help to understand the situation.

Is there a solution for this ? This problem seams to be present since several years now, we would be happy to solve it because this is really a HUGE problem when using CX3 and FX3.

Please give a solution for a RELIABLE EP0 RESET when timeout arises !!

Thank you

Best Regards.

0 Likes
1 Solution
KandlaguntaR_36
Moderator
Moderator

Hello,

CyU3PUsbAckSetup should not be called if CyU3PUsbSendEP0Data success.

We will correct the lowpowertest example firmware in the next revision.

Is the issue solved after the code modification?

Regards,

Sridhar

View solution in original post

0 Likes
46 Replies
leda_289486
New Contributor II

Hi,

What can we do when the error condition from hardware is triggered ?

Could you indicate us a framework example preventing this error to happen in any case and where vendor commands are correctly post-processed ?

Last possibility : is it possible to restart cx3 device without being disconnected ?

Thank you for your help,

Best Regards.

0 Likes
KandlaguntaR_36
Moderator
Moderator

Hello,

The return value of CyFxUVCApplnUSBSetupCB is not updating properly. We defined "uvcHandleReq" as return value for USBSetupCB. This value is updated only once in the SetupCB: That is only for UVC Class Requests.

If the SetupCB is for Vendor class request, the SetupCB is returning CyFalse in this case, even though you have handled.

It is supposed to return CyTrue when you have handled the Vendor Request.

Please modify the snippet as below and check.

txApiRetStatus = VendorInterpreter(); // processing the command here. no EP0 handling in it

if (txApiRetStatus == CY_U3P_SUCCESS)

{

if ((setupReqType & 0x80) == 0x80)

     {

              uvcHandleReq = CyTrue;

          txApiRetStatus = CyU3PUsbSendEP0Data(RequestedReturnSize, AnswerToPC); // direct answer

          if(txApiRetStatus != CY_U3P_SUCCESS)

              {

               /* There was some error. We should try stalling EP0. */

                CyU3PUsbStall(0, CyTrue, CyFalse);

               }

     }

else

     {

               uvcHandleReq = CyTrue;

              CyU3PUsbAckSetup();

     }

}

else

{

               uvcHandleReq = CyTrue;

     CyU3PUsbAckSetup();

     if (ValidDebugMessage) CyU3PDebugPrint(4, "Bad return 0x%x\r\n", txApiRetStatus);

}

-----------------------------------------------------------------

Note that CyU3PUsbAckSetup function is used to complete the status handshake of a USB control request that does not involve any data transfer.

If there is a need for OUT or IN data transfers to process the control request, the CyU3PUsbGetEP0Data and CyU3PUsbSendEP0Data calls should be used instead.

This function should only be used if a positive ACK is to be sent to the USB host. To indicate an error condition, the CyU3PUsbStall call should be used to stall the endpoint EP0-OUT or EP0-IN.

----------------------------------------------------

I can see that lowpower test example is sending CyU3PUsbAckSetup eventhough CyU3PUsbSendEP0Data is success. In failure or isHandled CyFalse case, the zero endpoint is stalled.

This is contradicting the above note. I will check on this and update you. Meanwhile, you go with above snippet implementation: CyU3PUsbSendEP0Data or CyU3PUsbAckSetup at a time and returning the SetupCB with CyTrue when the command is handled in firmware.

0 Likes
leda_289486
New Contributor II

Hi,

thank you for this feedback. I implement the modifications immediatly. This is good news !

I'll wait for your update about the example you talked in your answer.

Thank you for your help,

Best Regards,

0 Likes
KandlaguntaR_36
Moderator
Moderator

Hello,

CyU3PUsbAckSetup should not be called if CyU3PUsbSendEP0Data success.

We will correct the lowpowertest example firmware in the next revision.

Is the issue solved after the code modification?

Regards,

Sridhar

View solution in original post

0 Likes
leda_289486
New Contributor II

Hi,

Thank you for this explaination it helped to have correct framework code.

For now, we are testing this modification in our code intensively to check that if this issue doesn't appear anymore.

For now it seems correct, so we hope the issue has been solved this way.

Best regards.

0 Likes
KandlaguntaR_36
Moderator
Moderator

Great!

It is a good news!

0 Likes
leda_289486
New Contributor II

hi,

here are a typical endpoint 0 error situation with a 2 transfer bytes. Errors appear at end of file. After that, nothing on EP0 IN. Capture has been done with UsbLyzer.

How frequent ? after typically 100 EP0 in requests, we are sure to be in this situation but it can happen after much less...

I check the value CY_U3P_UIB_EEPM_EP_READY indeed. But when it never comutes to "ready", I'd like to know what to do.

Best Regards,

0 Likes