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.

MSP430F6723 Inbuilt Temperature sensor functionality failure after reset,

Other Parts Discussed in Thread: MSP430F6723

Hello All,

We are manufacturing company and we recently started mass production of a system with MSP430F6723. Till now, we produced around 1500 units, out of that 6 are not working for MSP430 inbuilt Temperature sensor. In our application, we are entering/exiting both LPM0 and LPM3 more frequently and also we are executing this below temperature sensor function once in every 15 minutes and forever.

The problem we see with Temperature sensor in faulty units is: after reset the temperature is always showing as 0 even after many hours, it means always failing to sense the temperature if it fails even once after reset. Where as good ones are always working with the same code.

Please find the code below and suggest the fault in this and the way to handle this.


//This is called during firmware initialization and for every 15 minutes and forever.
bool  Msp430TempSensorConfigure(void);

//This is called in the Interrupt service routine.
void Msp430TempSensorStop(void);

//MSP430F6723 Temperature sensor calibration factors
#define CALADC10_15V_30C        *((unsigned int *)0x1A1A)   // Temperature Sensor Calibration at 30°C
#define CALADC10_15V_85C        *((unsigned int *)0x1A1C)   // Temperature Sensor Calibration at 85°C


// ADC10 configuration for measuring Temperature with MSP430 Inbuilt temperature sensor
bool Msp430TempSensorConfigure(void)
{
    // Configure ADC10 - Pulse sample mode; ADC10SC trigger
    ADC10CTL0 = ADC10SHT_8 + ADC10ON;         // 16 ADC10CLKs; ADC ON,temperature sample period>30us
    ADC10CTL1 = ADC10SHP + ADC10CONSEQ_0;     // s/w trig, single ch/conv
    ADC10CTL2 = ADC10RES;                     // 10-bit conversion results
    ADC10MCTL0 = ADC10SREF_1 + ADC10INCH_10;  // ADC input ch A10 => temp sense
    // Configure internal reference
    while(REFCTL0 & REFGENBUSY);              // If ref generator busy, WAIT
    REFCTL0 |= REFVSEL_0+REFON;               // Select internal ref = 1.5V, Internal Reference ON      
   
    //Enable ADC10 Interrupt and conversion start
    ADC10IE |= ADC10IE0;                      // enable the Interrupt request for a completed ADC10_B conversion
    ADC10CTL0 |= ADC10ENC + ADC10SC;          // Sampling and conversion start
   
    return TRUE;
}

//ADC10 completely stop function
void Msp430TempSensorStop(void)
{
    ADC10CTL0 &= ~ADC10ENC;            // ADC10CTL0 can be modified only when ADC10ENC = 0
    while(REFCTL0 & REFGENBUSY);    // If ref generator busy, WAIT
    REFCTL0 &= ~REFON;                         // Select internal ref = 1.5V
    ADC10CTL0 &= ~ADC10ON;              // ADC10 switched off
}

//ADC10 Interrupt service routine
#pragma vector=ADC10_VECTOR
__interrupt void ADC10_ISR(void)
{
    volatile int32 i32_AdcValue;
    int16 i16FinalTemperature;
    switch(__even_in_range(ADC10IV,12))
    {
        case 12:
            i32_AdcValue = ADC10MEM0;
            ADC10IE &= ~ADC10IE0;           // disable the Interrupt request for a completed ADC10_B conversion
           
           Msp430TempSensorStop();
            i16FinalTemperature = (i32_AdcValue - CALADC10_15V_30C) *  (85-30)/(CALADC10_15V_85C-CALADC10_15V_30C) +30;

//With MSP430 temp sensor, there is an offset of gi16_TempCalibration between actual and measured    temperature. This gi16_TempCalibration is configured/supplied for all units individuallly in production. i16FinalTemperature will hold the measured temperature in degree Celcius for further actions in app.

            i16FinalTemperature -= gi16_TempCalibration;

            break;
        default:
            break;
    }
}


