2D AB-Syncronized EDMA Transfer

malden2507

Other Parts Discussed in Thread: OMAPL138

Hello,
could you please help me solve the issue regarding the configuration of EDMA for McASP peripheral on C6747 DSP (OMAP L137).

The application is a typical (standard) one:
Interfacing stereo ADC and DAC are of higher (24-bit) resolution, thus 32-bit slot of McASP is used.

I'd like to adapt the existing (and working) 3D setup to perform as 2D setup (found such in one OMAP L137 TI-example).
How adapted? By changing the A-dimension to process both L & R samples.

Two drawings are attached to illustrate both concepts, an existing, and an alternative one (latter not workin properly).
Please review them for discussion of indexes.

Existing 3D setup (RX part discussed):
A-dimension processes one channel sample (L i.e. R), B-dimension both channels (L & R), C-dimension processing the block (eight audiosamples).

SOURCE (McASP Port 0 with 2 serializers with consecutive addresses):
BIDX = 0        Peripheral (port), thus unchangable
CIDX = 0        Peripheral (port), thus unchangable

DESTINATION (Memory):
BIDX: Distance between neighbouring elements of the same frame    [bytes]
CIDX: Distance between last element in one frame and the 1st element in the next frame [bytes]
ping_c_index = (rcv_ping_R – rcv_ping_L) + sample_size             [bytes]
pong_c_index = (rcv_pong_R – rcv_pong_L) + sample_size             [bytes]

Both SOURCE and DESTINATION:
ACNT = 4      Array (1st dym.): Four bytes (=32-bit audiosample)
BCNT = 2      Frame (2nd dym.): STEREO (1.AUDIO_L 2.AUDIO_R)
CCNT = 8      Block (3rd dym.): AUDIO_BLOCK_SIZE

This setup works (see attached oscillogram).

Alternative 2D setup (RX part discussed) not working properly:
A-dimension processes both channel samples (L & R), B-dimension the block (eight audiosamples).

SOURCE (McASP Port 0 with 2 serializers with consecutive addresses):
BIDX = 0       Peripheral (port), thus unchangable
CIDX = 0       Peripheral (port), thus unchangable

DESTINATION (Memory):
BIDX: Distance between neighbouring elements of the same frame    [bytes]
CIDX: Distance between last element in one frame and the 1st element in the next frame    [bytes]
ping_c_index = pong_c_index = 0   (there’s no another frame in the block)

Both SOURCE and DESTINATION:
ACNT = 2*4 Array (1st dym.): 2 x 4 bytes (L&R 32-bit audiosamples)
BCNT = 8       Frame (2nd dym.): AUDIO_BLOCK_SIZE CCNT = 1     Block (3rd dym.): 1

New setup does not work (see attached oscillogram; 500 Hz signal is distorted, although main harmonic recognizable).

Question:

Do you see anything wrong in the alternative setup from above?

Can it be that I need to setup McASP in a different way in order to be able to setup EDMA this way?

Thanks!

Mladen

APPENDIX 1 (only A-synchronized version works properly):

APPENDIX 2 (neither A- nor AB-synchronized version works properly):

over 9 years ago

0 Sivaraj Kuppuraj over 9 years ago

TI__Mastermind 35645 points

Hi,

Thanks for your post.

I think, only EDMA PaRAM Set configuration parameters ACNT, BCNT, CNT, BIDX, CIDX would differ for 2D and 3D AB-Sync mode of transfer and nothing else. I don't think, McASP configuration needs to be changed for 2D/3D AB sync mode of DMA transfer.

I do think, your EDMA PaRAM Set configuration for 2D and 3D AB Sync transfer seems to be fine. In your case, both 2D and 3D AB sync, the total size of the transfer in bytes would remain same which is 64 bytes. In 3D AB-Sync transfer, the total size of transfer is ACNT*BCNT*CCNT = 4*2*8 ~=64 bytes and likewise, in 2D AB-Sync case too, the total size is 8*8*1 = 64 bytes but ACNT*BCNT bytes of transfer per DMA event would differ in both 2D and 3D AB-Sync mode transfer, which for 3D case, it should be ACNT*BCNT = 4*2 ~= 8 bytes/DMA event, likewise, for 2D case it is 8*8 = 64 bytes/DMA event. I mean, your EDMA PaRAM Set configuration per DMA event seems to be fine.

