ADC - First read is always wrong

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 09 Mar 2022 12:50:49 GMT

I am happy to hear that, Tero!

Please do not hesitate to open another ticket if you should encounter any other issues or questions in the future.

Good luck with your development!

Best regards,
Karl

RE: ADC - First read is always wrong

anicare-tero — Wed, 09 Mar 2022 12:27:15 GMT

Hi Karl,

Thanks for helping, I'm fine now without the offset calibration.

BR,
Tero

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 09 Mar 2022 12:08:43 GMT

Hello again, Tero and Damien

I just wanted to let you know that I have been unable to reproduce the unexpected sample / buffer shift behavior without the offset calibration present, which aligns with my previous conclusion that this is an artifact of the CALIBRATEOFFSET description in the nRF9160's Product Specification.

Tero, If you are still seeing unexplained samples appear in your buffer, please open a separate ticket for this issue so that we may investigate that separately.

Best regards,
Karl

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 19 Jan 2022 15:17:29 GMT

Hello again,

Thank you for elaborating and providing the snippet, Damien.
I will attempt to replicate the behavior on my end using the provided code and NCS version.

[quote user="ziirou"]I just noticed that when I have CONFIG_LOG_MODE_MINIMAL enabled, ADC readings are giving incorrect values. Usually I test our devices with minimal logging disabled (CONFIG_LOG_MODE_IMMEDIATE enabled) and there it is working properly.[/quote]

If the loggings are processed in-place/immediately it could generate a delay akin the one mentioned by Damien. However, I find it strange that my minimal example did not behave the same way when I tried to replicate this earlier. In my minimal application, the calibration was the only source of incorrect / unexpected samples - without any delay or timer interference, and it only ever happened directly following the calibration, unlike what Damien describes.

[quote user="ziirou"]

I removed the CALIBRATEOFFSET calling and now it is working with minimal logging enabled too.

Have you (DamoL and Karl Ylvisaker) tested the ADC without any calibration there?

[/quote]

I did try without calibration in my minimal example as well, in which case I never saw any incorrect / unexpected samples being placed in the buffer, which is what lead me to the conclusion that this was 'as expected' when the calibration was initiated without the SAADC first being stopped, as (poorly) described in the Product Specification.

Best regards,
Karl

RE: ADC - First read is always wrong

anicare-tero — Tue, 18 Jan 2022 12:47:00 GMT

Hi,

I just noticed that when I have CONFIG_LOG_MODE_MINIMAL enabled, ADC readings are giving incorrect values. Usually I test our devices with minimal logging disabled (CONFIG_LOG_MODE_IMMEDIATE enabled) and there it is working properly.

I removed the CALIBRATEOFFSET calling and now it is working with minimal logging enabled too.

Have you (DamoL and Karl Ylvisaker) tested the ADC without any calibration there?

Regards,
Tero

RE: ADC - First read is always wrong

DamoL — Mon, 17 Jan 2022 12:45:50 GMT

Hi Karl,

Thanks for the update.

[quote userid="87869" url="~/f/nordic-q-a/80796/adc---first-read-is-always-wrong/347440#347440"]Damien, could you confirm whether you meant that the unexpected sample happens periodically without the added kprint delay, or only during startup of the SAADC peripheral?[/quote]

When I have the printk() it only happened the first time I tried reading. Without the printk() it happened fairly often. I don't have a copy of the original code as I was just playing around with it and trying out the libraries, etc. But it was essentially exactly what was in the original question of this post, with added printk() before reading the buffer.

main.c would look a bit like this;

#include <drivers/adc.h>
#include <hal/nrf_saadc.h>

#define ADC_RESOLUTION 12
#define ADC_GAIN ADC_GAIN_1_4
#define ADC_REFERENCE ADC_REF_VDD_1_4
#define ADC_ACQUISITION_TIME ADC_ACQ_TIME(ADC_ACQ_TIME_MICROSECONDS, 10)
#define ADC_1ST_CHANNEL_ID 0  
#define ADC_1ST_CHANNEL_INPUT NRF_SAADC_INPUT_AIN0

#define BUFFER_SIZE 1
/* ADC Struct */
static struct device *adc_dev;

static uint16_t m_sample_buffer[BUFFER_SIZE];

static struct adc_channel_cfg channel_cfg = {
	.gain 				= ADC_GAIN,
	.reference 			= ADC_REFERENCE,
	.acquisition_time 	= ADC_ACQUISITION_TIME,
	.differential 		= 0,
	.channel_id			= ADC_1ST_CHANNEL_INPUT ,
};