Many thanks
Venkat

  • Hello All,

    Can anyone please reply on this topic.

     

    Thanks

    Venkat

     

     

  • Since most units work, and the code is the same for all, the problem likely is in the hardware.
    On the faulty units, did you check the calibration values? Did you try to manually do the temp calculation with these values? Keep in mind that you’re doing integer math, so decimals are truncated.
    However, even for weird calibration values (including zero or identical), the calculation shouldn’t give zero (due to the +30 offset you correctly add).
    So the problem might be the Gi16_TempCalibration. Where doe sit come from?. Maybe due to faulty calibration values, subtracting this one form the result, the result is always zero.

  • Hello Jens-Michael,

    Thank you for the response.

    >>Since most units work, and the code is the same for all, the problem likely is in the hardware.
    But the faulty units are again starting to function may be after reset or after firmware update again randomly. If there is failure then irrespective of retries, it's not recovering. But starting to function normally after micro warm reset or after firmware update mostly after few attempts for reset or firmware update. So, suspecting, some thing to do with reset or re-flashing firmware process influencing temp sensor module operation.

    >>On the faulty units, did you check the calibration values? Did you try to manually do the temp calculation with >>these values? Keep in mind that you’re doing integer math, so decimals are truncated.
    Whether the faulty units (<1% of total units) or perfectly working units, the calibration values are perfectly good. We performed calculations manually by taking calibration values from faulty units, seems correct.

    >>However, even for weird calibration values (including zero or identical), the calculation shouldn’t give zero (due >>to the +30 offset you correctly add).
    >>So the problem might be the Gi16_TempCalibration. Where doe sit come from?. Maybe due to faulty calibration >>values, subtracting this one form the result, the result is always zero.
    We just added "Gi16_TempCalibration" to address any offset problem in the production. for the moment in all the units we are having this as constant "3", our intention is to reduce the resultant temparature by 3 in production.

    Thanks,

    Venkat

  • When operating at the edge or outside the specifications, things like that can happen. Changes in software timing, changes in humidity or ambient temperature, all this may push a hardware ‘over the edge’. However, in case of the built-in temperature sensor, this is rather unlikely.

    So one other possibility is a non-deterministic soft-error. Like a stack overflow that exhibits problems only under certain circumstances.

    A possible explanation for giving a 0 result despite of the non-zero offset and the +30 in the calculation might be that the ADC10 ISR is never executed and the temperature variable remains on its initial 0 value (btw, did you declare it volatile?).
    It’s difficult to say without knowing the whole code (and honestly, I don’t have the time to analyze a whole project)

  • Hello Jens-Michael,

    Many thanks for your time.

    Yes, I declared it as volatile. As you mentioned, I am also in the impression that ADC10 ISR is never executed and the temperature variable remains on its initial value 0 when the failures are encountered. But not able to conclude it because of no possible reason because the same code is working 99 out of 100 times. Regarding stack overflow, we have enough space for it, definitely there is no chance for that to occur.

    Anyways, thanks once again for your findings.

    Thanks

    Venkat

  • There are several reasons that may prevent an ISR to be called.

    1) the IE bit isn’t set (but you do, and if not, none of the devices would work if the share the same code).
    2) the DTC is fetching the results (well, only on devices with DTC, on 5x/6x family, you have DMA and it won’t work if the IE bit is set). Again, this would always or never work.
    3) GIE isn’t set (again, always or never working code)
    4) a different ISR with higher priority is constantly executing. This would prevent the ADC ISR from being called and also virtually freeze main. A problem with external circuitry and other modules could cause this on individual devices.
    5) the device is resetting before it ever reaches the ISR. Again a problem with external circuitry, maybe with the supply rails or such.
    6) Failure of the ADC10 clock source, so it never finishes the conversion. Or any other internal failure. Highly unlikely.

**Attention** This is a public forum