Only one suggestion, If AB-sync was chosen, ‘CIDX' is calculated from the first byte in the first frame to the first byte of the second frame. So, kindly make sure to validate SRCCIDX and DSTCIDX byte offset address when you change from 3D AB-Sync to 2D AB-Sync mode of transfer according to the note below:

NOTE:

SRCCIDX for AB-synchronized transfers:The byte address offset from the beginning of the first source array in a frame to the beginning of the first source array in the next frame.

DSTCIDX for AB-synchronized transfers: The byte address offset should be from the beginning of the first destination array in a frame to the beginning of the first destination array in the next frame.

Also, kindly note that, for AB-synchronized transfers, the EDMA3CC submits the BCNT in the TR and the EDMA3TC decrements BCNT appropriately. For AB-synchronized transfers, BCNTRLD is not used. Kindly ensure BCNTRLD is not used in your 2D AB-Sync case.

Please refer the below E2E post and find attached the "7573.OMAPL137_McASP_EDMA_StarterWare.zip” for a working McASP-EDMA audio loopback sample code available for OMAPL137 platform which is ported from OMAPl138 shall be used to validate EDMA PaRAM set configuration for 2D mode of DMA transfer.

https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/423721/1512249#1512249

Kindly look for the sample .CCS project path below to look for OMAPL137 McASP EDMA audio loopback example after extracting the above attached zip file:

~\OMAPL137_McASP_EDMA_StarterWare\build\c674x\cgt_ccs\omapl137\evmOMAPL137\mcasp\.ccsproject

Thanks & regards,

Sivaraj K

---------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

---------------------------------------------------------------------------------

0 malden2507 over 9 years ago in reply to Sivaraj Kuppuraj

Intellectual 450 points

Hello,

thanks for comment regarding the dimension of synchronization.
Regarding the total size: yes I intentionally left the total size of transferred bytes unchanged (64 bytes),
by wanting to change only the kind of EDMA3.

Question 1:
What are precisely the differences between A- and AB- type of synchronization?

What exactly needs to be done in order to modify A-synchronized type of transfer to AB-synchronized one?

In OPT register, set bit SYNCDYM
Re-define "c_index"
(it's new meaning for AB: offset from one frame's 1st array to the same of the following frame)
When programming reloads, omit configuring the BCNTRLD and put there 0-value? Right?
...what else?

As seen from my drawing (see comment on c-index), I must realize to have used a A-synchronized transfers!
Indeed. Our code is based on one TI-example we found in Web (since it uses a low-level CSL approach with minimal overhead):
http://software-dl.ti.com/dsps/dsps_public_sw/c6000/web/c6747_audio_edma_app/latest/index_FDS.html

In this example, EDMA3 OPT-Register field SYNCDYM (1/AB-synchron. 0/A-synchrizatiom) has never been initialized in an explicite way!
So we didn't initialize it, either.

Now it comes: in the OMAPL137 McASP EDMA audio loopback example you've passed me (files edma3.c omapl137_mcaspPlayBk.c) the mentioned SYNCDYM field has neither been initialized to 1 (for AB-synchronization type). Hmmm. How can that be? BCNTRLD was used in that code for configuring the reload for sure.
Please notify: the default-value after reset for SYNCDYM/OPT is 0 (= A-synchronized).

Question 2:
This here seems to be the first E2E-post to the topic of kind of synchronization (A or AB-type).
Are there any running McASP examples where AB-type of synchronization is used?

Question 3:
BCNTRLD may NOT be used (when configuring reload) or is not necessary to use?
In other words, is it necessary to set 0 for its value (when configuring the reload transfer)?

Question 4:
Neither of my examples (3D, 2D) works properly if I use AB-synchronization.
I've updated the drawings to now contain both types of synchronization.

I updated the oscillogram of 500 Hz. As you may see, 8 samples (166 us) are good, 8 corrupted, 8 good again etc.

Thanks.
Mladen

0 malden2507 over 9 years ago in reply to malden2507

Intellectual 450 points

Hello,
in order to further investigate why two 2D and 3D EDMA3 setups (2D AB-synchronized, 3D-AB-synchronized) do not work properly,
I decided to change the strategy.

