MSP430 damaged?? internal oscillator damaged??

One suspect is the calibration constants.

Examine the typical values of CALBC1_8MHZ of some of the working chips (they usually vary from chip to chip, but should not vary wildly). Compare with that of the chip that act strangely.

You can also examine the contents of the entire Info-A. Does that chip stand out alone? There is a check-sum and you can verify that too.

Thanks for your reply.

When u say "Examine the typical values of CALBC1_8MHZ" what does that mean.

One thing i found out is when i use setting below:

DCOCTL = 0;

BCSCTL1= CALBC1_8MHZ;

DCOCTL = CALDCO_8MHZ;

TA0CCR1 = 50000;

TA0CCTL1 = CCIE;

TA0CTL = TASSEL_2 + MC_2 + TAIE;

and if i have 0.5 second loop in the timer

it still acts like i have 0.25 second.

that means clock speed is culprit.

let me know how can i fix it or how can i find root cause.

The factory calibrates the oscillator and stores the calibration constant in some sections of info memory.  Depending on how many calibrated frequencies there are, you will have multiple 2 byte values stored in SegmentA.  These values trim in the oscillator to account for wafer differences.  Pull up your family manual for your part (not datasheet) and search for CALBC.  You will find a table for the SegmentA memory.  For the particular G Series I am looking at you have the Word address of 0x10FE for the CALBC1_1MHZ and 0x10FC for CALBC1_8MHZ.   It is a 2 byte value. 

So read you chip Segment A info memory at 0x1000 - 0x10FF and look at the correct two bytes called out by the table and you should see a trim value.  Read one from a good chip and one from your bad sample.  If the value is radically different, then there is likely your culprit.

For assessing how the value got changed, If the wrong box is checked in production, the cal value could be erased back to 0xFFFF and your calibrated timing would be out the window.  Either TI, a Field update (if applicable) your production or QC could have made this error.  If the rest of the Info memory is suspect - that is a smoking gun as well (not sure what is supposed to be in there from your application code).  Write the good chips info memory over to the bad chips info memory (making sure you uncheck, protect oscillator calibration), verify the value changed, and then retest your chip - it may be somewhat out of calibration, since it is the correction for a sister chip, but it should not be 2x anymore (if this is the root cause).

DCO stands for "Digital Controlled Oscillator". Its frequency depends on the digital values you put into BCSCTL1 and DCOCTL registers.

CALBC1_8MHZ and CALDCO_8MHZ are just the Flash Memory addresses where TI wrote some digital values. When you load those digital values into the corresponding registers, the DCO should produce about 8MHz. However, those digital values are in Flash Memory and thus can be erased or altered. Once that happened and you blindly copy those values into the registers, the DCO will produce a different frequency.

If you have and use a debugger tool, that tool should be able to show you the contents of Flash Memory. When I say "examine", I mean use debugger to show them so that you know what they are.

Old_cow,

Thanks for detailing. I checked few good MCU vs bad MCU and found that bad MCU's caliberation constants are erased. it show 0xFFFF for CALDCO_8Mhz  and CALBC1_8mHZ.

Next question is how to fix this?

Thanks,

abhishek Sabnis said:

Thanks for detailing. I checked few good MCU vs bad MCU and found that bad MCU's caliberation constants are erased. it show 0xFFFF for CALDCO_8Mhz  and CALBC1_8mHZ.

Next question is how to fix this?

Using 32kHz quartz oscillator and software (never used it but seemingly it does the job):

http://forum.43oh.com/topic/211-flashing-the-missing-dco-calibration-constants/