Measuring temperature with 3.3V AREF? (issue with AREF stabilization)

Go To Last Post
29 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a project where the hardware is designed such that the ADC is referenced to AVCC (3.3V).  AREF is connected to a 100nF cap to ground.

 

I wanted to add temperature measurement, so I have to switch the ADC's voltage reference to the internal 1.1V reference internally.

 

This requires a delay while AREF settles, something like 5ms.  I'd rather avoid this if possible, and it's also undocumented.  All the datasheet says is:

 

When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong.

"certain time" is not defined (resistance of the bandgap isn't specified), so I'm not sure I can count on that.  Reducing the external capacitor to 10nF will help, but it's still not really reliable.  I'd also argue that the datasheet's a little misleading, as many more than the "first" value read will be wrong.

 

I'd really like to avoid redesigning the hardware such that all of the ADC's are 1.1V referenced, if possible.

 

Is it reasonable/reliable to use 3.3V as the reference for the temperature sensor perhaps?  This is probably riskier than moving to 10nF with an excessively safe delay, but maybe it's acceptable if lower temperature resolution is needed?   (It does seem to "work")

 

Or is redesigning all the analog inputs to reference to 1.1V the only reliable option?

This topic has a solution.
Last Edited: Fri. May 22, 2020 - 08:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not just take two samples and only use the second.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An unusual approach I took to this was that I first run some software that continuously measured the reference voltage in a loop and sent it to a serial port.
I used the Arduino IDE as it has a serial monitor.
By collecting a sample of a few hundred readings I was able to clearly see in the output one of the readings regularly appeared in that output.
I used this to characterize that particular chip.

In the application I set the software to only except a reference reading that was within a percentage of the characterized figured, if it was not I discarded the reading then did another.
When the reference was correct I then took an ADC reading.
I found this to be the most reliable way to get a good reading.
I also fitted the recommended capacitor and inductor.
With a good clean layout on a prototype on a perf board I was able to get good readings down to 5 mV accuracy.
However in the application I found I had to broaden the tolerance a bit to allow for temperature variations.
Each individual chip needs to be first characterized as described,

I have also considered that the accuracy could be increased by using the on board temperature peripheral provided in the chip and then adding or subtracting a correction figure.

Last Edited: Tue. May 19, 2020 - 06:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Why not just take two samples and only use the second.

 

 

This does not work, unfortunately.  The datasheet is misleading (I would say flatly wrong) when it implies that will be the case.  The issue is settling/stabilization of AREF, which takes several ms.  Many, many samples will be wrong during this time. 

 

(It took me a while to realize this was the problem, frustratingly, because I also interpreted the datasheet as you did.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kerlin wrote:
An unusual approach I took to this was that I first run some software that continuously measured the reference voltage in a loop and sent it to a serial port. I used the Arduino IDE as it has a serial monitor. By collecting a sample of a few hundred readings I was able to clearly see in the output one of the readings regularly appeared in the out put. I used this to characterize that particular chip. In the application I set the software to only except a reading that was within a percentage of the characterized figured, if it was not I discarded the reading then did another. I found this to be the most reliable way to get a good reading. I also fitted the capacitor and inductor recommended to the Aref. With a good clean layout on a prototype on a perf board I was able to get good readings down to 5 mV accuracy. Each individual chip needs to be first characterized as described,

 

Thanks, that's quite a hack!  I suppose I could measure continuously until it stabilizes, but I don't think that will be any/much more reliable than just including a generous delay, and has the same time constant problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, just check that post again as I am making some additions to it.

Last Edited: Tue. May 19, 2020 - 06:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kerlin wrote:
I also fitted the capacitor and inductor recommended to the Aref.

I hope you ment Avcc! 

In a similar situation, I looked at my program flow and looked where "natural" delays occurred and switched the Aref there, then read the temperature value after the delay, most temps move pretty slowly so where I took that reading was not as important as the other more critical ADC readings at the higher Aref value.  So look for opportunities in your code where you can switch your Aref value in a place where you have the time to do so. 

 

Even at 1.1 volts, the resolution of the internal temp sensor is roughly 1 decree C per ADC tick, using a higher Aref would make that even coarser and the range would be smaller.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Always a negative comment.
That's why I do mostly, and will continue to, sit on the side.

The main point is not the temperature, or time, it is calibrating for that individual chip!
It works. Bye.

Last Edited: Tue. May 19, 2020 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

In a similar situation, I looked at my program flow and looked where "natural" delays occurred and switched the Aref there, then read the temperature value after the delay, most temps move pretty slowly so where I took that reading was not as important as the other more critical ADC readings at the higher Aref value.  So look for opportunities in your code where you can switch your Aref value in a place where you have the time to do so. 

 

Even at 1.1 volts, the resolution of the internal temp sensor is roughly 1 decree C per ADC tick, using a higher Aref would make that even coarser and the range would be smaller.

 

Jim

 

 

Thanks.  Sadly, I don't have any real "natural" delays, because the chip is constantly responding to commands from other sources, and guiding things like servos and whatnot based on other measured values.  I suppose I could fit one in somewhere, sigh, nothing is ever as easy as it should be.

 

But I could tolerate 2C accuracy if it came to it, as long as I could rely on it being consistent; mostly it's to sense internal overheating.  I'm afraid that if it's not in the datasheet, maybe I can't rely on it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But I could tolerate 2C accuracy if it came to it, as long as I could rely on it being consistent; mostly it's to sense internal overheating.  I'm afraid that if it's not in the datasheet, maybe I can't rely on it.

 The internal temp senor is fairly crude & make sure you do a basic cal, since it is much worse  if you don't!

 

 

Reducing the external capacitor to 10nF will help, but it's still not really reliable.

How many ms are you able to change the ref ahead of time ( to avoid waiting)?  I'm not saying it isn't true, but I've switched between both refs & don't recall seeing an extreme delay where many many samples are out of kilter.  I probably did organize them a bit so I could get some small time gap in place.  How fast do you need to take samples?

Are you changing the vref, starting a conversion, tossing the result, and doing another & keeping the result?  Does the temp sensor itself have a delay/warmup, that might make it look like the process is flawed?

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. May 19, 2020 - 10:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Grrr -- lost a long post.  Paraphrasing:  The "better" your system, the longer it will take doing no conversions, depending on leakage.

 

I don't understand about "undocumented" in #1, followed immediately by the datasheet quote.  Explain?

 

What do you see with a good 'scope probe on your AREF pins, with and without conversions?

 

There is an extensive thread on this; maybe more than one.  I'll try to find.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

But I could tolerate 2C accuracy if it came to it, as long as I could rely on it being consistent; mostly it's to sense internal overheating.  I'm afraid that if it's not in the datasheet, maybe I can't rely on it.

 The internal temp senor is fairly crude & make sure you do a basic cal, since it is much worse  if you don't!

 

 

Reducing the external capacitor to 10nF will help, but it's still not really reliable.

How many ms are you able to change the ref ahead of time ( to avoid waiting)?  I'm not saying it isn't true, but I've switched between both refs & don't recall seeing an extreme delay where many many samples are out of kilter.  I probably did organize them a bit so I could get some small time gap in place.  How fast do you need to take samples?

Are you changing the vref, starting a conversion, tossing the result, and doing another & keeping the result?  Does the temp sensor itself have a delay/warmup, that might make it look like the process is flawed?

 

The overall control loop is running at about a 6ms interval, so adding another 5ms or whatever is going to require throwing away a control cycle.  Not the end of the world, but I really with it didn't come to that.

 

I'm just grumpy that the datasheet is effectively silent on the matter, and was arguably misleading when it implied that only one sample would be erroneous (rather than 5ms of samples). There is no specified output resistance of the bandgap, so there is no way to predict (reliably) the amount of stabilization time required.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

Grrr -- lost a long post.  Paraphrasing:  The "better" your system, the longer it will take doing no conversions, depending on leakage.

 

I don't understand about "undocumented" in #1, followed immediately by the datasheet quote.  Explain?

 

What do you see with a good 'scope probe on your AREF pins, with and without conversions?

 

There is an extensive thread on this; maybe more than one.  I'll try to find.

 

The datasheet quote says nothing about the specific amount of time required for stabilization, or better yet, what the bandgap resistance is, so I can predict it.  On the contrary, it reads as if we only need to throw out one sample, which is incorrect (vague wording that's easy to misinterpret).  "A certain time" tells me nothing whatsoever when I'm trying to design a reliable system.  I find it absurd it's said this way.

 

On a scope, switching between reference sources shows an instant jump to 3.3V, then a decay over ~5ms to 1.1V, as would be expected for an RC. 

 

Clearly, 5ms seems to be enough for this particular chip, but there is nothing in the datasheet that allows me to rely on that.  What if the bandgap resistance varies between chips?

Last Edited: Wed. May 20, 2020 - 01:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just rereading the datasheet:

When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong.

I would argue that this is flat out wrong, and worthy of a published correction.  It's stated that the "first value read after the first conversion may be wrong".  This is not the case - several ms worth of samples will be wrong, many more than the first.

 

They should have said:

The bandgap reference voltage has a maximum series resistance of X ohms, so time required for stabilization would depend on this resistance, capacitance connected to AREF, and desired accuracy.  For a 100nF bypass capacitor, Y ms is sufficient to guarantee accuracy to 1 LSB.

If they had done this, it would have saved me and undoubtedly other people several hours of frustration.

Last Edited: Wed. May 20, 2020 - 01:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is the five millisecond observation with or without conversions.

Apparently you expect the datasheet to give exact values for all combinations of model, packages, clock speed, voltage levels, and other variables. Harrumph.

Re you last post, there are pretty much entirely different considerations in using bg as an adc channel, and using bg as ref. Aren't we discussing the latter?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They also mention the bandgap ref needs time to stabilize when it gets turned on (enabled)...so perhaps they are using "stabilization" to cover everything..interesting they don't provide actual numerics for stabilization time.

The classic bandgap requires software calculation cal, since its raw accuracy spec is horrific (+/-10%)...Only thing good is the low drift, once you do a cal.  Newer parts are somewhat improved in this area.

 

I wish they had a 10 cent upgrade option for +/- 1%  or +/- 0.5% !!!   I'm gonna write to Mr. Atmel & inquire.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Is the five millisecond observation with or without conversions. Apparently you expect the datasheet to give exact values for all combinations of model, packages, clock speed, voltage levels, and other variables. Harrumph. Re you last post, there are pretty much entirely different considerations in using bg as an adc channel, and using bg as ref. Aren't we discussing the latter?

 

The 5ms is with conversions, but I doubt the conversions have anything to do with the AREF voltage stabilization.  It's purely the high resistance of the bandgap that's the issue here, and the lack of documentation.

 

Don't strawman this.  The datasheet states that "one" measurement "might" be wrong due to stabilization time, which is just wrong.  The suggested replacement I wrote would be the reasonable way to document this.  I'm pretty sure the bandgap has a maximum resistance, which they know, and should just plainly state.

 

I've only been talking about switching the ADC's reference between AVCC and the 1.1V bandgap.  I'm not intending to use the bg as a channel, I didn't know that was even possible (probably isn't).

Last Edited: Wed. May 20, 2020 - 05:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

They also mention the bandgap ref needs time to stabilize when it gets turned on (enabled)...so perhaps they are using "stabilization" to cover everything..interesting they don't provide actual numerics for stabilization time.

The classic bandgap requires software calculation cal, since its raw accuracy spec is horrific (+/-10%)...Only thing good is the low drift, once you do a cal.  Newer parts are somewhat improved in this area.

 

I wish they had a 10 cent upgrade option for +/- 1%  or +/- 0.5% !!!   I'm gonna write to Mr. Atmel & inquire.

 

Right, they do, my irritation is that the datasheet only says that one measurement "may" be off if not stabilized, not several ms worth of measurements.

 

For my purposes I'm fine with 10% for temperature, but it would certainly be nice to have it more accurate.  But if it can be calibrated at programming time, and doesn't drift, I think that would cover a lot of people pretty well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much temperature change do you expect to happen in 5ms loop time?  Tell us more about your control loop, maybe its time to consider other ways to control (whatever) and monitor temperature.

An LM35 or LM36 are cheap, don't take much board space and can be read using Avcc and are more accurate to boot, seems you have wasted a lot more time on this then is needed to come to a better solution.

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

For my purposes I'm fine with 10% for temperature

Oh  no no no no, that's +/-10% for the Vref.... the temps sensor has it's own additional uncertainty (even if the vref were perfect).

I've used temp sense & found it to be pretty awful before calibration. 

After cal, it was "tolerable", to the point you could say your PCB was  "ok" or "burning up" (I do not use the noise reduction mode)

---the sensor measures the chip die, which can differ a lot from temp 2 inches away, so it is limited.

 

due to process variations the temperature sensor output voltage varies from one chip to another. Also, the internal voltage reference used as the ADC reference....

typical accuracy of temperature measurements over the full temperature range of the AVR is ±10°C after offset calibration and compensation.
 

http://ww1.microchip.com/downloads/en/AppNotes/Atmel-8108-Calibration-of-the-AVRs-Internal-Temperature-Reference_ApplicationNote_AVR122.pdf

 

Hey, the price is right!

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


jrs454 wrote:
Don't strawman this. 

I don't know what that is.  Some kind of a Wizard of Oz reference?  I'd know, if I only had a brain.

 

jrs454 wrote:
I've only been talking about switching the ADC's reference between AVCC and the 1.1V bandgap.  I'm not intending to use the bg as a channel, I didn't know that was even possible (probably isn't).

 

"AVRs measure their own VCC, but do it badly" https://www.avrfreaks.net/forum/...

 

I brought it up because you said

jrs454 wrote:
When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong.

What do you think that refers to?  But being the scarecrow...

 

Oh, I get it -- you are going to burn me in effigy?

 

Maybe a picture will help:  (same section of the datasheet btw)

 

Now, I've never done a conversion on the BG channel using the BG reference to get an offset, but I'd bet a virtual cold one you can.  Hmmm--  Use that nulling to solve the reference change problem -- change to BG reference, and do repeated conversions on the BG channel until [near] null.  QED

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. May 20, 2020 - 09:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

How much temperature change do you expect to happen in 5ms loop time?  Tell us more about your control loop, maybe its time to consider other ways to control (whatever) and monitor temperature.

An LM35 or LM36 are cheap, don't take much board space and can be read using Avcc and are more accurate to boot, seems you have wasted a lot more time on this then is needed to come to a better solution.

Jim

 

 

 

Thanks, Jim!  There won't be any change in temp over 5ms, of course.  But the ADC is running a control loop using a couple of other ADC channels from various places. Right now that loop is running at around 6ms, but that's even longer than I'd like.  And those other sources are designed to be referenced to 3.3V.

 

So I don't have the time to switch between ADC reference sources in time, that's the main issue.  I might be able to find some kind of workaround though, but no matter what I'll have to either compromise the control loop, or redesign the hardware, it seems.  Oh well. 

 

Maybe a cheap external temperature sensor is worth considering.  I do have I2C capacity available for this. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

The big issue is the AREF 1.1V seems to rely on a weak (slow) "pull down".  The aref pulls up/(drives) fast to 1.1V

 

Another AVR user came up with an interesting workaround, though it makes some chip assumptions (that this semi-pulldown condition remains in place):

 

As a workaround for the slow settling issue, I added the following logic to my ADC sampling application:

(starting at 5V internal reference)
- WANT TO change to external reference
- short AREF to Gnd (I used digital pin 3 for this)
- wait 5us
- disconnect AREF from Gnd
- change to internal 1V1 reference

With above steps, it was possible to reduce settling time from in excess of 5000us to around 5us. So, there may be hope for round-robin sampling with alternating AREF's after all. However at the added cost of an IO pin and some additional code.

 

from:

https://forum.arduino.cc/index.php?topic=22922.0

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very clever!  I wouldn't have expected a difference in time constant, looks like internally it's a diode+resistor.  We give up a precious pin but maybe...

 

avrcandies wrote:

 

The big issue is the AREF 1.1V seems to rely on a weak (slow) "pull down".  The aref pulls up/(drives) fast to 1.1V

 

Another AVR user came up with an interesting workaround, though it makes some chip assumptions (that this semi-pulldown condition remains in place):

 

As a workaround for the slow settling issue, I added the following logic to my ADC sampling application:

(starting at 5V internal reference)
- WANT TO change to external reference
- short AREF to Gnd (I used digital pin 3 for this)
- wait 5us
- disconnect AREF from Gnd
- change to internal 1V1 reference

With above steps, it was possible to reduce settling time from in excess of 5000us to around 5us. So, there may be hope for round-robin sampling with alternating AREF's after all. However at the added cost of an IO pin and some additional code.

 

from:

https://forum.arduino.cc/index.php?topic=22922.0

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very clever!  I wouldn't have expected a difference in time constant, looks like internally it's a diode+resistor.  We give up a precious pin but maybe...

Most cheapie power supplies can only push the voltage one way (usually higher).  In the other direction, the voltage just reduces as loading (internal or external) drains down the output filter caps.  So it's likely they didn't bother to actively drive the AREF in both direction...leaving us with this "problem".   Using the spare IO is a quick way to bleed down the system.   Some other users instead tacked around 1K-10K to speed things along.  Too much load, however, will  disrupt the AREF accuracy (not that it is very good)  & perhaps drift coefficient.

 

I have some 4 quadrant power supplies that can absorb external loads (like stopping a spinning motor)....good stuff! 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. May 21, 2020 - 10:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the detailed explanation, this makes total sense.

 

I still wish they would fix/clarify the datasheet though. :)

 

avrcandies wrote:

Very clever!  I wouldn't have expected a difference in time constant, looks like internally it's a diode+resistor.  We give up a precious pin but maybe...

Most cheapie power supplies can only push the voltage one way (usually higher).  In the other direction, the voltage just reduces as loading (internal or external) drains down the output filter caps.  So it's likely they didn't bother to actively drive the AREF in both direction...leaving us with this "problem".   Using the spare IO is a quick way to bleed down the system.   Some other users instead tacked around 1K-10K to speed things along.  Too much load, however, will  disrupt the AREF accuracy (not that it is very good)  & perhaps drift coefficient.

 

I have some 4 quadrant power supplies that can absorb external loads (like stopping a spinning motor)....good stuff! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure witch AVR this is, but on some AVR's (I remember tiny85) there have some threads about finding the temperature by finding the drift in the WDT (it don't have a temp sense).

 

So perhaps because your chip has one it can self calibrate that way, so when you really need the 3.3V Vref you could keep it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know I'm late to this party but I'm surprised at the amount of traction you got without once showing your temperature circuit or telling us the measurement range or resolution you required. We could have helped you design a ratiometric measurement circuit.

 

I've never tried to switch ADC reference, I've always set it and left it. My gut feeling is to expect big trouble; because as you found; you are connecting a pre-charged capacitor straight across it's output.

 

Putting that aside and onto the datasheet:

 

You called out this datasheet statement out previously:

When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong

I read that as MUX input to the ADC, i.e. MUX setting 1110   1.1V (VBG)

As such it is placed wrongly in the datasheet. It should appear in Section: 24.6.1 Analog Input Circuitry where it makes perfect sense due to the high bandgap source resistance.

 

 

Despite my negativity above, I'm with you on this one however. I found the datasheet misdirection compounded here

24.5.2 ADC Voltage Reference

...

If no external voltage is applied to the AREF pin, the user may switch between Avcc and 1.1V as reference selection. The first ADC conversion result after switching reference voltage source may be inaccurate, and the user is advised to discard this result

 That DEFINITELY needs a re-write.

 

Last Edited: Sun. May 24, 2020 - 09:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think I mentioned it was intended to detect/warn of overheating.  A large amount of precision is unnecessary; really all I was hoping for was to have the inherent precision of the chip itself (possibly with one time calibration), maybe I could live with a little less. But my results were obviously radically wrong and unusable.

 

(There is no temperature "circuit" - it's on chip only.)

 

Clearly the switching of references is a slow process.  But I, like many other people, as you recognize, took the datasheet at its word when it claimed the "first" sample may be wrong (much like changing MUX channels), not that several ms worth of samples was sure to be wrong.  This caused several hours of wasted time, head-scratching and frustration totally unnecessarily.  The datasheet really ought to be fixed.  I have no idea where to request such a thing.

 

N.Winterbottom wrote:

I know I'm late to this party but I'm surprised at the amount of traction you got without once showing your temperature circuit or telling us the measurement range or resolution you required. We could have helped you design a ratiometric measurement circuit.

 

I've never tried to switch ADC reference, I've always set it and left it. My gut feeling is to expect big trouble; because as you found; you are connecting a pre-charged capacitor straight across it's output.

 

Putting that aside and onto the datasheet:

 

You called out this datasheet statement out previously:

When the bandgap reference voltage is used as input to the ADC, it will take a certain time for the voltage to stabilize. If not stabilized, the first value read after the first conversion may be wrong

I read that as MUX input to the ADC, i.e. MUX setting 1110   1.1V (VBG)

As such it is placed wrongly in the datasheet. It should appear in Section: 24.6.1 Analog Input Circuitry where it makes perfect sense due to the high bandgap source resistance.

 

 

Despite my negativity above, I'm with you on this one however. I found the datasheet misdirection compounded here

24.5.2 ADC Voltage Reference

...

If no external voltage is applied to the AREF pin, the user may switch between Avcc and 1.1V as reference selection. The first ADC conversion result after switching reference voltage source may be inaccurate, and the user is advised to discard this result

 That DEFINITELY needs a re-write.