How accurate is ST VREFINT Calibration?

[mp035]

I am using STM32F030F4P6.

VREFINT is supposed to be calibrated at 3.3v +/- 10mV and 30 degrees C. In my application the VREFINT calibration value is 1543 meaning the reference voltage is 1.243V (3.3/4096*1543) this is on the high end of the spectrum, but within limits.

When using the calbirated VREFINT, I found that my VDDA calculations were stable, but off by a bit over 1%. I have a VDDA/VDD voltage of 3.3013V measured with a calibrated multimeter (I have a DC standard to check calibration) and ambient temperature is 24.3 deg C.

Taking the average of 4000 samples from VREFINT with this setup yields a reading of 1527 or 1.230V which is bang-on specification. It is also 1.01% different to the calibrated value. How accurate should I expect the VREFINT calibration value to be? I ask because if factory calibration should be better than this, I need to find out where my design is inaccurate.

[waclawek.jan]

This is given in the Datasheet to the part, together with the required times after switching on the VREFINT source, and minimum sampling time.

The consumption from VDDA is pulsed, so it needs to be not only precise, but also be decoupled enough. VSSA (ground) arrangement is important, too.

JW

[mp035]

Thanks for the reply, but I don't think it is. To be clear I am looking for an indication of the accuracy expected from the FACTORY CALIBRATION PROCEDURE of VREFINT. NOT THE ACCURACY OF VREFINT itself.

[Uwe Bonnes]

With the STM32F030 you have choosen a part from the Value line where many tests and calibrations are not done for costs reasons. Study the datasheet of thre F030 and compare to a the parts with more characterisation to find out what has been left out.

[mp035]

I have done some testing to try to prove where the inaccuracy lies (in my system or in the VREFINTCAL value). To provide some quantifiable evidence, I performed tests using a calibrated Keysight multimeter (model U1281A), and a Kyoritsu DC standard (model 2553). All supply rails and reference voltages were checked with an oscilloscope to ensure no interfering noise is present on the supply rails or the sampled voltages. The sampling was done using 200,000+ samples which were checked in 4,000 sample blocks to ensure that readings were consistent (max of 1LSB variance between readings) and no outliers were present.

Method:

3.2686V is applied to VDD/VDDA of the MCU as a power/reference source. The MCU core is clocked at 48Mhz via PLL running from an external 4Mhz Crystal. The ADC is calibrated according to the datasheet and set to sample at 4Khz via Timer3. The ADC clock is derived from HSI14RC and sample time is 71.5 cycles. The Kyoritsu DC standard is set to 1.230V (measured at 1.2296V on the PCB) and applied to an external input of the ADC. The readings taken from the external input are compared to VREFINT readings, and the calibration value supplied by ST.

*Note: The ambient temperature in the test environment is 23.5 degrees C. Temperature variance at this value should be insignificant, so has not been accounted for.

Tested Values:

VDD/VDDA: 3.2686V

ADC Reading on external 1.2296V standard: 1540

ADC Reading on VREFINT: 1541

VREFINTCAL value: 1543

Calculations:

EXT Standard measurement: 3.2686 / 4096 * 1540 = 1.2289V

VREFINT Reference measurement: 3.2686 / 4096 * 1541 = 1.2297V

VREFINTCAL reference voltage: 3.3 / 4096 * 1543 = 1.2431V

System inaccuracy (derived from external reference): (1.2296-1.2289) / 1.2298 * 100 = 0.06%

VREFINTCAL inaccuracy (assuming 0% system inaccuracy): (1.2431 - 1.2297) / 1.2297 * 100 = 1.09%

Results:

VREFINTCAL accuracy range (including system uncertainty): 1.03%-1.12%

The error appears to be almost entirely due to inaccurate VREFINTCAL. Looks like the ST calibration value is useless for any sort of real accuracy! I hope this information helps someone.

[waclawek.jan]

This is interesting and I don't doubt your findings. I would like to discuss this further - as you've said in the hope it will be helpful for the community, I personally don't use the STM32 internal ADC in no application where any higher precision would be needed.

