SAADC with timer CC results in inconsistent period among boards

Working on 52832, with SoftDevice S132, SDK 17.0.2

Our boards have external 32MHz crystal as the source of HFCLK.

Our application samples the ADC periodically using the NRFX_SAADC_API_V2. 

Codes look like this:

// config saadc
nrfx_saadc_adv_config_t saadc_adv_config = {
    .oversampling = NRF_SAADC_OVERSAMPLE_DISABLED,
    .burst = NRF_SAADC_BURST_DISABLED, 
    .internal_timer_cc = 1040,
    .start_on_end = false,
};
nrfx_saadc_advanced_mode_set(1,
                        NRF_SAADC_RESOLUTION_12BIT,
                        &saadc_adv_config,
                        saadc_event_handler);

// set buffer
nrfx_saadc_buffer_set(m_saadc_sample_buffer, 256);

// trigger SAADC
err_code = nrfx_saadc_mode_trigger();

As we measure the sampling period of the 256 samples (raise a GPIO pin in NRFX_SAADC_EVT_READY event, and turn it off in NRFX_SAADC_EVT_DONE, measure the interval), the period appears not consistent among several boards. We observed about 1% differences among boards.

Reading the DevZone posts saying the Softdevice will turn on and off the external crystal so wondering if this is the cause of the deviations.

Any suggestion on this issue? Our application requires an accurate sampling period and 1% difference is not likely acceptable.

Thanks!

  • Hello,

    Reading the DevZone posts saying the Softdevice will turn on and off the external crystal so wondering if this is the cause of the deviations.

    If you are using the SAADC in continuous mode then it will not matter what state the external crystal is in, since the SAADC will perform the sampling based on its internal timer.

    As we measure the sampling period of the 256 samples (raise a GPIO pin in NRFX_SAADC_EVT_READY event, and turn it off in NRFX_SAADC_EVT_DONE, measure the interval), the period appears not consistent among several boards. We observed about 1% differences among boards.

    I think the issue here might be with the way you are measuring it - could you elaborate on how the event is connected to the GPIO toggling? Is it done through CPU intervention, or through PPI?
    In case of the former you will not be able to guarantee that the CPU is free to handle the event (toggle the GPIO) at the time that the sampling actually finishes, since it may be busy in a higher priority interrupt.
    In case of the latter it would be great to see a more complete version of how you have implemented this in the code.

    Best regards,
    Karl

Related