MSP430F2274-EP: High Temp Operation of ADC

Todd,
I researched this, and I have not found any evidence of similar issues reported for this device.
Can you confirm what clock frequencies you are using for CPU and ADC?
What operational VCC?
Can you provide sample of the data? Is it erroneous on single value out of all the channels? After more errors is it same channel, or random?
What is sample rate?
Is the conversion clock enabled and disabled as part of the acquisition?
Sorry for all the questions.
Regards,
Wade

Hello Wade,

The clock for the MSP430 is 16MHz. For the ADC, the clock is ADC10DIV_3 so divide by 4.
ADC10CTL1 = CONSEQ_1 | ADC10SSEL_0 | ADC10DIV_3 | SHS_0 | INCH_15;


The VCC is 3.3V
It is erroneous on all the channels, but the range is more gross on the temp.
For example, I am reading 66.7C..and I read that 20 times...and then I will read -708C or 156C. And then back to 66.7C on the next read.

The sample rate is just using a polling scheme in the main loop execution. I wait till if((ADC10CTL0 & 0X01) == 0)

I do not enable and then disable the clock. It is just a large routine that polls the values and then moves the sample channel and then again sets the ADC and goes off and does the rest of the program until the ADC is complete and then gets the value and stores it away.

if((ADC10CTL0 & 0X01) == 0) // See if ADC10SC is cleared now
{
ADC10CTL0 &= ~ENC;
GetADValues(); // Go get A to D Values and process them.
ADSeq(); // Sets up channels for next conversions
while (ADC10CTL1 & BUSY); // Wait if ADC10 core is active
ADC10SA = 0x340; // Data buffer start
// ADC10SA = (unsigned int)ADBuf; // Data buffer start
ADC10CTL0 |= ENC + ADC10SC; // Sampling and conversion ready
// __bis_SR_register(CPUOFF + GIE); // LPM0, ADC10_ISR will force exit
A2DDoneFlag = 0; // Reset flag
ADC10CTL0 |= ENC + ADC10SC; // Start conversion
}

Let me know if this is unclear.

Thank you,
Todd

Todd,
Can you try polling the ADC10BUSY bit vs ADC10SC?
I need to confirm, but I believe that the ADC10SC only indicates the start of conversion, not necessarily completed conversion.

It may be you are right on the edge of getting completed conversions and most of the time it works correctly.
Regards,
Wade

Hello,

So I switched the code from the 

if((ADC10CTL0 & 0X01) == 0) // See if ADC10SC is cleared now

to if((ADC10CTL1 & 0X01) == 0) // See if ADC10BUSY is cleared now

This did not make a difference.  Above 55C, the issue hits.  It seems like a full scale value is produced.

When I cool the IC, then I never get the issue.

I am thinking of trying to run the ADC from the external OSC input.  Perhaps at higher temps, the ADC clock starts to change or something.

Regards,

Todd

Hello,

So I switched to MCLK and /16 and still does the same thing.
still get very high and extreme values.

Regards,
Todd

Thanks for checking. I am going to research this further and check with the commercial experts for advice.
Regards,
Wade

Todd,
Do you ever set the MSC bit? Are you expecting all channels to be acquired within each loop?
You can see the behavior of the multiple sequence in the family users guide fig 22-6.

Also, when using ADC10SC for trigger it is indicated that ENC does not need toggled. Presumably this is not the issue, but thought I would mention it.

What does your function ADSeq() do?

Have you considered using ISR to service the ADC10? This may be much more efficient.

FYI, I am out of the office though Monday.

Regards,
Wade

Hello Wade,

This project was generated using Grace initially.  What is the MSC bit?

The main loop is checking ADC values to update a BIT status of the different voltages, currents, and temperatures.

It is also monitoring a single button press.

After I see the ADC finished, I go get the value of the results and process it.  Then ADSEQ goes and gets the next channel and starts the ADC and keeps moving in the main loop.

The ChannelNum is incremented after every completion.

/** Routine for cycling through the AtoD Channels *********************************************/
void ADSeq(void)
{
switch (ChannelNum)
{
case 0:
ChannelNum = 1;
ADC10CTL1 = INCH_1 + CONSEQ_0; // Single channel
break;
case 1:
ChannelNum = 2;
ADC10CTL1 = INCH_2 + CONSEQ_0; // Single channel
break;
case 2:
ChannelNum = 5;
ADC10CTL1 = INCH_5 + CONSEQ_0; // Single channel
break;
case 5:
ChannelNum = 6;
ADC10CTL1 = INCH_6 + CONSEQ_0; // Single channel
break;
case 6:
ChannelNum = 7;
ADC10CTL1 = INCH_7 + CONSEQ_0; // Single channel
break;
case 7:
ChannelNum = 12;
ADC10CTL1 = INCH_12 + CONSEQ_0; // Single channel
break;
case 12:
ChannelNum = 13;
ADC10CTL1 = INCH_13 + CONSEQ_0; // Single channel
break;
case 13:
ChannelNum = 14;
ADC10CTL1 = INCH_14 + CONSEQ_0; // Single channel
break;
case 14:
ChannelNum = 15; // LED_Vsense , switches the voltage detect inside results
ADC10CTL1 = INCH_15 + CONSEQ_0; // Single channel
break;
case 15:
ChannelNum = 0;
ADC10CTL1 = INCH_0 + CONSEQ_0; // Single channel
break;
}

}

Hello Wade,

So we tried something else.  We replaced the MSP430 on the same board that I have been testing with.

This IC came from a previous order and we are not sure the LOT for the actual IC.

With the new IC installed running the same firmware as the original IC, the production version....no failures.

I am running the IC at 67C for the last 15min and I have not triggered on the BIT temp failure. The other IC would have failed in 10 seconds.

It is tracking the actual IC itself.   We would like to see if TI can analyze the part itself.

Regards,

Todd

Hello,

There are two date code markings on the iCs.  They are 78C67RTG and 5AA9J2TG.

I am unable to figure out the markings.  The online docs that I have been looking at do not seem to match these.

We replaced the IC on a 2nd board and now that board does not fail.  We have inspected the soldering and we do not see any issues with the soldering.

Regards,

Todd

Todd,
Thanks for providing more information. I apologize for the delay due to the long Memorial weekend.

We looked up your information on the LTCs. Based on this information, they both originate from the same wafer lot, even though they were assembled 2 years apart.

Are these the only 2 devices (single board) that you have tested?

I am checking with our QA for proper procedure to follow if you would like to pursue an RMA.
Regards,
Wade

I have 7 boards that have this same failure mode. We have removed and replaced the ICs on two of the boards. We could do all 5 left.


Our end customer...the military would like to know how this is occurring and if this could happen to units in the field. We have not seen this behavior before. We built 30 units before without issue of the same patch.

Then another 130 units where just built and tested at the beginning of this year. This is now how we are seeing the issue in final production.


Regards,
Todd

Todd, I will send you an email with information on sending units back for evaluation.
Regards,
Wade