• did you switch off VREFINT between the measurements, and if so, did you observe tSTART? Could you perhaps publish the code you've used?
• can you please repeat the measurement with a different sampling time? Maybe try to push to extreme?
• nice touch with using an external reference with similar voltage, takes out doubts with regards to offset and integral nonlinearity
• what is the datecode of device you've used? Can you please retry with other specimens, or perhaps also devices in different package? (maybe on Nucleo/Disco boards)? The reason for this question is erratum Imprecise V REFINT calibration values in the 'F303xB/C errata, ES0204 Rev 10. The 'F3 were introduced roughly at the same time as 'F0 and they bear lots of similarities.

Thanks,

JW

PS. @Amel NASRI​  , can ST please comment on this?

[Amel NASRI]

Hi @mp035​ ,

Thanks for sharing this detailed description and the deep results. Now I don't have the answer to this topic, but I'll be checking with our experts and will come back to you.

Meanwhile, and if you are not already aware about it, please have a look to AN2834 How to get the best ADC accuracy in STM32 microcontrollers.

-Amel

[mp035]

@Community member​ Thanks for the reply, VREFINT is activated at startup and stays active, tSTART is observed on startup. This project has no constraints on power consumption so everything stays switched on. Sorry, but I have packed up the test setup, removed the testing code from the source files and moved on to other portions of the project, so I don't really want to waste more time in testing. I will be calibrating out the error anyway, but I needed to prove where the inaccuracy was, to ensure that it was not caused by a fault in the circuit or code. I am happy to share the ADC code, and always welcome a critical eye on my work. I have created a gist here: https://gist.github.com/mp035/09b4cf7e82c6f59ccf0363632726a375 note that the Gist is just a copy of the ADC code from my application, NOT THE EXACT TEST CODE. ADC setup is done via STM32Cube before app_adc_startup is called.

I don't know how to read the date code, but attached is a photo the acutal chip tested.

@Amel NASRI​ Hi, thanks for the reply. Yep, I'm aware of the application note. Actually, I have never had any trouble with the ADC being inaccurate in the many variations of STM32 that I have used. Even in this case, the error in VREFCAL will be calibrated out to zero when the entire system is calbirated. It was just that my initial values were different to what I expected, so I needed to confirm where the error was to ensure that the rest of the system was operating as expected.

[waclawek.jan]

mp035,

Thanks for the explanation.

I don't know how to read out the datecode internally either, if it's present at all, but the photo is great. 452 that's last week of 2014 (I expressed my doubts about the 1-digit year in light of ST's 10 year commitment, to be ignored as usually) - that's quite an early piece. I don't remember when the 'F0 were introduced, but the mentioned 'F303 inaccuracy erratum mentions dates prior 6xx.

JW

[Antoine Odonne]

Dear mp035,

It's a very interesting analysis, thank you for sharing this and your concern on the calibration value for Vrefint is valid in regards of the data listed above.

We realize this calibration instability for F0 family in 2015, main issue was that the calibration was performed during wafer testing using particular needles on VDDA (the calibration is performed by in chip ADC) with a non negligible resistivity on its path, this leads to important voltage drop on VDDA (and consequently Vref +) and thus calibration value for Vrefint artificially pushed up.

The samples with a date code of "540" and above presents a more accurate value for calibration field of Vrefint.

I hope this answer doesn't come too late in your development process.

Best regards,

Antoine

[Uwe Bonnes]

****** tricky error sequencing. Thanks for sharing! However I do not see a hint in the errate sheet. Did I miss the hint?

[Antoine Odonne]

Dear Uwe,

I agree it lacks clarity in tracking down this issue.

It is I think linked to the fact that in parallel, we realized that the DS data for Vrefint itself were incorrect in DS, It has been associated to a F030 DS update in January 2017 and a PCI "product change information" with below descritpion (not referencing calibration correction explicitly but the VREFINT testing improvement) it was previously stated that Vrefint typ value was 1.20V:

Extract of PCI

"No change on product function nor performance.

VREFINT documentation is updated thanks to 100% production testing:

- Minimum value is improved.

- Maximum value, that was previously based on characterization, is now aligned with

production testing criteria.

- Typical value is updated accordingly."

I hope it helps explain a bit the situation.

Best regards,

Antoine