• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 31 subscribers
  • Views 645 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GH6PM: negative temperature readings of the internal temperature sensor

rohith banoth
Prodigy 210 points
Part Number: TM4C123GH6PM

Hi ,

TEMP = 147.5 - ((75 * (VREFP - VREFN) × ADCCODE) / 4096) , this is the formula that is taken as a reference from the data sheet to calculate the temperature .

We have some challenge in computing the negative temperature values.

below is the code snippet:

unsigned char
get_temp(void)
{
    unsigned int count = 0;
    unsigned int temp_X_10 = 0;
    unsigned char temp;
    count = adc_count_volt_seq1[2];   // the ADC _CODE read from the internal ADC of MCU .
  
    temp_X_10 = (1475 - ((75 * 30 * count)/4096)); //VREFP-VREFN =3 V
    temp = temp_X_10/10;
  
    return temp;
}

here the temp is defined as unsigned char and since there is no provision to send the values to cpu in the form signed char it is declared to be unsigned char.

when the temp_X_10 value goes negative , the final temp value that is computed results to be 153 and keeps on reducing with increase in the negative value of temp_X_10 .

So when this 153 is send to CPU how can it be decoded to the actual negative temperature value ?

it would be very thankful if there is any solution .Thanks in Advance .

Regards,

Rohith.

  • 0
    TI__Guru*** 135355 points

    Hello Rohith,

    You are using unsigned variables, so if you go into the negatives, the sign bit will throw off your results. You need to use signed variables. Try again with proper signed variables, and honestly for the main calculation, use a float for highest accuracy.

  • 0
    Guru 117855 points

    Greetings,

    Our tech group does not agree w/your finding of "153" as the (hoped for) ADC reading (spanning 0 - 4095) resulting from the MCU's juncture temperature equaling 0°C.   Instead we find that ADC reading to be "2686" - which rather nicely agrees w/the temperature curve provided w/in the MCU manual.    You don't "show your work" - thus we cannot advise as to how you arrived at "153" - yet that's (assured) incorrect.   (as it strays FAR from the manual's temperature curve!)

    We're providing 3 series of variable captures - under IAR - proving out our "2686" ADC result when the junction temperature (nears) 0°C.   By changing the variable (we called it "temp") to an "Integer" (i.e. Signed) the switch from Positive to Negative Junction temperature very nicely revealed.    You may note our vendor agent "Ralph" advised similarly.

    Note (again) that this is MCU Junction Temperature ... NOT the temperature of the MCU's surrounding environment.   And - based upon MCU System Clock, Number of Peripherals in operation, and GPIO output load - along w/the surrounding temperature - the MCU's junction temperature may NOT prove of great value.

    Follows our "simplified code" - we elected not to employ "float" as the junction temperature is unlikely to require such accuracy - and working entirely via integers - we can resolve the temperature (as shown) w/in a degree or two.   (i.e. Clearly - "Good for Gov't Work!")

    Credit "Cassandra" one of our college-student staff - virus-free - and "Working Saturday" for this "compressed yet highly detailed" data presentation!    She employed the suffix "p" for positive temperature; "n" for negative temperature; & "0" as the temperature "crosses" polarity.   We found her "singular code run" (as shown below) convincingly able to display the temperature transitioning above & below 0°C - which (somehow) eluded the poster...

  • 0 in reply to cb1_mobile
    Prodigy 210 points

    Greetings,

    Thanks for the response .

    Below is the output of the code run , which shows the values as 153 if it goes negative .

    The reason being the declaration of "temp" as unsigned char ...my question is that i can't avoid using unsigned data type so wanted to know is there any way to obtain the exact value of temp from the result obtained using unsigned data-type.


    CODE:


    #include <stdio.h>

