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 suddenly ignores the rest of the sync. events

Hi,

I previously wrote into the thread "Cannot clear EDMA3 synchronization event input from a GPIO pin", but since the discussion began to slide out of the topic I continue the story here.

I am using the 6638 K2H EVM board rev 4.0. I need to do some AB-synchronized DMA transfers periodically from the EMIF16 memory to the DDR3 memory..

The problem now is that the EDMA sometimes stops reacting to the incoming sync. events. This happens in average to the every 3000th of transfers.

Example:

My peripheral gives 16 sync inputs to the EDMA through the GPIO 11 pin. Each of these 16 events trigger a transfer of 2 X 12 bytes. I repeat this procedure once per second (or 10 000 times per second, it does not matter). It succeeds most of the time.

But then, at some random moment, only 2 events are processed (it's not always 2, it varies randomly between 1-15). When stopping the software with the debugger into the spot where it prepares the next transfer there are never any errors visible in the EDMA error registers, but I can see that the CCNT register in the PaRAM is still > 0; 14 in this example case. With the debugger I can give more events for the EDMA by writing into the ESR-register and the EDMA reacts to them alright --> the CCNT decreases by one after each write.

Below is an oscilloscope image of the problem.

There are 2 transfers visible in the image above,. As seen, the EDMA processes the first transfer OK, but then during the 2nd transfer it suddenly stops working. The peripheral gives all the 16 pulses nicely in both of the cases, but the 2nd transfer the EDMA reacts only to 2 of them.

What can stop EDMA working? As told above there are no visible errors in the EDMA registers but the CCNT still has 14 events to receive and the transfer can still be continued by manually triggering the event with software/debugger.

Best regards,

Ari

  • Hi,

    Thanks for your post.

    Kindly validate the following suggestion below:

    To enable the EDMA controller to chain channels by way of a single event, you should set the TCINT bit to 1. Additionally, you should set the relevant bit in the channel chain enable register (CCER) to trigger off the next channel transfer specified by TCC. Since events 8−11 are the only EDMA channels that support chaining, only these bits are implemented in CCER.

    Reading unused bits returns the corresponding bits in EER and writing to the unused bits has no effect. Therefore, you can still specify a TCC value between 8−11, and not necessarily initiate the transfer on channels 8−11.

    However, ER bits 11−8 still captures the event, even if the corresponding bit in CCER is disabled. This would allow selective enabling and disabling of these four specific events.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

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

    -------------------------------------------------------------------------------------------------------

  • Hi,

    thanks for your reply.

    I am sorry, but I don't fully understand why you suggest using chained transfers instead of an AB-synchronized transfer.

    I program the OPT field of the PaRAM to 0x80113004 (TCINTEN = 1, TCC = 0x13). This is the way it has already worked for years in my earlier DM6443 platform. Now I just want to do the same with the Keystone 2. I do not want to start using chained transfers because a single AB-sync is good enough for me. In addition, if my configuration was wrong, then also all the 3000 now successful transfers would fail in the same manner, right?

    I did another test this morning: I disabled the HW input from the peripheral and triggered the GPIO 11 only by software by calling the EDMA3 LLD function EDMA3_DRV_enableTransfer(hEdma, 19, EDMA3_DRV_TRIG_MODE_MANUAL). The EDMA configuration was exactly the same where it fails with 1/~3000 transfers when externally triggered.

    I let it run for ~15 minutes and then stopped. The missed event count was 0 out of 8984421 transfers. So the problems seems to come from the electrical interface only. I suspected first if some other CPU (4 ARMs and 7 other DSPs) interferes with my transfers, but this test should clearly prove that it is not the case.

    I will try the same with another EDMA controller and another GPIO pin to see if it behaves any better.

    Best regards,

    Ari

  • Hi,
    the EDMA3 CC2 with the GPIO pin 0 gives good results. I can now run the system for several minutes without one single error.

    It appears that the EVM board connects the GPIO pins 0...16 to a host processor (LM3S2D93) in 2 banks: pins 0...7 and 8..15. The lower bank seems to be more stable for application use than the upper bank for some reason. So it is better to use GPIO pins 0...7 for EDMA inputs.

    I think this case is now closed.

    Best regards,
    Ari
  • Hi,

    Glad that your issue gets resolved.

    Thanks for your update.

    Regards,
    Sivaraj K