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.

Silicon (?) problem with MSP430F2617 rev H temperature sensor

We are using MSP430F2617T microcontroller in one of our products. Multiple units from the latest production batch (rev H chips) seem to exhibit a problem where temperature sensor reads incorrect temperature. For example factory calibration data as read from TLV:
CAL_ADC_15T30 = 2922
CAL_ADC_15T85 = 3369
The readout from ADC is 3013 counts at room temperature which implies 41C die temperature.
I also see slow upward creep in temperature reading. Typically cold unit will start at about 36C and gradually get to 42C.

Potential culprit elimination:

1. Is this temperature real? No, does not appear so. I placed a thermocouple on the chip and there was no noticeable temperature rise. Note that on a good unit I see only about 4C between room temperature and die temperature.

2. Firmware bug? Not likely as we have tested and shipped thousands of units with this exact firmware.

3. Known silicon bug? Errata does not have any relevant entries.

4. Assembly error? VCC pins, ground pins, reference pin, crystal pins and reset pin all look good on the scope. Note that ADC is also used for other housekeeping measurements and they all look correct. Not sure what else can affect the internal operation of the chip.

Has anybody seen this? Is there a problem with the latest silicon that did not make it into errata?

Best Regards,

Sergei

  • Hi Sergei,

    Thanks for providing so much detailed information. Could you please let us know if you have tried a part swapping test (e.g. take a good unit and a bad unit and swap the MSP430 devices) - does the issue follow the MSP430 device, or the board, or disappear? Would that be possible for you to do or are the parts somehow inaccessible?

    In addition, I know that you mention you already have shipped lots of units with the same firmware but can you report your ADC code/settings or provide a simplified example that shows the issue? It would be helpful for us to see your settings to better understand what is happening. It also would be helpful to have a simplified example that reproduces the issue on your board as it would help rule out any potential impact of other functions on your board.

    Regards,
    Katie
  • Have not tried swapping the chips yet. Next on TODO list.

    I understand your concern about correct programming of ADC registers. Here is decoded register dump from the same unit/chip during temperature measurement:

    ADC12CTL1=0x250
    not busy
    single channel, single conversion
    mclk as clock (16 MHz). Note: Vcc=3.3V, 16MHz is OK.
    clock / 3 = 5.3333 MHz
    sample input not inverted
    SAMPCON is from sampling timer
    ADC12SC is source for S&H
    conversion start address is 0


    ADC12MCTL0=0x5a
    input channel is temperature diode
    reference: VR+ = VREF+ and VR- = VREF-/ VeREF-
    not end of sequence

    ADC12CTL0=0x7733
    sw start active
    ADC12 enabled
    Conversion time overflow interrupt disabled
    Overflow interrupt disabled
    ADC12 on
    Reference on
    Reference is 1.5 V
    sampling timer requires a rising edge of the SHI signal to trigger
    SHT0x is 192 ADC12CLK cycles (36us)
    SHT1x is 192 ADC12CLK cycles (36us)


    ADC12MEM0=2999
    T=35 C, 2999

    And here is the source code. Not sure how to preserve src formatting with copy/paste. Above register dump is from printfs added in the code below:

    uint16_t adcSingle(uint16_t ch, int16_t ref)
    {
    uint16_t ctl0,ctl1;

    debug("adcSingle(%u,%d)\n",ch,ref);

    ctl0 = ADC12CTL0; /* save cfg */
    ctl1 = ADC12CTL1; /* save cfg */

    /* Must go into single mode before clearing ENC bit */
    ADC12CTL1 = SHS_ADC12SC | /* SC bit starts conversion */
    SHP | /* use ADC's sampling timer */
    ADC12SSEL_MCLK | /* MCLK clock src */
    ((ADC_DIV-1)<<5) | /* ADC clock = clock src / N */
    CONSEQ_SINGLE; /* single channel / single conversion */

    while(ADC12CTL1 & ADC12BUSY); /* wait for conversion to complete */

    if(DebugLevel)
    printf("ADC12CTL1=0x%x\n",ADC12CTL1);

    ADC12CTL0 &= ~ENC; /* disable conversion */

    ADC12CTL0 = ADC12ON | /* power up the core */
    SHT0_DIV(ADC_SAMPLE_SLOW) | /* S&H 0 time */
    SHT1_DIV(ADC_SAMPLE_SLOW) | /* S&H 1 time */
    REFON;

    if(ref & REF25) /* update REF2_5V bit */
    ADC12CTL0 |= REF2_5V; /* ref = 2.5V */
    if((ctl0 ^ ADC12CTL0) & REF2_5V) /* new reference value */
    sleep_ms(VREF_SETTLING_TIME); /* reference settling */


    ADC12MCTL0 = ref | ch; /* configure conversion memory */
    if(DebugLevel)
    printf("ADC12MCTL0=0x%x\n",ADC12MCTL0);

    ADC12CTL0 |= ADC12SC | ENC; /* start conversion */

    if(DebugLevel)
    printf("ADC12CTL0=0x%x\n",ADC12CTL0);

    while(ADC12CTL1 & ADC12BUSY); /* wait for conversion to complete */

    if(DebugLevel)
    printf("ADC12MEM0=%u\n",ADC12MEM0);

    return ADC12MEM0;
    }

    Regards,

    Sergei

  • OK, we swapped the CPU chips and the problem followed the chip.

    Bad chip is marked:
    4CC459TG4
    M430F2617T
    REV H

    Good chip is marked:
    07CL93TG4
    M430F2617T
    REV F

    Note that not all chips from latest build fail the test. I am still trying to get exact munbers from the manufacturing.
    Anything else we should try?

    Thanks,
    Sergei
  • Hi Sergei,

    One very important information would also be the LTC (Lot trace code).

    You can find it on the device package.

    Best regards

    Lukas

  • Lukas,

    It looks like Sergei provided the chip markings in his previous post:
    "Bad chip is marked:
    4CC459TG4
    M430F2617T
    REV H"

    Regards,
    Katie
  • Sergei,

    Thanks so much for doing the part swap test and providing all of this information, including the device marking. This helps to narrow down the issue. I'm working with Lukas on next steps and will contact you soon.

    Regards,
    Katie

**Attention** This is a public forum