Interfacing to STM32F767ZI temperature sensor

[PB1]

Hello to everyone. I am teaching an embedded system lab courses and this is our first year with a STM32F767ZI Nucleo board. We are at a point where we want to exploit the on-board temperature sensor to generate some input data. In our first experience with the sensor we are setting ADC1 in single channel, continuous conversion mode, and we are working with interrupts. The first thing I notice is that, if I apply the conversion formula on the MCU reference manual (RM0410 pag. 466, T = (V_sense - V_25)/Avg_Slope + 25), where V_sense is the value read by the temperature sensor and all the other data are on the datasheet, I obtain completely bogus values for T, of the order of 100 °C. Instead I found an application note (AN3964), that discusses the use of the temperature sensor for STM32L1x microcontrollers, and suggests a two-point approach based on the calibration data TS_CAL1 and TS_CAL2 to calculate the temperature. This yields temperature values much more realistic, closer to that of room temperature. My first question is if others experienced such a large discrepancy between the two methods.

My next questions are about my ideas for evolving the lab experience. The next step would be introducing multi-channel data acquisition via DMA. To this end my rough idea is to acquire both the temperature and the Vrefint channels from ADC1 and to use these data to apply the drift formula for battery-operated devices that I found on AN3964 to correct the sensed value. The formula is V'_sense = V_sense * 4096 * Vrefint / (V_DDA *V_REFINTCAL), where V'_sense is the after-correction value for V_sense, V_DDA is the ADC reference voltage, and V_REFINTCAL is on the datasheet. My questions are:

1- I might be completely dumb, but I cannot find how to obtain V_DDA. Is it the same as Vbat channel in ADC1?

2- This formula might be OK for STM32L1x, but what about STM32F767ZI? I am especially concerned about the 2^12 = 4096 factor.

3- Again, I might be completely dumb but I cannot understand whether Vrefint changes in time, and so must be resampled, or is stable, and so can be acquired once at startup.

Of course any suggestions to make the example more realistic, or to find a better example, are welcome.

Thank you

Pietro

[waclawek.jan]

0.

I never tried without the calibration values, but yes, the difference IMO may be significant. The "sensing element" is probably just a simple diode

thus prone to process variations.

Note, that the sensor measures the *internal* temperature of the chip, and that can easily be 20-30degC higher than the ambient - given

"workload" (expressing itself as current consumption) and thermal conductivities (IMO in school environment this may be a great opportunity to

demonstrate both (does the Nucleo have a facility (jumper) to measure chip's current?) - if the chip runs suitably hot cca 50deg.C, the latter can

be demonstrated spectacularly by actually *cooling* down the chip by pressing finger on the package).

1 . , 2., 3.

I don't know where you have that formula from - I can't see it in AN3964 - so don't know what the individual values in it represent.

I concocted a writeup attempting to clarify things, maybe I made them worse.

http://www.efton.sk/STM32/STM32_VREF.pdf

 Comments are welcome.

[EDIT] The writeup was written with voltage measurement in mind. For temperature, the formula is given e.g. in the 'L4 RM (don't ask me why this was not propagated to other RM and/or AN3964 and/or other suitable AN):

The basic formula is:

T = TS_CAL1_TEMP+(TS_CAL2_TEMP - TS_CAL1_TEMP)/(TS_CAL2-TS_CAL1)* (TS_DATA -TS_CAL1)

And the correction is described as:

 For example if V REF+ = 3.3 V and TS_CAL data are acquired at V REF+ = 3.0 V, TS_DATA must be replaced by TS_DATA x (3.3/3.0).

but you can also easily derive it yourself, from the assumption that the voltage output of temperature sensor is linear. [/EDIT]

JW

[PB1]

You are right, the formula is not in the application note, but I derived it from a remark on the application note itself. For consistency with your writeup (that was very useful in clarifying things, thank you!) I will report the formulas below. The AN says (page 6) that, to compensate the fact that the temperature sensor factory calibration data were derived with a V_cal, rather than V_refext, reference ADC scale, we shall normalize MEAS as follows:

MEAS_NORM = V_cal * MEAS / V_refext

and then (if I did not understand bad) replace MEAS with MEAS_NORM in the formula of the temperature reported on page 9. This however disagrees with the sentence about the correction in the L4 RM that you are citing, because according to the AN formula if calibration data are acquired at 3.0 V, and the current Vref+ voltage is 3.3 V, TS_DATA must be replaced with TS_DATA * (3.0 / 3.3). Am I wrong somewhere?

[waclawek.jan]

Pietro,

If in doubts, invent some credible values and test your formulae.

The formula you are referring to, from AN3964 page 6, is in original

ValTS = 3 * ValTS_bat / VDDA

(accompanied with text "Since the temperature sensor factory calibration data are acquired with the ADC scale set to 3 V, we need to normalize ValTS_bat to get the temperature sensor data (ValTS) as it would be acquired with ADC scale set to 3 V" which gives the context, VDDA being VREF of the actual measurement ValTS_bat, i.e. the "battery voltage".

So, let's assume the temperature sensor's output is 2V and the battery voltage = VDDA = 2V; clearly ValTS_bat = 4095.

According to that formula, the corrected ValTS would be 3 * 4095 / 2 which is obviously nonsense as it's >4095.

So, the formula in AN3964 is incorrect (@Amel NASRI​ , can you please have a look at this?)

JW

PS. I amended the writeup by the temperature measurement, current version is v2.1

 PS2. I wonder how many errors did I do in the formulae in that writeup... =)

[Tesla DeLorean]

VDDA is likely wired to the same 3.3V (or 3V) supply everything else on the board is wired too, check the schematic.

Given the expectations that data sheet has of VREF+ and VDDA, and VREF- and VSSA, they typically have the same voltages as each other.

The VREFINT is the 1.21V (or whatever) bandgap voltage.

[PB1]

Hello Clive. I was able to track VDDA on the schematics, and it is indeed shorted to VREF+ and, as far as I could understand, to VDD. From hence I am unable to proceed (I conjecture that VDD is 3V, at least when the board is powered via ST-LINK). However it is less important now that I have the formulas to calculate the temperature from just ADC reads. Thank you.

[waclawek.jan]

Once Clive started this issue...

> I was able to track VDDA on the schematics, and it is indeed shorted to VREF+

Today I was discussing this thread with my friends and one of them brought up the issue of the requirement of VDDA being very close to VDD, which in smaller mcus where VDDA is tied to VREF+ prevents to use a precise voltage regulator supplied from VDD being used as reference, as they usually require quite some voltage drop (and using two regulators, one precision for VDDA/VREF+ and other for VDD is problematic as it's difficult to ensure they won't depart from each other more than the allowed difference throughout powerup/powerdown). So, we went to look at which small STM32 do provide separate VREF+, to find out that from the "old ones" and excluding the insane WLxxx packages, oly some 'F401 are available in QFN48 with separate VREF+ - but then there's a whole bunch of 'G0 and 'G4 in 48-pin packages even QFP providing that.

And that lead me to have a look at the 'G431 Nucleo https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-nucleo-boards/nucleo-g431rb.html - and indeed, not only has it the separate VREF+ brought out, but there's also a TL431-family reference onboard, which can be jumpered to two voltages and then be jumpered onto that VREF+.

So, maybe that - together with the onchip OPAMPs and whatnot - might be a better option to explore the analog facilities of STM32s.

JW