STM32L0x2 bug in reference manual

[MWebj]

RM0376 Reference manual for STM32L0x2 DocID025941 Rev 5 states in 14.9 "Temperature sensor and internal reference voltage" :

The following formula gives the actual VDDA voltage supplying the device:
VDDA = 3 V x VREFINT_CAL / VREFINT_DATA

This can't be right! If VDDA is greater than 3V then VREFINT_DATA > VREFINT_CAL, but the formula above will yield an actual voltage < 3V. The correct formula must be

VDDA = 3 V x VREFINT_DATA / VREFINT_CAL

How on earth has this been able to passed the documetation review???

[waclawek.jan]

> If VDDA is greater than 3V then VREFINT_DATA > VREFINT_CAL

VREFINT_DATA is the readout the ADC takes from the internal VREF source. Let's assume that's internal source is 1V (it is not, but let's assume that for sake of simlpicity). If VDDA=VREF+ = 3V, ADC readout will be one third of the full range (which is 4095 for 12-bit ADC), i.e. around 1365. That's what has been measured by the manufacturer and stored in the system memory as VREFINT_CAL.

Now let's increase VDDA=VREF+ to 4V (again it can't be done in reality, but for the simplicity let's assume that it can be). The readout for 1V internal source is now one fourth of the full range, i.e. around 1024 - so for increased VDDA, VREFINT_DATA < VREFINT_CAL.

Maybe you might want read my writeup on this topic.

JW

[MWebj]

No, VREFINT_DATA is not the readout from the internal VREF source. It's the A/D conversion of the external Vdda pin on the processor. VREFINT_CAL is the factory stored ADC value of the internal precise voltage reference of 3V. It just makes no sense in multiplying 3V with the corresponding ADC value as is done in the reference manual.

It's like saying that if I'm driving at 90km/h and the engine is running at 3000rpm then the speed from the rpm should be

speed = 90 * 3000 / rpm

Because that would mean that if engine was running at 6000rpm then car would go 45km/h. And I can just conclude that if I follow the reference manual and try to establish the Vdda voltage then I get a completely incorrect value, whereas the corrected formula produces what I can measure with a DVM on the pin.

[waclawek.jan]

> No, VREFINT_DATA is not the readout from the internal VREF source.

My RM says otherwise:

But I understand your confusion. The RM should be clearer in stating, that that formula is to be used when VREF+ is tied to VDDA, and their voltage is not known (the intended usage of this is in direct-battery-powered appliances).

JW

[MWebj]

This is really wheird. Theoretically the formulas in the RM are correct, but not in practice.

VREFINT_CAL is 1667 on my chip. For VREF+ == 3V ->

VREFINT_V / 3 = VREFINT_CAL / 4095 -> VREFINT_V = 1,221 which is ok acc.to datasheet.

Measuring ADC_IN17 (verified that it's set in CHSELR) which is connected to VREFINT ->

VREFINT_V * VREFINT_CAL / _VREFINT_DATA should acc.to theory give VREF+, which on my chip is connected to VDDA why it is physically measureable on the PCB.

VDDA on my board is approx 3.3V, so acc.to theory should (as you also pointed out above) VREFINT_DATA be less than VREFINT_CAL. But it isn't.

Instead VREFINT_DATA = VREFINT_CAL + dV = 1842 which naturally produces an incorrect VREF+ voltage by the formulas.

But it turns out that if I feed (VREFINT_CAL - dV) into the formulas above, then I get the correct VREF+(VDDA) value !!

And just using 3.3V as a rough estimate of VREF+ used gives VREFINT = 3.3 * 1842 / 4095 = 1,48V which clearly is incorrect.

Two other channels measuring other external analog sources produces ADC values which even with above estimate of VREF+ matches physically measured values. So the ADC setup works.

So the qestion becomes, what the heck is measured on ADC_INT17 ??

And why is the value so exactly mirrored around the VREFINT_CAL value?

[MWebj]

Found the problem. Obviously the setting of ADC_SMPR is extreamly important for the validity of the ADC value. As has been discussed above must the conversion value of ADC_INT17 (VREFINT_DATA) be lower than VREFINT_CAL which for my chip is 1667. And as can be seen in the table below must ADC_SMPR be set to a value > 12,5 ADC Clock cycles to even fulfill that requirement. And a stable value seems to require a 79,5 Clock cycles or more.

The conclusion of this is that one has to manually test what value to use before even considering proceeding with any calculations on the ADC results.

ADC_SMPR clock cycles                 VREFINT_DATA   
1,5                                       2428
3,5                                       2305
7,5                                       2089
12,5                                     1839
19,5                                     1520
39,5                                     1510
79,5                                     1506
160,5                                   1505

[waclawek.jan]

> And a stable value seems to require a 79,5 Clock cycles or more.

I believe you can find this parameter in the datasheet - not in terms of ADC clocks, but as an absolute time.

JW