Page 1 of 1

software triggered eDMA does not start

Posted: Thu Dec 12, 2013 7:54 am
by fd9750
Hi,

I used to work with a dev-70 board + a hand wired prototype board that required single value data transfers to get my AD converter data into SRAM.

I used the DREQ1 pin to trigger those transfers and it worked quite well except for the fact that potentially the eDMA transfer would be delayed and I could miss the data, I very definitely got the appropriate Chip select signal (CS1) though to read the data on the flexbus.

In the mean time I have a board with all the necessary FIFO RAM etc... so that I can now store the 900 or so samples in the FIFO RAM before transferring them all in one go to the more spacious DDRAM.

I have set up the eDMA in much the same way as I had it before except for the fact that I now specify to transfer 3600 bytes (minor loop count) and I am using eDMA channels 30 and 31 for it.

I am using an Interrupt service routine function linked to a compare function on one of the PWM modules which should repetitively trigger the start of the 900 sample DMA transfers (there are two of them).

Code: Select all

INTERRUPT( PwmModule3ValueMatch_ISR, 0x2700 )
{
sim1.mcpwm.sm[3].sr |= PWM_MATCH_VAL3_INT_ENABLE;
IsrTick = !IsrTick;
SetStatusLed(STATUSLED2, IsrTick);
sim2.edma.tcd[30].csr &= 0xFF7F;
sim2.edma.tcd[30].csr |= 0x0001;
sim2.edma.tcd[31].csr &= 0xFF7F;
sim2.edma.tcd[31].csr |= 0x0001;
}
I am sure that ISR works OK because I see the signal towards LED2 toggle very nicely and alwayd perfectly in sync with the associated PWM signal.
However, I don't get to see any signals coming out of CS1 (J1-5) or CS4 (J1-6).

I have gone through the V3 reference manual with a fine tooth comb and I think everything is set up correctly but i get nothing.
So: is there anything particular about starting eDMA transfers via software which is not mentioned in the reference manual ?

Any help much appreciated and if I find out myself what is still wrong I will post the answer.

Re: software triggered eDMA does not start

Posted: Thu Dec 12, 2013 9:38 am
by dciliske
There's not enough information here to see what you're doing wrong. Can you please post all eDMA configuration information?

-Dan

Re: software triggered eDMA does not start

Posted: Fri Dec 13, 2013 2:11 am
by fd9750
OK, here are the various sections dealing with edma setup and use.
I have checked thoroughly that all sections get called in the right order.

First: some defines used in the code below

Code: Select all

#define FB_CS1_BASE	0x01000000;			// CS_1 base address
#define AD1reading	*(DWORD*) FB_CS1_BASE
#define FB_CS4_BASE	0x04000000;			// CS_4 base address
#define AD2reading	*(DWORD*) FB_CS4_BASE
second: initialization of the FB_CS signals:

Code: Select all

void InitCS (void)
{
sim1.gpio.par_cs |= _00111100_;		// activate CS1 & CS4 pin function (primary function for those pins)
sim2.cs[1].csar = FB_CS1_BASE;		// set base address for CS1
sim2.cs[1].cscr = 0x00000500;			// 1 wait state, internal transfer acknowledge, 32 bit transfer
sim2.cs[1].csmr = 0x00000101;			// CS1 range = FB_CS1_BASE...FB_CS1_BASE+0xFFFF, read only + valid
sim2.cs[4].csar = FB_CS4_BASE;		// set base address for CS4
sim2.cs[4].cscr = 0x00000500;			// 1 wait state, internal transfer acknowledge, 32 bit transfer
sim2.cs[4].csmr = 0x00000101;			// CS4 range = FB_CS4_BASE...FB_CS4_BASE+0xFFFF, read only + valid
}
Third: setting up the eDMA channels

Code: Select all

void InitPWM_DMA (void)
{
// general/common eDMA control register setup
sim1.gpio.par_cs |= _00111100_;	// J1-5 => CS1 function (FIFO RAM 1 OE), J1-6 => CS4 function (FIFO RAM 2 OE)
sim2.edma.cr 	  &= ~0x000300FF;	// Leave the group priorities alone, but clear all other control flags (default eDMA setup)
sim2.edma.erql	  |=  0xC0000000;

// transfer control description block for transfer from CIS1 Sample FIFO RAM to normal RAM
volatile edma_tcdstruct &tmrTcd1 = sim2.edma.tcd[30]; // eDMA channel 30: software triggered, see Table 19-6 in MCF54418RM_V3.PDF
tmrTcd1.saddr  	= FB_CS1_BASE;								// set the start address for the DMA transfer
tmrTcd1.attr   	= 0x0202;									// no address modulo's, source/target both 32 bit (4 bytes)
tmrTcd1.soff   	= 0; 											// source offset: this must be 0, the source address is always the same !
tmrTcd1.nbytes 	= SAMPLES_PER_CIS*4;						// number of bytes transferred per DMA request (samples x 4 bytes/sample)
tmrTcd1.slast  	= 0; 											// source offset applied at completion of all requests, before resetting
tmrTcd1.daddr  	= (DWORD)g_ulRawSampleDataCIS1;		// Raw pixel data address
tmrTcd1.doff   	= 4; 											// destination offset, how much to move destination address after each request
tmrTcd1.dlast_sga = -(SAMPLES_PER_CIS*4);					// destination address adjustment at the end of the major loop (bytes).
tmrTcd1.biter		= 1;											// major loop count reload value (single DMA transfer per request)
tmrTcd1.citer		= 1;											// initial loop count value (single DMA transfer per request)
tmrTcd1.csr    	= 0; 											// default DMA operations, no interrupts, leave request enabled when DMA ends

// transfer control description block for transfer from CIS4 Sample FIFO RAM to normal RAM
volatile edma_tcdstruct &tmrTcd2 = sim2.edma.tcd[31]; // eDMA channel 31: software triggered, see Table 19-6 in MCF54418RM_V3.PDF
tmrTcd2.saddr  	= FB_CS4_BASE;								// set the start address for the DMA transfer
tmrTcd2.attr   	= 0x0202;									// no address modulo's, source/target both 32 bit (4 bytes)
tmrTcd2.soff   	= 0; 											// source offset: this must be 0, the source address is always the same !
tmrTcd2.nbytes 	= SAMPLES_PER_CIS*4;						// number of bytes transferred per DMA request (samples x 4 bytes/sample)
tmrTcd2.slast  	= 0; 											// source offset applied at completion of all requests, before resetting
tmrTcd2.daddr  	= (DWORD)g_ulRawSampleDataCIS2;		// Raw pixel data address
tmrTcd2.doff   	= 4; 											// destination offset, how much to move destination address after each request
tmrTcd2.dlast_sga = -(SAMPLES_PER_CIS*4);					// destination address adjustment at the end of the major loop (bytes).
tmrTcd2.biter		= 1;											// major loop count reload value (single DMA transfer per request)
tmrTcd2.citer		= 1;											// initial loop count value (single DMA transfer per request)
tmrTcd2.csr    	= 0; 											// default DMA operations, no interrupts, leave request enabled when DMA ends
}
Fourth: a modified version of the original ISR:

