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 */
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
Actually, FX3 recieve a CY_U3P_USB_EVENT_RESET and CY_U3P_USB_EVENT_SETCONF from Host :
CyU3PDebugPrint (4, "USB Event CB = type %d data %d Rx %d Tx %d \n",evtype, evdata, glDMARxCount, glDMATxCount);
/* Stop the application before re-starting. */
/* Stop the loop back function. */
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();
qDebug() << "XferData Error" << m_endptconfig_out->LastError;
If I uncomment msleep(1), it works but have very bad performances...
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.
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?
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 "188.8.131.52 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.).