DM6443 - Event-triggered transfer is not working

Hi There,

In my previous post lines 3-5  may be bit confusing.

Basically I have two problems.

1.  DMA transfer is not taking place when I select a channel number grater than 32 during the call to transer request (In both the MANUAL/EVENT triggered mode )

2. EVENT triggered mode is not at all working.

krishna prasad said:

1.  DMA transfer is not taking place when I select a channel number grater than 32 during the call to transfer request (In both the MANUAL/EVENT triggered mode )

I do not have a lot of experience with the LLD, but it should certainly be able to handle channels in the upper half, that is 32-63. Please take a look at the Param for the channel you are trying to trigger to make sure it is configured correctly, then take a look at the other EDMA registers to see what might seem to be missing or wrong. You could run to the line of code that is supposed to manually trigger the event (set a breakpoint there) and write to the right bit in ESRH using CCS in a memory window or a watch window.

krishna prasad said:

2. EVENT triggered mode is not at all working.

Is the event occurring?
Is the ER/ERH register getting set?
Is the EER/EERH register enabled for the channel you are using?
Are you using the channel associated with the event you want to use as the trigger?

Hi Randy,

Thank you, I appreciate the quick response and your valuable suggestions.

I have checked various registers including DRAE and ESRH. Here are my observations.

1. When I select the DMA channel number greater than 31, the bit positions in the DRAE (H) register is not set.

2. In the source code of the EDMA LLD channels32-63 are not properly handled.

I am suspecting a bug in the EDMA LLD code. Your thoughts on this are much appreciated. Please let me know if there is any quick solution to the problem.

Regards, Krishna.

krishna prasad said:

1. When I select the DMA channel number greater than 31, the bit positions in the DRAE (H) register is not set.

We need some more detail on this statement, please. Which region are you using? Which DRAEH bit are you expecting to be set? Which other bits are actually set?

krishna prasad said:

2. In the source code of the EDMA LLD channels32-63 are not properly handled.

We need some more detail on this statement, too, please. Is this based on your reading of the LLD source code (please be specific) or are you claiming this because the operation is not working the way you expect it to be working?

Hi Krishna prasad

              I am trying to trigger a DMA transfer on channel 0 by setting the ESR bit. I filled up the paRam0 which is for channel 0. Still I dont see data being moved. I am attaching my code below

#include <stdio.h>
#include <stdlib.h>
#include <csl.h>
#define SRCADDR  (0x02A04004)

void main()
{
 int *ptr=(int *)(0x0800000);
 unsigned int status,index;
 *((int *)0x02A04000)=0x00100008;
 *((int *)SRCADDR)=0x800000;
 *((int *)0x02A04008)=0x00010100;

 *((int *)0x02A0400C)=0x800500;

 *((int *)0x02A04010)=0x000000;

 *((int *)0x02A04014)=0x0000FFFF;

 *((int *)0x02A04018)=0x000000;

 *((int *)0x02A0401C)=0x000000;

 for(index=0;index<255;index++)
 {
  *(ptr++)=index;
 }
 
 *((int *)0x02A01010)=0x00000001;

 *((int *)0x02A01060)=0x00000001;

 status=*((int *)0x01A0FFA4);

}

 Please let me know what i am doing wrong

regards

Bala

Since this is a new topic, please re-post to a new thread with the following updates to your posting:

1. Be sure it is in the best sub-forum. This may be the right one, but that is up to you.
2. Please identify the device you are using in the new thread.
3. Please use CSL or EDMA LLD which have examples for doing a transfer. Everything you need to initialize has already been done for you.
4. Please use symbolic names from the libraries, which comes naturally when using CSL or LLD. It is not easy to have to reverse-engineer your hard-coded addresses.
5. Set CCNT = 1.

After you re-post, please come back to this thread and reply with a link to or information about the new one so I can follow it.

I appreciate such a prompt and a speedy response.

I will try to re-post the same in the new thread. In the meantime, please find more deatils (that you have requested) on the problem below .

We need some more detail on this statement, please. Which region are you using? Which DRAEH bit are you expecting to be set? Which other bits are actually set?

I am expecting one of the DRAEH1 (0x01C0034C) bits to be set when I select channel number greater than or equal to 32. In particular, in my code, I am trying to use channel 32-40. When I use channel 0-31, the bit positions in the DRAE1 (0x01C00348) are setting ok.  Furthermore, the EDMA transfer is taking place and the destination buffer contents are matching the source buffer contents.  Please find the source code attached.

 2. In the source code of the EDMA LLD channels32-63 are not properly handled.

