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.

MSP430G2553: MSP430G2553 using internal 1MH clock

Part Number: MSP430G2553

Dears

MSP430G2553 p/n, using internal 1MH clock, power on to determine CALBC1_1MHZ== 0xFF and CALDCO_1MHZ== 0xFF, But some can start run, some can not start run, if I do not judge, after the system starts the clock error is very large,If CALBC1_1MHZ== 0xFF and CALDCO_1MHZ== 0xFF, the internal 1M clock is not calibrated?Now 4500pcs are used, and there are 2100pcs. When I judge that the ICALBC1_1MHZ== 0xFF and CALDCO_1MHZ== 0xFF program cannot be started and run, 2400pcs is ok.

Is the internal 1M clock factory calibration, how can I judge?

My code is as follows:

if(CALBC1_1MHZ==0XFF||CALDCO_1MHZ==0XFF)

{

while(1)_NOP();          //if cal const erased

}

BCSCTL1=CALBC1_1MHZ;

DCOCTL=CALDCO_1MHZ;

  • Just to expand on what Allen said:

    1) A value of 0xFF indicates that the constant (Information Segment A) has been erased. This is by far the most common error. Using 0xFF results in a very high (far out of spec) clock rate.

    2) For a value which isn't 0xFF, there's no practical way to check it for correctness without re-generating the constant, which is what Allen's Example does. Re-generating it requires an external reference clock source; in the Example a 32kHz crystal is assumed.

    3) If you don't use the calibration constant you get a clock speed which "vaguely resembles" 1MHz. My (unscientific) survey over the years suggests a range of about 0.9-1.1MHz. This is actually good enough for some/many functions ("limp mode").

    4) User Guide (SLAU144J) Example 24-1 recommends setting DCOCTL=0 before setting the CAL constant(s). This doesn't quite match your symptom, but it's worth a try.

  • Thanks for Bruce's explanation.

  • Dear,Allen and Bruce

    Thanks for your reply, but according to the methods provided, the problem is still not solved. I need to know the reason for this.Is it because the internal 1M clock is not calibrated?Can you offer better suggestions to solve the current problem?

  • What you've described is consistent with erasure (0xFF) of the calibration constants (InfoA), but that's not quite the same as proof. The first things I would do:

    1) Connect one of the failing chips to a debugger (or equivalent) and read out the contents of locations 0x10F8-10FF. If they are 0xFF, then they have been erased.

    2) If they're not erased, load a program which configures P1.4 for SMCLK output, and probe P1.4 with a scope, to see what the actual clock speed is.

    3) Check your programming software/hardware for proper configuration. My experience is that, even with the safeguards, it's not particularly difficult to accidentally erase the calibration constants. (As a result, I make a point of designing-in a 32kHz crystal.)

    I'm guessing that TI might be interested in lot codes. It probably suffices to post a photo of one of the failing chips (and maybe one of the working chips).

  • Dear Bruce

    Thank you very much. It has been confirmed that it is the erasure (0xFF) of the calibration constant (InfoA). It is a problem with the burner setting, which has been corrected and solved.