Wrong data in DMA buffers from McASP

Remco Poelstra

Hi,

I'm trying to use the DMA to fill a Ping-Pong buffer from the McASP.

Currently I access the McASP in 32 bit mode and also have 32bit*N buffers.

When I present a sinewave at the analog input I hardly see a sinewave appearing in the buffers. It mostly looks like it misses large parts of the waveform.

I've checked all examples and other post I could find and it seems everything is setup correctly. I'm also not having overruns or missed DMA events. I've attached a screenshot of what ends up in the buffer.

My buffers are defined like:

static int ping_receive[1024]={0};

static int pong_receive[1024]={0};

I've setup the DMA PaRAM sets as follows:

paramSet.opt=0;

paramSet.srcAddr=SOC_MCASP_0_DATA_REGS;

paramSet.aCnt=4;

paramSet.bCnt=1024;

paramSet.destAddr=(unsigned int)ping_receive;

paramSet.srcBIdx=0;

paramSet.destBIdx=4;

paramSet.linkAddr=43<<5;

paramSet.bCntReload=0;

paramSet.srcCIdx=0;

paramSet.destCIdx=0;

paramSet.cCnt=1;

EDMA3SetPaRAM(SOC_EDMA30CC_0_REGS, EDMA3_CHA_MCASP0_RX, &paramSet);

EDMA3SetPaRAM(SOC_EDMA30CC_0_REGS, 42, &paramSet);

paramSet.destAddr=(unsigned int)pong_receive;

paramSet.linkAddr=42<<5;

EDMA3SetPaRAM(SOC_EDMA30CC_0_REGS, 43, &paramSet);

I would not be totally surprised if the lower half of the sinewave is incorrect, as the I2S setup functions seems to pad the value with zero's and I would expect it to pad with bit 15 to get a correct two's complement integer, but then at least the upper half of the sinewave should be correct.

I've no idea how to debug a issue like this. Can someone give some tips on how to figure out what's happening?

Thanks in advance.

Kind regards,

Remco Poelstra

over 12 years ago

0 Remco Poelstra over 12 years ago

Intellectual 985 points

Hi,

I noticed that the output was working quite well using a similar setup, so I used the two transmit buffers as receive buffers in an interleaved fashion. This works fine, so it seems that the receive buffers is filled up correctly.

Leaves the question why this is not apparent if you plot the memory contents.... Is it possible that the buffers get's over written before it's fully read over JTAG? The time to fill a buffer is about 20ms.

Regards,

Remco Poelstra

0 RandyP over 12 years ago in reply to Remco Poelstra

TI__Guru* 84110 points

Remco,

We are glad you have your buffers working well now.

When you click Refresh on the graph window, about how long does it take to show the new contents?

Which DSP and which board and which version of CCS are you using?

Regards,
RandyP

0 Remco Poelstra over 12 years ago in reply to RandyP

Intellectual 985 points

Is there a way to measure it? Otherwise I would say "very fast", way less than a second (only 50 samples are loaded).

But in "less than a second" multiple 20ms might occur. I've no idea where most time is spend to show the data.

I'm using an C6748LCDK without ARM and CCS 5.3.0.00090 with an XDS100V2.

Regards,

Remco Poelstra

0 RandyP over 12 years ago in reply to Remco Poelstra

TI__Guru* 84110 points

Remco,

Try stopping the McASP and see what the buffers look like.

An easy way (I think) to stop it is to write GBLCTL.RFRST = 0 to put the Receive Frame Sync Generator into reset. This might stop the receive events from reaching the EDMA since the receive data might not be being sampled without the frame sync. It all depends on a lot of things about how your system is setup.

If that does not work, clear the XFRST bit also. Or write 0 to the whole register. Or write 0 to CCNT for one of the Link PaRAM sets (leaving one buffer being updated and one buffer not being updated). Or clear the EDMA3 EER bits for the two channels.

Or put some code in your program to copy the entire buffer to another buffer whenever you set a flag, then you would not have to halt anything and you could graph what is in that copy buffer.

My guess is you are looking at a changing buffer, yes.

Regards,
RandyP

0 Remco Poelstra over 12 years ago in reply to RandyP

Intellectual 985 points

Thanks for the tip.With the McASP halted, I indeed see the expected sine wave with the wrong negative half.

Regards,

Remco Poelstra

Processors

Processors forum

Wrong data in DMA buffers from McASP