We need some more detail on this statement, too, please. Is this based on your reading of the LLD source code (please be specific) or are you claiming this because the operation is not working the way you expect it to be working?

My observations are based on the both. I have debugged the LLD source code; please find the EDMA LLD resource allocation function below. The problem appears to be in the function

“ EDMA3_RM_Result   EDMA3_RM_allocResource(EDMA3_RM_Handle hEdmaResMgr,    EDMA3_RM_ResDesc *resObj)”

In particular, In the following, I have observed the code jumping to error condition.

                                if (resId < rmObj->gblCfgParams.numDmaChannels)
                                    {
                                    /*
                                     * Check if specified resource is owned
                                     * by this instance of the resource manager
                                     */
                                    if (((rmInstance->initParam.rmInstInitConfig->ownDmaChannels[resId/32u])&(resIdSet))!=FALSE)
                                       {
                                        /* Now check if specified resource is available presently*/
                                        if (((rmInstance->avlblDmaChannels[resId/32u])&(resIdSet))!=FALSE)
                                            {
                                            /*
                                             * Mark the specified channel as "Not Available"
                                             * for future requests
                                             */
                                            rmInstance->avlblDmaChannels[resId/32u] &= resIdClr;

                                            /**
                                             * Check if the register modification flag is
                                             * set or not.
                                             */
                                            if (TRUE == rmInstance->regModificationRequired)
                                                {
                                                if (resId < 32u)
                                                    {
                                                    rmInstance->shadowRegs->EECR = (1UL << resId);

                                                    /**
                                                     * Enable the DMA channel in the
                                                     * DRAE registers also.
                                                     */
                                                    gblRegs->DRA[rmInstance->initParam.regionId].DRAE
                                                        |= (0x1u << resId);
                                                    }
                                                else
                                                    {
                                                    rmInstance->shadowRegs->EECRH = (1UL << resId);

                                                    /**
                                                     * Enable the DMA channel in the
                                                     * DRAEH registers also.
                                                     */
                                                    gblRegs->DRA[rmInstance->initParam.regionId].DRAEH
                                                        |= (0x1u << (resId - 32u));
                                                    }
                                                }

                                            result = EDMA3_RM_SOK;
                                            }
                                        else
                                            {
                                            /* Specified resource is owned but is already booked */
                                            result = EDMA3_RM_E_SPECIFIED_RES_NOT_AVAILABLE;
                                            }
                                        }
                                    else
                                        {
                                        /*
                                         * Specified resource is not owned by this instance
                                         * of the Resource Manager
                                         */
                                        result = EDMA3_RM_E_RES_NOT_OWNED;
                                        }

I am getting an error of -160. Which is from the line of the codeshown below.

                                        /*
                                         * Specified resource is not owned by this instance
                                         * of the Resource Manager
                                         */
                                        result = EDMA3_RM_E_RES_NOT_OWNED;

I am using EDMA LLD version "edma3_lld_01_06_00_01". Moreover, I have tried with the newer version of "edma3_lld_01_10_00_01". The problem appears to be same in the both versions of the LLD libraries.

Thanks in advance.

Regards,

Krishna.

Krishna, This is your thread. There is not a need for you to change to a new thread. That request was for Bala who has already posted the same request elsewhere.

Excellent debug work so far, by the way. We just need to continue this debug path to the next area it points us to. Since your error message comes from the test of the ownDmaChannels variables, it is now important to find what value is being placed in that variable pair.

This is set when you call EDMA3_DRV_open(). The second argument is a pointer to an EDMA3_DRV_InitConfig struct, and this struct will contain drvInstInitConfig which is a pointer to an EDMA3_DRV_InstanceInitConfig struct. That struct will then contain the values that are copied to ownDmaChannels.

So, prior to your call of EDMA3_DRV_open, what initialization values were used to fill the EDMA3_DRV_InstanceInitConfig struct?

It appears to be common to use a pre-defined struct called sampleInstInitConfig. In bios_edma3_drv_sample_dm644x_cfg.c, sampleInstInitConfig has {0xFFFFFFFFu, 0x0u} for ownDmaChannels, which means it only allocates 0-31 and none of 32-63.

Hi Randy,

Thank you for your valuable suggestions.

You are right, I have checked the file "bios_edma3_drv_sample_dm644x_cfg.c". 

Can you please advice me on fixing this problem.

Regards,

Krishna.

Your program provides values to the EDMA3_DRV_open function through the structs inside of structs. You have to change the values that you supply so that it will initialize the region the way you want it to be setup.

Hi Randy,

Thank you again for all the help.

I have a problem in the external event-triggered DMA transfer request. I am using this mode of transfer based on the GPIO event. Our GPIO events are periodic with period equal to 1.25ms, the DMA transfer is taking place correctly, but only once (for the first event).   The subsequent DMA transfers are not happening.  Please find more details and code below.

 1. I am requesting the channel resources using the following code

   /* Setup for Channel 36*/

   tcc = EDMA3_DRV_HW_CHANNEL_EVENT_36;

    chId = EDMA3_DRV_HW_CHANNEL_EVENT_36;

    tccCb = &edma_isr;                   // callback function from EDMA handler

    /* Request  DMA channel 36 and  TCC */

        result = EDMA3_DRV_requestChannel (hEdma, &chId, &tcc,

                                        (EDMA3_RM_EventQueue)0,

                                            tccCb, NULL);

2. Enabling the transfer completion interrupts    

// Interrupt enable ENABLED for iChannel - required to generate interrupt when xfr is complete

EDMA3_DRV_setOptField (hEdma,chId, EDMA3_DRV_OPT_FIELD_TCINTEN, EDMA3_DRV_TCINTEN_EN);  

3   Now enabling the  transfer          

            result = EDMA3_DRV_enableTransfer (hEdma, chId,                                 

                                                          EDMA3_DRV_TRIG_MODE_EVENT);

4. ISR code as below

void edma_isr()

{

    //printf("\nedma3MemToMemCpytest() passed\n");

            CSL_gpioHwControl(hGpio, CSL_GPIO_CMD_CLEAR_BIT, &pin10);

            LOG_printf(&myLog, "WE GOT TO THE ISR \n");

·        SEM_post(&wait_for_completion);  (BREAK POINT)

            CSL_gpioHwControl(hGpio, CSL_GPIO_CMD_SET_BIT, &pin10);

}

The execution control is reaching the break point only once. I have checked the contents in the destination buffer; they are unchanged after the first transfer. That means the periodic DMA transfers are not happening.

Shed some light on this problem, please. Thanks in advance,

Regards,

Krishna.

You are doing most everything right, since you get one transfer to occur and you get to the ISR. You may be 95% of the way to being done. To help you find the last remaining part will require some more information.

1. What values do you program into the PARAM that is the active set associated with DMA channel 36?
2. How and when do you re-program that PARAM for the next transfer?
3. When you hit the breakpoint in the ISR, what are the values in that PARAM? What are the values in EERH, EMRH, SERH, IPRH, IERH?
4. When you hit the breakpoint, does GPIO4 still get toggled every 1.25 ms?

The IPRH bit might not get cleared until you exit the ISR function, so bit 36 might still be set and that would be okay. But EERH, EMRH, and SERH should not have bit 36 set. And the PARAM set needs to be programmed before the next GPIO4 event occurs.

At a higher level, what do you want to happen when the GPIO4 event occurs each time? What should be different from one event to the next, if anything (source, destination, count, etc.)?

Hi Randy,

Thank you for the quick response. Please find my answers below.

How and when do you re-program that PARAM for the next transfer?

 I am setting up (programming) channel 36 for the first time (in the initialization code). I was expecting the PARAM set to be active for this particular channel until I release (delete) this channel. So, I am not re-programming  this channel. I want the channel 36 to be dedicated for that particular event (transfer) all the time. Please advice me if I need to re-program this channel again.  When and what is the right place to do re-programming the PARAM?. May be this is what I am missing in my code.

GPIO events are always coming. I have checked in the oscilloscope, they are generated by the external device, FPGA and occurring for every 1.25ms.

At a higher level, what do you want to happen when the GPIO4 event occurs each time? What should be different from one event to the next, if anything (source, destination, count, etc.)?

When the GPIO4 pin goes low, I need to transfer the source buffer contents from FPGA memory space (source buffer) to the DSP internal memory (destination buffer) using the DMA. There is no difference between the first event and the next events. In otherworld, I am treating the signal pulse from the FPGA as a interrupt source. Furthermore, I would like to  extend this mechanism to other GPIO events. Since, my system requirements demand 5-different transfers (using the events, GPIO4-GPIO8)  from FPGA for every 1.25ms.

Thanks in advance.

Regards,

Krishna.

To get this discussion continuing from a common level, please review the training video for EDMA3 for the C6474 at http://e2e.ti.com/media/p/36682.aspx (sometimes you have to refresh to see the list of modules). The EDMA3 module is one of the several modules in this training packet. It has a few details that are specific to the C6474, but the EDMA3 information is generally common with your device, too.

This will help you understand what happens after a transfer completes and what you need to do to get ready for another one. The pin-pong buffering might be useful for you, too.