static int adc_sample(void)
{
	int ret;

		struct adc_sequence sequence = {
		.channels    = BIT(channel_cfg.channel_id),
		.buffer      = &m_sample_buffer,
		.buffer_size = sizeof(m_sample_buffer),
		.resolution  = ADC_RESOLUTION,
	};

	if (!adc_dev) {
		return -1;
	}

	ret = adc_read(adc_dev, &sequence);
	if (ret) {
        printk("adc_read() failed with code %d\n", ret);
	}

	for (int i = 0; i < BUFFER_SIZE; i++) {
                printk("ADC raw value: %d\n", m_sample_buffer[i]);
				uint32_t mV = (m_sample_buffer[i] *1000)*3/4096;	//n*1000*Reference (3V) / 12bit adc
				printk("ADC mV after Divider: %u\n", mV);
				mV = mV *2;
				printk("Voltage Sensed: %u\n", mV);
	}

	return ret;
}

int adc_value=0;

static void button_handler(uint32_t button_states, uint32_t has_changed)
{	
	if (has_changed & button_states &
		BIT(0)) {
		    adc_value = adc_sample();
		    printk("Value - %i", adc_value);
	}
}

void main(void)
{
	int err=0;
    adc_dev = device_get_binding("ADC_0");
	if (!adc_dev) {
        printk("device_get_binding ADC_0 failed\n");
    } 
    NRF_SAADC_NS->TASKS_CALIBRATEOFFSET=1;
    err = adc_channel_setup(adc_dev, &channel_cfg);
    if (err) {
	    printk("Error in adc setup: %d\n", err);
	}
	
#if defined(CONFIG_DK_LIBRARY)
	dk_buttons_init(button_handler);
#endif
	
}

As for the versio, it would have been V1.6.1 .

Thanks,

Damien

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 12 Jan 2022 16:10:14 GMT

Hello again, Tero and Damien

It seems that the incorrect sample does indeed stem from the calibrateoffset procedure - at least in my minimal NCS ADC test application.

Damien, could you confirm whether you meant that the unexpected sample happens periodically without the added kprint delay, or only during startup of the SAADC peripheral? If it is periodically, could you possibly send me the stripped down version of the project (only adc parts needed) that you tested with along with which NCS version you used when you saw this behavior?

Tero, does the previous discussion not explain the similar issue you saw/are seeing?
If your issue now diverges from this issue, please open a separate ticket where you detail your issue.

In any case, I thought I should let you both know that I have made an internal ticket with the SAADC driver developers to have the adc_nrfx_saadc driver's implementation of the errata 86 workaround reviewed, and to have it re-implemented to instead exactly match the workaround described in the errata 86 documentation.

I have also opened an internal request to have this elaborated on and clarified in the nRF9160's SAADC Product Specification section, akin to that of the nRF5340's SAADC section or better.

Best regards,
Karl

RE: ADC - First read is always wrong

Karl Ylvisaker — Tue, 11 Jan 2022 15:39:19 GMT

Hello again Tero and Damien,

Thank you for your extreme patience with this issue. I have been out of office for some time, but now I am back in office and will resume work with this investigation.

A colleague has conducted some tests on this in my absence and come to the conclusion that the incorrect sample is as expected as per the 9160's SAADC documentation, which reads:

The ADC has a temperature dependent offset. If the ADC is to operate over a large temperature range, we recommend running CALIBRATEOFFSET at regular intervals. The CALIBRATEDONE event will be fired when the calibration has been completed. Note that the DONE and RESULTDONE events will also be generated.

Which implies that a junk DONE and RESULTDONE event will be returned following a successful calibration. I will have to test this some more, to see if this might have been what is causing the behavior you have seen on your end as well. I have also noted that the implementation of the Errata 86 workaround in the adc_nrfx_saadc.c driver does not exactly follow the workaround detailed in the mentioned Errata 86 (namely, it does not wait for the appropriate events to be generated), which I am unclear on whether has played into this issue.

Best regards,
Karl

RE: ADC - First read is always wrong

anicare-tero — Mon, 20 Dec 2021 10:21:45 GMT

Hi Karl Ylvisaker,

Do you have any updates on this?

Regards,
Tero

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 03 Nov 2021 13:50:03 GMT

Hello again, Damien

