i.MX RT Crossover MCUsのトピックRT685 CTimer0 callBack delayed

RT685 CTimer0 callBack delayed

katte82 — Wed, 03 Dec 2025 10:55:16 GMT

I modified the mimxrt685audevk_lpadc_dma_cm33 example from SDK 25.9 for MIMXRT685-AUD-EVK to create this chain:
CTIMER0 -> ADC -> DAC -> PingPongBuffer in RAM.
CTIMER0: 32kHz; ToggleBit on Match_CH_3
ADC0: Start on Trigger 5; Create interrupt for DMA every 16 samples (FIFO watermark = 15)
DMA0: PingPong; Start on Hardware trigger 24

I added Set/Clear pins to the callbacks for debugging.

From the pin log, it appears that the CTimer0 callback is delayed when the DMA is triggered, even though the DMA is executed at a time that does not overlap with the CTimer timing.

Can anyone tell me why this happens?

Re: RT685 CTimer0 callBack delayed

mayliu1 — Thu, 04 Dec 2025 07:04:23 GMT

Hi @katte82 ,

Thank you so much for your interest in our products and for using our community.

I suggest double checking the following points:

1：Set the NVIC priorities and try to assign a higher priority to CTIMER0 than DMA and ADC, then test again.

2：Verify that the transfer type is set to kDMA_PeripheralToMemory.

mayliu1_0-1764831075550.png

Best Regards

MayLiu

Re: RT685 CTimer0 callBack delayed

katte82 — Thu, 04 Dec 2025 08:03:19 GMT

1) Setting the priority solves the problem. But I don't understand why it's necessary. In theory, the hardware has all the time it needs to handle the DMA callback.
2) I've tried many times, but if I switch to PeripheralToMemory, strange things happen and nothing works. The ADC still remain in interrupt and DMA never calls the callback. Maybe PeripheralToMemory don't handle correctly the watermark set to 15? Could using DMA in MemoryToMemory be a problem?

Thanks in advance.
Regards.

Re: RT685 CTimer0 callBack delayed

mayliu1 — Fri, 05 Dec 2025 10:39:24 GMT

Hi @katte82 ,

Thanks for your updated information.

A1: It is necessary, because the callback runs in the interrupt service routine (ISR), and NVIC priority decides who runs first. DMA/ADC ISR preempted CTIMER0, so the CTIMER0 callback was delayed.

A2: I suggest you can refer to SDK demo "evkmimxrt685_lpadc_dma_cm33"

Best Regards

MayLiu

Re: RT685 CTimer0 callBack delayed

katte82 — Wed, 10 Dec 2025 09:17:57 GMT

Thanks for the hint.
1) I continue not understand why the ctimer interrupt need a greater priority. There are many "free usec" after DMA callback.

2) In example, the data flow is handled by the software.
I'm trying to configure the cpu to do all the hard work by itself.

Thanks and Best regards.

Re: RT685 CTimer0 callBack delayed

mayliu1 — Thu, 11 Dec 2025 08:54:54 GMT

I think if the ctimer has a lower priority, its execution could be delayed, affecting timing precision and real time performance.