- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I'm working with the FX3, Slave fifo setup, Control EP(0) and bulk in EP.
I start read data from the Bulk EP and at the same time work with the Control EP. After few transactions the CyU3PUsbSendEP0Data function fails with CY_U3P_ERROR_TIMEOUT error code. From that time all calls to CyU3PUsbSendEP0Data fails. The control OUT direction continue to work. The situation appears more frequently when the FX3 device connect to USB2 port (host side).
I use SDK 1.3.1.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
who can solve,I encountered a similar problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
how is the transmitted data size? Is it may be a multiple of USB packet size (512 bytes while connected to high speed and 1024 bytes when connected to super speed when transfer timeouts?
Or are you sure, that host PC has preloaded an URB for the control transfer?
regards,
lumpi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
When operating at USB 2.0 speeds, we have observed bulk IN transfers sometimes create errors during control IN transfers when both happen in parallel. To avoid this possibility, ensure that the bulk channel is suspended for the duration of the control request and resume it once control request is completed.
Here is how you can do it.
When configuring the DMA channel, enable callback with callback notification = CY_U3P_DMA_CB_CONS_SUSP. This will generate a callback whenever channel is successfully suspended.
In the CyFxApplnUSBSetupCB function,
if (bType == CY_U3P_USB_VENDOR_RQT)
{
if (bRequest == <your Control-IN request code>)
{
if (CyU3PUsbGetSpeed () != CY_U3P_SUPER_SPEED)
{
/* Suspend the Bulk pipe and wait until it suspends. */
glChannelSuspended = CyFalse;
CyU3PDmaChannelSetSuspend (&glDmaChHandle, CY_U3P_DMA_SCK_SUSP_NONE, CY_U3P_DMA_SCK_SUSP_CUR_BUF); // Note that this function returns immediately and the channel suspension is confirmed when callback function is invoked.
while ((!glChannelSuspended) && (timeout--)) // glChannelSuspended is set to true in the DMA channel callback function
CyU3PThreadSleep (1);
}
glEp0Buffer[0] = vendorRqtCnt;
glEp0Buffer[1] = underrunCnt;
glEp0Buffer[2] = 1;
glEp0Buffer[3] = 2;
CyU3PUsbSendEP0Data (wLength, glEp0Buffer); // Control IN transfer
vendorRqtCnt++;
isHandled = CyTrue;
CyU3PDmaChannelResume ( &glDmaChHandlee, CyBool_t isProdResume, CyBool_t isConsResume ) // Resume the suspended BULK-in channel
}
}
note: Refer GpifToUsb example project in basic_examples section in FX3 SDK where this problem is dealt with.
Regards
Mudabir Kabir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
This issue is already answered in the following thread:
Jayakrishna