Instead of RX, to use TX part of an audio application (ie. Memory-to-McASP EDMA transfer).
RX and TX EDMA3 setup are completely symmetric, so why not?

Here's the advantage that I see when using this method:

Thus I can use intentionally created own test-pattern (test-vectors in RAM as EDMA SRC) in order to measure (using an oscilloscope) precisely what comes out it is. what EDMA3 does.
Here EDMA3 DEST is a McASP XMT port!

Here detailed description of two issues regarding th EDMA3 setup for I2S audio (XTM part).

Thanks,
Mladen

0 Sivaraj Kuppuraj over 9 years ago in reply to malden2507

TI__Mastermind 35645 points

Hi,

Thanks for your update.

To address Question 1, basically the difference between A-Sync and AB-Sync transfers is as follows:

If you are syncing to a peripheral, you almost always use Async because most peripherals can only handle one data item at a time (like a serial port). So, you have a choice to transfer ACNT bytes (A-sync) or ACNT * BCNT bytes (AB-sync) which depends on your requirement.

Usually, peripherals require A-sync transfers because they are limited in size (e.g. the serial port cannot provide 16 32-bit data values at one time – it is normally one 16-bit value). AB-sync is used in various ways, but primarily for blocks of data with one single event that transfers the entire block.

You can see that A-sync moves ACNT bytes per event and using AB-sync, the entire ACNT * BCNT is moved per event. This would be the primary difference between A-Sync and AB-Sync.

To address Question 2,

There are no existing examples for McASP-EDMA with AB-type of synchronization but you have to customize the code attached in the above post which is "7573.OMAPL137_McASP_EDMA_StarterWare.zip"

To address Question 3,

Normally one would configure BCNTRLD to be identical to BCNT. As the transfers are occurring (using A-synchronized transfers) the BCNT field gets decremented after each transfer of ACNT bytes (i.e. each sync event). Once BCNT=0 it gets reloaded with the value in BCNTRLD. So let's say you want to transfer 200,002 bytes, i.e. 100,001 elements of 16 bits each. We might use the following parameters:

•ACNT=2 (16-bit data)

•BCNT = 1

•BCNTRLD = 25000

•CCNT = 5

So in the above scenario the first data transfer would move 1 element and BCNT would decrement to 0. This would cause CCNT to be decremented and BCNT reloaded with BCNTRLD. Now we will do 4 more "frames" of 25000 elements for a total of 100,001 elements total.

The above way of using different values for BCNT and BCNTRLD to do transfers of any size is only applicable to A-sync transfers. It cannot work with AB-sync because BCNT never decrements and hence BCNT is never loaded with BCNTRLD. In other words, BCNTRLD should be a "dont care" for AB-sync transfers.

To address Question 4,

There is no existing 2D, 3D examples available for AB-Sync mode of DMA transfer. So, it needs to be customized according to your desired requirement.

In my guess, there could be two reasons since your 3D,2D examples doesn't work with AB-synchronization:

1. The indexing would be wrong is one reason. May be, DSTCIDX would set differently depending on whether you are doing an A-synchronized or AB-synchronized transfer- kindly validate on the same.

2. The other reason is that the BCNTRLD field will never be utilized because BCNT isn't decremented in the Parameter RAM during AB-sync transfers since you have OPT.SYNCDIM=ABSYNC

Hope it addresses all your questions.

Thanks & regards,

Sivaraj K

---------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

---------------------------------------------------------------------------------

0 malden2507 over 9 years ago in reply to Sivaraj Kuppuraj

Intellectual 450 points

Hello Sivaraj,

thanks for detailed explanation.