int main()
{
   
   	unsigned int count = 0;
	unsigned int temp_X_10 = 0;
	unsigned char temp;
	for(int i=2680; i<2691;i++) {
	count =i;
	printf("\n count is %d",count);
	temp_X_10 = (1475 - ((75 * 30 * count)/4096));
	printf("\n temp_X_10 is %d",temp_X_10);
	temp = temp_X_10/10;
	printf("\n temp is %d",temp);
	}
	return 0;
}

    OUTPUT:

    count is 2680
 temp_X_10 is 3
 temp is 0
 count is 2681
 temp_X_10 is 3
 temp is 0
 count is 2682
 temp_X_10 is 2
 temp is 0
 count is 2683
 temp_X_10 is 2
 temp is 0
 count is 2684
 temp_X_10 is 1
 temp is 0
 count is 2685
 temp_X_10 is 1
 temp is 0
 count is 2686
 temp_X_10 is 0
 temp is 0
 count is 2687
 temp_X_10 is -1
 temp is 153
 count is 2688
 temp_X_10 is -1
 temp is 153
 count is 2689
 temp_X_10 is -2
 temp is 153
 count is 2690
 temp_X_10 is -2
 temp is 153


    Regards,

    Rohith.

  • 0 in reply to rohith banoth
    Guru 117855 points

    My friend,

    rohith banoth said:
    Below is the output of the code run , which shows the values as 153 if it goes negative .

    Once more - the brevity of your response - as well as the "153" result - yield continued, "helper discomfort."

    Our detailed report earlier revealed the ADC's count reading at/around 2686 when the MCU's junction approached 0°C.   

    Kindly note the temperature curve (Pg. 813, '123 manual):  Does it not (clearly) reveal that "153" (either °C or °F or something else - you fail to specify units) is unlikely!

    Have you "Missed the fact" that the (equality) 1475 = ((75 * 30 * count)/4096)); escapes the requirement for a "further" division by ten?   (as (both) sides of the equation have been multiplied by the same constant! [10])   A confirming check of this work appears upon the graph, below.

    Time for your "Green Tipped Pen!"

  • 0 in reply to cb1_mobile
    Prodigy 210 points

    Greetings ,

    There is no bias to the point that "153" is unlikely and i completely agree that according to the spec/description 153 is not predictable.

    May be Me mentioning the value as "153 " had created a bit confusion.

    My whole point of concern was the output that has been obtained after the calculation is stored in a variable "temp" which is of "unsigned char " data type but ideally works fine for Positive Temperature values but not for negative temperature values as it should be of signed data type to store negative values.

    Since there is no provision for me to send the signed values to CPU , i am forced and bound to use the unsigned data type only.

    So now when unsigned data type is used , if the result that is obtained after all the calculation is for suppose to be "X" then how can it be converted to the actual signed value of Temp is my only concern.

     " Have you "Missed the fact" that the (equality) 1475 = ((75 * 30 * count)/4096)); escapes the requirement for a "further" division by ten?   (as (both) sides of the equation have been multiplied by the same constant!) "

    Regarding the point mentioned above , temp_X_10 = (1475 - ((75 * 30 * count)/4096)) is the formula used.

    the equation 1475=((75*30*count)/4096) holds good only when temp_X_10 is zero. Ideally the equation would be

    1475 - temp_X_10 = ((75*30*count)/4096) and for all the values other than zero divison by 10 is must to derive to the equation 

    147.5 - (temp_X_10/10) = ((75*3.0*count)/4096) on replacing temp_X_10/10 with temp , results in 147.5-temp =((75*3*count)/4096) which is in par with the equation mentioned in the data sheet  "13.3.6" "pg-813" .

    Thanks and Regards,

    Rohith.

  • 0 in reply to rohith banoth
    TI__Guru*** 135355 points

    Hello Rohith,

    rohith banoth said:
    Since there is no provision for me to send the signed values to CPU , i am forced and bound to use the unsigned data type only.

    Can you explain this point in more detail please? What is limiting you?

  • 0 in reply to Ralph Jacobi
    Prodigy 210 points

    Hi Ralph,

    There is communication protocol that is used for transmission of messages from CPU to MCU and vice versa through I2C.

    So the message should be stored in a Tx field and a Rx field which is defined to be a data field structure of type unsigned char, so any parameter that is sent or received would be of Unsigned Datatype..

    Since there are multiple communications to and fro from CPU and MCU , dependent on these fields any change in the structure datatype to signed will effect the other functionalities.

    Now, Since the project is on the verge of delivery ,it would be really difficult to bring major changes.hence there came up a limitation.

    Thanks and Regards,

    Rohith.

  • 0 in reply to rohith banoth
    Guru 117855 points

    rohith banoth said:
    There is communication protocol that is used for transmission of messages from CPU to MCU and vice versa through I2C.

    Should not that point have been introduced - far earlier - and w/far more emphasis?

    It is believed that "methods do exist" which enable the passage of "polarized variables" (even) via an I2C connection medium...

    Staff's investment of time/effort in your behalf proves disheartening...

  • 0 in reply to cb1_mobile
    Prodigy 210 points

    Hi ,

    Sorry for that

    But since the first description of this thread  i have been mentioning about the unsigned char declaration and about the provision not being to declare it as signed , there was no intention to mislead or hide things .

    Regards,

    Rohith.

  • 0 in reply to rohith banoth
    TI__Guru*** 135355 points

    Hello Rohith,

    Regarding the issue with printf, I found the following: "The "%d" format is for (signed) int values. If you use it with an unsigned value, it could print something other than the actual value. Use "%u" to see the actual value, or %x to see it in hexadecimal."

    So that would explain your 153 result which makes no sense to any of us.

    Regarding the issue of only being able to send the value is unsigned vs signed, have you tried the following:

    1) Send the data as an unsigned value.

    2) Type cast the data as a signed value after reception.

    3) Print the value on the CPU in order to see the correct signed value.

    One more thing to consider if doing this is that you need to make sure you are calculating the unsigned result with the correct number of bits that you would send over I2C because you have to ensure the sign bit is being sent correctly or else you won't be able to send the value correctly.

    Another alternative would be to have intelligence on the MCU to send some indication the value sent is negative.

    By doing this, you would send the absolute value which can be done with unsigned, and then an indicator to the CPU that the value is positive or negative, and based on that, the CPU can re-construct the variance as a signed value.