uDMA scatter gather looping

Hi Amit

Thanks for the quick reply.

It is correct that i would like the timer to only cause one interrupt. After initialization i get a continuous burst of rising edges that each should cause a dma transfer reloading the timer and preventing it from running out. This however only seems to happen once.

Somehow the looping of the sg dma does not work. I however find it hard to exactly pinpoint the issue.  Does this clarify my problem?  

The signal on GPIO E4 is an external input to my board. It is either low, or consitsts of variable length pulses with frequencies in the range of 20kHz to 2Mhz.

To properly interpret my adc signals, i need to know the beginning and end of such pulse bursts.

Detecting the rising edge is easy, what i am struggling with is detecting the falling edge i.e. the absence of a pulse. By loading the timer on every rising edge to a value equivalent to 50us i can be sure that when the timer runs out the pulses on the input pin must have stopped.

I tried this completely interrupt based and it works for moderate pulse frequencies, but for higher pulse frequencies i starve my low priority tasks due to the interrupt handling taking up too much time. That's why I'm trying to use a continuously running dma.

Hi Amit

I have continued doing some more debugging work and have made some progress:

By changing the task list to

static tDMAControlTable uDMAsg_TaskList[] =
{
	
	//
	// Task 2: copy source buffer to timer interval load
	//
	uDMATaskStructEntry(1,
						UDMA_SIZE_32,
						UDMA_SRC_INC_NONE,
						&GPTM_ILR,
						UDMA_DST_INC_NONE,
						(void*)(TIMER5_BASE + TIMER_O_TAILR),
						UDMA_ARB_1,
						UDMA_MODE_PER_SCATTER_GATHER
				),
	

	//
	// Task 4: loop
	//
	uDMATaskStructEntry(
	                4,
	                UDMA_SIZE_32,
	                UDMA_SRC_INC_32,
	                &uDMAsg_LoopTask,
	                UDMA_DST_INC_32,
	                &(B134_332_DMAControlTable[UDMA_CH14_GPIOE & 0x1f]),
	                UDMA_ARB_4,
	                UDMA_MODE_PER_SCATTER_GATHER
	        )
};

(both tasks are now UDMA_MODE_PER_SCATTER_GATHER) 

I have now been able to observe the uDMA channel reinitializing itself successfully in debugging mode. So that part of my question seems to be solved. 

The cause for the Timer not reloading seems to be that the Timer peripheral does not seem to realize that the TIMER_TAILR register is written. Also changing the destination to TIMER_TAV does not seem to help. In the next debugging steps, the timer just continues counting down. 

Similar to using the uDMA to e.g. writhe a ssi peripheral output buffer register, i have assumed that i could also use the uDMA to write the TIMER_TAV or TIMER_TAILR register. Is this not the case? 

How can I use a DMA transfer to load a given value into my timer while its counting down?

Thanks a lot in advance for your help!

Hi Amit

I noticed this section in the Datasheet and therefore ensured that the TAILD bit is clear and the counter is counting down. Still i did not observe the timer being reloaded, even though I am not absolutely sure it didn't. I ended up writing directly to the TIMER_O_TAV register which is working for me. 
So most of my initial questions are solved: I can now reload the timer and the scatter gather dma indefinitely reloads itself. 

Thank you very much for assisting me in getting there!

Here is the current state of my code for anyone interested: 

uint8_t GPTMCTL_disable= 0x00;
uint8_t GPTMCTL_enable = TIMER_CTL_TAEN;
uint32_t GPTM_ILR= TIMER_DMA_LOAD_PEROID;

// Temporary storage for the first uDMA primary task, for scatter-gather looping
static tDMAControlTable uDMAsg_LoopTask;

static tDMAControlTable uDMAsg_TaskList[] =
{

	//
	// Task 1: copy source buffer to timer interval load
	//
	uDMATaskStructEntry(1,
						UDMA_SIZE_32,
						UDMA_SRC_INC_NONE,
						&GPTM_ILR,
						UDMA_DST_INC_NONE,
						(void*)(TIMER5_BASE + TIMER_O_TAV),
						UDMA_ARB_1,
						UDMA_MODE_PER_SCATTER_GATHER
				),


	//
	// Task 2: loop
	//
	uDMATaskStructEntry(
	                4,
	                UDMA_SIZE_32,
	                UDMA_SRC_INC_32,
	                &uDMAsg_LoopTask,
	                UDMA_DST_INC_32,
	                &(B134_332_DMAControlTable[UDMA_CH14_GPIOE & 0x1f]),
	                UDMA_ARB_4,
	                UDMA_MODE_MEM_SCATTER_GATHER
	        )
};

