C6678 : problems to trig DMA on events

Apologize me for the mistake:

Who  How to trig a DMA transfer with the GPIO 0 ?

Thanks

Jean-Christophe Peltier

Hi,

You are correct about your observation.

The 'sample_c6678_cfg.c', is considered as a default input to the the EDMA RMAN driver, if system specific input is not supplied.  

So it is still generic. I am trying to find for you a file that is more specific.

You have one of the two options :
a. supply this info thru, EDMA3_DRV_InitConfig-> drvInstInitConfig, at initialization time. I am also trying to find an example for you.
b. edit the 'sample_c6678_cfg.c' file as per you needs. In the file, look for ' /* ownDmaChannels */ ', for EDMA instance #1 and #2, and then add 

channel 6 in the list of 'own DMA channels'. 

Keep us updated.

Hello,

I have looked at your options. You suggest adding the needed information, either dynamically or statically.

It might be possible for me to do something by myself, but it could be quite hazardous for an end-user to proceed to such a modification. If I add the channel 6 in the list of "own DMA channels" for EDMA instance #1, the EDMA instance  #1 would have 3 channels as its owns instead of 2. Then, what could happened because of "defines" such as "#define EDMA3_MAX_DMA_CHAN_DWRDS (EDMA_MAX_DMa_CH / 32u)"  (edma3_common.h) ?

And what about information written in the arrays such as dmaChannelHwEvtMap[EDMA3_MAX_DMA_CHAN_DWRDS], ownDmaChannels[EDMA3_MAX_DMA_CHAN_DWRDS] or resvdDmaChannels[EDMA3_MAX_DMA_CHAN_DWRDS] ?

The sample_c6678_cfg.c file and some other files should take into account some specific information about the C6678, given by the tms320c6678.pdf document, chapter 7.8.4. Theses information are specific to the C6678, but are common to every C6678 whatever the applications these processors might have to support.

For example, the sample_c6678_cfg.c file may give defaults input to the EDMA driver within which the GPIO events are associated to the EDMA instance #1 and/or #2, but it should not give defaults input to the EDMA driver within which the GPIO events are associated to the EDMA instance #0.

For theses reasons, a specific but valid sample_c6678_cfg.c file for every C6678 will be indispensable for a good application development.

I will wait for it.

Thank's

Jean-Christophe Peltier

Hello,

After having wrote what you may read above, I have tried the dynamic modification of sampleInstInitConfig by writing : sampleInstInitConfig[1 or 2][0].ownDmaChannel[0]  =  sampleInstInitConfig[1 or 2][0].ownDmaChannel[0]  |  (1 << 6);

 Results :

1) It's effectively hazardous for an end-user to proceed to such a modification : I have understood the reason of the define " EDMA3_MAX_DMA_CHAN_DWRDS (EDMA_MAX_DMA_CH / 32u)" that I had not understood preceedingly : the size is divided by 32 only because of the need of one bit per channel, and that' all.

2) Now, the EDMA3_DRV_requestChannel () API returns me another error. It's value is -160.

I realize that perhaps the event numbers might have a different signification for the EDMA instances #0, #1,  and #2. So there would not be forbiden event numbers for an instance or another one, and then any sample_c6678_cfg.c file might valid.

But it's uneasy to understand and to modify (error -160).

Jean-Christophe Peltier

sampleInstInitConfig and edma3init() both exist in the EDMA driver and in the resource manager, with the same names.

I don't know which ones I am using, I am lost...

I am consulting with the device expert and the software driver team. We will update you.

Hello,

Thanks to your first idea, I have found how to trig a DMA on GPIO 0 event :

1) You have had suggested to modify  sampleInstInitConfig :

sampleInstInitConfig [1 or 2] [shadow register number]ownDmaChannels [0] |= (1<<6)

2) The same has to be done on ownPaRAMSets and ownTccs :

                 sampleInstInitConfig [1 or 2] [shadow register number] . ownPaRAMSets [0] |= (1<<6),

                 sampleInstInitConfig [1 or 2] [shadow register number] . ownTccs [0] |= (1<<6),

3) Then call edma3init and EDMA3_DRV_requestChannel () with  chID = EDMA3_DRV_HW_CHANNEL_EVENT_6,

                 EDMA3_DRV_setSrcParams (), EDMA3_DRV_setDestParams () and so on,

4) Modify the "event enable set register" :   Useless

*((Uint32*)0x02721030)  =  (*((Uint32*)0x02721030))  |  (1 << 6)

EDMA3_DRV_enableTransfer () with EDMA3_DRV_TRIG_MODE_EVENT,

6) And then enjoy playing with the GPIO 0 :

                  * gpioSetDirection (0, GPIO_OUT), gpioSetRisingEdgeInterrupt(0), gpioSetFallingEdgeInterrupt(0), gpioEnableGlobalInterrupt(),

                  * Toggle the GPIO 0 state with gpioReadInput (0) gpioClearOutput (0) and  gpioSetOutput (0).

But I don't now if side effects may occur or not because of the use of three two different abstract levels to do one thing :

- register access,

- modification of library's global data

- API calls.

A new API might do what I have done on global data.

Jean-Christophe Peltier