Repeated bulk transfers fail when performed for more than 1..2s. | Cypress Semiconductor
Repeated bulk transfers fail when performed for more than 1..2s.
we encounter bulk transfer problems with the FX3 when performed repeatedly for a long period of time - any help or input on this is very much appreciated.
Background: We are working with the FX3 controller in slafe fifo mode and are trying to stream continuous data (60Mb/s) from the FPGA to our software in multiple bulk transfers [=tf] (we have set up the fx3 ss tf size to 16*1024, and work in 16bit mode). Short transfers (<10000 tf at 10000 tf/sec, where the tf packet size is up to 8kB) work and usually perform well (=>80MB/s). The software works with the CyUSB.Net dll and repeated XferData() on one bulk-in SS endpoint.
We now would like to record data for more than the one second (>10000 transfers) (desired: -> minutes, hours.... -> millions of transfers) but this fails.
Problem: When performing many and repeated bulk transfers for more than one second so we encounter repeated, very short USB/FIFO overflow/full problems (see capture attached). The USB transfer gets paused.
The FX3 signals the FPGA a "USB Full" - normally seen during transfers. While USB Full, the FPGA buffers data in its own fifo (FIFO full) and stops writing (WR) to the FX3 - this usually works well. However, as you can see on the capture, this USB full sometimes (seemingly at random) is set way too long and the FPGA's fifo gets full as well - our data is lost. We've played with all the firmware parameters - nothing helped
Thougts & Questions: Some of the reasons we thought of and the questions that arised:
- First of all, we were thinking of the restricted bus-access time by the host controller/software - how can we improve this and make sure that our device gets the needed time? Is isochronous transfer an option at such high data rates? what about data integrity? Should we use a differend driver (WinUSB, ...)?
- We found, that during the first few transfers - the data can only be held low and can later gradually be increased. Could it be that windows somehow restricts our thread priority in the beginning and after a while allows it more time? (recording and Xferdata is done in a seperate thread from our main application that is instantiated/created for every record). How can we make sure the thread gets its processing time right from the first time? (C#)
- The FX3 has SRAM on it. Could we use this to buffer the USB data? How-to would we do that? (SRAM/Blockram in the FPGA is very limited).
- Any other ideas that you can think of?
Thank you in advance,