SAADC BURST problems in scan vs non-scan acquisitions

[pabigot]

I'm using the SAADC peripheral by controlling its registers directly (no SDK or MDK HAL). I have an application that alternates between two configurations:

* One sample from AIN1
* A sample from AIN4 followed by a sample from AIN5

Reduced reproducing code is available in this gist.

For each case I configure the SAADC registers including setting RESULT.MAXCNT set to 1 or 2 as appropriate, enable SAADC and issue START and SAMPLE, then when it's done stop and disable the SAADC, and sleep for one second.  All configurations use oversampling and enable BURST in all channels.  Per the nRF52832 PS and this devzone question this should work for both one-shot and scan mode, even though it's not supported in the SDK/nrfx driver.

If I repeat the sequence above I get the following results:

* The first acquisition of one sample from AIN1 works correctly.
* The first acquisition of two samples from AIN4-AIN5 works correctly.
* The second acquisition of one sample from AIN1 works correctly.
* The second acqusition of two samples from AIN4-AIN5 fails.

For the last case I get a successful collection from AIN4 (one EVENTS_RESULTDONE), then the SAADC STATUS goes to idle with RESULT.AMOUNT=1 but RESULT.MAXCNT=2 as configured. I never get an END event.

I can repeat one-sample acquisitions forever.

I can repeat scan-mode (2, 3, 4 channels) acquisitions forever.

What I can't do is capture scan-mode, capture one-shot, then capture scan-mode again: the peripheral always stops after the first channel in the scan-mode completes.

If I turn off BURST in CH.CONFIG and trigger the extra samples manually after each EVENTS_DONE it works.

My current hypothesis is that BURST works in one-shot mode, and in scan mode, but does not work in scan mode after use in one-shot mode.

Can anybody confirm this? I notice that CONFIG.BURST is not discussed in the nRF52840 oversampling documentation, which suggests it's not stable even though it's worked fine except for this situation.

[Jakub Rzeszutko]

Hi pabigot,

Currently we are investigating similar issue. May you please try to execute power cycle of SAADC after each configuration change?

I mean try following approach:

1. configure SAADC for 1 sample on AIN1

2. Measure a value

3. Uninint / switch off SAADC completely

4. Init SAADC for AIN4-AIN5

5. Measure values

6. Uninint / switch off SAADC completely
start again...

This shall help.

[pabigot]

AFAICT that's exactly what I do by writing 0 to SAADC.ENABLE after receiving EVENTS_STOPPED in the example.  It does not resolve the problem

If there's a stronger version of power-cycle (used to be some peripherals that had a hidden register) I'd be happy to try that, but I need more details.

[pabigot]

I updated the example to disable all channels, which appears to be the only difference between our solutions, and to dump the ADC state after the successful completions showing that all events are cleared.  The problem remains.

[Jakub Rzeszutko]

Thank you for update, we will investigate your example. I will try to give you an update by end of this week - latest on Monday.

[pabigot]

Thanks.  On further testing the workaround I had hopes for fails: triggering additional TASKS_SAMPLE from within the interrupt doesn't do the right thing in scan mode, as all results are taken from the first enabled channel.  As best I can tell there's no way to do oversampling in scan mode if you also do collections in one-shot mode.  Unless there's a hidden task that would kick off a second conversion without resetting the channel index, which would be really nice....

(Correction: oversampling in scan mode takes one sample from each channel for each issued TASKS_SAMPLE.  So if OVERSAMPLE=1 and two channels are enabled you get two values as expected, but they're the average of the readings from the enabled channels: instead of thermistors reading 20 Cel and 30 Cel, you get two thermistors reading 25 Cel.  Not very useful.)

[Jakub Rzeszutko]

Hi,

Problem you have observed is hardware related and we will shortly release PAN-212 for that.

You should execute following code before changing channel configuration:

*(volatile uint32_t *)0x40007FFC = 0;
*(volatile uint32_t *)0x40007FFC = 1;

[pabigot]

Thanks, I've confirmed that works, but have a question:

This appears to power-cycle the SAADC peripheral (that being the role of 0xFFC within other peripherals). I've confirmed that although INTEN appears to be preserved, the sequence clears the CH[i], RESOLUTION, OVERSAMPLE, and RESULT registers (didn't test SAMPLERATE).

Is SAADC calibration affected by this sequence?

If so, this workaround may not be useful in my applications since I'd hoped to only have to calibrate when the temperature changed, not before every acquisition.

[Later: Testing suggests the undocumented registers at 0x62C and 0x630 are affected by calibration.  The workaround does reset those registers.]

[Einar Thorsrud]

Hi,

You are right. The 0xFFC register controls the power to the SAADC peripheral, and the peripheral and its registers will be reset to its initial state by switching the peripheral off and then back on again. This includes the calibration.