void initMLSFallingEdgeDetection(){
	// initialize dma channel

	uDMAChannelDisable(UDMA_CH14_GPIOE & 0xffff); // Ensure channel is disabled before modifying register
	uDMAChannelAssign(UDMA_CH14_GPIOE);
	uDMAChannelAttributeDisable((UDMA_CH14_GPIOE & 0xffff)|UDMA_PRI_SELECT,UDMA_ATTR_ALL);
	uDMAChannelAttributeDisable((UDMA_CH14_GPIOE & 0xffff)|UDMA_ALT_SELECT,UDMA_ATTR_ALL);
	uDMAChannelAttributeEnable((UDMA_CH14_GPIOE & 0xffff)|UDMA_PRI_SELECT,UDMA_ATTR_USEBURST);
	uDMAChannelAttributeEnable((UDMA_CH14_GPIOE & 0xffff)|UDMA_ALT_SELECT,UDMA_ATTR_USEBURST);


	uDMAChannelScatterGatherSet(UDMA_CH14_GPIOE & 0xffff, 2, uDMAsg_TaskList, true);

	// Copy the primary control structure from the uDMA controltable
	uDMAsg_LoopTask.pvDstEndAddr = B134_332_DMAControlTable[UDMA_CH14_GPIOE & 0xffff].pvDstEndAddr;
	uDMAsg_LoopTask.pvSrcEndAddr = B134_332_DMAControlTable[UDMA_CH14_GPIOE & 0xffff].pvSrcEndAddr;
	uDMAsg_LoopTask.ui32Control = B134_332_DMAControlTable[UDMA_CH14_GPIOE & 0xffff].ui32Control;
	uDMAsg_LoopTask.ui32Spare = B134_332_DMAControlTable[UDMA_CH14_GPIOE & 0xffff].ui32Spare;


}

