EDMA3 end transfer

As long as you don't turn on "early completion" then the generated interrupt should signal that the data has actually made it all the way to memory. 

Are you sure you have things configured correctly?

Vladimir Solodky said:

EDMA3CHANPARAM [8].opt = 0x80400004 | (18 <<12);

This looks like you've enabled chaining.  Since you are programming TCC=18 then I would expect this to trigger Channel 18 to run afterward.  Does your ISR check the EDMA's IPR?

*******************

Sorry.
It was sealed up.

Here what code

EDMA3CHANPARAM [8].opt = 0x80100004 | (18 <<12)

I have conducted research.

If priority EDMA for the given channel is distinct from the higher (QUEPRI != 0) the given effect is shown. If a priority the highest (i.e. QUEPRI = 0) all works normally, the data isn't rearranged.

What is the expected output  vs the actual output?  Does a CPU delay change the behavior?

And already wrote.
If the priority at EDMA is distinct from the highest (i.e. isn't equal 0) at the moment of interruption reception it is real not all data are transferred in EMIF. And if after that CPU too writes in EMIF the data from CPU slips faster than from EDMA.
At EDMA is FIFO on transfer, and there is a suspicion that there the data is the interruptions not transferred to the moment from EDMA.

Vladimir Solodky said:

EDMA3CHANPARAM [8].dst = (unsigned int) (CE4DATA);

Vladimir Solodky said:

Semaphore_pend (Sem, BIOS_WAIT_FOREVER);
*CE4DATA = x;

If CE4DATA corresponds to the start of the destination and you are writing the value 8 then I would expect 8 to be at the first address in the destination.  However, 8 shows up way later.  This makes it very difficult for me to understand what issue you are even reporting.

Please make it easy for me to understand your problem.  Here's what I need to know:

• Contents of "data" (i.e. src)
• Contents of CE4DATA for working case
• Contents of CE4DATA for non-working case

I understand you're having issues and that the queue priority seems to be involved, but I still don't understand what the failure looks like.  Without knowing the failure I cannot possibly tell you what's wrong.

#define CE4DATA  ((volatile long long *)0xC0000000)

unsigned long long *data;

data = Memory_alloc(NULL, 32768, 32, NULL);

for (i = 0; i < 4096; i++)

  data[i] = i;

EDMA3CHANPARAM [8].opt = 0x80100004 | (18 <<12);
EDMA3CHANPARAM [8].src = (unsigned int) data;
EDMA3CHANPARAM [8].dst = (unsigned int) (CE4DATA);
EDMA3CHANPARAM [8].acnt = 8;
EDMA3CHANPARAM [8].bcnt = 4096;
EDMA3CHANPARAM [8].ccnt = 1;
EDMA3CHANPARAM [8].bcntrld = 0;
EDMA3CHANPARAM [8].srcbidx = 8;
EDMA3CHANPARAM [8].dstbidx = 0;
EDMA3CHANPARAM [8].srccidx = 0;
EDMA3CHANPARAM [8].dstcidx = 0;
EDMA3CHANPARAM [8].link = 0xffff;

*EESR |= (1 << 18);
*ESR |= 1 << 18;

Semaphore_pend (Sem, BIOS_WAIT_FOREVER);
 *CE4DATA = 0x0123456789abcdef;
}

void IntEDMA3 ()
{
Semaphore_post (Sem);
}

In EMIF in the end gets here so.

..... 4090    4091    4092    4093   0x0123456789abcdef    4094    4095

Record from the processor puts even before data transmission with EDMA

Thank you.  There is still some internal discussion on this topic, but I thought I would go ahead and post some info to keep things moving.

One solution that will work regardless of priority is to issue a dummy read to CE4DATA prior to the write.  That will force the previous write to complete.

Vladimir Solodky said:

Semaphore_pend (Sem, BIOS_WAIT_FOREVER);
 *CE4DATA = 0x0123456789abcdef;

Specifically you would instead do:

  Semaphore_pend (Sem, BIOS_WAIT_FOREVER);
 *CE4DATA;   // dummy read
 *CE4DATA = 0x0123456789abcdef;

Another possible solution is to make sure the CPU priority is set at the same level or lower as the EDMA TC doing this transfer.

Vladimir,

Would you please send your EMIFA configuration register values? 0x7000 0088 and 0x7000 00A0

Also please change the two lines in your program from

*EESR |= (1 << 18);
*ESR |= 1 << 18;

to the single line

*ESR = 1 << 18;

The EESR is not needed because you are triggering directly from the ESR and not from an event.

The ESR is intended to be directly written instead of through a read-modify-write.

Please let us know your results after these changes.

Regards,
RandyP
[on behalf of Brad Griffis]

Vladimir,

FYI, the behavior you are experiencing is not the intended design of the device.  We would like to do some deeper investigation.  Can you please supply a stripped down, minimal test case that reproduces the issue?  This is critical for a couple reasons:

1. Often times upon simplifying the code the customer discovers something elsewhere in his code that is responsible for the behavior.  At a minimum this helps rule out something else in the code.
2. It will give us a starting point where we can see the issue and diagnose the root cause.

Thanks,
Brad

Vladimir,

I had a bunch of people lined up to help get to the root cause of this issue.  We've not heard from you in weeks.  What's the status?

Brad