We are streaming video via a GPIF sync_slave_fifo_2bit interface, with FLAGA defined as Thread 0 DMA Ready and FLAGB defined as Thread 0 DMA Watermark. The watermark is set to 2 with no bursting, resulting in FLAGB leading FLAGA by 4 clocks.

We have noticed that whenever the FX3 negates FLAGB on the same clock edge as the video generator negates SLWR# for a line blanking interval, the FX3 never reasserts FLAGB again. This is true even after we send an additional beat of data to correct for the difference between the 3-cycle FLAGA latency and the 4-cycle FLAGB configuration.

In probing the FX3 registers while in this FLAGA asserted / FLAGB negated state we see the following:

"Socket has gone inactive within a DMA Transfer" (CY_U3P_PIB_PIB_ERR_CODE_TH0_SCK_ACTIVE)

 "statemachine has transitioned to an invalid state" (CY_U3P_PIB_GPIF_ERR_CODE_INVALID_STATE_ERROR)

...and the GPIF state machine in IDLE state.

Has anyone experienced similar issues, or know what conditions trigger these error codes?

Hi

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.

-Silvio

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.