I have experienced similar issues described here: http://www.cypress.com/?app=forum&id=167&rID=62658
However, I was never able to track it down to the SLWR signal changing at the same time as FLAGB. What USB host controller are you using? Does it still happen if you try another controller (ASmedia instead of NEC or vice versa). I am also desperate to get this issue solved.
Right now I do not have the setup available to read out the GPIF state machine state but should get it back within the next couple of days and then will be able to tell what it reports.
Hi Silvio, Our firmware is coded to respond to a host request to begin streaming by first synchronizing to the video generator. In that "sync phase", all packets received over GPIF are discarded until one with the EOP flag is received. After that point, GPIF packets are committed to USB. The hang is occurring during the sync phase, which I believe rules out USB involvement. Regards, Steve
You are probably right.
To solve your problem I would define a minimum burst size, e.g. 16 words, to get around your issue. It is anyway not good if you end up in the condition that FLAGB indicates alsmost full and you cannot finish the USB packet as you will have difficulties handling the next write cycle (flushing the output pipe and so on...).
It turns out that the error codes are spurious, and can be generated at times other than when we see the slave sync FIFO interface hang.
It also turns out that the 3-cycle latency in FLAGB (DMA watermark) creates a window during which, if the external HW decides to suspend transfer (negate SLWR#), once it decides to resume it will "owe" the FX3 up to 4 beats of data before FLAGA (DMA Ready) pulses and causes FLAGB to reassert.
The attached zipfile contains oscilloscope captures of what we believe to be the various window cases.
Bottom line, it is even trickier to avoid over/underflow with the slave sync FIFO interface than you may have thought.
GPIF_Timing.zip 165.7 K