Page 1 of 1

Bizarre ADC results when using external signals [SOLVED]

Posted: Fri Apr 22, 2016 9:05 am
by rbinns
ATSAMD20E14, Atmel Studio 7.0

I'm having huge problems getting the ADC to work with any analog inputs or an external reference. It works fine when measuring internal inputs with the internal reference, but as soon as I enable any external signal (sampling an external input OR using an external reference) I get ridiculous values.

1. Internal signals with external reference:
I've got a 2.5V external reference (3.3V analog supply) but looking at the values I get when measuring the internal supplies, it's giving the same values I'd get if the external reference was 2V, not 2.5V. I have checked the external reference multiple times and it's certainly the correct value with almost no noise.

2. External signals with external reference
If I use 1x gain, both inputs give full-scale readings, despite one being 1.82V and the other begin 0V, with a 2.5V reference. If I set the gain to DIV2, both inputs give me the same value - about 1100 counts (out of 4096) but with lots of noise (+/- 100 counts)

This is my setup code (for reading the external signals with external reference; what I actually need to do):

Code: Select all

                              PORT_WRCONFIG_WRPMUX   |
                              PORT_WRCONFIG_PMUX(1)  |
                              PORT_WRCONFIG_PMUXEN   |

                     ADC_INPUTCTRL_INPUTOFFSET(0) |
                     ADC_INPUTCTRL_INPUTSCAN(1)   |
                     ADC_INPUTCTRL_MUXNEG_IOGND   |
My interrupt handler is simply this:

Code: Select all

    debugPrintf("%u, ", ADC->RESULT.reg);
    debugPrintf("%u\r\n", ADC->RESULT.reg);

BTW, debugPrintf() is non-blocking, so it's not a interrupt-handler-taking-too-long issue. My ADC interrupt is being triggered 10 times a second by a timer, so it's not particularly quick. The ADC GCLK is 1.8432MHz - I have confirmed this as it's the same clock generator my debug UART uses, which works perfectly.

I have stepped through my code with the debugger several times and confirmed that the registers do have the correct values that I'm writing to them. Changing the ADC clock speed or sampling time doesn't make any difference. Neither does averaging (except for smoothing out some of the randomness). Neither does removing the input scan and only converting one input.

Does anyone have ideas of what I could be doing wrong?

[UPDATE] It was improperly soldered pins for all three analog inputs

Re: Bizarre ADC results when using external signals

Posted: Tue Apr 26, 2016 9:32 am
by sarlacii
Greetings rbinns

Each time a config issue comes up you get a split between those using the ASF, and those who are not. :) Unfortunately I am one of the people using the ASF to do the low-level config, so the only suggestion I can make is to compare what you have against the ASF ADC example. If the ASF example works as expected, then check your approach against it, to see perhaps where you have missed a step in the setup.

Given the full-scale errors, I suspect that the port pin is not set as required. Have you disabled the digital I/O, so that the ADC is the only one controlling the pin? Else your ADC could be reading the digital pull-up, and not your desired external signal.

Good luck.

Re: Bizarre ADC results when using external signals

Posted: Tue Apr 26, 2016 9:53 am
by rbinns
Hi sarlacii,

Thanks for the reply, but just in the last 5 minutes under a powerful magnifier, I discovered that three pins on the chip are not soldered properly, which just happen to be the external reference and the two analog inputs. Previous inspection didn't show the problem as it was a very, very small air gap.

I suspect this will solve the problem :)


Re: Bizarre ADC results when using external signals

Posted: Tue May 03, 2016 8:12 am
by sarlacii
rbinns wrote:I discovered that three pins on the chip are not soldered properly
Eish, that's always a killer! BGA devices are the worst for that sort of horrible error, but any small pitch pins suck for it too... esp. when you have a prototype PCB that didn't go through the usual x-ray inspection etc.

Glad you got it solved!