K70 Temperature reading - Slopes

[crezyoz]

I am attempting to read the temperature from the K70 and compute the degrees.

The docs mention a warm slope and a cold slope. I have found a slope value in the K70 docs of 1.715 mV/C.

I am not sure how this corresponds to the Warm / Cold slope values I should be using in the temp calc. I have looked at AN3031, which addresses the HC08 MPU.

The values for the slopes in AN3031 are 1.769 (Warm) and 1.646(cold).

Please advise.. or better yet.. if there is a code sample for this computation it would save me time and help me understand the process.

thank you!

P

[egoodii]

AFAIK, Kinetis has only the 'one slope' that is applied at all temperatures, so you don't need to vary the equation based on the conversion result.  BTW, I find that with integer math it is much easier to look at the slope as 583 C/V. -- No fractions, no divide.  (int32_t)TEMPx1000=25000-( Vtemp(mV)-Vtemp25(719mV) )*583

[crezyoz]

" Thanks EARL! I was beginning to think that was the case. Where in the heck did you finally find that info? All I keep getting referred to it AN3031."

so Vtemp would be =  conversion * 1715?

But in section 39.4.9 the of the K70 ref manual it does state two curves.

Though in the ADC Electricals it does say "Across the full temperature range of the device"

I'm going to give this a shot!  REALLY appreciate it! Still a little confused tho..

[egoodii]

I've made these 'temperature' routines a couple of times, and honestly I find AN3031 to be a little 'deep' trying so hard to rework the 'basic' formula into AtoD units everywhere. I find it much easier just to keep everything in millivolts and integers. If your Vref is 'good' then mVs are easy to convert into. If not, you can try to rely on the internal bandgap to calculate the Vref in a simple inverse-calculation, but the internal isn't that tightly guaranteed(+/-3%!).  If you know Vref, then Vtemp (measured temperature sensor volts) in mV is your reference (in mV, say 3000 from a REF3030) times the converted ADC result and then divided by the total range (4096 for 12 bits), since 3000/4096 would be the ADC 'step sizes'.  The K70 'ref' manual is written for the general case, you have to rely on the electrical sheet for the numbers -- it has one slope, so one slope it is.

[crezyoz]

Earl.

Do you mind if I ask how you arrived at 583? I am trying your method and comparing it to the regular floating point method and it is not correct. So I must be doing something wrong.

This is a quick test routine:

int tempInC, intTempInC;

float vTemp,vTemp25;

float step = (float)(3.3/65536.0);

vTemp25 = 0.719;

vTemp = (float)cpuTemp * step;

intTempInC =  25000 -((vTemp - vTemp25) * 583);

tempInC = (int)(25.0 - ((vTemp - vTemp25) / 0.001715));

printf("\r\n CPU Temp = %d C  %d C",tempInC,intTempInC);

Thank you sir.

[egoodii]

One other thing you have missed -- to keep everything Integer, the Vtemps in my original work need to be in mV, so Vtemp25mV=719, and the measured CPU temp needs to be kept in integer mV as well, so Vtemp_mV=3300L*cpuTemp/65536.  And the result will be in mC:

(int32_t)intTempInmC =  25000 -((vTemp_mV - vTemp25mV) * 583);

Or, rounded to C:

intTempInC = (intTempInmC + 500)/1000;

[adampribyl]

The problem with this calculation is that the 719mV for 25C is at Vdd=3V, but phil is using 3.3V, therefore the step size is IMHO wrong. This is why AN3031 is using so cryptic calculation based on bandgap and Vdd.

[egoodii]

I'm not sure what you mean.  In the device data sheet, Vtemp25 is indeed called out as 719mV, and the slope as 1.715mV/C (both typical).  Those are 'absolutes' based on semiconductor physics -- the whole 'variation with Vdd' calculations as per AN3031 is because they wanted to represent everything directly in ADC steps, and thus as a % of Vref the Vtemp measurement varies.  My calculations try to keep it all represented in 'true mV', dispensing with ADC units in the 'Vtemp_mV=3300L*cpuTemp/65536' operation (which is, of course, for a 3300mV Vref in that equation -- for my work, Vref is 3.00V+/-0.6%(all errors) from a REF3030@75cents.).  As you mention, part of AN3031 is also in the attempt to 'calculate' Vref 'backwards' from the on-chip bandgap, which is much less accurate at +/-3% (hardly better than garden-variety 3.3V regulators...).

[adampribyl]

OK, you are probably right. It could be I got confused by the graph in AN3031 and that the tables with Vtemp25 value is labeled with Vdd=3V. So you thing the Vtemp25 will not change with Vdd?

[egoodii]

AN3031 is 'particularly confusing' in its attempts to relate everything to AtoD counts.  Granted, at some point 'every measurement is a set of AtoD counts', but there is little point to dragging that metric thru all subsequent calculations.  Take the basic measurements in Figure 1, and let's just use 0C as our point:  From VDD=3.6V we get about 210 counts, and 210/1024*3.6=0.738V.  Dropping all the way to 1.9V nets 400 counts, and 400/1024*1.9=0.742V -- well within 'graph approximation' error to the SAME actual measured voltage for 0C (as opposed to 25C, which is about 200 counts at 3.6V or 0.703V for this example chart). It is like AN3031 is 'going out of their way' to make this measurement confusing...

If we change the measurement-conversion-result to mV, then 'Equation 1' can be applied directly using the mV values directly from the part datasheet.  My only change to Equation 1 is that instead of dividing by 0.001715V for the slope, I multiply by the inverse (583) -- better all around.  And mV returns mC.

[adampribyl]

OK, I agree, thank you.

[egoodii]

This on-chip temperature measurement is a 'variation' on measuring a Vbe 'bandgap' voltage variance over temperature, presumably using a ratio process.  In any case, that electron-activation-energy physics sets the voltage, with 'secondary' influences only based on things like activation current, which is surely 'well controlled' over Vdd.  Suffice it to say that thru all Freescale parts I have used this math on, I have not found absolute VDD to be important at all.

[crezyoz]

Earl. Thank you for taking the time to explain that. Greatly appreciated. It's deadline time and I am a bit frenzied.

[egoodii]

So, do you have some resultant 'printf' output you could share across a bit of a test range?  The same basic integer equation running on a KL1-family processor yields 23 at 23C, 83 at 85C and -43 at -40C -- not too shabby.  I expect your integer results should track most satisfactorily with your floating-point?

[crezyoz]

Hey Earl.. sorry I missed your post. I haven't had time to address that. It's only called rarely in my design. When the user requests it. So I placed your response in near that code as a comment for when I finally get back there! The unit has shipped already so I barely got everything else done!

[egoodii]

583 is 1/0.001715.  Integer, and saves a divide.