Sharing EDMA Device between Multiple Peripherals

Brian,

I will check and get back to you as soon as possible. Thank you.

Hi Raja,

Did you get any info on this since?

Thanks

Brian

Brian,

Your wording is a little different than we usually use, so there might be confusion here. To me, 'device' usually means a packaged part with pins, so a 'SPI device' would be the physical SPI memory on the board and not the SPI module (or SPI peripheral) inside the DSP device. But I believe you are talking about the modules and peripherals inside the DSP, primarily. If I got this wrong, please clarify for me.

The EDMA3 has two instances or modules inside the C6748, which I am assuming is the DSP you are referring to. I do not see any mention of the specific DSP, but the other questions I have been reading today were on the C674x so I am making a rash assumption. And it has two EDMA3 modules.

Each EDMA3 instance has one Channel Controller that manages the activity of one or two Transfer Controllers. The Channel Controllers have specific peripheral connections for trigger events, and these are listed in the datasheet in the EDMA3 section. EDMA3_0 CC0 has two TCs that can be actually moving data simultaneously, depending on how the channels are programmed by you. EDMA3_1 CC0 one one TC. If you are using MMCSD1, it will work with EDMA3_1, but if you are using MMCSD0 then it will have to share EDMA3_0. Both the McASP and SPI events are tied to EDMA3_0.

You can definitely share EDMA3_0 with the three peripherals. It will be wise to split them between EDMA3_0 TC0 and TC1 for some efficiency, but that will only matter if you have some performance issues with EDMA3_0 CC0 being overloaded. Depending on the data rate on each of these, there are always potentials for stalls that could miss some data. First build it, then see if there are any issues.

If you start with just the McASP audio stream, are you able to get that running without first starting the SPI interface?

Regards,
RandyP

Hi Randy,

Yes, I meant the modules/peripherals inside the DSP. Maybe I saw the MMCSD controller being referred to as a device and applied this terminology to SPI and McASP modules. In any case, when I said device, I was referring to McASP , MMCSD and SPI peripherals. 

I am using a C6746, which I believe is the same as C6748 in terms of EDMA provision.

I am using MMCSD1, so I had to configure this to use EDMA3_1 to work. I believe it MMCSD1 must use EDMA3_1 as they are both in the same power domain, PSC1.

It sounds like my best solution then would be to share EDMA3_0 between McASP and SPI, making use of both transfer controllers. 

I am not sure, at the moment, of what exactly is required to initialise both McASP and SPI in DMA mode using EDMA_0. I believe I will need to use a global handle to EDMA_0, initialise and use this to initialise McASP audio streams and SPI streams? I had tried this, but initialising McASP failed. I also tried initialising 2 separate handles to EDMA_0, one for SPI and another for McASP, but this failed also when trying to create a McASP stream.

What is the general procedure, in terms of EDMA handles, when initialising multiple modules/peripherals in DMA mode, using a single EDMA controller?

Thanks

Brian

Brian,

EDMA3_0 must be initialized and opened globally, but the terminology varies depending on the software package you are using, like CSL or LLD or some other package. EDMA3_1 should probably be maintained with a global handle, too, since various functions and interrupts will need to access it also.

Initializing an EDMA3 module consists of clearing all the status and control registers and initializing any mapping registers to some defaults. This should only be done once, and it is usually part of the _init or _open step.

Once that initialization is completed, the initialization of the peripherals are independent from each other. Clock and power domains need to be handled, and the DMA PARAM sets need to be programmed, and the peripherals' registers need to be initialized. There is always a specific order for doing that, described in the TRM or User Guides for the different peripherals.

When I am setting up a new project, I generally start the initialization of a peripheral using CPU accesses before trying the EDMA3. It is usually more straight-forward, or at least seems that way. Once you know you have all the external pins working and moving data back-and-forth, then you can more easily move to DMA control of the data flow.

Are you working from some supplied examples for McASP initialization? The User Guide has pretty good descriptions of the order of initialization and we usually have good examples ready to show you how to get it done.

Regards,
RandyP

Hi Randy,

Thanks for your detailed response. I think I've got it working now, setting up McASP and SPI using EDMA_0. I had a issue with an extra global EDMA handle conflicting with the handle I was using to initialise McASP.

In a broad sense, how can I split McASP and SPI between EDMA3_0 TC0 and TC1?

Many thanks
Brian

Brian,

When you are setting up the DMA channels for each peripheral, one of the things you can do is to change the DMAQNUMn register field for the DMA channel you are using. This will map that DMA channel (such as 14 for SPI0 read events) to the Queue number that you put in the corresponding field. The Queue number maps 1:1 with the Transfer Controller (TC), and is explained a little in the NOTE: on the DMAQNUMn register description page in the TRM.

It is possible that leaving these at the default value of 0 will work fine, but it is good planning to spread them out, in my opinion.

It is possible that the best allocation could be putting the McASP and SPI reads on TC0 and the McASP and SPI writes on TC1. That would depend on the nature of the transactions you expect to have going on.

Often, McASP read and write events happen at the same time, so it is common to only use one of them to trigger a transfer. If you use the McASP Read event to trigger its DMA channel, it could chain (ITCCHEN=1 and TCCHEN=1) to the transmit channel so that the two are naturally sequential.

Depending on the data rate, it can be helpful to have the memory target be internal memory to avoid any extra delays holding off servicing the peripheral. That could be a good use for the On-chip RAM at 0x80000000. You could copy one buffer of some size into there and when it is full (or empty) your DMA channel could chain to move it/from to another place without the worry of slowing down an immediate access (since that access would be done before the chaining occurs, if programmed that way).

Lots of possibilities, so I apologize if they all get confusing side-by-side. I wanted to give you your options, and there are a lot when you use the EDMA3.

Regards,
RandyP

Hi Randy,

Thanks for your insights here. I have other more pressing tasks to see to at the moment, so I will go with the default DMAQNUM settings for now. There will be very little traffic on the SPI line (and virtually none while McASP is running), so I will not need to make full use of both TCs in this case.

It may be be worthwhile (even required) for me to place audio buffers in internal memory and chain transfers to/from external memory as you say. I have yet to test the McASP with a full load, so I will bear this advice in mind.

Many thanks

Brian