DMA Hardware Trigger Latency

[ibrahim_youssef_pcsn]

Hello,

I am using an LPC55S16 MCU, and I had a question about the expected latency between a PINT or SCT0 DMA trigger and transaction completion. I could not find references to these timings in the datasheet, but perhaps I have overlooked something? I have elaborated on my scenario below.

Configuration:

The behavior I'm trying to achieve is pretty simple; I am trying to trigger a memory transfer from GPIO->PIN[0] to a buffer in RAM. This is done to read digital output of some custom hardware that outputs over 8 bits in parallel.

I want this transfer to be triggered on each rising edge of a 25MHz input clock signal. To achieve this, I have configured SCT0 to trigger a DMA transfer on each rising edge of the input signal. I have the DMA channel configured to burst mode, with a burst power of 0 (i.e. one transaction per burst), to ensure that only one DMA transaction occurs per rising edge. My MCU is configured to operate at the rated maximum clock frequency of 150MHz.

Problem:

When this input signal is driven at lower frequencies (below approx 8MHz), the MCU behaves exactly as desired. The problem arises when I try to increase beyond this. At higher frequencies, I observe that start missing data. It seemed to me as though the MCU is unable to perform triggered DMA transactions at this rate.

To test this theory, I conducted an experiment where I used HW triggered DMA in this exact configuration to toggle a GPIO, instead of using it to read the GPIO port into a RAM buffer. When I did this, it appeared to me that the latency between a hardware trigger and the subsequent transaction completing is around 70-90ns. This is illustrated via the attached photo. The lower signal (TRIGGER SIGNAL) is the input signal, which is driven at 6.25MHz in this experiment, and MCU OUTPUT is the DMA-driven GPIO toggle. I measured a minimum latency of 70ns between the rising edge and the subsequent GPIO toggle.

Is that 70-90ns of latency between SCT0 trigger and DMA completion to be expected, or is there perhaps something that I have configured incorrectly?

Any help or insights you could provide would be greatly appreciated!

[HangZhang]

Hi @ibrahim_youssef_pcsn 

Can you try to reduce the latency?

1. Increase DMA Priority: If you have multiple DMA channels active, ensure that the DMA channel handling your GPIO-to-RAM transfer is set to the highest priority.
2. Use a Faster Clock for SCT0: Ensure that SCT0 is running at the maximum possible clock frequency to reduce the latency in detecting edges and triggering the DMA.

BR

Hang

[ibrahim_youssef_pcsn]

Hello Hang,

Thanks for the feedback!

1. The DMA channel I am using is indeed set at the highest priority. In fact, no other DMA channels are currently being used by this DMA controller (I have currently tested with DMA controller 0).

2. The MCU is being driven by the PLL output, configured to generate a 150MHz clock. This configuration has been confirmed as correct by measuring CLKOUT. The SYSCON->SCTCLKSEL register has been set to a value of 0x01, which should indeed be configuring the SCT0 peripheral clock source as the PLL0 clock.

Despite this, the delay I see between an SCT event and the corresponding DMA-driven GPIO toggle, is approximately 90ns (see measurement capture attached). Perhaps I might be making a mistake in my configuration, in which case I'd be happy to share a minimal reproducer for review. I am also curious if the time between DMA trigger event and transaction completion has been characterized?

Thanks a lot for your help!
Ibrahim Youssef

[HangZhang]

Hi @ibrahim_youssef_pcsn 

I think that it’s possible that this latency is inherent to the MCU architecture and not just a result of misconfiguration.

Even though you’ve configured everything optimally, a few inherent factors could contribute to the latency you’re observing:

For example, Trigger Propagation Time: The time it takes for the rising edge to be detected by SCT0 and for the corresponding DMA request to be generated.

BR

Hang

[ibrahim_youssef_pcsn]

Hello Hang,

This has indeed been my suspicion for a few weeks now. Is this something that has been characterized at NXP by any chance? I'd love to understand a bit more what kinds of latencies exist, as well as how consistent that latency might be across time.

I've observed variations from 70ns to around 90ns in the experiment that I shared previously in this thread. Is this consistent with chip characterization that has been performed internally at NXP? Any details regarding average propagation delays + variances you can point me to would be a huge help to me as I solidify my design with the LPC55S16.

Continued thanks!

Ibrahim