Using McASP in Burst Mode

In my initial post I assumed that I could use a CPU initiated DMA transfer from IRAM to the McASP DMA port (e.g. 0x54000000).  I figured I could initialize the McASP and take the clock, frame sync, and state machine out of reset, then at a later time, setup and trigger a DMA transfer to the McAPS DMA port.  I would use a CPU initiated DMA transfer by toggling a DETR bit. 

But I see that the documentation and CSL example show the opposite, where the DMA transfer is configured first and then triggered by the McASP state machine coming out of reset.  This makes sense for TDM mode, which the example is showing, but seems less convenient for Burst Transfers. 

I would like to use a CPU initiated DMA transfer with the McASP DMA port as the destination address to shift words of data out the serializer.  Is this possible?

Thanks!

I think there were some discussions about this in the past few weeks on the forum. They may have been for a McBSP instead of McASP, but the issues are the same.

Basically, you have two end cases:

1. When you take the McASP transmitter out of reset, it will immediately request data. This is why the DMA channel is usually setup ahead of time.

2. When you send the last word for the McASP to transmit, it will again request a new word by asserting XRDY. This can cause problems with the DMA channel.

Please try the greatly improved red Search Community box in the upper-right corner and look for "burst mode" and either McBSP or McASP. There should be some good reading in there, and there may be some sample code, if you are lucky.

Regards,
RandyP

Hi RandyP,

Thanks for the response.  I searched the forums for "Mc" and "DMA" and found several posts which were somewhat related to my question.  I also downloaded the C6747 PSP drivers and browsed the McASP/DMA source code examples.  Unfortunately I have not found all the answers I am looking for yet.

RandyP said:

1. When you take the McASP transmitter out of reset, it will immediately request data. This is why the DMA channel is usually setup ahead of time.

I do expect this, but I would like to ignore this McASP request event, and initiate the DMA asynchronously from the CPU.  In Burst Mode the frame sync is data driven and begins when all the XBUFs have been updated with new data.  This is different from TDM Mode, where the frame sync is synchronous and the DSP must adhere to the setup time for writing the next slot of data.  Is there a problem with ignoring a McASP request event in Burst Mode?

Thanks! Colin

Colin,

The thread C6747: MCASP can't receive data with EDMA3 has some good discussion of the issues with getting McASP burst mode working with EDMA3. Even though Lian's problem was solved differently in that thread, the information is there for what should help you. And another is McASP configuration. You may have already found both of these.

If you want ti figure out if the PSP drivers will work for you, then you will be best off going to the BIOS forum. I noticed a thread that discussed PSP drivers (I think) with burst mode, and I know I read that it used a SWI to turn off the Mc*SP activity when a burst had completed. Even though I do not have the link to that one, you might have run across it in your searches, too. It may have been McBSP, but it definitely had SWI and burst in the thread.

If you want to get your own drivers working, I recommend getting it working with CPU reads/writes first and save the EDMA3 implementation until you have the sequencing figured out. Then you can map it back to a DMA channel to automate it more.

I have not tested the following, so I use words like could and should.

The start conditions could be as easy as setting and clearing the EDMA3.EER bit for the McASP's DMA channel. When you take the McASP out of reset and it generates an event, that event will sit waiting in the ER register as long as it is not enabled in EER. When you are ready to transmit and have everything ready in your PARAM, then you can write to EESR to enable that event and the DMA should start running just the way you want.

Now for the end conditions. When the last intended word has been sent, you can generate an interrupt from the DMA channel and let that ISR write to EECR to disable the next McASP AXEVT. As long as there is plenty of time and the EECR gets written before the next AXEVT, this should work well. A safety plan could be to have a LINK PARAM with a dummy transfer (one or two but not all three xCNT values = 0) to respond to a quick AXEVT; the drawback is that now there is not a pending ER bit set.

Another option would be to chain to another DMA channel that is setup to write the value to the EECR for you directly. This would not be guaranteed to work, just because there can be long delays sometimes in servicing the prior AXEVTs so that there could be two in a row very quickly.

This is all just ideas and not solutions, but hopefully you have some ideas how to proceed.

Regards,
RandyP

Thanks RandyP,

The information you was provided was very helpful.  I have some ideas on how to solve my problem now.  I do have another question.  I am trying to find where the XINT and RINT interrupts from the McASP peripheral are connected on the C6727.  I have checked the McASP, dMAX and C6727 Datasheet without luck.  I would like to use these CPU interrupts to test the McASP without DMA.

Thanks! Colin

Colin,

I am not sure that there is a direct way to route these signals to CPU interrupts. The McASPs are expected to be serviced by dMAX for system efficiency, and I do not see anything listed in Table 2-3 CPU Interrupt Assignments.

You may be able to test the McASP without DMA by polling these status bits. That would not be efficient for real operation, but to make sure you have the ports configured correctly, it may be the best choice.

Regards,
RandyP