In order to move further I additionally slightly changed the strategy today helping me to somewhat move forward (although not to an extend I'd expect and need).

I was wondering how to verify only the indexing part of my EDMA3 setup.

It can easily be done using manually issued transfers; in other words, via ESR/Event Set Register and MEM-to-MEM transfer.
This method is very suitable for comfortable debugging.

This method helped find me one bug preventing me from getting quite good results. In my initialization routine ACNT
wasn't written appropriately into PaRAM set.

After fixing a bug, verification of indexing via MEM-to-MEM issued manually (as described above) has shown both of the scenarios (described on drawings above) work properly. Contents SRC and DST are the same, and events occur exactly when they should:
array-wise/A-Synchronized and frame-wise/AB-Synchronized transfers, including the TCC interrupt on block-boundary.

Having this smaller' bug resolved, I applied the same EDMA indexing scheme onto my native situation:
Interfacing stereo ADC and DAC are of higher (24-bit) resolution, thus 32-bit slot of McASP is used and I2S mode.
Simplified, McASP TX transfer (DEST = McASP).

Unfortunately, my problem (described using drawings from above) here - still exists!
Only left I2S samples get transferred, but - each 2nd one (as before). Right samples are trash.

I generally see two problems:

Using AB-transfers seems to be unsuitable for interfacing peripherals.
In EDMA3 manual following is stated:
Nonbursting peripherals (explained on McBSP example)
"Nonbursting peripherals include the on-chip multichannel buffered serial port (McBSP) and many external
devices, such as codecs. Regardless of the peripheral, the DMA channel configuration is the same.
To transfer the incoming data stream to its proper location in L2 memory, the DMA channel must be set
up for a 1D-to-1D transfer with A-synchronization. Since an event (REVT) is generated for every word as it
arrives, it is necessary to have the EDMA3 issue the transfer request for each element individually."

An exception to this rule there seems to be the AFIFO functionality of McASP, which is actually the real motivation for this E2E post of mine, you know.
Using FIFO audio samples are buffered, so EDMA gets at one event more than one sample.
2D transfers of dimension A containing L & R sample seem not to be suitable for managing I2S interface.

Strange, quite strange:

The "7573.OMAPL137_McASP_EDMA_StarterWare.zip" (available for OMAPL137 platform)
https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/423721/1512249#1512249

you've referred to some before, uses exactly that kind of synchronization: 2D mode of DMA transfer.
You know, I took an idea for my A-Synchronized 2D transfer exactly from there.
In this starter-code you can see the following:

#define BYTES_PER_SAMPLE                      ((WORD_SIZE << 1) * NUM_I2S_CHANNELS)        // WNUMEVT = 0x 10 (16 words)

static struct EDMA3CCPaRAMEntry const txDefaultPar =
       {
           (unsigned int)(EDMA3CC_OPT_DAM | (0x02 << 8u)), /* Opt field */
           . . .
           (unsigned short)(BYTES_PER_SAMPLE), /* aCnt <<<<<<<<<<< */

How can that be? How can it work in an OMAPL137 starter code.
Unfortunately I cannot verify this setup (I don't have the evaluation board).

Since my setups work for manually issued MEM-to-MEM setups, it must be interfacing the specific peripheral that causes an issue.

Unpatiently awaiting for your response,

regards

Mladen

0 Sivaraj Kuppuraj over 9 years ago in reply to malden2507

TI__Mastermind 35645 points

Hi,

Thanks for your update.

We do agree that, there are limitation in AB-Sync transfer in syncing to a peripheral interface and probably, this could be the cause of an issue.

The OMAPL137 Starterware code which we shared above is based out of event triggered DMA transfers and it is tested on OMAPL137 EVM, which would work perfectly fine with the defined EDMA PaRAM configuration in the code.

In order to verify the indexing part of EDMA3 and you know well that, DSTCIDX would be set differently depending on whether you are doing an A-synchronized or AB-synchronized transfer. In this case we're doing A-synchronized. The terms for the various dimensions are arrays, frames, and blocks. Each frame will be composed of n arrays. The DSTCIDX for A-synchronized transfers is the distance from the last array in frame "n-1" to the first array in frame "n". So if the data is contiguous it would simply be ACNT which is simply the array size in this case.

To know more on McASP AFIFO functionality, kindly refer section 26.2.4.4 from the TRM below:

http://www.ti.com/lit/ug/spruh92b/spruh92b.pdf

Thanks & regards,

Sivaraj K

---------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

---------------------------------------------------------------------------------

0 malden2507 over 9 years ago in reply to Sivaraj Kuppuraj

Intellectual 450 points

Hello Sivaraj,

here my replies to your points.

In my approach I did take into account a specific way of definition of c-index in A/AB-synchronisation case.
And: all indexing works well in case of manually triggered transfer. Only not in conjunction with McASP.
For some reason the OMAPL137 starter code and there implemented 2D setup doesn't work in my environment.
The only difference I see is that L137 eval. board uses 16-bit audio, ours 24-bit (therefore we use 32-bit slotsize).

As far as AFIFO feature of McASP is concerned,:
to simplify the whole communication, let me compress my questions into the following one:

I'd actually need to know what kind of DMA - structure is needed in order to make use of McASP (A)FIFO feature.

AB-synchronization is a must for AFIFO support?
It's stated in some E2E posts.
Which DMA-dimension needs to be implemented?
Your OMAPL137 starter uses 2D but doesn't make use of McASP FIFO feature.
Is there anything else that needs to be considered in EDMA or McASP (+AFIFO) setup for I2S?
Do you know of any working example of AFIFO-featured McASp (EDMA3 supported)?

My application is processing I2S audio.

Here some comments on examples you've passed me:

OMAPL137 startware (audio loopback) contains two subfolders with slightly different EDMA-for-McASP setup:
..\OMAPL137_McASP_EDMA_StarterWare\build\c674x\cgt_ccs\omapl137\evmOMAPL137\mcasp\omapl137_mcaspPlayBk.c
and
..\OMAPL137_McASP_EDMA_StarterWare\examples\evmOMAPL137\mcasp\omapl137_mcaspPlayBk.c
The only difference (besides codec-setup) is this:

    /* Enable the transmitter/receiver slots. I2S uses 2 slots */
    McASPRxTimeSlotSet(SOC_MCASP_1_CTRL_REGS, 3);
    McASPTxTimeSlotSet(SOC_MCASP_1_CTRL_REGS, 0xFFFEFFFF);

DMA-setup is the same.
Unfortunately, none of these projects makes use of McASP FIFO feature (FIFOs RX & TX are configured of size 1).

Thanks!
Mladen

0 Sivaraj Kuppuraj over 9 years ago in reply to malden2507

TI__Mastermind 35645 points

Hi,

Thanks for your update.

To address your questions, kindly see the response below:

#1: It is not mandatory that AB-Sync mode of transfer needs AFIFO support, instead you could use A-Sync mode which would do good.

#2: The OMAPL137 starterware code which was shared user McASP AFIFO feature through the below mentioned API's and you could also disable the AFIFO through commenting out the below two lines of code:

/* Enable the FIFOs for DMA transfer */

McASPReadFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, 16);

McASPWriteFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, 16);

Also, you could place breakpoints at appropriate places to see the AFIFO register values in the register window as well, you could also look at the below addresses to explore in memory browser through CCS debug console for the desired AFIFO registers

#define SOC_MCASP_1_CTRL_REGS (0x01D04000)

#define SOC_MCASP_1_FIFO_REGS (0x01D05000)

#define SOC_MCASP_1_DATA_REGS (0x01D06000)

#3: Other than the omapl137 starterware code shared, nothing else is needed as a benchmark configuration for EDMA and McASP+AFIFO setup for I2S mode. May be, you could traverse the code in debug mode and see how the McASP AFIFO is enabled in the code which configures the AFIFO registers and how EDMA uses AFIFO feature to execute 2D DMA transfer. Kindly capture the register dump of McASP AFIFO registers and explore in the memory browser.

#4: Only the omapl137 starterware example which was shared in this post was the working example of EDMA + McASP with AFIFO

It is a standalone project which you can run "as-is" on OMAPL137 EVM and it is not required to download starterware separately.

Today, I have tested the above example on OMAPL137 with a typical scenario using AFIFO enabled on McASP and use the DMA to service the McASP through the DMA port and the audio loopback demo works fine.

WNUMEVT = 0x01

WNUMDMA = 0x01

Please find attached the WFIFOCTL, WFIFOSTS, RFIFOCTL, RFIFOSTS register dump with my testing environment

Also, I have adjusted ACNT values to 32, 64, 128, 256 (BYTES_PER_SAMPLE) accordingly in the above example code to obtain WNUMEVT values to 8, 16, 32, 64 write word count per DMA event to send/receive more data and have tested with following scenario:

1. With 1 Tx/Rx Serializer, WNUMEVT = 0x08 (8 Words), FIFO Enabled, Test Passed - Kindly refer the attached reg. dump

2. With 1 Tx/Rx Serializer, WNUMEVT = 0x10 (16 Words), FIFO Enabled, Test Passed - Kindly refer the attached reg. dump

3. With 1 Tx/Rx Serializer, WNUMEVT = 0x20 (32 Words), FIFO Enabled, Test Passed - Kindly refer the attached reg. dump

4. With 1 Tx/Rx Serializer, WNUMEVT = 0x40 (64 Words), FIFO Enabled, Test Passed - Kindly refer the attached reg. dump

The above test results witnesses the examples uses McASP AFIFO feature and executed DMA transfer.

There were only ACNT and WNUMEVT changes to be modified in the source code to send/receive more data

For example, in order to make set it for WNUMEVT = 0x10 (16 Words) are below:

#define BYTES_PER_SAMPLE ((WORD_SIZE << 1) * NUM_I2S_CHANNELS) // WNUMEVT = 0x 10 (16 words)

The below two lines would be modified inside the function static void McASPI2SConfigure(void):

/* Enable the FIFOs for DMA transfer */

McASPReadFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, 16);

McASPWriteFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, 16);

Likewise, you could modulate the above snippet to obtain WNUMEVT values to 8, 16, 32, 64 write word count per DMA event.

Thanks for your understanding.

Regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

-------------------------------------------------------------------------------------------------------

0 malden2507 over 9 years ago in reply to Sivaraj Kuppuraj

Intellectual 450 points

Hello Sivaraj,

many thanks for your detailed explanation and test done!

Let me pass following questions (one of which was slightly missunderstood, to some I have new findings):

(#1) I'd like to know NOT if AB-Sync mode of transfer needs AFIFO support but contrary:
for McASP AFIFO support AB-synchronisation is obligatory?
Please tell me if I'm wrong.
In order to add AFIFO support into an existing EDMA3 & McASP driven audio application, one has to:

A. Modify 1st dimension (A_CNT) to make it diviable by NUMEVT,
or leave it as such if this condition already met.

B. Add AFIFO configuration in given AFIFO depth (NUMEVT), most important part of which is:
McASPReadFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, RNUMEVT );
McASPWriteFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, WNUMEVT );

C. Anything else?
I have just discovered something very important regarding my inability to find appropriate EDMA setup of McAP for EDMA.
To remind you, our application transmits stereo 32-bit audio via I2S.

I've already reported that the only EDMA3 setup in my environment that works is the following one:
3D EDMA (A-synchr.): 4 x 2 x 8 (A_CNT=4 bytes, B_CNT=2 for stereo I2S, C_CNT=block length of 8)