[quote user="DamoL"]Apologies I have been away for a few days.[/quote]

No need to apologize - we will continue this whenever you have the chance.

[quote user="DamoL"]I have tried your suggestion. But do not see a change in behaviour. My current workaround is just using printk() between adc_read() and looking at the buffer. [/quote][quote user="DamoL"]For some reason this gives enough time for the buffer to be filled. If I comment out that line it reads correctly about 30% of the time.[/quote]

Thank you for trying this, and updating us on the results. I find this very strange. I will need to look deeper into this, and once I have done so I will escalate it to the SAADC driver's developer team so that they may examine my findings and patch it. I will update you as soon as I have got anything to share.

Thank you for bringing this to our attention!

Best regards,
Karl

RE: ADC - First read is always wrong

DamoL — Tue, 02 Nov 2021 09:58:50 GMT

Hi Karl,

Apologies I have been away for a few days. I have tried your suggestion. But do not see a change in behaviour. My current workaround is just using printk() between adc_read() and looking at the buffer.

ret = adc_read(dev, &sequence);
	if (ret) {
        printk("adc_read() failed with code %d\n", ret);
	}
	else{

		for (int i = 0; i < BUFFER_SIZE; i++) {
					printk("Reading ADC\n");    //THIS ADDS SUFFICIENT DELAY
					uint32_t mV = (m_sample_buffer[i] *1000)*3/4096;	//n*1000*Reference (3V) / 12bit adc
					printk("ADC raw value: %d\n", m_sample_buffer[i]);
					printk("ADC mV after Divider: %u\n", mV);
					mV = mV *2;
					printk("Voltage Sensed: %u\n", mV);
		}
	}

For some reason this gives enough time for the buffer to be filled. If I comment out that line it reads correctly about 30% of the time.

Thanks,

Damien

RE: ADC - First read is always wrong

Karl Ylvisaker — Thu, 28 Oct 2021 11:26:09 GMT

Hello again Damien and Tero,

As mentioned I previously had the nRF5 SDK in mind when discussing this issue earlier. Looking into the NCS SAADC's irq handler it is apparent that the CALIBRATEDONE event is indeed cleared before the main context ever sees it. While this explains how the application is getting stuck waiting for the event, it does not unambiguously explain why you saw a change in the behavior after triggering the stop tasks before and after the calibrate done triggering.

Could you try to add a delay in between your call to trigger calibration and the first sampling, to see if this then gives the SAADC sufficient time to finish calibration and the STOP task, before it is started again?
If it is the Errata 86 at play, the driver's implementation of the workaround should take care of it as long as it is given time to finish before the first call.

Best regards,
Karl

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 27 Oct 2021 14:47:09 GMT

Hello again Damien and Tero,

Thank you for your patience with this.

[quote user="ziirou"]We have had the similar problem like this one. I tried what Karl Ylvisaker suggested and it gave some errors on missing arguments. So I did it like this:[/quote]

Yes, I wrote the section with the nRF5 SDK in mind, my mistake.

[quote user="ziirou"]Earlier I had it like below and it was working but I'm not sure if I did it at the right way.[/quote]

I am not sure that this will work, since the program counter will move on immediately after having triggered the task to cleared the event - regardless of the event actually having happened.

[quote user="DamoL"]As Tero said, it does get stuck on the NRF_SAADC_EVENT_CALIBRATEDONE line. I tried what Tero had previously and that didn't work for me either. [/quote]

I just created a minimal NCS ADC example to test this on my end as well, and I notice that the same thing - the CALIBRATEDONE event never seems to occur. I am not immediately sure why this is happening - perhaps the calibrate done event is cleared somewhere else with a higher priority, so that the section here never sees the event, or similar.

I will have a look into what is happening behind the scenes here tomorrow.

Best regards,
Karl

RE: ADC - First read is always wrong

DamoL — Mon, 25 Oct 2021 13:16:11 GMT

Hi Karl and Tero.

As Tero said, it does get stuck on the NRF_SAADC_EVENT_CALIBRATEDONE line. I tried what Tero had previously and that didn't work for me either.

Thanks,

Damien

RE: ADC - First read is always wrong

anicare-tero — Mon, 25 Oct 2021 07:47:12 GMT

Hi,

We have had the similar problem like this one. I tried what Karl Ylvisaker suggested and it gave some errors on missing arguments. So I did it like this:

