2418319_en-US

[#1]

ADC Conversion time issue

Hello NXP Support,

I am working with an S32K312 MCU using S32 Design Studio and RTD drivers, and I am trying to understand the actual conversion timing of the SAR ADC for a single-channel normal conversion.

My setup is:

• MCU: S32K312

• Core clock: 120 MHz

• ADC functional clock: 120 MHz

• ADC mode: Normal conversion

• Number of channels: 1

• Pre-sampling: Disabled

• Sampling time: 33 ADC clock cycles

• Conversion time used in my calculation: 48 ADC clock cycles

• Hardware averaging: Disabled for this test

• End-of-chain notification/interrupt enabled

The relevant code is:

int main(void) {

Clock_Ip_Init(&Clock_Ip_aClockConfig[0]);

IntCtrl_Ip_Init(&IntCtrlConfig_0);

IntCtrl_Ip_EnableIrq(ADC0_IRQn);

Siul2_Port_Ip_Init( NUM_OF_CONFIGURED_PINS_PortContainer_0_BOARD_InitPeripherals, g_pin_mux_InitConfigArr_PortContainer_0_BOARD_InitPeripherals );

volatile Adc_Sar_Ip_StatusType status = ADC_SAR_IP_STATUS_ERROR;

status = Adc_Sar_Ip_Init(0, &AdcHwUnit_0);

status = Adc_Sar_Ip_DoCalibration(0);

Adc_Sar_Ip_EnableNotifications( 0, ADC_SAR_IP_NOTIF_FLAG_NORMAL_ENDCHAIN );

Siul2_Dio_Ip_TogglePins(PTA_L_HALF, 1U << 1U);

Adc_Sar_Ip_StartConversion( 0, ADC_SAR_IP_CONV_CHAIN_NORMAL );

while (1)

{ __asm__("nop");

}

}

void Adc_EndOfNormalChain_Callback(void)

{

Siul2_Dio_Ip_TogglePins(PTA_L_HALF, 1U << 1U);

}

I measure the time between the two GPIO transitions using a logic analyzer.

Based on the ADC timing alone, I calculated it, which gives approximately 700ns.

However, the measured GPIO pulse width is approximately 4us.

I would like to understand the following:

1. What is the correct formula for a single normal conversion when pre-sampling and hardware averaging are disabled?

2. Does the ADC calibration performed by Adc_Sar_Ip_DoCalibration() affect the timing of every subsequent ADC conversion, or does it only calculate/store calibration values during initialization?

3. Do gain correction, offset correction, internal capacitor charging, settling time, or any internal ADC processing add additional cycles to every conversion?

4. What is the exact conversion-time formula for the S32K312 SAR ADC for one channel in normal conversion mode?

5. Does the measured time between:

   • Adc_Sar_Ip_StartConversion()

   • and Adc_EndOfNormalChain_Callback()

   include significant RTD software overhead, interrupt latency, ISR processing, or callback overhead?

6. Is there a recommended method to measure only the ADC hardware conversion time, excluding RTD and interrupt overhead?

7. If possible, could you provide the expected ADC timing in clock cycles for this configuration?

My main objective is to determine whether the approximately 4 µs measurement is caused mainly by ADC hardware timing or by RTD/interrupt/software overhead.

Any help related to this ADC conversion is appreciated!!

Thank you. 

Re: ADC Conversion time issue

Hi,

The ADC conversion-time equation is provided directly in S32K3 Reference Manual, section 60.3.18 "Conversion time". For your configuration (single channel, pre-sampling disabled, hardware averaging disabled), the conversion time can be calculated using that formula and the configured ADC clock.

A few additional notes:

1. Adc_Sar_Ip_DoCalibration() does not affect the timing of subsequent conversions. Calibration is executed during initialization and the calibration values are then used by the ADC hardware.

2. The measured ~4 µs is not ADC conversion time only. Your measurement spans:

• Adc_Sar_Ip_StartConversion()
• ADC sampling and conversion
• ADC interrupt generation
• NVIC interrupt latency
• RTD ISR processing
• Callback dispatch
• GPIO toggle operations

Therefore, the measured pulse width includes both ADC hardware time and software overhead. It is expected to be noticeably larger than the conversion time calculated from the RM formula alone.

3. To measure the ADC hardware conversion time more accurately, we can recommend below

• Toggle the first GPIO immediately after Adc_Sar_Ip_StartConversion() returns. This removes most of the start-API execution time from the measured pulse.
• In the ADC interrupt handler, toggle GPIO as early as possible, before calling the configured notification callback. This separates interrupt entry from callback-dispatch overhead.
• For the lowest GPIO software overhead, temporarily use a direct SIUL2 GPIO register write instead of Siul2_Dio_Ip_TogglePins().
• Alternatively, poll the ADC end-of-chain status flag and toggle the GPIO immediately when the hardware flag becomes set. This excludes NVIC and callback overhead, although polling-loop and GPIO-write latency remain.

So, based on the information provided, the ~4 µs measurement is most likely dominated by the complete software/interrupt path rather than the ADC conversion itself.

BR, Petr