This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

EDMA Trigger delayed be code execution while accessing L2 Memory

Other Parts Discussed in Thread: TMS320C6413

HI to all

I have a system that is working in a 2us Loop inside the DSP

This loop is controlled by TMR0 generated in DSP to sync my external CPLD processes. 

The CPLD that controls the ADCs issue a INT that triggers the EDMA controller to start memory transfer after ADC conversion.

My problem, is that the INT generated by the CPLD to start EDMA transfer in the DSP, sometimes is delayed by the DSP for a few "ns", depending what I am doing in the code of the DSP. 

I believe that if I am accessing the L2 Memory during code execution on the DSP, the EDMA will have to wait to the transfer to finish, delaying the process by a small time.

Does some one suggest any way to guarantee that the time of the ADC transfer is always correct. This problem is relavant to me, because I have chain events that depend to this time accuracy.

I try to swicth the chain events to other INT based EDMA transfer, but since the loop in the DSP is waiting to process the next batch of ADC samples with:

while ((IFR & (1 << EDMA_CHA_EXTINT5)) == 0) { if (++Devices.Adc.Counter > ADC_MAX_WAITING) break; }

The problem also happen.

Another question, is the check of the IFR register be also one problem, by delaying the EDMA controller?

If yes, how can I trigger code execution, based on external int, that does not affect the EDMA controller?

Changing a volatile variable inside one DSP interrupt to trigger the code will generate the same problem, I believe ?

best regards

Nuno Pereira

  • Hi,

    Thanks for your post.

    In my opinion, you could reprogram the code execution time on the DSP to process the ADC sample conversion, may be, you could break the ADC chunk of samples into smaller quantity per batch, sothat, you could reduce the process time of ADC sample conversion thereby, we could avoid the EDMA waiting time to start memory transfer after ADC conversion. It all depends on how you program the timing of external CPLD process which will control the ADC process to trigger INT.

    Also, in other perspective, we need to know the EDMA traffic queue request from other peripheral request and usually, EDMA system will give less priority for memory to memory transfer requests rather than requests from any other master peripheral requests awaiting to meet critical real time deadlines. I mean we need to consider the EDMA traffic queue priority requests too for the delay on an overall EDMA system.

    May be, for more details you could refer the c645x EDMA user guide as below:

    Thanks & regards,

    Sivaraj K


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


  • Nuno,

    Welcome to the TI E2E forum. I hope you will find many good answers here and in the documents and in the TI Wiki Pages. Be sure to search those for helpful information and to browse for the questions others may have asked on similar topics.

    Sivaraj mentioned the C645x documentation, but I did not notice where you mentioned the device you are using. The CSL you are using is old enough to be related to much older devices. Which TI DSP device are you using?

    If I understand correctly from your description, your CPLD toggles an external signal on the DSP that is probably EXT5 or some similar name. And my understanding is that you are polling for that pin to set an IFR bit (bit 5) in the DSP, and then triggering the EDMA to start the transfer after polling for that IFR bit. Is my understanding of your situation correct?

    The normal use of the EDMA for an automatic transfer is to have the EXT5 pin routed to the EDMA to immediately start a transfer of data, and then the EDMA may send an interrupt to the DSP to indicate that the transfer is complete and that the DSP processing on that new data can start. This is the intended use of the EDMA and greatly reduces the time latency to start the transfer, and it also greatly reduces the DSP's overhead for handling the transfer, mostly removing that overhead.

    The normal use of the IFR register is to cause an interrupt to occur on the DSP. Polling IFR is only useful in a very limited set of circumstances, and yours may be one of those, but the normal use that I would recommend in to have the IFR cause an interrupt.

    Once you have mentioned the DSP you are using, Sivaraj and I can point you to training material to learn about the use of the DSP and the free TI-RTOS that will make your job much easier. And as I mentioned at the beginning, you will want to search and the Wiki and this forum for training references and helpful answers. Everyplace we point out will be from one of those sources, so you may find it quicker that we can get back to you.


  • Hello RandyP

    I lost my previous contributions since I have changed my account from NSN to Coriant. My previous email was Thank you for your welcome message.

    Regarding my problem, I can inform you that I am really using an older TI device, the TMS320C6413.

    Regarding the EDMA process, is a little bit different from what you describe. I have an external INT 6 to trigger the EDMA controller that was previously programmed, to start transfer of the ADC Samples.

    At the middle of this ADC memory transfer, the INT 5 is generated in the CPLD, but the time is directly related with the time of INT 6. If INT 6 is delayed, INT 5 is also delayed.

    Initially I start to use chained events, but the delay between the end of the conversion in the EDMA and the next TCC8 was too big. Meanwhile I have found out, that probably this could be solved by increasing the priority of the EDMA TCC8, but for now let´s continue with INT5.

    Has I have explained in my previous email, I am polling the IFR to check for INT 5 to do other DSP stuff not related with the automatic behavior of the EDMA. I am not using QDMA to start any process here.

    Since I believe this polling is delaying the EDMA controller in some cases (when I am executing the test and the INT5 arrives), I ask for a better solution.

    For now, meanwhile, after reading Sivaraj reply, I have done a work around, taht it seems to work. Image that the polling process takes “X” ns seconds to perform the test of IFR and “Y” ns to execute the timeout control (always the same, since in normal operation, no timeout should be achieved).

    If I guarantee that the INT 5 arrives always during the Y time, the “X” time will never interfere with the EDMA INT5 kick off process.

    To do this, I initialize timer2 at the begging of the DSP process, get the total time when I have being complete the DSP calculations (most of the time different, because it not always execute the same code) and then add a variable delay based on NOP instructions, depending on the time of DSP execution code. This variable delay, will synchronize the DSP to start the polling process in such way that the INT 5 will always appear in the “Y” time.

    The code executed after the DSP calculations is as simple as this:


    Index = TIMER_RGET(CNT2) % 5;

    while (Index++ != 5) { asm (" NOP"); }


    The number 5 was obtain using more and less the try and error approach :)

    If someone can suggest a more elegant way to do this, I am open to discuss :)

    Best regards

    Nuno Pereira