Large EDMA3 transfer is interfering with audio EDMA transfers

Howy,

What is the data rate of your audio data?

How much audio data do you transfer per audio DMA event? How many audio DMA events and channels do you use?

How often do you expect to get audio interrupts?

Sort of combining all of those questions: what is the time period between audio events at which the DMA response is required to be able to meet real-time requirements?

What would your ideal DMA operation be to go to the LCD?

Your function name is QDMAxfer, but it is using ESR to trigger. Is QDMA the old way you used to do it?

How small do you have to make the LCD transfers to avoid any stalls in your audio?

To the question on selecting TC0 or TC1, please see the EDMA3 User's Guide Section 4.2.1.4 on the DMAQNUMn registers. You make this setting on a channel-by-channel basis. There is also a QDMAQNUM register for the QDMA channels.

howy said:

I am having a second problem with not being able to write to the LCD module's single address data register in non-increment mode.  I read that the EMIF will not support this mode when used as a destination since it is not a fifo. Is there any way around this so I can use DMA to transfer to the same EMIFA address repeatedly?  I am currently getting around this by isolating the EIMFA address bus from my LCD module temporarily with a PLD. This will become a bigger issue when I apply this transfer strategy to my CF card interface however which also uses a single 16bit data register for sector data transfers.

You are correct that you cannot use the CONST mode for SAM and DAM. Just use BIDX=0 and ACNT=2 and ABSYNC and BCNT=#words to xfer. The EDMA3 UG explains this most technically, but one of the online training videos may help you understand how this works.

In the Training section of TI.com, there is a training video set for the C6474. Although it is a different device, the EDMA3/QDMA/IDMA Module may help you understand some of the features and options available within the EDMA3 module. You can find the complete video set here.

The EMIF transfers are generally more efficient if you use incrementing addresses. If you can map the pins to your EMIF devices so they do not use the bottom 8 EMIF address bits, for example, then you can send data to 256 half-words using one command with incrementing addresses and your device will not know the difference between that and sending the data to a single address. Just a thought and recommendation, but not a requirement.

Regards,
RandyP

My audio sample rate is currently 48khz but will be 192khz.  I have about 20 McAsp serializers for 40 channels of audio into and out of the box.

My audio interrupt occurs every 32 samples so my interrupt rate is 1500Hz at 48k and 6000 Hz at 192K. My Audio DMA is set to 2 words per transfer.

At an interrupt rate of 1500 Hz my program fails when I transfer more than about 1400 words to the LCD in one shot.

The LCD transfer does not have a strict deadline so my intention was to give it the lowest priority possible which is what the QDMA seems to do nicely on the 6713.  I was expecting to transfer 16 to 64 words at a time to the LCD. If I set up an LCD chained EDMA transfer of 32 words at a time would that allow my audio DMA to sneak in between the delay in the chaining process?

If I use the PRU to large transfers will I have the same problem?

-howy

>>>Your function name is QDMAxfer, but it is using ESR to trigger. Is QDMA the old way you used to do it?

I was under the impression that using PARAMSET 0-7 dictated that I was using QDMA. How should I trigger QDMA and what difference in behavior should I expect to see when using QDMA properly?

-howy

Howy,

How much audio data do you transfer per audio DMA event? How many audio DMA events and channels do you use?

What is the time period between audio events at which the DMA response is required to be able to meet real-time requirements?

You have multiple McASPs, and there are a total of 6 DMA events that could be used if you also need to do any transmitting of audio data. Or you could do all the transfers off a single event under the assumption they are synchronous. Also, there are FIFOs that can be used to reduce the number of times the DMA channel responds to an event while increasing the amount of data the DMA event will transfer each time. That information may be useful for figuring out where your problem is.

Which memory do the audio transfers move data to/from, L2, DDR, EMIFA SDRAM, Shared memory?

Which memory do the LCD transfers move data from, L2, DDR, EMIFA SDRAM, Shared memory?

If there is not a bottleneck or conflict at the memory device, then moving the LCD transfers to TC1 should get rid of your problems.

Please let us know the result of moving to TC1 (Q1), or send the extra answers and questions if that does not solve it for you.

Regards,
RandyP

Howy,

Howy said:

I was under the impression that using PARAMSET 0-7 dictated that I was using QDMA. How should I trigger QDMA and what difference in behavior should I expect to see when using QDMA properly?

That is not a common way to allocate the PARAM, from my experience, but that depends on how you have configured the channels. The training video I referenced discusses this, but the software you use to do the configuration makes the final choice.

If you were trying to use QDMA, then you were doing it wrong. You do not use ESR for QDMA. Either the videos or the EDMA3 UG will help you understand it better.

Regards,
RandyP

It only took me 30 minutes to get the PRU fired up and it does exactly what I want now, so I will just leave the EDMA3 programming to the younger guys who still have a few brain cell s left.

thanks,

-howy