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.

MSP430FR5969 Internal Temperature Sensor

Other Parts Discussed in Thread: MSP-TS430RGZ48C, MSP430FR5969

Hi all,

I started using Internal Temperature Sensor of MSP430FR5969 (board MSP-TS430RGZ48C). Unfortunately I have some problems maybe to set correctly registers (I use CCS5) and to display the exact value because it doesn't exist a datasheet in which I can find the characteristic Voltage-Temperature and so I can't convert it. (The user guide shows only a linear slope without any values). I've tried to find something in internet, but there is nothing about it. Do you have some code or any solutions?

Thank you very much.

Fabio

  • Datasheet said:
    A typical temperature sensor transfer function is shown in Figure 18-10. The transfer function shown in Figure 18-10 is only an example. Calibration is required to determine the corresponding voltages for a specific device.

    Regards,
    Maciej 

  • Yes, I've already read the calibration part but I don't know what value I must set for CAL_ADC_15T30, CAL_ADC_15T85, because CCS considers them as 2 undefined variables. I guess ADC(raw) is the value that ADC returns (ADC12MEM0 for instance). I'm sorry but I've just begun to work with these kind of MCUs.

  • You don't have to set CAL_ADC_15T30, CAL_ADC_15T85, they are part of the TLV structure and factory calibrated.

  • Hi Fabio,

    You can find a temperature sensor example with calibration in the FR57xx code examples MSP430FR57xx_adc10_16.c. This is for the FR5739 device which has the ADC10, but you can at least look at how they did the calibration equation for guidance.

    CAL_ADC_12T30 and CAL_ADC_12T85 (and all the rest of the different temp sensor calibration values) in the user's guide are something you need to find the right address for from your device datasheet - they aren't defined in the header file or anything I don't think. So for MSP430FR5969, you can see from p. 75 of the device datasheet that the  ADC 1.2V Reference Temp Sensor 30C value is the word at 0x1A1A, and the 85C for that same reference is at 0x1A1C.

    So in your code, you can make two variables:

    unsigned int CAL_ADC_12T30;
    unsigned int CAL_ADC_12T85;

    Then define these to be the value stored at the two addresses we found from the datasheet:

    CAL_ADC_12T30 = *(unsigned int*)0x1A1A;
    CAL_ADC_12T85 = *(unsigned int*)0x1A1C;

    Now they will each contain the calibration value and you can use them in your equation.

    Also, you are correct - ADC(raw) in the user's guide equation means the result that you got from the ADC memory buffer that you are using.

    A couple of additional tips:

    • All of the FR5969 devices out now are pre-release samples of experimental silicon - they probably say "X430FR5969" on them (to indicate experimental silicon). These devices don't always have all of the temperature calibration values I don't think because they may not have undergone this temp chamber measurement at test (since not a final production device). So before using the values, take a look in the memory browser view and see if there is actually data at these addresses or if it is blank (0xFFFF). All final released devices will have full calibration data, so when you go to production parts you won't have to worry about this anymore.
    •  When you are doing your equations from the user's guide, you may have to cast some of the data to float when you are doing your division, to make sure you actually get a ratio value before multiplying, instead of just getting zero.
    • Make sure that you use the correct calibration values that correspond to which internal reference voltage you have set up in your code. For example, use the data for CAL_ADC_12T30 if using 1.2V reference, but use CAL_ADC_20T30 if using the 2.0V reference. You'll have to find the right addresses in the datasheet as described above.

    Regards,

    Katie 

     

     

  • You shouldn't need to use a float (and all the overhead that comes along with that). Just store your cal at some factor (say, 1000x) and then divide that factor out after all the math is done.

    Here is a DriverLib-based example:

       // Get the calibration data for the ADC and internal temp sensor
       TLV_getInfo(TLV_TAG_ADC10CAL, 0, &length, (unsigned int**)&ptr);

       // Get the calibration data from the chip's TLV data
       if (ptr != NULL)
       {
          calDataADC = (struct s_TLV_ADC_Cal_Data*)ptr;
          calADC20T30 = calDataADC->adc_ref20_30_temp;
          calADC20T85 = calDataADC->adc_ref20_85_temp;
          calTempScaleFactor1000x = ((INT32)(85-30)*1000)/(calADC20T85-calADC20T30);
          calADC_Gain = calDataADC->adc_gain_factor;
          calADC_Offset = calDataADC->adc_offset;
       }

    And then something like:


    #define ADC_TEMP_OFS_1000X 300000 // 30 degrees C is the lower calibration point
    #define KELVIN_OFS_1000X 273150 // 0 degrees C = 273.15 Kelvin

    UNSIGNED16 convertADCtoKelvin10x(void)
    {
       INT32 result = 0;

       // Operations are done at 1000x to increase precision in the division
       // calculations below. 1000X factor is partially removed at end with
       // divide by 100, leaving result in tenths of a degree Kelvin.
       result = ( (INT32)SampleBuffer[PFM_TEMPERATURE] - (INT32)calADC20T30 ) *
                 calTempScaleFactor1000x;
       result = (result + ADC_TEMP_OFS_1000X + KELVIN_OFS_1000X) / 100L;
       return((UNSIGNED16)result);

    }

  • Thank you Kate; a last question: what is the best way to view the result of the temperature formula? I've tried to declare a "volatile int temp" in order to view it in the expressions table, but I can't view the correct result.  While ADC12MEM0 varies changing temperature, the variable temp remains the same having a busted value.

    However I have declared the variable as volatile, otherwise I was unable to see it in expression table setting it as unsigned int temp (Error: identifier not found).

    Thank you.

  • Hi Fabio,

    Your variable is probably getting optimized out. You may want to try making it a global variable with the volatile keyword, or using the result somewhere to prevent the compiler from getting rid of it, or turning off optimizations for your initial testing/experimentation. See Jens-Michael's post here: http://e2e.ti.com/support/microcontrollers/msp430/f/166/p/227561/801191.aspx#801191

    Regards,

    Katie

  • Hi Katie,

    I used your hints and I made my program, but when I define CAL_ADC_12T30 and CAL_ADC_12T85 (as you showed me above) I get the value 2676 and 65535 respectively. I think that CAL_ADC_12T85 is really bigger than CAL_ADC_12T30 and so the temperature formula gives always the same value because CAL_ADC_12T85 has a bigger weight in the formula. Any ideas?

    Thank you again.

    Fabio

  • Fabio Marinosci said:
    when I define CAL_ADC_12T30 and CAL_ADC_12T85 (as you showed me above) I get the value 2676 and 65535 respectively.

    This is definitely wrong.

    The values cannot be >4095 for the 12 bit ADC12 or 1024 for the ADC10. 65535 is 0xffff = empty/unprogrammed.

  • Fabio,

    Jens-Michael is right - 0xFFFF (65535) means that this calibration value is not programmed in the part. This is what I was trying to warn of in my first response:

    Katie Enderle said:

    All of the FR5969 devices out now are pre-release samples of experimental silicon - they probably say "X430FR5969" on them (to indicate experimental silicon). These devices don't always have all of the temperature calibration values I don't think because they may not have undergone this temp chamber measurement at test (since not a final production device). So before using the values, take a look in the memory browser view and see if there is actually data at these addresses or if it is blank (0xFFFF). All final released devices will have full calibration data, so when you go to production parts you won't have to worry about this anymore

    Regards,

    Katie

  • Perfect, thank you for all. Grazie.

    Fabio

**Attention** This is a public forum