ADC - First read is always wrong

[DamoL]

Hi, 

I have been playing around with the nRF9160 DK trying to get it reading a range of sensors, so far with success, however I have found an issue which has stumped me. I am using ADC0 to read a voltage. Although this is intended for a pressure transducer, for debugging I have just put the 5V out through a resistive divider (10K / 10K) and the ADC successfully reads 2.5V. 

However, when the program is first run, the very first ADC reading is around 50. The next one, and all instances after, it reads correctly (around 3500 - using 3V VDD as reference and gain of 1/4, 12-bit resolution). 

I assumed this may be due to acquisition time, but I tried a few different values and nothing helped. 

I wont post the full code, but here is the config and read code

#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
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 ,
	.input_positive 	= SAADC_CH_PSELP_PSELP_AnalogInput0,
};

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;
}



//WITHIN MAIN

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);
	}
	
//END

The adc_sample() function is called when button 1 is pressed, but I'm sure that shouldnt make a difference. 

Thanks, 

Damien

[Kenya87]

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

[DamoL]

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

[DamoL]

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

[Karl Ylvisaker]

Hello again, Damien

DamoL said:

Thanks for the Reply.

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

DamoL said:

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

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

[anicare-tero]

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

[DamoL]

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

[Karl Ylvisaker]

Hello again Damien and Tero,

Thank you for your patience with this.

anicare-tero said:

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:

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

anicare-tero said:

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

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.

DamoL said:

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. 

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

[Karl Ylvisaker]

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

[DamoL]

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

[Karl Ylvisaker]

Hello again, Damien

DamoL said:

Apologies I have been away for a few days.

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

DamoL said:

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. 

DamoL said:

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.

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

[anicare-tero]

Hi Karl Ylvisaker,

Do you have any updates on this?

Regards,
Tero

[Karl Ylvisaker]

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