- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dears,
We have a FX3 device which uses GPIF to keep reading large datasets from FPGA and then sends them to PC host through a bulk-in end point.
With Wireshark, we find that sometimes PC sends a clear-feature to the device to reset the bulk-in end point (before this, a bulk-in reading failure occurred on PC site). We think this maybe caused by some bulk-in transaction failures ( CRC errors , time-out, or USB device stalled, etc.) detected by PC host.
From the examples provided by Cypress, after receiving a clear-feature request, FX3 needs to reset the DMA channel associated with the bulk-in end point, flush and reset the end point, etc. . this may lead to the un-transmitted data lost in the DMA buffer.
Is it possible to retransmit the lost data after communication recovery (with GPIF interface between FX3 and FPGA, it is hard to do the data backup before transmission)? if so, how to do it?
Thanks,
Scott
- Labels:
-
USB Superspeed Peripherals
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Scott,
Could you share with us your firmware example or tell us the DMA channels being used?
Best Regards,
AliAsgar
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi AliAsgar,
We are developing a device which continuously samples multiple channels' signal and then sends the sample value to PC.
In the device, FPGA keeps sampling the signals without interrupt, and FX3 reads the sample value from FPGA through GPIF interface and sends the data to PC with USB bulk-in end points.
Sometimes, PC application prompts that there is a bulk-in reading failure and the USBDStatus got from driver is"STALL". With wireshark, we find that a USB re-enumeration occurred and a clear-feature request was sent to the device (This request should be sent by USB driver automatically and not by PC application).
Currently, we can recover the USB communication after a bulk-in reading failure, but can not ensure no data loss.
Here are some code snippets showing the DMA channels creation and the set/clear-feature request handling:
//create DMA channel for reading sample value from GPIF interface or reading calibration coefficients from EERPOM
dmaCfg.size = 16384;
dmaCfg.count = 8;
dmaCfg.prodSckId = 0x0100;
dmaCfg.consSckId = 0x0301;
dmaCfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmaCfg.notification = 0;
dmaCfg.cb = 0;
dmaCfg.prodHeader = 0;
dmaCfg.prodFooter = 0;
dmaCfg.consHeader = 0;
dmaCfg.prodAvailCount = 0;
apiRetStatus = CyU3PDmaChannelCreate (&glChHandleDataPtoU,CY_U3P_DMA_TYPE_AUTO,&dmaCfg);
if (apiRetStatus != CY_U3P_SUCCESS)
{
AppErrorHandler(apiRetStatus);
}
//create DMA channel for calibration coefficients writing
dmaCfg.size = 8192;
dmaCfg.count = 1;
dmaCfg.prodSckId = 0x0402;
dmaCfg.consSckId = 0x0103;
dmaCfg.dmaMode = CY_U3P_DMA_MODE_BYTE;
dmaCfg.notification = 0;//CY_U3P_DMA_CB_XFER_CPLT | CY_U3P_DMA_CB_PROD_EVENT | CY_U3P_DMA_CB_CONS_EVENT;
dmaCfg.cb = 0;
dmaCfg.prodHeader = 0;
dmaCfg.prodFooter = 0;
dmaCfg.consHeader = 0;
dmaCfg.prodAvailCount = 0;
apiRetStatus = CyU3PDmaChannelCreate (&glChHandleCalibrationDataUtoP,CY_U3P_DMA_TYPE_AUTO,&dmaCfg); //CY_U3P_DMA_TYPE_MANUAL CY_U3P_DMA_TYPE_AUTO
if (apiRetStatus != CY_U3P_SUCCESS)
{
AppErrorHandler(apiRetStatus);
}
////////////////////////////
The following codes shows how to handle the set/clear feature request:
if ((bTarget == CY_U3P_USB_TARGET_ENDPT) && (bRequest == CY_U3P_USB_SC_CLEAR_FEATURE)
&& (wValue == CY_U3P_USBX_FS_EP_HALT)) //wValue: feature selector, 0x01: clear; 0x03: set
{
if (glIsApplnActive)
{
if (wIndex == CY_FX_EP_PRODUCER)
{
/*
* All bulk and interrupt endpoints on the FX3 device can be forced to NAK any host request while the corresponding
function driver is not prepared for data transfers. This function is used to force the specified endpoint to NAK all
requests, or to clear the NAK status and allow data transfers to proceed.
*/
CyU3PUsbSetEpNak (CY_FX_EP_PRODUCER, CyTrue);
CyU3PThreadSleep(100);
CyU3PDmaChannelReset (&glChHandleCalibrationDataUtoP);
CyU3PUsbFlushEp(CY_FX_EP_PRODUCER);
CyU3PUsbResetEp(CY_FX_EP_PRODUCER);
CyU3PUsbSetEpNak (CY_FX_EP_PRODUCER, CyFalse);
}
else if (wIndex == CY_FX_EP_CONSUMER_1) //wIndex specifies the referring end point and direction for requests
{
CyU3PUsbSetEpNak (CY_FX_EP_PRODUCER, CyTrue);
CyU3PThreadSleep(100);
CyU3PDmaChannelReset (&glChHandleDataPtoU);
CyU3PUsbFlushEp(CY_FX_EP_CONSUMER_1);
CyU3PUsbResetEp(CY_FX_EP_CONSUMER_1);
CyU3PUsbSetEpNak(CY_FX_EP_CONSUMER_1, CyFalse);
}
else
{
}
CyU3PUsbStall (wIndex, CyFalse, CyTrue);
isHandled = CyTrue;
}
}
Thanks !
Scott
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Scott,
1. Could you share with us the hardware logic analyzer traces of when you are seeing the issue?
2. How is STALL being done from the firmware?
Best Regards,
AliAsgar