Re: Persistent stall in the Cypress FX2 FIFO
- From: "A.D." <stevenson@xxxxxxxxxxx>
- Date: Wed, 23 Nov 2005 09:42:26 +0100
"Antti Keskinen" <antti.keskinen@xxxxxxxxx> ha scritto nel messaggio
news:dlvrhi$249l$1@xxxxxxxxxxxxxxxxx
> Hello A.D.
>
> This hints that the in-built firmware (whatever version it might even be
> ?)
I use the "old" FX2, not the newer low power one.
Yes, I konw, the part that I'm using is discouraged by Cypress... :-)
> is quite incompetent in it's design: it assumes each packet it receives
> completely fills the first-, second-, third- or fourth-order buffer,
> respectively. It cannot handle situations when packets it receives are
> smaller or larger than what a single buffer could hold.
Yes, it is exactly what happens. I noticed that the manual call this feature
"Quantum FIFO"! ...Actually it is a waste of bandwidth!
But I suspect that there is also some kind of "silicon bug": apart from the
persistent deadlock that is triggered by the reception of N-1 packet
(when an N-buffered FIFO is used), I get corrupted data from the
FIFO if I send more than one packet.
Maybe the newer versions behaves differently...
> Your only solution, without rewriting the firmware for FX2, would be to
> use the triple-buffering feature, and order your FPGA to instantly react
> for FIFO interrupts. In english, the FPGA must react fast when data
> arrives into the FIFO, so that it is immediately extracted to whatever
> temporary storage you can muster up. This allows the FIFO buffer to
> receive more data from the USB host. Using a triple-buffer allows you some
> leeway as to how fast the data is extracted from the buffer.
I found a quick&dirty workaround: I wrote a little routine in the FX2
firmware that stalls the endpoint when the FIFO is not empty, and clears
the stall when it get empty. In this way the host have just to try to send a
packet until it succeeds...
> The other option, obviously, is to hand-write the FX2 firmware to be able
> to cope with smaller-than-buffer or larger-than-buffer packets, so that
> they get crammed into the same buffer slot or distributed over multiple
> buffers.
Inserting the CPU in the datapath will dramnatically reduce the througput.
For this reason I have not considered this approach.
> As for the reason as to why the firmware deadlocks when the buffers are
> "used up", I have no clue.
Maybe it is a "feature", or maybe it is a bug... I don't know...
> Also, in the firmware example, the OUT endpoints are armed with dummy
> bytes at start-up, with equal dummy writes as there are buffering levels
> (See page 9-32 in the TRM). I presume you've done this ? The endpoints
> must be "armed" for the AUTOIN/-OUT feature to work (don't ask me why,
> though).
Yes, the firmware do this.
> Dunno if this helps. But it's worth a shot :)
I really appreciated your help!
Regards,
A.D.
.
- References:
- Persistent stall in the Cypress FX2 FIFO
- From: A.D.
- Re: Persistent stall in the Cypress FX2 FIFO
- From: Antti Keskinen
- Re: Persistent stall in the Cypress FX2 FIFO
- From: A.D.
- Re: Persistent stall in the Cypress FX2 FIFO
- From: Antti Keskinen
- Persistent stall in the Cypress FX2 FIFO
- Prev by Date: Re: Which LCD is this?
- Next by Date: Digi or Lantronix
- Previous by thread: Re: Persistent stall in the Cypress FX2 FIFO
- Next by thread: PIC PSP port bus contention
- Index(es):
Relevant Pages
|
