No Underrun/Overrun Error : 18

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

cross mob
Anonymous
Not applicable

Hi,

   

I'm interfacing FX3 with a FPGA (32b/100MHz) using slavefifo inteface.

   

I am doing burst write operations and sometimes happen a GPIF Error 18.

   

Data tracker: buffers received: 0, buffers sent: 0.
Data tracker: buffers received: 729, buffers sent: 0.
Data tracker: buffers received: 1539, buffers sent: 0.
Data tracker: buffers received: 2367, buffers sent: 0.
Data tracker: buffers received: 3177, buffers sent: 0.
Data tracker: buffers received: 3987, buffers sent: 0.
Data tracker: buffers received: 4806, buffers sent: 0.
Data tracker: buffers received: 5616, buffers sent: 0.
Data tracker: buffers received: 6426, buffers sent: 0.
Data tracker: buffers received: 7038, buffers sent: 0.
Entering GPIF Error
No Underrun/Overrun Error : 18
Data tracker: buffers received: 7038, buffers sent: 0.
 

   

Board disconnects and reenumerate, but don't reset.

   

In source code this error corresponds to : CYU3P_PIB_ERR_THR0_SCK_INACTIVE = 0x12

   

/**< One of the Thread 0 sockets became inactive during transfer. */

   

Any idea will be good.

   

Thanks

   

Pierre

0 Likes
5 Replies
Anonymous
Not applicable

I trying to do synchronization with FPGA using a packet pattern.

   

Each packet is composed by a header and datas.

   

Header is read to let the FPGA controller know witch next size he has to read. Default size is 3x32b (header size)

   

FPGA pattern has been validated using an external FX2 interface.

   

 

   

Can the FPGA/GPIF interface timings cause that kind of  "inactif thread" troubleshoot?...

   

 

   

Can the problem come from Endpoint sockets?... How can I debug this?

   

 

   

Can the problem come from FX3 clocks settings?

   

I declared :

   

    /* Initialize the device */
    CyU3PSysClockConfig_t clockConfig;
    clockConfig.setSysClk400  = CyTrue;
    clockConfig.cpuClkDiv     = 2;
    clockConfig.dmaClkDiv     = 2;
    clockConfig.mmioClkDiv    = 2;
    clockConfig.useStandbyClk = CyFalse;
    clockConfig.clkSrc        = CY_U3P_SYS_CLK;
    status = CyU3PDeviceInit (&clockConfig);

   

 

   

Any idea please

0 Likes
Anonymous
Not applicable

Actually, FX3 recieve a CY_U3P_USB_EVENT_RESET and CY_U3P_USB_EVENT_SETCONF from Host :

   

CyFxSlFifoApplnUSBEventCB (
    CyU3PUsbEventType_t evtype,
    uint16_t            evdata
    )
{
    CyU3PDebugPrint (4, "USB Event CB = type %d data %d Rx %d Tx %d \n",evtype, evdata, glDMARxCount, glDMATxCount);

    switch (evtype)
    {
        case CY_U3P_USB_EVENT_SETCONF:
            /* Stop the application before re-starting. */
            if (glIsApplnActive)
            {
                CyFxSlFifoApplnStop ();
            }
                CyFxSlFifoApplnStart ();
            break;

        case CY_U3P_USB_EVENT_RESET:
        case CY_U3P_USB_EVENT_DISCONNECT:
            /* Stop the loop back function. */
            if (glIsApplnActive)
            {
                CyFxSlFifoApplnStop ();
            }
            break;

        default:
            break;
    }
}

   

it calls CyFxSlFifoApplnStop () and restarts with CyFxSlFifoApplnStart ()

   

that's why Socket 0 it temporaly inactive and generate a GPIF error 18.

   

 

   

The question now is why fx3 recieves these reset/setconf events?

   

 

   

Software part is doing :

   

 

   

for(int i = 0; i < packets.count(); i++)

   

    {

   

        LONG xfersize = packets[i]->packetSize();

   

        m_endptconfig_out->SetXferSize(xfersize);

   

        if(!m_endptconfig_out->XferData(packets[i]->packet(), xfersize))

   

            qDebug() << "XferData Error" << m_endptconfig_out->LastError;

   

        //msleep(1);

   

    }

   

If I uncomment msleep(1), it works but have very bad performances...

   

 

   

Please Help

0 Likes
Anonymous
Not applicable

Hi Pierre,

   

Check FX3  PHY/ LNK error counters. If there appear errors, SuperSpeed communication is very likely to reset.

   

Using GPIF causes some extra noise and this in turn may cause PHY errors to appear.

   

See http://www.cypress.com/?app=forum&id=167&rID=74739

   

Br,

   

kalev

   


 

0 Likes
Anonymous
Not applicable

Thank you very much for your answer, it gaves us new eye on the problem.

   

 

   

I made the test and it's worst than I expected...

   

Using Notebook has host :

   

> 3.3 V core voltage :

   

1 Phy error each 3 packets

   

Writting works until 100 000 packets

   

Reading works until >1 000 packets

   

> 2.5 V core voltage :

   

1 Phy Error each 20 packets

   

Writting works until 6 000 000 packets

   

Reading works until 100 000 packets

   

> 1.8 V core voltage :

   

EPCS16 doesn't configure the FPGA...

   

 

   

On a desktop using PCIe to USB3.0 board :

   

> 2.5 V core voltage :

   

1 Phy error each 2 packets....

   

Writting works until 50 000 packets

   

Reading works until >500 packets

   

 

   

I have been looking at routing and it might be the cause :

   

We made via on super-speed RX+/RX- routes and we add resitors between FX3 and FPGA that causes GPIF routes looks like a spider and come close to super-speed routes.

   

 

   

It looks like reset in relate to number of retry on a single packet. Like if 2 retry on a single packet generate a reset.

   

Is there a way to configure this?

   

Regards,

   

Pierre

0 Likes
Anonymous
Not applicable

Hi pierre,

1) I know that FX3 does something with its USB3.0 PHY (resets it) if there appear too many (64) LINK errors in time interval (I guess, in 1 second). Should the USB3.0 communication recover from that, I do not know.

If you do have so many PHY errors, maybe you exceed this LINK errors limit as well? BTW, I have found that CyU3PUsbGetErrorCounts function reports LINK errors incorrectly - LINK errors counter gets periodically cleared in timer interrupt. So, potentially this could be FX3 that resets its PHY.

2) Excerpt from "3.2.4.2 Error Handling" in USB 3.0 standard:

"A USB host controller will try a transmission that encounters errors up to three times before informing the client software of the failure. The client software can recover in an implementation-specific way."

I have no idea how this is implemented in host drivers. But anyway, there seems to be now way the users could control this.

Cypress tech support team states that from FX3 point of view everything seems to be correct and this is the host that gives up.

I personally have not found any other solution to this PHY errors issue than reducing the errors rate to zero (perfect hw design, short cables, reduced GPIF throughput, etc.).

Br,
kalev

0 Likes