...
	LOG_INF("nrf_saadc_task_trigger NRF_SAADC_TASK_STOP");
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_STOP);
	LOG_INF("nrf_saadc_event_check NRF_SAADC_EVENT_STOPPED");
	while(!nrf_saadc_event_check(NRF_SAADC, NRF_SAADC_EVENT_STOPPED));
	LOG_INF("nrf_saadc_task_trigger NRF_SAADC_TASK_CALIBRATEOFFSET");
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_CALIBRATEOFFSET);
	LOG_INF("nrf_saadc_event_check NRF_SAADC_EVENT_CALIBRATEDONE");
	while(!nrf_saadc_event_check(NRF_SAADC, NRF_SAADC_EVENT_CALIBRATEDONE));
	LOG_INF("nrf_saadc_task_trigger NRF_SAADC_TASK_STOP");
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_STOP);
	LOG_INF("nrf_saadc_event_check NRF_SAADC_EVENT_STOPPED");
	while(!nrf_saadc_event_check(NRF_SAADC, NRF_SAADC_EVENT_STOPPED));
	LOG_INF("done");
...

And it's getting stuck on NRF_SAADC_EVENT_CALIBRATEDONE.

[00:00:01.773,071] [1B][0m<inf> adc_control: nrf_saadc_task_trigger NRF_SAADC_TASK_STOP[1B][0m
[00:00:01.781,768] [1B][0m<inf> adc_control: nrf_saadc_event_check NRF_SAADC_EVENT_STOPPED[1B][0m
[00:00:01.790,740] [1B][0m<inf> adc_control: nrf_saadc_task_trigger NRF_SAADC_TASK_CALIBRATEOFFSET[1B][0m
[00:00:01.800,506] [1B][0m<inf> adc_control: nrf_saadc_event_check NRF_SAADC_EVENT_CALIBRATEDONE[1B][0m

Earlier I had it like below and it was working but I'm not sure if I did it at the right way.

...
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_CALIBRATEOFFSET);
	nrf_saadc_event_clear(NRF_SAADC, NRF_SAADC_EVENT_CALIBRATEDONE);
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_STOP);
	nrf_saadc_event_clear(NRF_SAADC, NRF_SAADC_EVENT_STOPPED);
	nrf_saadc_task_trigger(NRF_SAADC, NRF_SAADC_TASK_START);
...

I hope we could solve this issue.

Regards,
Tero

RE: ADC - First read is always wrong

Karl Ylvisaker — Sun, 24 Oct 2021 18:22:19 GMT

Hello again, Damien

[quote user="DamoL"]Thanks for the Reply.[/quote]

No problem at all, I am happy to help!
Thank you for clarifying with the diagram and updating us on your findings.

[quote user="DamoL"]I followed the Errata 86 document, and added the below into my code on setup. [/quote]

This is almost correct, except you should not write to the events but instead wait for them to be generated as a result of the triggered task.
So, you should only write to the TASKS registers to trigger them, and not write to the EVENTS registers but instead wait for them to be set on their own as a result of the triggered TASK finishing. You should also add a STOP task trigger before the calibrate offset task, as shown in the workaround.
The result could look similar to this:

..
    NRF_SAADC_NS->TASKS_STOP = 1;
    while(!nrf_saadc_event_check(NRF_SAADC_EVENT_STOPPED));
    NRF_SAADC_NS->TASKS_CALIBRATEOFFSET=1;
    while(!nrf_saadc_event_check(EVENTS_CALIBRATEDONE));
	NRF_SAADC_NS->TASKS_STOP=1;
	while(!nrf_saadc_event_check(NRF_SAADC_EVENT_STOPPED));
..

And then you can proceed to start the SAADC and its regular operation afterwards.
You may of course replace the busy waits with something more productive, or have the CPU go into a SYSTEM_ON sleep / idling to reduce power, if you intend on calibrating the SAADC somewhat frequently.

Could you try it with this change, and see if the non-debug mode works as when stepping through the code?
I look forward to hearing what you observe with these changes implemented!

Best regards,
Karl

RE: ADC - First read is always wrong

DamoL — Thu, 21 Oct 2021 07:59:57 GMT

Hello Karl,

I followed the Errata 86 document, and added the below into my code on setup.

if (!adc_dev) {
        printk("device_get_binding ADC_0 failed\n");
    }
    NRF_SAADC_NS->TASKS_CALIBRATEOFFSET=1;
	NRF_SAADC_NS->EVENTS_CALIBRATEDONE=1;
	NRF_SAADC_NS->TASKS_STOP=1;
	NRF_SAADC_NS->EVENTS_STOPPED=1;
	NRF_SAADC_NS->TASKS_START=1;
    err = adc_channel_setup(adc_dev, &channel_cfg);

I'm not sure if this is exactly what I should have done, but it almost worked.

When I step through the code, it works fine, the output on the COM port is:

ADC raw value: 3588
ADC mV after Divider: 2626
mV Sensed: 5252

However, when I just run it not in debug mode, the output is this:

ADC raw value: 0
ADC mV after Divider: 2627
mV Sensed: 5254

So for some reason, it's printing the raw value as 0, but it seems to still be converting what it should have read correctly.

I will play around a little more, but I think it's pretty much there.

Thanks,

Damien

RE: ADC - First read is always wrong

DamoL — Wed, 20 Oct 2021 13:36:21 GMT

Hi Karl

Thanks for the Reply. See diagram below.

As for whether I am waiting till offset calibration is finished, how is it possible to tell? I am allowing the program to run and then press button 1 to perform an ADC measurement. If I allow 30 seconds to pass before pressing the button, I get a wrong reading. If I allow 2 seconds and press the button twice, the second reading will be correct. So I assume it cant be offset calibration not having enough time to finish.

I will have a look at the errata - thanks for pointing that out.

Thanks,

Damien

RE: ADC - First read is always wrong

Karl Ylvisaker — Wed, 20 Oct 2021 13:10:13 GMT

Hello Damien and Dan,

I concur with Dan that this definitely could be the case depending on your surrounding circuitry.
Would it be possible for you to share with us the diagram for your connection of the chosen AIN pin to the measured voltage, and the circuitry surrounding the voltage being measured?
You description is clear, but it would be neat to see the drawing to rule out any potential for misunderstandings there.

I am not immediately seeing anything wrong in the code you've supplied.
Could you confirm whether you're waiting until the offset calibration has finished before you attempt to perform a sampling?

I also know that there has been an issue in the past that the offset calibration would output a junk sample under certain conditions, but I have never heard about this being the case on the nRF9160 before. Could you try to apply the workaround in this Errata 86 for the nRF52832, to see if that makes any difference?

Best regards,
Karl

RE: ADC - First read is always wrong

DamoL — Tue, 19 Oct 2021 13:04:06 GMT

Hi Dan,

Thanks for the suggestion. I did wonder about capacitance on the input, but the voltage at the middle of the resistor divider is constant - meaning when I reset the device/program, it doesn't drop to 0V and need recharging, its powered but a constant source. I put a 1uF cap in parallel, and used an oscilloscope to measure it voltage during a read and it doesn't fluctuate at all, so I struggle to see how that can be the cause.

I realise I can do a double read and throw the first one, but I just wondered why this was in case there was something inherently wrong with my code/logic, which could become a larger issue later.

Thanks,

Damien

RE: ADC - First read is always wrong

Kenya87 — Mon, 18 Oct 2021 21:02:31 GMT

I am a 20 plus year experienced hardware embedded design engineer. When I have seen the symptoms like you described it is often caused because the ADC input has some capacitance (which is normal)... the first time you read the ADC the amount of time the capacitance is allowed to charge is too short and thus a low reading is achieved.. after two or three readings the capacitor is charged enough to have an accurate reading. A great way to test this is to put a capacitor in parallel with the bottom (one connected to DC common often referred to as ground) resistor of your resistor divider. This way the external capacitor you have just connected will be fully charged at the 2.5VDC level BEFORE the ADC samples. Now the external capacitor charge can be delivered very quickly to charge the ADC capacitance and thus a correct reading can be acquired on the first attempt. I normally use a 0.1 to 1 uF capacitor for this purpose but the value is not very critical (I would avoid anything in the pF range as the idea is to have lots of charge in the external capacitor versus the relatively small ADC capacitance (normally about 10 to 20 pF).

What if your company has already made 10 million circuit board assemblies and they don't want to go back and add the extra capacitor to the design... what can you do?... two solutions that do NOT require an external capacitor are common.

1) Do exactly what you stumbled upon... read twice and throw the first reading out! then use the second reading OR

2) If the ADC has a mux in front of it you can read a similar voltage on another channel first and then switch to your ADC channel as the internal capacitance charge will remain. This only works IF you have a mux and a similar voltage on another channel (internal power rail is a common choice).

Hope this helps.

Dan