Hi

I'm using an Embedded Artists LPC2468 board for development.
Part of my application requires a large amount of data (e.g. 1GB) to
be read from SD card, processed and written to an external hi-speed
USB interface.
I buffer data in external SDRAM.

CCLK is 48MHz.
MCLK is 24MHz.
I use 4-bit mode for the SD Card (i.e. 96MHz bandwidth).
MCI uses GPDMA channel 0 (high priority).
External USB interface uses GPDMA channel 1 (low priority).

I've been doing read - process - write with no problems, with a
20.5Mbit/second throughput.
To improve performance, I decided to use multiple buffers and overlap
the reads and writes.

However, when both DMA channels are used simultaneously, I get
frequent rx fifo overruns on the MCI.
It appears that the low priority GPDMA channels delays / steals too
much time from the high priority channel...
Dropping the MCI clock to 12MHz (i.e. 48MHz bandwidth for SD card)
solves the overruns.
But the throughput is then not significantly better than without the
overlapped I/O.

Is anyone else doing high-speed reads on the MCI and using both DMA
channels at the same time?

Thanks

Alan

Start a New Thread

>> be read from SD card, processed and written to an external hi-speed

I assume you mean FullSpeed USB. LPC2468 does not do HiSpeed.

What are your IRQ assignments? The order in which you assign your IRQs and/or FIQ could make a difference as well.
Do you have activity going through IRQs?

Chris.


Start a New Thread

--- In l..., wrote:
>
> >> be read from SD card, processed and written to an external hi-speed
>
> I assume you mean FullSpeed USB. LPC2468 does not do HiSpeed.
>
> What are your IRQ assignments? The order in which you assign your
IRQs and/or FIQ could make a difference as well.
> Do you have activity going through IRQs?
>
> Chris.
>

Hi Chris

Thanks for replying.

I have a hi-speed USB host interface connected to the external memory
interface.

The following interrupts are occurring:
Timer 0 (priority 0)
UART 0 (priority 10)
GPDMA terminal count, both channels (priority 10)

I do task-switching with CrossWorks Tasking Library.

This is what I do:
1) I setup high-priority GPDMA for MCI, then start the MCI to read the
SD card.

2) I call ctl_events_wait, which will switch to my USB task while the
GPDMA transfers MCI data.

3) The USB task does some processing, then starts a low-priority GPDMA
transfer and calls ctl_events_wait while the transfer completes.

4) The GPDMA ISR calls ctl_events_set_clear, which allows each task to
continue when the corresponding GPDMA channel has completed.

5) The whole sequence repeats, with task-switching occurring at the
start and end of the GPDMA transfers.

I don't think interrupt priority should matter, as this could only
delay the start of the next transfer, which is not critical (as the
MCI is idle again).

The high priority GPDMA channel seems to suffer from reduced
performance if a transfer is already running on one channel when a
transfer is started on the other channel. This results in the MCI rx
fifo overrun.

Everything works OK if:
a) Only one GPDMA channel is used at a time.
or
b) The MCI bandwidth is reduced from 96MHz to 48MHz (4-bit @ 12MHz)

I think I'll have to stick with a single task for now and forget about
overlapping the I/O.

Best regards

Alan

Start a New Thread

If a DMA handler is receiving data, and the CPU is still busy doing something else before it can get back to process the DMA data coming in, or fast enough to keep up, then an overflow condition would likely occur unless the DMA handler has some way of stopping/suspending the incoming data. Since you are using a block of code that you did not write, you have to be very careful you understand what assumptions were made in the code, or that you have done everything required. Using code that one does not completely understand the internal workings of can lead to trouble.

With these kinds of high speed transfers and DMA, you always have the potential for something to go wrong because not all of the event conditions/scenarios were considered. It's easy to get bit my something you never thought about.

Chris.


Start a New Thread