Code: Select all

INTERRUPT( PwmModule3ValueMatch_ISR, 0x2700 )
{
DWORD test;
sim1.mcpwm.sm[3].sr |= PWM_MATCH_VAL3_INT_ENABLE;
IsrTick = !IsrTick;
SetStatusLed(STATUSLED2, IsrTick);
test = AD1reading;
test += AD2reading;
test+=1;
//sim2.edma.tcd[30].csr &= 0xFF7F;
//sim2.edma.tcd[30].csr |= 0x0001;
//sim2.edma.tcd[31].csr &= 0xFF7F;
//sim2.edma.tcd[31].csr |= 0x0001;
}
In this modified ISR I have commented out the eDMA transfer triggering and replaced it by single reads on the appropriate flexbus locations. Just as with the eDMA transfers I see absolutely nothing on pins J1-5 and J1-6.
If I set up those pins to be GPIO pins and include a bit of code in the ISR to simulate FB_CS pulses it all works OK so its not a hardware problem.
its almost as if setting up the pins to be FB_CS signals does not work but I have seen it work OK with exactly the same setup, in that case I was only using CS1 but that should not make a difference.
So it might not be an eDMA problem after all but something completely different.

I will keep on looking but for the moment I could do with some inspiration.

Re: software triggered eDMA does not start

Posted: Fri Dec 13, 2013 5:16 am
by fd9750
Update: changed the start addresses as follows to avoid overlap with FB_CS0 address range

Code: Select all

#define FB_CS1_BASE	0x02000000;			// CS_1 base address
#define AD1reading	*(DWORD*) FB_CS1_BASE
#define FB_CS4_BASE	0x02010000;			// CS_4 base address
#define AD2reading	*(DWORD*) FB_CS4_BASE
Result: dead as a doornail, no result whatsoever.
Then recompiled as "Debug" type instead of "release" and all of a sudden my modified ISR works, I do get to see single CS1 and CS4 signals at the appropriate time.

So, that begs the question: why is there a difference between "debug" and "release" ?

Just tried something else: replaced the single readings by the 900 sample eDMA transfers again and it works as well, in contrast to the single reads both in "debug" and "release" mode ??

Re: software triggered eDMA does not start

Posted: Fri Dec 13, 2013 2:45 pm
by dciliske
Can you try clarifying that last statement? I'm not sure whether or not it suddenly works with the eDMA engine. For your test where the debug version works, it's possible that compiler optimized away the calls due to not using the variable to do anything. Compiling in debug turns off all optimization. Try declaring 'test' as a 'volatile DWORD' instead.

If it does work now, then the issue was you had two chip selects (CS0 and CS1) mapped to the same memory region, leading to CS0 'winning' for the address.

-Dan

Re: software triggered eDMA does not start

Posted: Sun Dec 15, 2013 11:23 pm
by fd9750
Hi Dan,

You are probably right about the code being "optimised" away, it would certainly explain things.

The overlap with CS0 was definitely the root cause of the problem.
The processor's reference manual, logically, does not mention CS0 being used on the netburner board and I did not find it anywhere in the netburner documentation. I stumbled onto it because of the example in the reference manual on how to set up CS0 for a 32megabyte range.
As CS0 is not available on the board I thought that CS0 could very well be used and configured already and it is set up for a 32megabyte range.

Oh well, one more problem solved. On to the next one.

Re: software triggered eDMA does not start

Posted: Mon Dec 16, 2013 7:59 am
by pbreed
Anytime a variable, array etc... is changed by something other than the current task, ie DMA hardware or an interrupt or another task it must be declared volatile or the compiler will not see changes in the value.

If it works in debug but not relealse its probably a volatile problem

Re: software triggered eDMA does not start

Posted: Mon Dec 16, 2013 9:09 am
by rnixon
Any processor with external flash memory typically needs a default chip select to boot, and that will normally be the first one. In this case the board actually boots from spi flash, so this isn't an exact match, but it does still make sense for the system to assign the first chip select to the flash.

Re: software triggered eDMA does not start

Posted: Mon Dec 16, 2013 10:07 am
by pbreed
I believe the nano CS0 setup was a fix for the null pointer optimization hang/delay.....
(I could be wrong this is from memory)

Paul