SAADC scan mode sample order is not always consistent

RE: SAADC scan mode sample order is not always consistent

Hemabas — Sat, 02 Feb 2019 11:34:45 GMT

hey olaf,

can you please elaborate to where exactly this piece of code needs to be called.

thanks

RE: SAADC scan mode sample order is not always consistent

jakub — Tue, 11 Sep 2018 20:28:43 GMT

Indeed this solution solves the problem, Thank you Olaf for sharing that.

RE: SAADC scan mode sample order is not always consistent

Olaf — Mon, 04 Jun 2018 17:04:54 GMT

I would like to share my findings on this issue. When using UART and SAADC at the same or different IRQ levels, I was experiencing this issue reproducible during startup. It happened always after a SAADC calibration while UART was processing a lot of data.

Changing the IRQ priority did not help. Neither for UART nor SAADC. The -DNRF52_PAN_28 did not help as well.

What solved the issue for me was using this sequence to stop the ADC before a next calibration:

void stop_adc()
{
	nrf_drv_saadc_uninit();
	nrf_drv_ppi_uninit();
	nrf_drv_timer_uninit(&m_timer);

	while (nrf_drv_saadc_is_busy())
		;

}

RE: SAADC scan mode sample order is not always consistent

Anne van Rossum — Wed, 26 Jul 2017 08:41:01 GMT

@Alessandro. I wish it was that simple. We're running it at 3, should be low enough.

RE: SAADC scan mode sample order is not always consistent

Alessandro — Wed, 26 Jul 2017 08:37:09 GMT

I had the channels swap every now and then, what solved the problem was to set the priority of the SAADC to 2 (or even 6) keeping the BLE enabled.

RE: SAADC scan mode sample order is not always consistent

Anne van Rossum — Tue, 25 Jul 2017 15:52:15 GMT

I have seen all kind of behavior w.r.t. scan mode. I would love Nordic engineers to take a look at scan mode, put one pin consistently at say 3.3V and another at 0V and observe all kind of interesting effects... I assume it has to do with timing issues on the peripheral bus (related to other activities on it, e.g. addressing the encryption peripheral).

Things we have seen:

Swapping of channels halfway
Individual samples suddenly coming from another channel
The first sample from another channel (especially if acquisition time is set low)

We still have to create a short example to show these cases, but didn't have time yet to do so. Anyone heavily using scan mode and relying on correct samples should encounter these things though.

RE: SAADC scan mode sample order is not always consistent

jprofit — Fri, 07 Oct 2016 15:28:30 GMT

The example I presented above was simplified in order to make it brief. A full examination of both channel's data shows that it is not simply a sampling rate limitation (peak error). I am sampling at 4kHz and the signal is bandwidth limited at 1kHz. The two channels' data can be compared directly and it is clear that one channel's data is always ~15 times larger than the other (at every data point). The problem is that sometimes that channel has address offset 0 and sometimes it has address offset 2.

I am wondering if this problem could be due to the fact that my code occasionally calls nrf_drv_saadc_abort(). I am thinking there may be a bug somewhere in the driver if abort is called at the wrong time or possibly the state doesn't get cleared properly for my next call tonrf_drv_saadc_buffer_convert().

buffer size: 2048 * 2 * sizeof(int16) = 8096 (2 byte aligned) sample rate is 4kHz

RE: SAADC scan mode sample order is not always consistent

Stefan Birnir Sverrisson — Thu, 06 Oct 2016 08:01:32 GMT

I have not seen this problem before that you are describing. There is saadc scan mode example here that should be similar as yours. Try to run that example and check if you get the same behavior. You probably need to set a higher sampling frequency and increase the EasyDMA sampling buffer.

Update 6.10.2016 Make sure the buffer size is a multiple of number of configured channels. If you have two channels configured, the buffer size should be 2,4,6,8,... . If the number of configured channels is 5, then the buffer size must be 5,10,15,20,...

Scan mode does not work on nRF52832 Engineering A IC. It should work on Engineering B, C, and revision 1.

Update 12.10.2016 I am unable to reproduce this issue. I have made a test example that calls nrf_drv_saadc_abort when pressing button 3 on the nRF52-DK board. Sampling is resumed by pressing button 2. After If I press button 3 to stop sampling and then press button 2 to resume sampling, I get consistent SAADC output values from the two configured saadc channels before aborting and after resuming. The test example is attached and is based on this github example.

ble_app_uart__saadc_timer_driven__scan_mode__abort_test.zip