• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 284 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

OMAP-L137: DMA block transfer - data not arriving in destination

Lorraine McLuckie
Prodigy 100 points
Part Number: OMAP-L137

I have an application which currently uses sample by sample interrupts to read in data from the McASP and I am trying to move it to a DMA based solution. 

Since I am not familiar with the DMA on TI devices, I set up a little test to transfer a very small block of data with manually triggered DMA , to help me confirm that I am programming up the DMA correctly, before trying to interface it to peripherals. 

Everything seems to be working exactly as I would expect - with one major exception - I am unable to see the data arrive at the expected destination. 

My setup in the param block

DSP: INFO: DMA_PARAM2_OPT @ 0x01c04040 = 0x81302000<LF>

<LF>

DSP: INFO: DMA_PARAM2_SRC @ 0x01c04044 = 0xc3e5d170<LF>
<LF>
DSP: INFO: DMA_PARAM2_A_B_CNT @ 0x01c04048 = 0x00040004<LF>
<LF>
DSP: INFO: DMA_PARAM2_DST = 0xc3e5d188<LF>
<LF>
DSP: INFO: DMA_PARAM2_SRC_DST_BIDX = 0x00040004<LF>
<LF>
DSP: INFO: DMA_PARAM2_LINK_BCNTRLD = 0x0000ffff<LF>
<LF>
DSP: INFO: DMA_PARAM2_SRC_DST_CIDX = 0x00000000<LF>
<LF>
DSP: INFO: DMA_PARAM2_CCNT = 0x00000001<LF>

 

I (repeatedly) set the appropriate bit in the ESR to manually trigger the transfer and then I monitor the IPR. 

I can see the bit in the IPR being set at the end of each intermediate (and the final)  transfer.

I can see the SRC and DST registers update with the new addresses on each intermediate transfer.

I can see the TCSTAT register in the TC updating the pointer to the FIFO and there are no errors in the TC's ERRSTAT

DMA_TC1_TCSTAT = 0x00000100 and  DMA_TC1_ERRSTAT = 0x00000000

then after the next intermediate transfer

DMA_TC1_TCSTAT = 0x00000900 and  DMA_TC1_ERRSTAT = 0x00000000

(This example shows TC 1, but I have also tried changing DMAQNUM and sending the requests to TC0) 

Basically,everything seems to be operating exactly as I would expect it to. However, when I look at my destination address (both reading it in the code and looking at the memory location with the debugger) the data has not been moved to the new location.

I feel like I've tracked the DMA transfer through the various stages but I am obviously missing something..............

What could be going on? Where to look next? 

Thanks in advance

Lorraine 

  • 0
    TI__Mastermind 27355 points
    Hi Lorraine,

    There are some threads with similar issues that were resolved, can you please take a look and see if they help?

    e2e.ti.com/.../512107
    e2e.ti.com/.../12447
    e2e.ti.com/.../493574

    Additionally, while Starterware is no longer supported, there is a McASP + EDMA example that may be a good reference.

    wiki.tiprocessors.com/.../McASP_FAQ_for_OMAPL13x_C674x_devices

    I hope this helps. Please let us know if you have any questions.
  • 0 in reply to Sahin Okur
    Prodigy 100 points

    Thanks for your speedy response.

    However, the links you sent seem to be related to servicing peripherals with the dma.

    Although that it my end goal, my current set up is a simple block transfer memory to memory, and that isn’t working. - while it seems to be reporting  that it has compeleted successfully.  

    Any suggestions on what could be causing that simple memory to memory transfer to fail would be appreciated.

    Lorraine

  • 0 in reply to Lorraine McLuckie
    Prodigy 100 points

    Update : When the destination of my DMA block transfer is set to the shared RAM @ 0x80000000 it seems to work OK and I can see the data arrive at the destination.

    When the destination address is hardcoded to an unused external address ( eg 0xc5000100), I can see the data arriving at its destination. 

    However, when the destination is within the space that my code is currently using (e.g. 0xc3000100) I can no longer see the data at the destination. 

    I'm wondering if there is some cache coherency issues or permissions issues involved here that I need to consider??  I am now convinced that the DMA is programmed correctly. 

    Lorraine 

  • 0 in reply to Lorraine McLuckie
    Prodigy 100 points

    As I started to suspect, this turned out to be a cache coherency issue, so I thought I'd close the thread in the hope that it might help someone else in the future. 

    From SPRUG82a

    In the following cases, it is your responsibility to maintain cache coherence:
    · DMA or other external entity writes data or code to external memory that is then read by the CPU
    · CPU writes data to external memory that is then read by DMA or another external entity
    · DMA writes code to L2 SRAM that is then executed by the CPU (this case is supported by the
    hardware protocol on C621x/C671x and C64x DSPs, but is not supported on C674x DSPs)
    · CPU writes code to L2 SRAM or external memory that is then executed by the CPU

    I verified this was the issue by executing 

    BCACHE_wbInvAll();

    BCACHE_wait();

    before transferring the data to external memory using the DMA. Then, the subsequent CPU read back returns the updated values.