XMega E5 ADC troubles?

Log in or register to post comments
Go To Last Post
12 posts / 0 new
Author
Message
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
#1
Posted by Svuppe: Sun. Jul 27, 2014 - 01:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all.

I remember that some of the earlier revision XMegas didn't come with any useful ADC calibration in the signature row.
But what about the E5? I have an early 32E5 rev B, that only has 0x00 in ADCACAL0/1. Do I need to worry much about that (as in finding a more recently produced 32E5), or doesn't it matter?

Regarding the averaging feature of the ADC. Does anyone use it successfully?
I am trying to use it in signed singleended mode, but am getting some nasty discontinuous jumps (looks like sign reversals) at certain input values, when I try to average 16 samples or more. Is that a known problem? I can't find anything about it.
I am working on simplifying my setup, so I can test this further. I am currently using a rather noisy sensor, that isn't useful for repeatable tests.

Tags:

AVR Microcontrollers, AVR XMEGA
Top
DocJC
DocJC's picture
Level: 10k+ Postman
Joined: Tue. Dec 11, 2007
Posts: 12605 View posts
Location: Cleveland, OH
Posted by DocJC: Sun. Jul 27, 2014 - 03:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Per the data sheet:

Quote:

38. Errata – ATxmega32E5 / ATxmega16E5 / ATxmega8E5
38.1 Rev. B

Issue: ADC: Offset correction fails in unsigned mode
In single ended, unsigned mode, a problem appears in low saturation (zero) when the offset correction is activated.
The offset is removed from result and when a negative result appears, the result is not correct.

While not specifically related to the data averaging feature, I wonder if the issues are related.

JC

Top
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
Posted by Svuppe: Sun. Jul 27, 2014 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EDIT: This turned out to be user error. Please see my post further down in the thread.

Regarding the average (and oversampling) feature, after a few experiments, I now have a clear picture of what is happening. And I am afraid to say that the averaging feature has one heck of an error in its implementation, rendering it more or less unusable.

We know from the XMega E manual chapter 24.8.3, that it can average over up to 1024 samples (I am not taking oversampling into account yet). Well, it does make 1024 samples and add them all together. Unfortunately, it adds them in a 16 bit register
This means that we can't use the full input range of the ADC, or the 16-bit sum register will overflow. In order for the 1024 sample average to work properly, the sum should be kept in a 22 bit register, or the input restricted to the equivalent of a 6 bit ADC.

The average feature can be used as long as the sum doesn't overflow the 16 bit register. This is only guaranteed if the average is made up of no more than 16 samples. This also means that the oversampling described in chapter 24.8.4 only works properly when trying to oversample to 13 or 14 bits resolution.

I made a small test program on the E5 Xplained board, that outputs all values from 0 to 4095 on DAC 0, and then reading it with the ADC. The ADC is set up for oversampling to 15-bit resolution, as per table 24-4. I have attached the result. The X axis is DAC output, and Y is what the ADC was reading back.

Attachment(s): 

Image icon ADC input when oversampling to 15-bit resolution
Last Edited: Mon. Jul 28, 2014 - 10:36 AM
Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2198 View posts
Posted by mojo-chan: Mon. Jul 28, 2014 - 07:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your effort diagnosing and characterizing this issue. Are you planning to report it to Atmel? If not I could on your behalf.

Top
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
Posted by Svuppe: Mon. Jul 28, 2014 - 09:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't really thought that far.
I was planning on reducing my testprogram to the simplest possible and adding some useful comments, and then present it here so others could either verify my findings, or tell me what I am doing wrong :twisted:

If this really is a bug in the E5, then the next step would probably be reporting it to Atmel.

Top
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
Posted by Svuppe: Mon. Jul 28, 2014 - 10:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And now that I am going over my code, I realize that I indeed have made a small error in the ADC initialization. The resolution in CTRLB need to be changed to more than 12-bit when oversampling.
Whether this also affects the averaging (without oversampling) or not, remains to be seen.

Top
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
Posted by Svuppe: Mon. Jul 28, 2014 - 10:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My mistake all the way.
It was RESOLUTION in CTRLB that must be set to MT12BIT when using averaging, regardless of oversampling or not. Now everything works perfectly.

Top
Torby
Torby's picture
Level: 10k+ Postman
Joined: Tue. Nov 11, 2003
Posts: 10146 View posts
Location: Bartlesville Oklahoma USA
Posted by Torby: Mon. Jul 28, 2014 - 12:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How cool.

That example you mentioned above would be helpful.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

Top
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
Posted by Svuppe: Mon. Jul 28, 2014 - 12:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Of course. Attached.

Look at the end of adc_init, and select one of the AVGCTRL settings, or make your own. Run the code on a XMEGA-E5 Xplained board. Once started, the code will cycle through 0-4095 on the DAC, and read the ADC. Results will come out on the USB-serial port at 115200 baud.

Capture the output into a text file, and open it with a spreadsheet program to plot a graph. Or just look at it directly in text.

I know that both DAC and ADC are missing their calibration initialization, but they are not available in the production signature row on my two boards (just 0x00).

Attachment(s): 

File DAC to ADC test program
Top
Torby
Torby's picture
Level: 10k+ Postman
Joined: Tue. Nov 11, 2003
Posts: 10146 View posts
Location: Bartlesville Oklahoma USA
Posted by Torby: Mon. Jul 28, 2014 - 10:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow. Thanks!

I'll examine it tomorrow.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

Top
mojo-chan
mojo-chan's picture
Level: Raving Lunatic
Joined: Thu. Jan 24, 2008
Posts: 2198 View posts
Posted by mojo-chan: Tue. Jul 29, 2014 - 08:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think they are implying that you need to do calibration yourself now. It's a bit of a pain but I suppose if you want 16 bit resolution an absolute accuracy out of a low cost micro you can't expect to avoid it. At that point you need to deal with temperature changes and the like too.

The good news is that the uncalibrated error in the datasheet looks fairly low, and if you are only making differential measurements you probably don't need to calibrate anyway.

Top
Svuppe
Svuppe's picture
Level: Hangaround
Joined: Mon. Jul 23, 2001
Posts: 289 View posts
Location: Copenhagen, Denmark
Posted by Svuppe: Wed. Jul 30, 2014 - 09:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having a bit of a linearity problem when measuring close to Vref. Something I can't remove in calibration. I'll just switch to differential measurements instead.
Btw: I don't need the higher resolution or accuracy. I looked into it for the averaging feature. Unfortunately my signal source (a Hall effect DC current sensor) is quite noisy, so I'll probably have to add additional filtering in hardware anyway.

Top