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.

Data was not completely moved to destination when using EDMA3 LLD

Hello, there:

To try EDMA3 LLD 2D to 2D copy, I prepare a buffer > 64Kbyte filled with 0x80.

The result below shows some data was not correctly moved.

 

Do you have any idea how/why this happens?

The problem also occurs when using DAT_fill(), and DAT_copy() to

do the same task.

My platform info: TMS320DM8148 (Vision-Mid) 

600-MHz ARM® Cortex™-A8 RISC MPU

500-MHz C674x™ VLIW DSP

200-MHz M3-ISS/M3-HDVPSS 

Your quick response is highly appreciated.   

Joey Lin

  • This looks like cache coherency issue, assuming the input buffer resides in external memory.

    1. make sure that 'after' you initialize the input buffer before issuing a DMA transfer you do a Cache write-back of the input buffer.

    2. make sure that the input buffer start and end addresses are cache-line size aligned (128-byte boundaries).

    Cache coherency issues can arise due to the way EDMA transfers work. EDMA will transfer the data directly from the physical memory, so if you have dirty cache lines due to CPU writes the transfered data will not be coherent with respect to the contents of your local processor cache. Note that this will happen if you initialize memory or do dynamic memory allocation which initialize allocated memory.

    Finally, you are not reporting an issue with this, but on the 'reader' side similarly you need to Cache invalidate any external memory buffer that have been written to using EDMA transfers. If you don't do this and there are resident cache lines in your local processor cache due to an earlier CPU access, then CPU will read 'stale' data from the cache line instead of the newly DMA'ed in data sitting in external memory.

    Hope this helps,

    Murat

  • Hi, Murat:

    Indeed. It is the cache coherency issue.

    The problem has been fixed. 

    Thank you so much for your support and quick response!

    Joey Lin