Re: Persistent stall in the Cypress FX2 FIFO



Hello A.D.

"A.D." <stevenson@xxxxxxxxxxx> scribed:

> Hi Antti,
> thank you for your answer!
> You're right, it doesn't looks like a real stall condition... Moreover in
> my application I use the AUTOIN/AUOTOUT feature, so the CPU does not
> access the data (data are directly committed to the FIFOs), and so the CPU
> doesn't need to handle the IBN and PING interrupt (Am I right?).

You're correct, partly. According to the manual, when the endpoint is
configured for AUTOIN/-OUT, the FX2 CPU is bypassed and data is directly fed
into the FIFOs. However, it might still be possible that the CPU is
triggered with the IBN and PING interrupts. Your best bet, if you can access
the FX2's firmware code, would be to install some sort of stub routines
there that give at least some debug output. This will let you know if the
interrupts are fired even when the AUTOIN/-OUT mode is enabled.

> Today I noticed that the condition that triggers this apparent "stall" is
> sending 2 bulk packets without empting the FIFO first, it doesn't matter
> how long they are (it appends even for 4 byte long packets). If I download
> a packet from the FIFO before sending the next one all works fine... But
> if the EP receive two packets it doesn't take other packets, even if I
> empty the FIFO: I have to reset the FX2!

Since you're using double-buffering, this is exactly what I'd presumed would
happen when you're using the AUTOIN/-OUT feature: the internal firmware of
the FX2 is able to receive two packets (each packet occupies it's OWN buffer
position), and after receiving two packets without being cleared out, the
firmware enters a deadlock-stall state, unable to recover from the
situation, because both reception buffers are full.

This hints that the in-built firmware (whatever version it might even be ?)
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.

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.

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.

As for the reason as to why the firmware deadlocks when the buffers are
"used up", I have no clue. Your best bet would be to e-mail the tech
department of Cypress, with exact instructions on replicating what you've
observed so far, and a query of how the stock firmware's AUTOIN/-OUT feature
really works.
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).

Dunno if this helps. But it's worth a shot :)

- Antti


.



Relevant Pages

  • Re: Persistent stall in the Cypress FX2 FIFO
    ... > This hints that the in-built firmware (whatever version it might even be ... I use the "old" FX2, not the newer low power one. ... > smaller or larger than what a single buffer could hold. ... "Quantum FIFO"! ...
    (comp.arch.embedded)
  • Re: In-tree version of new FireWire drivers available
    ... Just to recap, the dual buffer receive mode, as described in section ... quadlet aligned amount of header data can be appended into one buffer ... *either* the header buffer or the payload buffer fills up. ... enough to hold headers for all the packets it takes to fill up the ...
    (Linux-Kernel)
  • Re: Waveform Audio - MMSYSERR_INVALPARAM
    ... Also, packets/buffers that you waveOutWrite, are packets ... right after the last sample from the previous buffer seamlessly. ... the waveOutWrite function DON'T return the error. ...
    (microsoft.public.pocketpc.developer)
  • Re: iptables dropping legitimate packets?
    ... >Robert Spangler wrote: ... >> only logging these packets but dropping them as well with the last ... even icmp was broken by the 1.50.18 firmware. ... icmp protocol with the cli -I option. ...
    (Fedora)
  • Re: chelsio driver and Myricom driver
    ... firmware will be automatically be updated when you up an interface on ... I just figured that out a few min ago by accident and the card looks happy now! ... Last clearing of "show interface" counters never ... input packets with dribble condition detected ...
    (freebsd-current)