saadc scan output order sdk 12.2.0

[Ryjan]

The output order of my scanning Saadc is not predictable.

I found two related questions, but they both are for SDK 11 and seem to have been resolved.

devzone.nordicsemi.com/.../

devzone.nordicsemi.com/.../

But they suggest that the order should always be in channel order. I use 3 channels - 0, 1 & 2. but my results come out in every order but that. I noticed that the correct values were appearing in the buffer[2] location, so I swapped the indices, but the order remained the same. I swapped the variable assignment lines in the code and the data swapped, positions, but not in a predictable manner. What was loading into my final variable should have been loading into the first, but it showed up in the second. Now I've set things up as they were originally and the first value is showing up in the second variable, instead of the third as it did when it was setup like this before. I need more control. Right now I have a single buffer that takes 3 samples (from all three inputs) and then calls the even handler to extract the data.

These lines of code extract the data from the buffer:

nrf_saadc_value_t adc_press 	= p_event->data.done.p_buffer[0];															//Raw result from the ADC for pressure - it's a 2's complement 16 bit number.
uint16_t motor_curr 		    = p_event->data.done.p_buffer[1];															//Raw result from the ADC for motor current - it's a 2's complement 16 bit number.
uint16_t amb_temp		        = p_event->data.done.p_buffer[2];															//Raw result from the ADC for ambient tempurature - it's a 2's complement 16 bit number.
					

[Jørgen Holmefjord]

Hi,

The main issue in your code seems to be that you are setting up the buffer for conversion again before reading the values, by calling:

nrf_drv_saadc_buffer_convert(m_buffer_pool[0],SAADC_SAMPLES_IN_BUFFER);

Almost at the top of the SAADC callback handler. You should move this call to the end of the handler, to avoid that the buffer is overwritten by the sample task before you read the values in the buffer.

After placing this call after reading the buffer, I only see issues on the samples received after calibration (NRF_DRV_SAADC_EVT_DONE is called 4096 times between each time the buffer contains wrong values). I will do some more research on why this buffer is not correct.

Best regards,

Jørgen

[dmf3030]

Any update on this, I'm seeing my channels shift position after my first calibration call, which happens roughly every 500 samples.  After the first calibration call the channels seem to hold their new positions through any following calibration calls, so not sure if there is something special that happens on an initial calibration that doesn't happen later?

[dmf3030]

Looks like I may have solved this by doing a buffer convert on the buffer when it comes in on the EVT_DONE after calibration but before the EVT_CALIBRATEDONE comes in.  I don't think the git example does this buffer convert, which is what threw me off.