topic CTIMER DMA requests/triggers, pacing the transfers in LPC Microcontrollers

CTIMER DMA requests/triggers, pacing the transfers

hemanth1 — Thu, 25 Jun 2020 03:23:33 GMT

I got a DMA0 channel to successfully trigger from a CTIMER0 trigger source. The setup is as follows (using a custom board, not EVAL):

1. CTIMER0 with match1, with a capture input as source (10 MHz clock). Also successfully outputs to an External match output as a 5 MHz square wave by matching for 1 and resetting after.

ctimer_config_t config;
CTIMER_GetDefaultConfig(&config);
config.mode = kCTIMER_IncreaseOnRiseEdge;
config.input = kCTIMER_Capture_0;
config.prescale = 1;
CTIMER_Init(CTIMER0, &config);
ctimer_match_config_t matchConfig;
matchConfig.enableCounterReset = true;
matchConfig.enableCounterStop = false;
matchConfig.matchValue = 1;
matchConfig.outControl = kCTIMER_Output_Toggle;
matchConfig.outPinInitState = true;
matchConfig.enableInterrupt = false;
CTIMER_SetupMatch(CTIMER0, kCTIMER_Match_1, &matchConfig);
CTIMER_StartTimer(CTIMER0);

2. INPUTMUX configured to connect CTIMER0's Match1 trigger to DMA0's channel 0.

INPUTMUX_AttachSignal(INPUTMUX, 0, kINPUTMUX_Ctimer0M1ToDma0);

3. Setup DMA0's channel 0 with the following config:

dma_channel_trigger_t channelTrigger;
channelTrigger.type = kDMA_HighLevelTrigger; //or kDMA_RisingEdgeTrigger
channelTrigger.burst = kDMA_LevelBurstTransfer; //or kDMA_EdgeBurstTransfer1
channelTrigger.wrap = kDMA_NoWrap;
dma_channel_config_t transferConfig;
DMA_Init(DMA0);
DMA_CreateHandle(&g_DMA_Handle, DMA0, 0);
DMA_EnableChannel(DMA0, 0);
DMA_SetCallback(&g_DMA_Handle, DMA_Callback, NULL);
DMA_PrepareChannelTransfer(&transferConfig, s_srcBuffer, (uint32_t*)&GPIO->MPIN[0],
   DMA_CHANNEL_XFER(false, false, true, false, kDMA_Transfer32BitWidth,
   kDMA_AddressInterleave1xWidth, kDMA_AddressInterleave0xWidth, 4000),
   kDMA_MemoryToMemory, &channelTrigger, NULL);
DMA_SubmitChannelTransfer(&g_DMA_Handle, &transferConfig);
DMA_StartTransfer(&g_DMA_Handle);

The DMA is supposed to push parallel data from memory to the GPIO's MPIN port, with the register updated once every CTIMER/match1 trigger. But the config that worked seems to go through all the transfers (1000) without pausing between triggers. Increasing the matchValue or slowing the input clock seems to have no effect (the output square wave is behaving as expected).

Some observations/questions:

Q. kDMA_RisingEdgeTrigger doesn't seem to work at all for this type of hardware trigger (CTIMER's). The DMA transfer never starts. Also tried:

CTIMER0->IR = 0xFF;

to clear any active DMA request (UM mentions it clears both interrupts and DMA requests) to create a new rising edge but nothing. Any reason why? kDMA_LowLevelTrigger too doesn't working so I am assuming the DMA trigger is never going low? Is there some bit to be set to make the DMA controller clear the request after every trigger?

Q. Setting PERIPHREQEN (with kDMA_MemoryToPeripheral) too stops it from triggering. This might not be relevant as we aren't interfacing with any peripheral and is simply a MemoryToMemory transfer. But UM mentions:

"Once triggered, transfer on a channel will be paced by DMA requests if the
PERIPHREQEN bit in the related CFG register is set. Otherwise, the transfer will proceed
at full speed."

while the DMA transfer config mentions the pacing can be controlled by the hardware triggers using trigger burst settings. Are the trigger burst settings referring to DMA triggers or DMA requests as mentioned under peripherals?

Q. CTIMER's section in the UM mentions DMA requests while the INPUTMUX for DMA mentions them to be DMA triggers, not requests. The wording is really confusing at times. This makes it slightly clear:

Up to two match registers can be used to generate DMA requests. These are
connected to DMA trigger inputs on this device.

But it is still confusing as something like the SPI interface mentions that they generate DMA requests AND are connected to DMA controllers requests "port".

Q. For any general application requiring memory-to-memory DMA transfer, what other method do I have to pace the transfers to an internal counter? Are requests the only way to pace DMA transfers? Is there any advantage to using SCTimers rather CTIMERS for this?

EDIT:

It seems to pace the requests properly when I use:

channelTrigger.type = kDMA_HighLevelTrigger;
channelTrigger.burst = kDMA_SingleTransfer;
channelTrigger.wrap = kDMA_NoWrap;

