After updating to SDK 1.1.1 my FX3 application stopped working. Now I figured out that this was because I set the "burst" parameter in CyU3PGpifSocketConfigure() to 0. The description for this parameter is rather interesting:
"Logarithm (to the base 2) of the burst size for this socket.
The burst size is the minimum number of words of data that will
be sourced/sinked across the GPIF interface without further
updates of the GPIF DMA flags. The device connected to FX3 is
expected to complete a burst that it has started regardless of any
flag changes in between. Please note that this has to be set to
a non-zero value (burst size is greater than one), when the GPIF
is being configured with a 32-bit data bus and functioning at
As I am running the interface a 100 MHz and 32 Bit, this is affecting me. But does it also apply if I run the interfaceat at 95 MHz? Up to now I had the upstream data transfer stalling from time to time with certain USB host controllers. Can this be the reason? And if I understand correctly, I now need to adjust the FPGA logic, so that it ignores the flags during a burst packet? Does it mean that during a burst read or write the flags may become invalid?
If this parameter has to be non-zero, it means that the smallest burst size will be 2^1 = 2?.
It think Cypress should provide more detailled information on this as I did not find any mention of this in the slave fifo application note.
I think this is no problem. You can set the burst size to 1 which means every 2 words the flags are updatetd. And in my opinion the best solution is to slow down the write access if partial full is active and monitor the full flag in this mode. This is now described in the slave fifo application note (I think upon my suggestion here in the forum).
what makes me suspicious is the sentence that says the host needs to ignore flag changes in between:
"The device connected to FX3 is expected to complete a burst that it has started regardless of any flag changes in between"
Doesn't this imply that the flags can become invalid in between? And why would somebody want to define a burst size of more than 2?
Hmm...good question. Maybe the burst is also aborted on packet end....but I´m not sure. As I use 75MHz PCLK only, it works with burst = 0.