[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

R: ETRAX 100 EXT DMA



We are experiencing full ETRAX 100 resets during EXT_DMA transfers on our
prototype, custom, board.

Initially we used short transfers, but the software kept crashing after 3-50
burst of 1500 bytes. Working to delimit the cause, we ended with a driver
producing systematic resets during maximum lenght DMA transfers, when no
software seems to be the primary cause of the reset.

Note, that

- the very same driver/board works without resets when transferring data
from the device via Programmed I/O triggered by external IRQs

- our prototype board is "wirewrapped", and we add electical noise among the
usual suspects.

Had anyone such problems with EXT DMA in prototype hardware ?

[ Our first email is at the bottom, here follows our reply to the first
answer by Mr. Starvik]

Thanks in advance for any help !

    Stefano & Sergio


-----Messaggio originale-----
Da: Mikael Starvik <mikael.starvik@xxxxxxx.com>
A: 'Stefano Vicenzetto' <tesi01@xxxxxxx.com>
Data: mercoledý 12 settembre 2001 17.04
Oggetto: RE: ETRAX 100 EXT DMA



>ETRAX will generate an interrupt when the transfer counter
>reaches zero so why do you need to connect the dreq signal
>at all?

DMA transfers begin as soon as DREQ is asserted: without
connecting DREQ, DMA wouldn't start at all.

>>says that an IRQ is issued whenever
>>the run bit in EXT_DMA0_CMD is cleared [p. 7-22], and this seems that
could
>>happen not only when thr trf_count expires, but also when dreq is
deasserted
>>[p.7-22].


>I think a deasserted dreq will cause the run bit to be cleared and
therefore
>generate an interrupt. Otherwise it would be hard for software to detect
>that a transfer has ended prematurely.

This is what we understood reading the DMA chapter of the manual, too.

However the observed behaviour on our ETRAX hw is that a deasserted DREQ
_suspends_ the DMA transfers, doesn't stop them: in fact, DMA continues as
soon as DREQ is re-asserted.

A deasserted DREQ does NOT clear the run bit, that stays 1 until the
trf_count reaches 0; only then the "end of transfer" IRQ is generated, not
before.

>Now, we are wondering if the resets could be caused by our device
>deasserting dreq too early, or if someone else experienced glitches
>when using repeated DMA burst reads to fill short buffers (400 words).

>We have never seen an ETRAX restart due to hardware problems. Incorrect
>software may of course cause a restart.


We have been able to reproduce systematically full software resets happening
during long DMA transfers, while the cpu is doing a empty (busy) loop.
Actually, we programmed a long (64KB) dma input and then we monitored
(printed) the DMA_STATUS and other BUFFER/HWSW registers.

We observed that while the buffer is filled by the DMA state machine, the
system resets without apparent cause; here is the pseudo-code:

SETUP_DMA (CH5, 64KB, READ)
RESET CH5
START_EXT_DMA

while ( DMA_EXT_STAT.run != stop)
{ 
    // we get resets in this loop...
    // ...also commenting out the printks !!
    printk DMA registers
}

STOP_EXT_DMA
RESET_CH5

----------------------------

Regards
/Mikael

-----Original Message-----
From: Stefano Vicenzetto [mailto:tesi01@xxxxxxx.com]
Sent: Friday, September 07, 2001 7:10 PM
To: Mikael Starvik; Bj÷rn WesÚn
Subject: ETRAX 100 EXT DMA 


Sirs,

We want to transfer a fixed size block of data from an external device FIFO
to main memory. For this we use the EXT_DMA_0 channel, activating the transfer
counter and burst mode as in sample code AXIS sent us, and following the
procedures indicated in the manual.

One issue is that our device deasserts DREQ as soon as the FIFO of the
device starts to be emptied by the ETRAX DMA (before the transfer counter reaches zero),
essentally acting as a "FIFO FULL" signal. typical init values for the counter are in the range of 300-400 32-bit words.

The documentation of EXTRA 100 LX (yes, we use the 100 model, but the ETRAX
100 DMA chapter is light on "how to" issues...), says that an IRQ is issued
whenever the run b
it in EXT_DMA0_CMD is cleared [p. 7-22], and this seems that could
happen not only when thr trf_count expires, but also when dreq is deasserted
[p. 7-22].

For our test, watching EXT_DMA_0_STAT register with busy reading loops, we
see that the transfer counter decreases, and the IRQ is issued only when it
reaches 0; unfortunately, after a series of 3...50 such short DMA transfers
the
whole ETRAX resets itself.

Now, we are wondering if the resets could be caused by our device
deasserting dreq too early, or if someone else experienced glitches when
using repeated
DMA burst reads to fill short buffers (400 words).

Thanks in advance and Best Regards,

Stefano and Sergio