Now I've just discovered that it works in variety of setups which all have one common: 1st dimension (A) fix (=4)!

We use 3D TX transfer (DST=McASP) transmits audio from memory-buffer that is supposed to have the following structure (L&R interleaved):
L (4 bytes), R (4 bytes), L (4 bytes), R (4 bytes), ...

Why do setups don't work not having A_CNT equaling 4 (but instead 8, 16 etc.)?
There must be something missing in the McASP initialization.

// OK (3D):
    Uint16 A_CNT = sample_size;   // 1st (A-) dimension: array OK-setups (A_CNT x B_CNT x C_CNT): 4x8x2, 4x2x8, 4x16x1, 4x1x16
    Uint16 B_CNT = 2;                        // 2nd (B-) dimension: frame
    Uint16 C_CNT = 8;                        // 3rd (C-) dimension: block
    Uint32 b_indx = A_CNT;
    Int16 c_indx = A_CNT;                   // Due to one frame only (B arrays build a frame)

Why do setups not work as long as A-dimension gets changed to not-equal 4? NOK: 8 x 2 x 8, 8 x 16 x 1, 8 x 8 x 2 etc.
McASP is configured for I2S (2 slots of 32-bit audio).

Thanks and regards,

Mladen

0 malden2507 over 9 years ago in reply to malden2507

Intellectual 450 points

Hello Sivaraj,
let me append a following useful information:

If in an existing code a AFIFO functionality remoal is considered, you don't have to remove all relevant AFIFO-initialization code itself, but rather slightly re-configure it.

All you have to do is set RNUMEVT and WNUMEVT to 1:

McASPReadFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, RNUMEVT );
McASPWriteFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, WNUMEVT );

In this case there's actually no buffering (FIFO-depth is 1).

Regards,
Mladen

