Filip Dossche

eDMA oddity on MCF54415

Discussion created by Filip Dossche on May 16, 2013
Latest reply on May 21, 2013 by Filip Dossche



In an earlier discussion Tom Evans pointed me in the right direction to implement some functionality I need.

In essence I have coupled back a PWM signal to the DREQ1 pin function to trigger data transfers from the flexbus to an SRAM location.

it works to a degree but there is something odd that I can't explain.


The PWM signal  is a simple square wave with a frequency of 7.8125 MHz, the period is 128 nanoseconds.

The odd thing is that I do get the expected chip select signals on the FLEXBUS but only 3 out of 4 times

Furthermore: the 3 pulses I do get seem to "drift" away from each other.


This is how it is set up and a detailed description of what I see on my scope:


     - PWM_B0 generates the square wave with a period of 128 nanoseconds.

     - That signal is fed back to DREQ1. I have checked the signal with a scope and it is perfect, as expected the period is exactly 128 ns and very stable.

     - CS1 is set up to activate when there is a read operation in the range 0x02000000...0x0200FFFF.

     - the edMA module is set up to always read at address 0x02000000 and write the result to a fixed address in the processor's SRAM.

     - The total cycle time for the read operation on the FLEXBUS is 40 ns (4 basic 8 ns cycles + 1 wait state cycle of 8 ns).

     - After the first positive edge on the PWM/DREQ1 signal I see the chip select signal appear after a delay of 24 ns.

     - After the second positive edge on the PWM/DREQ1 signal the chip select delay becomes 40 ns.

     - After the third positive edge on the PWM/DREQ1 signal the chip select delay becomes 56 ns.

     - After the fourth positive edge on the PWM/DREQ1 signal the chip select signal does not appear.


Having shown this behaviour after four cycles of the PWM/DREQ1 signal everything repeats over and over again, regular as clockwork.

Its almost as if the total time taken for the eDMA transfer is 144 ns which I find hard to believe: the read operation on the external bus takes only 40 ns, the transfer to the SRAM on the processor's internal bus should be a lot faster than that so it should be far below 128 ns to complete the transfer.

Any ideas/suggestions as to what might be going on would be very much welcome.



Message was edited by: Filip Dossche


I have done some further searching in the documentation and testing so I have found a few things.

1) It is not the positive edge on DREQ1 that triggers the DMA operation, it is the negative edge.

2) I have activated the DACK1 pin function to see exactly when the DMA transfer is confirmed.

3) The reason it is failing to generate a DMA transaction is due to the fact that the minimum transaction time does appear to be 144 ms.

    The result is: it can't follow the 128 ns rate and lags by 16 ns each time. The fourth time the DREQ1 goes high before DACK1 does => it ignores that DMA transfer.

4) I have halved the frequency so it requests DMA transfers at  256 ns intervals and sure enough then it works. Not a single DMA transfer is missed any more. I get each and every chip select signal.

5) The timing between the various events is:

    Assertion of DREQ1 => Assertion of DACK1: 40 ns.

    DACK1 duration : 8 ns

    Assertion of DREQ1 => Assertion of CS1: 90 ns.

    CS1 duration: 16 ns (as expected).


It seems I am stuck with a minimum duration of 144ns which raises a few questions:


- Why does it take so long ?

- What is it the processor doing in the mean time: is it still executing code or does the eDMA module stop everything during those 144 nanoseconds ?

- Is there any way of speeding things up ?


Next thing I will try is getting the DREQ1 signal's period as close as possible to 144 ns.


Message was edited by: Filip Dossche

144 ns does not produce missing chip selects any more but the response to DREQ1 jitters a bit every few seconds.

160 ns works well though: no missing chip select signals and a very stable response time to DREQ1.

That will work for me but I am still curious as to the reason for the 144ns minimum DMA duration.