SAADC BURST problems in scan vs non-scan acquisitions

RE: SAADC BURST problems in scan vs non-scan acquisitions

Jakub Rzeszutko — Mon, 15 Apr 2019 06:27:30 GMT

Hi,

I'm sorry I didn't comment on your observation earlier but we're still working on the PAN-212. There's a chance that we will have a solution to not lose calibration data. We need some more time.

RE: SAADC BURST problems in scan vs non-scan acquisitions

pabigot — Sun, 14 Apr 2019 12:35:03 GMT

To collect the full set of information:

Yes, mixing BURST+OVERSAMPLE and moving between scan-mode and one-shot SAADC causes problems that will be PAN-212. The workaround is described in this response.

However, the workaround clears the SAADC calibration, as confirmed in this response.

Calibration is a one-shot measurement. Because both calibration and oversampling are important for repeatable accurate SAADC results, correct placement of the workaround is probably application-dependent (e.g., issue it before performing any calibration, and then never transition from scan-mode back to one-shot without repeating the power-cycle + calibrate sequence).

RE: SAADC BURST problems in scan vs non-scan acquisitions

Einar Thorsrud — Wed, 03 Apr 2019 11:01:40 GMT

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.

RE: SAADC BURST problems in scan vs non-scan acquisitions

pabigot — Sat, 30 Mar 2019 14:55:42 GMT

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.]

RE: SAADC BURST problems in scan vs non-scan acquisitions

Jakub Rzeszutko — Fri, 29 Mar 2019 11:39:59 GMT

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;

RE: SAADC BURST problems in scan vs non-scan acquisitions

pabigot — Tue, 26 Mar 2019 14:48:46 GMT

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.)

RE: SAADC BURST problems in scan vs non-scan acquisitions

Jakub Rzeszutko — Tue, 26 Mar 2019 13:24:28 GMT

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.

RE: SAADC BURST problems in scan vs non-scan acquisitions

pabigot — Tue, 26 Mar 2019 13:02:41 GMT

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.

RE: SAADC BURST problems in scan vs non-scan acquisitions

Jakub Rzeszutko — Tue, 26 Mar 2019 12:35:43 GMT

It might be not enough. May you please ensure that all events are stopped, interrupts deactivated and all channels uninitialized?

Please take a look at our implementation:

https://github.com/NordicSemiconductor/nrfx/blob/master/drivers/src/nrfx_saadc.c#L250

RE: SAADC BURST problems in scan vs non-scan acquisitions

pabigot — Tue, 26 Mar 2019 11:58:04 GMT

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.

RE: SAADC BURST problems in scan vs non-scan acquisitions

Jakub Rzeszutko — Tue, 26 Mar 2019 08:02:20 GMT

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.