TI E2E Community (Beta)
Welcome to the TI E2E (Engineer-to-Engineer) Community! We invite you to freely and openly interact with your peer Engineers, TI Engineers, and other experts in order to ask questions, share knowledge, explore ideas, and help solve problems.
More Search Options

Questions about DM648's McASP and EDMA3 transfers...

rated by 0 users
Not Answered This post has 0 verified answers | 6 Replies | 3 Followers

Top 500 Contributor
34 Posts
Community Member
JRasmussen posted on 6 Jul 2009 4:53 PM

Hello,

I have a few questions about the setup and McASP and EDMA3 transfers on the DM648.

1.  The EDMA3 manual I'm reading shows only examples of 1 Receive McASP Serializer and 1 Transmit Serializer.  While this makes it easy to write the example, it isn't very helpful to me.  Our setup is that we're using 8 McASP serializers (Channels 0 thru 7) for I2S output only, and No Serializers for Audio Input.  The output buffer to be transferred to the McASP Serializaers is an interlaced 8 channel array such that { Uint32 Chan0 data, Uint32 Chan1 data, ..., Uint32 Chan 7 data }, and repeated for each Timeslot.

After fighting the McASP and EDMA3 transferring, and checking the examples (NOTE- the PSP I have only has a one channel McASP receive example that I can't use), I have been trying to get the EDMA to do a 1D to 1D move to the entire Serializer Register range, such that Uint32 Chan0 data ->Ch0 Serializer Transmit Buffer, Uint32 Chan1 data ->Ch1 Serializer Transmit Buffer, etc..  Unfortunately I'm only getting partial success.

My questions:  Must I use an EDMA3 Parameter Set and have each Parm set Transfer one data sample to each fixed Serializer Transmit Buffer address?  Or is it permissible for me to have one channel write the 8 audio data words to each Serializer channel within one EDMA3 parmset?  The latter case is what I've been trying to do, but I'm not having much success with that.  Also, the manual examples keep showing an A-element count of 1.  Should that not be an A-element count of 4 for 4 bytes = 1 32-bit word that is needed to write to the Serializer Transmit Buffers?

Please don't refer me to the PSP, I have looked and found it less than useful.  We don't use and have no plans to use the DM648 PSP in our project.

Thanks,

 

--James Rasmussen

All Replies

Top 10 Contributor
368 Posts
Texas Instruments Employee

If I understand what you want to do with the McASP and EDMA, then you are very close to having it working already. Just a few comments and you can let me know if I am on the right page or not.

You have configured the McASP to generate an EDMA event (AXEVT) when the XDATA bit is set, which will occur on each timeslot. You have a buffer of data that has 8 32-bit words ready to go out on the next timeslot AXEVT EDMA event. The 8 words are consecutive in memory, one word for each of the 8 serializers you have configured as active+transmit..

Rather than work through what is wrong with the examples in the manual or in the PSP or even getting your code to work, here are some comments on what needs to happen:

  1. You will only need one or two DMA channels for these transfers. You will either use the single channel associated with the AXEVT event or the two channels associated with AXEVTE and AXEVTO, depending on how you have it configured. For now, I will assume that you will use AXEVT and will get an event for every timeslot.
  2. There will be one PARAM Set assigned to the AXEVT DMA channel. This PARAM Set will contain the active transfer parameters, generally the values to be used on the next AXEVT event.
  3. Depending on your actual data buffering scheme, you may use one more PARAM Set as a Link set to reload the same values once the first PARAM Set has gone through all of its programmed transfers. Or you might use two more PARAM Sets as Link sets to implement a double-buffered scheme to allow the CPU to be generating data for one buffer while the EDMA is transferring from the other buffer.
  4. When the AXEVT triggers the DMA channel, you will want to transfer a total of 8 consecutive words to the McASP. This can be done by configuring the DMA channel for ASYNC operation and setting ACNT= 8*4=32 to transfer all the data in one dimension. This can also be done by configuring the DMA channel for ABSYNC and setting ACNT=4 and BCNT=8 with BIDX=4 to get the right spacing between the source locations.
  5. The destination for the DMA transfer should be the Data Port (section 2.8.1.2 page 43 of spruel1a) and not the individual Serializer Transmit Buffer addresses on the CFG bus (section 2.8.1.3 page 43 of spruel1a). The Data Port is a 1KB port window where all addresses are mirrored to the same funnel into the XRBUF. Writing 8 words sequentially to 0x02044000-0x0204401C does the same as writing 8 words repeatedly to 0x02044000. This makes it easier for configuring the destination indexing for the DMA channel.
  6. You do have to make sure the XBUSEL bits are cleared correctly to 0 for the transmit serializers you will be using. And there could be some other setup details that an example in the PSP might list off for you.

Please look over these comments and see how they fit with what you are doing now and let us know the next step we need to take. Other members of the community may jump in with comments, too.

Top 500 Contributor
34 Posts
Community Member

Thanks much for the Reply, Randy P.   Your comments are right on target for what I am trying to do.

I was able to finally get the EDMA channel working with the McASP, with thanks from your comments.  Also, I found the DSP/BIOS McASP device Driver Architecture/Design Document in the DM648 DVSDK_1.11.00.00 under the pspdrivers_1_10_00 directory which also explained that the PSP was doing what I am trying to do.

Your Item #5 was of major help.  I did not see this information anywhere in the Data Manuals for the DM648 McASP or the TMS320DM647/tms320DM648 Data Sheet.  I am indeed using the Data Port area (0x02044000 - 0x0204401c) and was suspecting that I was only placing position dependent audio samples rather than writing to individual Serializer Transmit Buffers.

You might be interested in what I found in regards to your Item #4.  The DM648 McASP User Manual shows examples that set ACNT to 0x1, and I did figure out that it was supposed to be set to 0x4.  However, the EDMA still did not work properly with ACNT set to 4 and BCNT set to 8 (giving the 8 word, 32byte count) as you would have expected.  I also saw notes in the DSP/BIOS McASP device Driver Architecture/Design Documents (pg. 3 has one of these notes) stating "The McASP supports only 32 bit transfers to the serializer buffers.  Due to this limitation, the EDMA channel element size must necessarily be 32 bits."  I took this to mean that ACNT must be 32, and the EDMA to McASP is now working.  I tested the EDMA to McASP transfers setting A and B cnts to a combination that would give a 32 byte transfer, but the EDMA transfer only works on our system if ACNT is 32, and no other value.  Have you seen similiar?

 

Thanks again,

 

--James Rasmussen
Top 10 Contributor
368 Posts
Texas Instruments Employee

Very good to hear that you have your system working. The EDMA gives a huge benefit for any system by relieving the CPU of data movement responsibilities.

The "32 bits" requirement should be equivalent to ACNT=4, not 32. And in most cases with contiguous accesses, the Transfer Controller will combine accesses into consecutive 1D reads or writes even if they are broken into 2D sets, that is, if BIDX=ACNT.

Can you post your PARAM settings for the case that is working and for one of the cases that you expected to be working? Your results are not what I would have expected with only one configuration working correctly for the 8 word transfer.

Not Ranked
5 Posts
Community Member

The MCASP will generate an event to the EDMA3 for each slot in a frame. When the EDMA3 services this signal, it must satisfy the slot data requirements for all of the serializers. Since your data words is 32-bit and you have 8 serializers, ACNT=32 would be the correct setting for your implementation as long as you are using A-Synchronization. In this case, BCNT would obviously be bufsize/32. As far as I can tell, tell, using ACNT=4, BCNT=8 and CCNT=bufsize/32 (with BRELOAD=8) should also work as long as you switched to AB-Synchronization. There would be no reason to go to AB-Sync, though, unless you had a strange addressing requirement to deal with. But, you say you have a simple interleaved buffer. Interestingly, you also state that you are trying to address the individual serialization data registers. You shoud be able to simply use the single data port which will demux the data to the serializers automatically.

I am wondering if anyone in this forum has ever attempted to use EDMA3 to service simple I2S transmit (i.e., 2-slot TDM with word-width FS and a 1-clock delay) with a 16-bit word size. From what I can gather, you cannot use EDMA3 to access the data port as a 16-bit word. The only way I can find to do this is to use 32-bit port access and pad the EDMA buffer so that it is 2x its normal size. So, you'd be pulling consecutive 32-bit words from the buffer and only sending 16-bits per 32-bit word read. You can always get rid of the buffer padding by making BINDEX 2 instead of 4, but then you end up reading every odd 32-bit word from an address that is not 32-bit aligned which is inefficient. Any ideas?

 

 

 

Top 10 Contributor
368 Posts
Texas Instruments Employee

You will have the best chance getting a good answer if you post your 2nd paragraph to a new Post with a matching title and some details like which DSP (I'll assume DM648, but I am not always right at those). I would like to know for sure before digging too deep.

If you do, please reply here and include a link to the new posting so I can follow it. An admin could split it for you, but then the new thread loses some good properties.

Page 1 of 1 (7 items) |

ALL CONTENT AND MATERIALS ON THIS SITE ARE PROVIDED "AS IS". TI AND ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THESE MATERIALS FOR ANY PURPOSE AND DISCLAIM ALL WARRANTIES AND CONDITIONS WITH REGARD TO THESE MATERIALS, INCLUDING BUT NOT LIMITED TO, ALL IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT OF ANY THIRD PARTY INTELLECTUAL PROPERTY RIGHT. NO LICENSE, EITHER EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, IS GRANTED BY TI. USE OF THE INFORMATION ON THIS SITE MAY REQUIRE A LICENSE FROM A THIRD PARTY, OR A LICENSE FROM TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI and its suppliers reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.