EZ-USB FX3 firmware very slow
We are using the Cypress example code SlaveFifoSync. The demonstration host application GUI USB Control center works fine with our FPGA design for single transactions.
We have developed a host side application in C++ that exercises the API XferData() method function for reads and writes (each from the appropriate handle).
We have also connected to the Cypress card over a serial link in order to observe output of the CyU3PDebugPrint that the firmware source code is instrumented with.
What we initially observe on the firmware console debug are messages that appear at 1 second intervals that confirm that the firmware is in good working order.
When we run our host application which comprises a sequence of calls to XferData() for reads and writes (to CSRs in our FPGA design) is that a varying number of these complete successfully and then there is an apparent hang where some access never completes. On the debug console, the messages emitted at 1 second intervals have stopped.
We have further instrumented the firmware source code with CyU3PDebugPrint and isolated a function that never seems to return:
status = CyU3PDmaChannelCommitBuffer(chHandle, input->buffer_p.count,
0);
We have also attached a logic analyzer on the slave bus between the Cypress card and the FPGA and observed that expected transactions are not appearing at the interface when we expect Cypress to drive the bus.
We have found that introducing a delay (Sleep()) of 100 milliseconds into the host application after each call to the Cypress API XferData is sufficient to cause all the host generated accesses to proceed normally. We have observed that a delay of 10 milliseconds is insufficient.
That we need to pace the host application to workaround an apparent firmware issue is unacceptable. Our application requirements for full speed application cannot tolerate even a delay of 10 milliseconds. What we want is a stable, production ready code that implements the functionality of SlaveFifoSync at full speed.
We assume that customers using this chip in production must be using a fullspeed version of this firmware - please let us know if we can have access to this or if the expectation is for us to somehow develop our own.
