ADC conversion is delayed

[aditya_barve]

Hello, 

I have PWM of 65kHz, on every falling of the pwm an interrupt is generated. Adc group 1 with 3 channels is configured, whose conversion is started from the PWM interrupt. 

I have set GPIO pin to high in the PWM ISR before starting the conversion, and set it too low at the end of conversion. 

The ADC conversion time observed is around 4.38us, having said that sometimes the adc conversion takes upto 11us. 

What could be the reason for such an abrupt delay in the adc conversion timings ?

Is there anything wrong here ?

Thank you,

Aditya

[PetrS]

Hi,

from the scope screenshot, it appears that the ADC start is also delayed sometimes.
A possible reason could be the interrupt priorities of the enabled interrupts.
If an interrupt with a higher priority is being serviced, it can delay the execution of the lower‑priority interrupt, thus the ADC start or ADC end of conversion notification can be delayed.

If multiple interrupts are used in your system, check their priority configuration.

A recommended solution is to use hardware triggering via the BCTU, along with reading ADC results from the BCTU FIFO using DMA.
This can avoid interrupt‑based triggering and eliminates the observed timing jitter.

BR, Petr

[aditya_barve]

Hi PetrS,

As rightly mentioned, this happens due to multiple interrrupts. In this case as I am using a OS timing event driven by a PIT interrupt, the processing of this interrupt causes the delay. 

If I set the PIT interrupt as nested ISR, this behavior is improved with lesser delay but not solved. 

I am using MCAL S32K3_RTD_3_0_0 and find that the built in irq handlers take a long time to execute (approx 24-30us) when comparted to a 65kHz PWM signal (say ADC group Conversion completion every 15us).

From the measurements I find that the existing MCAL handlers cannot be used for such a task involving fast interrupts. Is the observation on NXP's side the same ?

Also, I would like to understand the interrupt latency time and time to execute to 2 successive interrupts whose interrupt status flag is already set. Once the PIT interrupt is serviced, it takes around 10us to service the next available interrupt. What is the status/ action of the controller during these 10us ?

Thank you,

Aditya

[PetrS]

Hi,

Your observations are correct.
The delays you are seeing are caused by interrupt contention, especially with the PIT‑driven OS timing event. When the PIT interrupt is serviced, lower‑priority ISRs—including your PWM/ADC trigger logic—are delayed. Enabling nested interrupts reduces but cannot eliminate this behavior.

The execution time of the RTD (S32K3_RTD_3_0_0) interrupt handlers you measured (24–30 µs) is expected. The MCAL layers include additional software abstraction and OS hooks, which add latency. For this reason, RTD ISRs are not suitable for very fast, deterministic control loops running at 65 kHz (15 µs period).

For applications requiring precise timing, NXP recommends using hardware triggering via BCTU and reading ADC results from the BCTU FIFO. This removes the CPU and MCAL ISR latency from the sampling path and eliminates the timing jitter.

Regarding the ~10 µs gap before the next pending interrupt is serviced: this time is spent in interrupt entry/exit sequences, MCAL dispatching, OS hooks, etc. This is expected behavior under RTD with multiple active interrupts.

As an additional improvement, you may try building the project with different compiler optimization levels (e.g., -O2 or -Os). Higher optimization can reduce ISR execution time and may improve overall responsiveness, although it will not fully eliminate the fundamental latency limitations.

BR, Petr