SAADC scan mode sample order is not always consistent

[jprofit]

I am seeing a problem using the nRF52 SAADC with two analog channels enabled in scan mode. Essentially, channel 0 is measuring an analog signal with gain ~= 15 while channel 1 is measuring the same signal with gain = 1.

The ADC is sampled in scan mode at 4kHz into a buffer that holds 2048 samples for each channel. When I receive the interleaved buffer, I usually see that the channel 0 ADC data is at address offset 0, 4, 8, etc and the channel 1 data is at address offset 2, 6, 0xa, etc.

Unfortunately, sometimes these channels are swapped. (ie. the channel 0 data is at address offset 2, 6, 0xa,... and the channel 1 data is at address offsets 0, 4, 8, ....).

Is there anything I can do to ensure that channel 0 data starts at offset 0 and channel 1 data starts at offset 2?

Here is a printf from the code that shows the peak value of each channel as well as the buffer address:

Capture 1:

base_ptr=0x20003028, peak=1363.000000

base_ptr=0x2000302a, peak=86.000000

Capture 2:

base_ptr=0x20005028, peak=1342.000000

base_ptr=0x2000502a, peak=96.000000

Capture 3:

base_ptr=0x20003028, peak=92.000000

base_ptr=0x2000302a, peak=1352.000000

As you can see, the first two captures have the higher gain signal in the 0 offset position as expected. However, the third capture has the lower gain signal in the 0 offset position.

Is there something I need to do to the EasyDMA module to reset between captures? Currently, I am just calling nrf_drv_saadc_buffer_convert() to start a new capture.

I am using SDK version 11.0.0 and S132 version 2.0.1

[Anne van Rossum]

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.

See also:

• devzone.nordicsemi.com/.../

Suggestions:

1. Regarding not swapping channels, enabling -DNRF52_PAN_28 solved that for us although rev1 shouldn't need this PAN. Doing the scan mode in software should not be your first course of action nevertheless. It's just because we got fed up by it.

2. Play around with the priority of ADC. Or even better, turn off BLE when doing ADC. I've never had the problem when doing just ADC. These problems arise only when more is done (e.g. a connection is set up and some information is acquired). A channel rotation also regularly occurred in our case in (the more involved) startup phase.

[Alessandro]

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.