Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
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 100 MHz."
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).