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.