SAADC oversample with burst configuration

[Gianlucamilani]

Dear DevZone,

I am trying to configure the SAADC on my custom nRF52840 board.

I would like to use it in blocking mode together with oversample 16x and burst enabled.

I started from the example provided in the SDK, and I firstly removed all the parts related to non-blocking mode.

Then I modified the parameters to set oversample and burst mode. Here the steps I performed:

• I modified the configuration struct to enable burst in this way:

#define NRFX_SAADC_DEFAULT_CHANNEL_CONFIG_SE(PIN_P) \
{ \
.resistor_p = NRF_SAADC_RESISTOR_DISABLED, \
.resistor_n = NRF_SAADC_RESISTOR_DISABLED, \
.gain = NRF_SAADC_GAIN1_6, \
.reference = NRF_SAADC_REFERENCE_INTERNAL, \
.acq_time = NRF_SAADC_ACQTIME_3US, \
.mode = NRF_SAADC_MODE_SINGLE_ENDED, \
.burst = NRF_SAADC_BURST_ENABLED, \ //enabled burst mode to automatically acquire 2^oversample samples with one request
.pin_p = (nrf_saadc_input_t)(PIN_P), \
.pin_n = NRF_SAADC_INPUT_DISABLED \
}

• I modified the following value in the sdk_config file:

// <0=> Disabled
// <1=> 2x
// <2=> 4x
// <3=> 8x
// <4=> 16x
// <5=> 32x
// <6=> 64x
// <7=> 128x
// <8=> 256x

#ifndef NRFX_SAADC_CONFIG_OVERSAMPLE
#define NRFX_SAADC_CONFIG_OVERSAMPLE 4
#endif

Is the procedure correct? Am I missing something? Do you think there could be any issues related to the buffer size if I use the blocking mode (nrfx_saadc_sample_convert function)?

Thank you very much in advance,

best regard,

Gianluca Milani

[Jared]

Hi,

It seems correct for blocking mode. However, what is your intention of using blocking mode instead of non-blocking? Are you using PPI to connect the SAMPLE task with the COMPARE event as in the example? That could be a bit problematic as it could lead to the buffer swap issue.

regards

Jared 

[Gianlucamilani]

Dear Jared, 

thank you very much for your answer.

I would use it without any PPI, I am initializing the saadc without any instructions in the callback handler:

void saadc_callback_handler(nrf_drv_saadc_evt_t const * p_event)
{
  //Empty
}


void saadc_init(void)
{

  ret_code_t err_code;

  // Create a config struct and assign it default values along with Pin number for ADC input
  //
  // Chosen paramters:
  //
  //    - Internal reference
  //    - Gain 1/6
  //    - Acquisition time 3us
  //    - Single ended
  //
  // The reasons for the choice of these parameters values can be found at the following link:
  //
  // https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/measuring-lithium-battery-voltage-with-nrf52

  // Configure the input as Single Ended (One Pin reading)


  nrf_saadc_channel_config_t  channel_config = NRF_DRV_SAADC_DEFAULT_CHANNEL_CONFIG_SE(NRF_SAADC_INPUT_AIN5);


  // Initialize the saadc

  err_code = nrf_drv_saadc_init(NULL, saadc_callback_handler);
  APP_ERROR_CHECK(err_code);

  // Initialize the channel which will be connected to that specific Pin
  // The selected channel is 0

  err_code = nrf_drv_saadc_channel_init(0, &channel_config);
  APP_ERROR_CHECK(err_code);




}

and I am triggering the saadc conversion only when I need it, using:

 nrfx_saadc_sample_convert(0, &adc_val);

Am I doing the wrong steps if I want to implement oversampling?

Thanks,

Best regards,

Gianluca

[Gianlucamilani]

In other words, what I understood from the documentation is that the relationship between the ADC modalities can be described as follows:

1) Am I correct?

In that case, I would use the one-shot - blocking since I need to leave free the timers.

2) Do you think is a good idea or I should go with one of the others?

3) To have the oversample with burst feature is it ok to use the blocking- one shot modality as I showed you in the code?

Thanks, I hope I was clear enough,

Best regards,

Gianluca

[Jared]

Hi,

1. This should be correct. 
2. I don't see any reason to use blocking in the first place as I don't see any benefit from it. It will just cause a higher power consumption.
3. Yes, that should be fine as in this case.

regards

Jared 

[Gianlucamilani]

Thank you very much Jared,

do you know if there is a suggested way to verify the actual realization of the 16 events related to the readings with an oscilloscope? Or via code? Thanks,

best regards,

Gianluca

[Jared]

Gianlucamilani said:

do you know if there is a suggested way to verify the actual realization of the 16 events related to the readings with an oscilloscope? Or via code? Thanks,

 "DONE event is generated for every input sample taken" from product spec, which means that you can use the callback handler to see that the samples are taken during the oversampling.