DSPRelated.com
Forums

Problem with EDMA and McBSP on C6713

Started by kari...@utu.fi August 7, 2007
Hello,

I am using McBSP configured as a SPI slave to transfer data from C6713 to a computer with EDMA feeding 128 element frames into McBSP and EDMA transfer complete interrupts invoking new frame transfers. The problem is that during almost every frame the transfer stalls at some point resulting the rest of the received frame to be zeroes. The transfer recovers when the next frame boundary normally.

I have tested the data transfer code with a program that simply sends consecutive numbers and it worked ok. The configurations should then be right and the problem is caused by the DSP and user interface code somehow interfering with the data transfer.

The platform I use is D.SignT D.Module.C6713 with a D.Module.ADDA16 analog IO daughter board that is memory-mapped into the C6713's memory space. I also use some digital IO lines on the DSP board's CPLD that is also mapped into the DSP memory. All code and data is in DSP's internal memory. Could the external memory accesses stall the EDMA transfer?

I have come up with couple of things I think the problem is not about (tell me if I'm wrong):

1. The EDMA receives McBSP's transmit events because the transfer is completed when the frame would otherwise normally end and the next frame transfer is invoked by the EDMA complete interrupt.

2. If the problem should be transmit underflow the McBSP would keep sending the previous word written into DXR and not zeroes. (SPRU580C page 55).
Kari Roth
Hi Kari,

you can send your program code to s...@dsignt.de to investigate the
problem.

If I understand the problem correctly, the EDMA always completes and calls
the EDMA complete service interrupt, but the tail of your buffer contains
only zeroes. If this is true, the EDMA must have processed all RXEVNTs
without data loss.

You may also check the McBSP receiver for overruns (RFULL bit set in SPCR):
if no overruns occurs, the EDMA transfers have completed in time.

Please make sure the EDMA source pointer is set to fixed address mode, and
is not accidently modified during program runtime.
Best Regards,
Adolf Klemenz, D.SignT
At 10:49 07.08.2007 -0400, k...@utu.fi wrote:

>Hello,
>
>I am using McBSP configured as a SPI slave to transfer data from C6713 to
>a computer with EDMA feeding 128 element frames into McBSP and EDMA
>transfer complete interrupts invoking new frame transfers. The problem is
>that during almost every frame the transfer stalls at some point resulting
>the rest of the received frame to be zeroes. The transfer recovers when
>the next frame boundary normally.
>
>I have tested the data transfer code with a program that simply sends
>consecutive numbers and it worked ok. The configurations should then be
>right and the problem is caused by the DSP and user interface code somehow
>interfering with the data transfer.
>
>The platform I use is D.SignT D.Module.C6713 with a D.Module.ADDA16 analog
>IO daughter board that is memory-mapped into the C6713's memory space. I
>also use some digital IO lines on the DSP board's CPLD that is also mapped
>into the DSP memory. All code and data is in DSP's internal memory. Could
>the external memory accesses stall the EDMA transfer?
>
>I have come up with couple of things I think the problem is not about
>(tell me if I'm wrong):
>
>1. The EDMA receives McBSP's transmit events because the transfer is
>completed when the frame would otherwise normally end and the next frame
>transfer is invoked by the EDMA complete interrupt.
>
>2. If the problem should be transmit underflow the McBSP would keep
>sending the previous word written into DXR and not zeroes. (SPRU580C page 55).
>
>Kari Roth
>
Hello again,

It seems that the problem is with the external memory accesses. I tried removing all the processing and having only one interrupt routine triggered by analog input interrupt. When the interrupt routine did nothing but create a new data word and add a new frame for SPI transfer when necessary the transfer worked just fine. However, when I added a line that read the ADC data the problem appeared.

Unless I can somehow find a solution I have to try using interrupts to transfer data to McBSP and just hope that it wont load the DSP too much.

Kari Roth

Hello,
>
>I am using McBSP configured as a SPI slave to transfer data from C6713 to a computer with EDMA feeding 128 element frames into McBSP and EDMA transfer complete interrupts invoking new frame transfers. The problem is that during almost every frame the transfer stalls at some point resulting the rest of the received frame to be zeroes. The transfer recovers when the next frame boundary normally.
>
>I have tested the data transfer code with a program that simply sends consecutive numbers and it worked ok. The configurations should then be right and the problem is caused by the DSP and user interface code somehow interfering with the data transfer.
>
>The platform I use is D.SignT D.Module.C6713 with a D.Module.ADDA16 analog IO daughter board that is memory-mapped into the C6713's memory space. I also use some digital IO lines on the DSP board's CPLD that is also mapped into the DSP memory. All code and data is in DSP's internal memory. Could the external memory accesses stall the EDMA transfer?
>
>I have come up with couple of things I think the problem is not about (tell me if I'm wrong):
>
>1. The EDMA receives McBSP's transmit events because the transfer is completed when the frame would otherwise normally end and the next frame transfer is invoked by the EDMA complete interrupt.
>
>2. If the problem should be transmit underflow the McBSP would keep sending the previous word written into DXR and not zeroes. (SPRU580C page 55).
>Kari Roth