The only issue remaining is that all my RTOS tasks cease functioning while DMA Channel 14 is enabled. Here is what I observe on my logic analyzer (GPIO's being toggled upon entry and exit of any task, timer ISR function, and GPIO ISR function, as well as an indication of the start and end of bursts i detect on the input)

Here is the code relevant for the burst detection:

void initMainLaserSuppression() {
	if(0==GPIO_read(MLS_BOARD_GPIO)){
		//pin is actively pulled down
		initMLSFallingEdgeDetection();
		GPIO_enableInt(MLS_BOARD_GPIO,GPIO_INT_RISING);
	}
}




void ISR_GPIOPortE(){
	GPIOIntClear(MLS_GPIO_PORT,MLS_GPIO_INT_FLAG);
	g_mlsDirtyFlag=1;
        Timer_start(g_mlsTimer);
	GPIODMATriggerEnable(MLS_GPIO_PORT, MLS_GPIO_PIN);
	uDMAChannelEnable(UDMA_CH14_GPIOE & 0xffff);
}

void ISR_Timer5(){

	g_mlsDirtyFlag=1;
	uDMAChannelDisable(UDMA_CH14_GPIOE & 0xffff);
	GPIODMATriggerDisable(MLS_GPIO_PORT,MLS_GPIO_PIN);
	GPIOIntClear(MLS_GPIO_PORT,MLS_GPIO_INT_FLAG);

}

The tasks don't get executet as long as DMA channel 14 is enabled, not depending on the DMA actually getting triggered by the GPIO peripheral or not. If I don't disable the DMA channel in ISR_TIMER5 , the tasks never get executed again.

Do you know by what this could be caused? Can you point me in any direction where to continue debugging this issue? Any help is greatly appreciated!

Hi Amit

I am sorry, but I don't quite understand your reply. 

I set up the scatter gather dma to loop itself (i.e. copy the initial primary control table entry back to its original location in the last task of my task list.) Therefore I would have thought the DMA will never finish its task. This is also what I observe. The DMA performs its task whenever it is enabled, without ever re-initializing it. 

The issue I have is that any tasks configured in the context of the TI-RTOS or more specifically in the SYS/BIOS cease to be executed while the DMA is running. I fail to see the connection between the DMA and these tasks getting triggered for execution. I also can not imagine that these tasks get starved during that time, since I don't change the processing load at all. 

Here is the example code of such a task:

/*********************************************************************************************************************//**
 * @brief task used to read the temperature.
 *
 * collectTemperature() is doing the reading/processing.
 *
 * @param arg0 argument 0
 * @param arg1 argument 1
 *************************************************************************************************************************/
Void taskTemperatureFxn(UArg arg0, UArg arg1)
{
    while(runtime)
    {

	RegisterGPIOToToogle(START, TOOGLE_ALL_TASKS);
        collectTemperature();
        UpdateHeater();

        RegisterGPIOToToogle(STOP, TOOGLE_TEMPERATURE);

    	Task_sleep(100);
    	
    }
}

Configured as follows:

One more thing: 

For debugging purposes, I registered an idle function to be executed when all tasks are blocked:

Idle.idleFxns[0] = "&_c_idle00";
Task.allBlockedFunc = Idle.run

The Idle function does get executed while the DMA channel is enabled:

It therefore seems that the DMA channel being active is somehow inhibiting the tasks from getting unblocked. I have however no clue how these two could be connected. 

"input signal" toggles in that screenshot with 25kHz. In the final application it can be anything between 20kHz and ~500kHz (edit: preferably it will work up to 2Mhz).

Hi Amit

I unfortunately can't find a DMAIME bit in the GPIOIM Register described in the TM4C123 Datasheet:

Am I looking in ther wrong place?

Hi Amit

I checked wheter the UDMA_CHIS bit is set and this does not seem to be the case:

I don't think i clear it anywhere. Does the RTOS clear it somewhere without my knowledge?

Hi Amit

I tried disabling the interrupt in the NVIC when enabling the DMA channel and enabling it again after disabling the dma channel:

void ISR_GPIOPortE(){
	GPIOIntClear(MLS_GPIO_PORT,MLS_GPIO_INT_FLAG);
        IntDisable(INT_GPIOE);
	g_mlsDirtyFlag=1;
        Timer_start(g_mlsTimer);
	GPIODMATriggerEnable(MLS_GPIO_PORT, MLS_GPIO_PIN);
	uDMAChannelEnable(UDMA_CH14_GPIOE & 0xffff);
}

void ISR_Timer5(){

	g_mlsDirtyFlag=1;
	uDMAChannelDisable(UDMA_CH14_GPIOE & 0xffff);
	GPIODMATriggerDisable(MLS_GPIO_PORT,MLS_GPIO_PIN);
	GPIOIntClear(MLS_GPIO_PORT,MLS_GPIO_INT_FLAG);
        IntEnable(INT_GPIOE);

}

I still observe the same behaviour that the tasks do not get executed:

Hi Amit

As you suggested, I posted my question in the RTOS forum.

I however made an interesting observation, that I hope you might be able to explain or that would give you another idea, what further actions I could take:

Regards,

Roman

I was aware of this although i thought the "routing"of the interrupt was controlled by enabling or disabling the DMACTL register bits in the gpio peripheral. From your answer i understand that this is not the case?

Furthermore i can't explain why the Timer2 interrupts would stop getting serviced. This is also the more worrying issue to me. I can live without gpio port e interrupts, but not without those from timer 2.

Hi Amit

I understand that if I use the GPIOPortE Peripheral to actively generate DMA requests, its interrupts will not reach the NVIC. However there are a number of places where I can mask/disable these DMA requests or the DMA transfers and the datasheet is not very clear in the effect they have on this behaviour:

In the DMA:
DMAREQMASKSET
DMAENASET
DMACHASGN 

Or in the Peripheral:
GPIODMACTL

Which of those actually determine if regular (non error) peripheral interrupts will reach the NVIC? 

Regards,

Roman

Hi Amit

I would appreciate it very much if you could provide me with that information. Thanks a lot in advance!

In the meantime I have spent some more time debugging and tried forcing RTOS to use Timer3 instead of Timer2 for its task scheduling by occuping Timer2 with a dummy.

The result is positive in the way that it gives me a workaround for the time being:

As you can see, the tasks keep getting executed even while the dma channel 14 is active.

My only explanation for this behaviour is that just because Timer 2 could be configured to trigger DMA Channel 14 transfers, its interrupts are blocked from reaching the NVIC whenever DMA channel 14 is enabled (with GPIOE assigned to it). 

Is this conclusion correct? And is that supposed to be this way?

Regards

Roman

Hi Amit

Thanks for confirming that.

Since to me that seems like a serious limitation complicating the use of the uDMA a lot, I would like to ask you if it were possible that you could quickly summarize the expected behaviour of an enabled DMA channel (e.g. 14) on interrupts of the assigned and the potentially assignable peripherals?

I was not able to find any indication of such cross implications in the TM4C123 datasheet. 

Regards

Roman

I am familiar with that section. It states the following:

When μDMA is enabled for a peripheral, the μDMA controller stops the normal transfer interrupts for a peripheral from reaching the interrupt controller (the interrupts are still reported in the peripheral's interrupt registers).

This however contradicts what I observe: When I enable uDMA for a peripheral (GPIO E), the uDMA controller seems to stop normal interrupts of another peripheral (TIMER 2A).  

Hi Amit

I agree, that could be the reason. But is this intentional?

Do I have to expect this behaviour on all channels concerning all peripherals or is this an exception?

Hi Amit

Were you able to get any additional information on this issue?

Regards,

Roman