QD4 Internal Voltage Reference Calibration

[PatrickW]

The QD4 series contains a built-in voltage reference that is better than 1% accurate.  Not bad, but I have an application that could benefit from better accuracy.  I am wondering if anybody has tried calibrating the reference with a trim value in software, on a chip-to-chip basis.  I think this could reduce the ADC's absolute voltage measurement error by a factor of 2-3.

Our factory uses a "beehive" gang programmer.  I am thinking we would need to modify it to

1) place a highly-accurate reference voltage on one of the inputs,

2) program the chip with a measurement program that can communicate a trim value back to the PC,

3) read the trim value back to the PC

4) Have the PC program each chip with a binary containing the proper trim value (probably only 10 or so values would come into play).

If anybody has suggestions on how to accomplish items 2-4,  or if you know of a reason why this whole thing will never work or be beneficial, or if you've tried this yourself and succeeded, please let me know.

Patrick 

[bigmac]

Hello Patrick,

There seems to be a slight misunderstanding about the ADC module. For the QD4 device the voltage reference for the ADC is actually tied to the Vdd and Vss lines - this can be seen in the block diagram for the device. This means that the ADC result will be dependent on the Vdd value at the time of the measurement. The bandgap voltage reference is available for correction of the reading to allow for variation of Vdd, maybe because an unregulated battery source is utilised.

I would doubt that much additional accuracy would be gained by comparison with an external reference. Each reading will be subject to a 10-bit quantization error, plus other errors associated with the conversion process. And there is likely to be variability of individual readings due to (internal) noise within the MCU, and possibly external noise on the Vdd line.

To reduce the effects of noise, any calibration process would need to take many measurements of both the bandgap reference and the external reference, perhaps alternating the readings, and then calculate the average result. The bandgap correction factor might be expressed as a quotient of two 10-bit values, which would be applied after the Vdd correction of each reading using the nominal bandgap value.

A possible method of performing the calibration process would be to include the calibration function within your normal code, with a means to externally activate the process after Vdd is stable and the reference device is connected. The calibration process would include non-volatile storage of the calibration factor.

Regards,

Mac

Message Edited by bigmac on 2009-05-19 08:07 AM

[PatrickW]

Hi Mac,

That's exactly the situation we are in - measuring a battery's absolute voltage on Vdd using the ADC and built-in voltage reference.  The ADC (in my experience) beats its specs in terms of performance.  As long as you add a proper capacitor of 0.1 uF near the pad, it will give remarkably consistent readings that are almost always accurate to within +/- 1 bit error.   Ie if I put 5.000V on VDD and 2.444V on ADC1 and sum 100 readings, I quite often get an exact result of 500*100 = 50,000 (decimal).  Kudos, Freescale.  So my digital readings are often 0.1% accurate, I would hazard to guess that they are always +/- 0.2%.  

The trouble is that it's hard/expensive to make a really accurate bandgap voltage reference - 1% is standard, 0.5% gets expensive.  But the tempco's are not large - it's the initial accuracy that is the issue.  So I'm thinking we should be able to calibrate this out with a trim value in sw, just as would be done for a clock.  In fact, I'm surprised this is not already done by Freescale - this is why I wonder if I'm miscalculating something.

It seems like we should be able to improve the reference accuracy from 1% to 0.2-0.3% by trimming. 

Your idea of calibrating off of the programmer is GREAT - I think that might be the simplest way - at least it is not programmer-dependent, so we don't have to redesign if we switch lines or something.  Could be as simple as plugging in an accurate 5.00V supply the first time powering up the device after programming.  If you have any suggestions on how to (or how not to) implement this, please let me know.  I will have to read up on storing in Flash rather than RAM from the program itself - I'm new at MCU programming.

Patrick  

[celsoken]

Dear Patrick,

Amazing results you've got, huh!

Following Mac's workline, maybe it's good for you build for your ATE a Vdd supply based on a good voltage reference with low TC.

I've been using the LM4040 (=/- 0.1%) even for products due to the low cost of SOT-23 version. Remember to place your supply voltage feedback spot as close as possible to the UUT. I don't know how your software is going to be but maybe setting Test Vdd to 5.12V could simplify math functions during the test procedure.

The software procedure could be:

- Program MCU leaving first flash page unprotected,

- Measure Vdd, Bandgap, program trim value,

- Protect flash

Be careful with math to keep accurary, and good luck!!

Cheers,

Celso

[PatrickW]

As I said, I'm still very new at this:  What would the purpose be of protecting the flash in this case?  Is this just good practice that's used to avoid any faulty program overwriting some of the flash?  I've also been wondering about the Computer Operating Properly module - I haven't been using it because I haven't experienced problems, but is this foolhardy?

Thanks,

Patrick 

[celsoken]

Dear Patrick,

In some markets you can't afford to "hang up" and other unwanted behaviour. In order to avoid situations like this, you have to use specific methodology when you are designing an embedded product.

One simple way of thinking about that is to assume that software is going to fail. When **bleep** happens, what are you going to do about it? Then you write recovery procedures, etc, etc.

The flash protection and watchdog timers (COP) are part of the design technology regarding embedded systems. I suggest that you look for proper literature in order to understand better what we're talking about.

Some useful texts: anything from Jack Ganssle  www.ganssle.com, textbooks about software engineering would be nice too.

Regarding your specific issues, COP could be used along with proper code to assure that the program is still operating. Basically you set a timeout and your program has to respond before this timeout that usually leads to a reset. But in order to work properly, you have to write your code in such a way that assures that all processes will be covered by this check. Once you understand the mechanism and implement your software from the start to comply with this, it works fine.

Flash protection is necessary because sometimes the misbehaviour of the software could try to (e.g.) erase your flash. If the flash is protected it'll be harder or almost impossible to erase it accidentally. Notice that QD4 flash programming software must run from RAM, you'll find plenty of examples on the forum.

Good luck,

Celso

[PatrickW]

Thanks for the words on COP/Flash protection.  I understand the technical reasoning behind these things - I am basically wondering: considering that I don't use either protection, am I crazy?  Is it considered really bad practice not to use these functions, or is it really quite common for consumer applications that are not absolutely mission critical?  I started out not using COP because it made catching glitches harder during the design phase, but I suppose I should now implement it.

New Question:  I am having trouble figuring out how to store/access variables in the Flash (rather than RAM).  The CodeWarrior help is a bit too low-level for my understanding, and I haven't found a good resource on this website to explain how to do the addressing.  I figured it would just be a matter of setting up a variable as "near" or "far" but apparently that just accesses different parts of RAM.  Any resources for understanding this out there?

Thanks,

Patrick 

[celsoken · Accepted solution]

Dear Patrick,

I've being using watchdog timers for over 25 years and since it is defined at initial software design phase and that this software is been reused over and over again, it does not add time in software implementation. So I don't have reasons to avoid using it even in small implementations, and that is precisely what I do. I think most programmers create their own programming style based on their experiences and background.

Maybe you should consider as an investment for your future desings and get in-depth knowledge in these issues. It is about the same regarding flash programming, you'll have to study (yep, low level studies) so that later you can use higher abstraction levels unless there is some flash beans in PE that deal w/ stack based runtime functions. I strongly suggest you look for programming flash issues in this forum, there's plenty of them.

Good luck,

Celso 

[PatrickW]

Thanks Celso.

Patrick