So kDMA_LevelBurstTransfer was the problem before. The clocking seems to be perfect now, but it still doesn't work with EdgeTrigger. Now to make a gapless/callback-free ping-pong transfer for this...

Re: CTIMER DMA requests/triggers, pacing the transfers

diego_charles — Sun, 05 Jul 2020 05:58:31 GMT

Hi Hemanth :smileyhappy:,

kDMA_RisingEdgeTrigger doesn't seem to work at all for this type of hardware trigger (CTIMER's). The DMA transfer never starts. Also tried:
CTIMER0->IR = 0xFF;
to clear any active DMA request (UM mentions it clears both interrupts and DMA requests) to create a new rising edge but nothing. Any reason why? kDMA_LowLevelTrigger too doesn't working so I am assuming the DMA trigger is never going low? Is there some bit to be set to make the DMA controller clear the request after every trigger?

I have tried to replicate your issue. However the high or low level triggers worked with my CTIMER and DMA configurations. A single CTMER match triggered a DMA transfer at full speed.

I attached my code just as a reference, I can not guarantee it will also work for you.

Setting PERIPHREQEN (with kDMA_MemoryToPeripheral) too stops it from triggering. This might not be relevant as we aren't interfacing with any peripheral and is simply a MemoryToMemory transfer. But UM mentions:
"Once triggered, transfer on a channel will be paced by DMA requests if the
PERIPHREQEN bit in the related CFG register is set. Otherwise, the transfer will proceed
at full speed."
while the DMA transfer config mentions the pacing can be controlled by the hardware triggers using trigger burst settings. Are the trigger burst settings referring to DMA triggers or DMA requests as mentioned under peripherals?

Since the CTIMER match is connected to the DMA channel interrupt input, After doing tests, I confirm your comments. After setting PERIPHREQEN, the DMA channel will wait a signal on its request input, if don´t arrives the trasnfer will not start.

The TRIGBURST bit on the CFG register of DMA channels, refers to the DMA hardware triggers configured on level trigger mode.

CTIMER's section in the UM mentions DMA requests while the INPUTMUX for DMA mentions them to be DMA triggers, not requests. The wording is really confusing at times. This makes it slightly clear:
Up to two match registers can be used to generate DMA requests. These are
connected to DMA trigger inputs on this device.

But it is still confusing as something like the SPI interface mentions that they generate DMA requests AND are connected to DMA controllers requests "port".

Taking into account that each DMA channel have interrupt and request inputs.

No matter if the CTIMER/SCtimer match request are mentioned as a DMA requests , they are connected to the DMA channels interrupt input using INPUTMUX registers.

For any general application requiring memory-to-memory DMA transfer, what other method do I have to pace the transfers to an internal counter?

As you may already considered, you could enable the interrupt for a TIMER and Configure the DMA with SW trigger. Then in the Timer ISR trigger a DMA transfer. However using the timer directly trigger by hardware seems more efficient.

Are requests the only way to pace DMA transfers? Is there any advantage to using SCTimers rather CTIMERS for this?

Well, since they can help you to trigger DMA transfers, we would have to check which characteristics of both can be worthy for your application.

From the DMA point of view I am thinking on that the CTIMER has more trigger options ( 9 ) than the SCTIMER (2 ) as seen in the register DMA0_ITRIG_INMUX register.

If this helps, you could let me know.

Also, I apologize for the delay on my response.

Regards,

Diego.

Re: CTIMER DMA requests/triggers, pacing the transfers

nick_ijzendoorn — Mon, 27 Jul 2020 16:22:54 GMT

Is it possible to output a PWM wave-form via DMA to a CTIMER->MR[] register? Where the DMA transfer is triggered by a CTIMER Match channel?

I Have the same problem Hemanth M is having. Where the complete transfer is done full speed even though I use kDMA_SingleTransfer as burst type.

ctimer_match_config_t matchConfigDMA;
matchConfigDMA.enableCounterReset = false;
matchConfigDMA.enableCounterStop = false;
matchConfigDMA.matchValue = 0;
matchConfigDMA.outControl = kCTIMER_Output_Toggle;
matchConfigDMA.outPinInitState = false;
matchConfigDMA.enableInterrupt = false;
// init first timer
ctimer_config_t config;
CTIMER_GetDefaultConfig(&config);
timerClock = CTIMERA_CLK_FREQ / (config.prescale + 1);
CTIMER_Init(CTIMER2, &config);
CTIMER_SetupPwm(CTIMER2, kCTIMER_Match_0, sineLookupTable[counta], PWM_FREQUENCY, timerClock, false);
CTIMER_SetupMatch(CTIMER2, kCTIMER_Match_1, &matchConfigDMA);
//** Attach CTimer Match request to DMA0**//
INPUTMUX_Init(INPUTMUX);
INPUTMUX_AttachSignal(INPUTMUX, 0, kINPUTMUX_Ctimer2M1ToDma0);
DMA_Init(DMA0);
DMA_CreateHandle(&g_DMA_Handle, DMA0, 0);
DMA_EnableChannel(DMA0, 0);
DMA_SetCallback(&g_DMA_Handle, DMA_Callback, NULL);

