This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How to set an uinterrupted dma transfer?

I am using C6455 DSP.

Currently I am setting up two DMA channels:

- Rx (Channel 55 on Queue 0). It gets triggered when GPI 7 gets asserted (EVT55) which happens every 11.5us. Per transaction DMA reads 1x28 bytes

- Tx (Channel 53 on Queue 1). DSP code initiates the transaction every 625us. In a single transaction DMA writes 54x8 bytes.

How do I set the DMA so that once the write transaction begins, it can not be interrupted by the other DMA transaction?

I saw on LA that sometimes DMA read transaction happened in the middle of the DMA write transaction, and it delayed the completion of DMA write transaction. 

I thought Channel 53 DMA has higher priority than Channel 55 DMA, therefore I am expecting DMA hardware to finish writing the whole 54x8 byte before reading 1x28 byte if the read transaction occurs in the middle of write transaction.

  • Jimmy,
    To do what you want, you need to have both transfers go to the same queue.

    Whats happening is this; each queue maps one-to-one to a transfer controller (TC). By default, queue0 maps to TC0, queue1 maps to TC1, etc. You can change this mapping using the QUETCMAP register but that's usually not needed.

    It's the TCs that do the heavy lifting of moving data by performing a series of reads and writes out on the bus. Each TC is independent from one another meaning TC0 can be issuing reads and writes while at the same time TC1 can be issuing reads and writes.

    So let's assume ch55 has already triggered and its corresponding TC0 is in the middle of transferring its data. Then ch53 gets triggered, in this case, its corresponding TC (TC1) will start transferring data simultaneously with TC0. Both TCs operate independently. If TC0 and TC1 both try to read/write to the same location, it's possible for them to interleave their transactions on a burst size boundary.

    So now onto priority, the channel priority only comes into play as a tie-breaker when two or more channels trigger at the same time. The priority logic determines which one gets pushed onto it's corresponding queue first. That's all there is to it, it just determines who gets queued first. After that, it's up the the transfer controller to actually move the data.

    If you assign both channels to the same queue, then one will get queued then the next, then they will both go to the same TC and will be serviced in FIFO order. One transfer won't start until the previous one completes.

    -Brad
  • Jimmy,
    I need to amend my previous answer. It turns out the reads of the second transfer can begin before the writes of the last transfer complete. This because we have a write FIFO in each TC. So by putting both transfers on the same queue/TC does not guarantee the first will complete before the second begins.