EDMA from DDR2 to MCASP

Which DSP? I assume you mean EDMA3 since you have DDR2 support.

Different DSPs have different implementation details, although failure to access DDR2 would not fit into any of the "normal" limitations I can think of. There can be restrictions on EDMA3 Transfer Controllers as to which ports they can access, but DDR2 is usually available to every TC on a device.

Kyle R said:

it will not service the mcasp

Please expand on this statement. What happens and what does not happen? Can you see activity on the DDR2 bus when it should be happening and no activity on McASP? Can you tell what, if anything, has changed in the EDMA PARAM?

We have the EDMA3 to McASP working from the DDR2 on the DM647/648.

james.rasmussen@ambrado.com

 Sorry for the vagueness...We are using the C6424+...I think it might be my initialization of the EDMA3 it seems that when the EDMA is enabled off the McASP event the DMA only transfers my ACNT. My guess is that the event is not signaling back to the DMA controller to continue to send data. I will look into this further. Maybe my GEL script is causing the problem. But I guess my main question would be if we are getting successful DMAs from internal memory changing the source address to external memory shouldn't change anything?

My source address of the PARAM set increments by ACNT then stops.

Thanks for the help,

Kyle

Kyle R said:

my main question would be if we are getting successful DMAs from internal memory changing the source address to external memory shouldn't change anything?

No, this should not change anything. DDR2 could be a bit slower, but it should easily be faster than the McASP. If your system were very heavily loaded and running a ton of EDMA transfers, this could be a system-level concern. But even then it would be very unlikely that you would hit a limit that causes this.

But something is causing your problem.

When your source is L2, then the PARAM SRC field increments by multiples of ACNT until completing, is this correct?

You can get some information by checking the McASP control registers and also the EDMA3 status registers like ER, EMR, SER, IPR to see what condition these are left at.

Will check. I found a strange anomaly and can't quite pinpoint why this happens. When I change the buffer that will service the McASP in DDR2 to a relatively small size say 5k, it seems to work. However only works every once in a while, I have to reset a few times before it will work again and sometimes when it is working it will just stop. This is very weird (hw related?). Anyways when I make the buffer larger 16k or more this transfer will just not occur. Any thoughts while I follow the error flags?

Kyle

Followed the errors flags or lack of. It seems when the McASP stops accepting data the EMDA shuts down. When this occurs I halt the program to look at the global error flags in the registers for the EDMA from the CSL library and the register values are non-existent. If I do this while the mcasp is running and excepting new data the register are all there. We do now think this is a  timing issue with the external memory. We have discover on pg 38 of McASP User Guide Rev. c that certain timing must be considered when servicing the mcasp event. Are we on the right path?

Kyle

Any thoughts?

Kyle R said:

I halt the program to look at the global error flags in the registers for the EDMA from the CSL library and the register values are non-existent.

Which global error flags did you look at? What does "non-existent" mean?

Kyle R said:

certain timing must be considered when servicing the mcasp event. Are we on the right path?

How fast is the McASP bit clock running?

How long of a word are you sending, 16, 24, 32 bits?

Setup a DMA transfer from DDR2 to L2 and measure the time from the write to ESR to the time when IPR is set. Use polling to read IPR and TSCL/H for the time measurement. How long does it take?