0 Sivaraj Kuppuraj over 9 years ago in reply to malden2507

TI__Mastermind 35645 points

Hi,

Thanks for your update.

To address your questions, kindly see the responses below:

#1: Yes, there are limitation in using McASP with AFIFO for AB-Sync mode of transfer.

#2: You are correct, nothing else needs to be added other than specified in A and B

A: If your ACNT= 64 bytes per samples (WNUMEVT = 16 words/serializer), keep the condition as such which is already met. In case, if you would like to modify the ACNT = 4 bytes per sample (WNUMEVT = 1 word/serializer) then you should modify the below snippet as follows:

#define BYTES_PER_SAMPLE ((WORD_SIZE >> 3) * NUM_I2S_CHANNELS) // WNUMEVT = 1 (1 word per Serializer)

and accordingly modify the minimum word per serializer (minWdPerSer argument) which are WNUMEVT/RNUMEVT = 1 Word as below:

/* Enable the FIFOs for DMA transfer */

McASPReadFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, 1);

McASPWriteFifoEnable(SOC_MCASP_1_FIFO_REGS, 1, 1);

It all depends on your requirement which needs to configured as desired. Also, other than ACNT = 8, 16 bytes (2 words, 4 words etc), the setup should also work for ACNT = 4 bytes (1 Word) which I have tested already and there is no conflict in McASP initialization part other than modifying the #define BYTES_PER_SAMPLE macro as below:

#define BYTES_PER_SAMPLE ((WORD_SIZE >> 3) * NUM_I2S_CHANNELS)

Setups will work for all ACNT dimension = 4, 8, 16, 32, 64, 128, 256 bytes (1, 2, 4, 8, 16, 32, 64 words per serializer) and I have tested for all these scenario and I do not see any issues when ACNT changed to other than 4 bytes and it worked for 8, 16, 32, 64, 128, 256 bytes and the audio loopback executed successfully on omapl137.

C: Nothing else.

Thanks for your understanding.

Regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

-------------------------------------------------------------------------------------------------------

0 Sivaraj Kuppuraj over 9 years ago in reply to malden2507

TI__Mastermind 35645 points

Hi,

Thanks for your update.

I wish to clarify you the below point:

If you keep WNUMEVT/RNUMEVT = 1 which would transmit/receive 1 word per serializer (BYTES_PER_SAMPLE = ACNT = 4 bytes) with AFIFO functionality. Kindly check the below snapshot from the datasheet which says WNUMEVT value should be set to a non-zero integer multiple of the number of serializers enabled as transmitter. So, WNUMEVT = 1 word per serializer which is a non-zero integer multiple of 1 serializer used in the code which is a valid configuration with AFIFO functionality and likewise for RNUMEVT too.

Thanks & Regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question.

-------------------------------------------------------------------------------------------------------

0 malden2507 over 8 years ago in reply to malden2507

Intellectual 450 points

Hello,

I've solved a problem with EDMA setup, which was also related to the AFIFO feature of McASP.

In my previous posts, I've mentioned that having 2D and 3D EDMA setups of A-dimension higher than 4 didn't work.

Here's why it didn't work.

Without AFIFO functionality, McASP-driven EDMA3 transfer cannot have dimension A larger than 4 bytes.

Why?
In unbuffered (AFIFO not used) mode, McASP port cannot deliver more than 32 bits at once, due to its slotsize - limitation (max. 32 bits).

Only thank to AFIFO functionality, it gets possible.

Regards,

Mladen

0 malden2507 over 8 years ago in reply to malden2507

Intellectual 450 points

Hello,

In my audio application input and outputting audio is implemented using a ping-pong technique, with both buffer-size of 8 audiosamples.
Sampling rate is 48 kHz.

Adding a McASP AFIFO feature, an overall audio latency increases to much more than I'd expect: around 0.7 ms
Eight 48 kHz samples take 0.17 ms.

Interesting: Regardless of the RNUMEVT and WNUMEVT values used.
Normally I use WNUMEVT = 8 an WNUMEVT = 4. Even if both equal 1 (I'd expect no buffering), the latency remains the - same.

How can this unpleasant phenomenon be explained?
In my application, audio latency is a critical requirement.

Regards,
Mladen

Processors

Processors forum

2D AB-Syncronized EDMA Transfer