dma_channel_trigger_t channelTrigger;
channelTrigger.burst = kDMA_SingleTransfer ;
/** select channel trigger **/
channelTrigger.type = kDMA_HighLevelTrigger ; /// a word transfer each CMTIMER match trigger
//** A complete transfer when a sigle trigger configuration */
//channelTrigger.type = kDMA_NoTrigger ;
//channelTrigger.type = kDMA_LowLevelTrigger;
//channelTrigger.type = kDMA_FallingEdgeTrigger;
//channelTrigger.type = kDMA_RisingEdgeTrigger;
channelTrigger.wrap = kDMA_NoWrap; // Here I would like to enable SrcWrapping as well, when I do this however it starts incrementing the dst address... I'm assuming SrcWrapping makes the dma transfer contiguous.
dma_channel_config_t transferConfig;

DMA_PrepareChannelTransfer(&transferConfig, dmaOutputTableA, &CTIMER2->MR[0],
DMA_CHANNEL_XFER(false, false, true, false, 2, kDMA_AddressInterleave1xWidth, kDMA_AddressInterleave0xWidth, (SINESTEPS*2)),
kDMA_MemoryToMemory, &channelTrigger, NULL);
DMA_SubmitChannelTransfer(&g_DMA_Handle, &transferConfig);
DMA_StartTransfer(&g_DMA_Handle);
// create the DMA buffers
for (int idx = 0; idx < SINESTEPS; ++idx)
{
dmaOutputTableA[idx] = (CTIMER2->MR[kCTIMER_Match_3] * (uint32_t)sineLookupTable[idx]) / 100U;
}
CTIMER_StartTimer(CTIMER2);

Re: CTIMER DMA requests/triggers, pacing the transfers

ie709758 — Sun, 02 Aug 2020 22:27:20 GMT

Hi Nick,

To debug the issue , I could recommend you to :

Enable Ctimer Match interrupts and place a breakpoint into the CTimer Match Interrupt handler. That way you can check the value that is being writtten on the destination register on each CTIMER match.
Try to not configure CTimer2 Match 0 for PWM (avoid calling CTIMER_SetupPwm ), and verify that Ctimer Match 1 could generate single word DMA transfer on each match (using kDMA_HighLevelTrigger and kDMA_SingleTransfer ) .
Check your CTimer2 Match1 configuration . For example, you could try to change .matchValue from 0 to CTIMER_CLK_FREQ/2 and .enableCounterReset from FALSE to TRUE.

As far I understand your application, it seems feasible from my point of view. However, I do not have a similar example to share.

Regards,

Diego

Re: CTIMER DMA requests/triggers, pacing the transfers

nick_ijzendoorn — Mon, 24 Aug 2020 11:55:39 GMT

Thanks for your reply, I made the wrong assumption the problem was that I tried to do 16bit word transfers instead of 32bit.

For people who are interrested I included my main file which is now working.

The CTIMERs must be clocked at 150Mhz for the frequency calculation to go correctly.

For testing I connected a low pass RC filter to the PWM output pins.

Enabling the macro's USE_16BIT and/or USE_SRC_WRAPPING will break it though.

Re: CTIMER DMA requests/triggers, pacing the transfers

xs_graziano — Wed, 11 Jun 2025 15:24:15 GMT

Hello, I'm experiencing a similar problem. I've deeply read the Diego answer, but I need to deep in.

As far I've understood every DMA channel has Requests and Triggers. Requests come from high speed peripherals, Triggers from 'events generator' peripherals. In the hypothesis of a Hardware Trigger, the sequence is the following (after the channel is initialized):

1 - The trigger enable the channel;

2 - Any change in the request enable a transfer (that can be configured as burst or single).

If all this is true, is the request flow, coming from the request wire, that define the pace of the transfer.

Is that all right?

So it's not possible, for instance, to transfer data from memory to a peripheral using a timer to set the pace of the transfer, but is the request itself that will set the pace based on the needs.

I've tried to configure the DMA to transfer one byte at the time from memory to a peripheral, using a ctimer match (Burst enabled, size 1 byte or burst disabled, single shot). If I enable and than disable the trigger from the running timer, on disable (?) I have just one transfer, and then everything stop.

Enabling the peripheral request and with single transfer having the channel peripheral with the DMA Request enabled, I got a Trigger set for the channel (in the channel status flag), one transfer on the trigger enable change, and then not anymore.

I'm trying to perform a move from memory to a gpio port at a selected speed, synchronized with the falling front of he clock, but I've not found any way to do it using the DMA.

There is something I'm missing?

Many thanks for any contribution