Calibration and trapping the CPU

Question

The following code is meant for MSP430. Can somebody help me what is the purpose of trapping the CPU? How will the program proceed if the CPU is trapped there?

Running the CPU of DCO and the crystal.

We want the MCLK sourced from DCO and ACLK to be sourced from VLO or 32KHz crystal. 
The ACLK is sourced from LFXT1 by default.   

#include <msp430g2553.h>

//This small set of code takes care of an inconsistency between g2553 and g2231. It should be present.

#ifndef TIMER0_A1_VECTOR
#define TIMER0_A1_VECTOR TIMERA1_VECTOR
#define TIMER0_A0_VECTOR TIMERA0_VECTOR
#endif

void main(void)
{
 //code goes here

WDTCTL = WDTPW + WDTHOLD;  //disables the watchdog timer by sending the  password (WDTPW) and hold command (WDTHOLD)

  //calibration starts here..           
if (CALBC1_1MHZ ==0xFF || CALDCO_1MHZ == 0xFF)  //trapping the CPU                          
{  
  while(1);  // If cal constants erased, trap CPU!!
} 

 .//rest of the code for calibration...
 .
 .

Answer 1

The comment makes it pretty clear: If the calibration constants have been erased (either one is equal to 0xFF), there's no point in continuing. The constants will need to be reprogrammed before the chip can do anything useful.

Answer 2

A trap in the context of programming is a software routine meant to be executed if an unexpected or anomalous condition is detected. Some general examples of traps are:

• Stack overflow (pushing more data than the defined stack can hold)
• Address error (a jump to unimplemented memory space)
• Divide-by-zero error

Some traps are automatically triggered by the CPU hardware, kind of like interrupts - no manual checking needed.

Quite often, the trap routine will perform some sort of error reporting (light an LED or set a status signal, report via UART, write a fault log) then either restart or halt execution.

In your example, the trap check is manually performed, and it's catching the absence or loss of two particular constants (most likely internal oscillator trim values programmed by the factory), since erased flash memory defaults to all ones.

The trap in this case is an endless while(1) loop - execution will not break from the while loop unless the CPU is restarted. (This product likely doesn't have any means of halting other than an endless loop.)

Of course, if you restart without fixing the original problem, the code will run and fall into the trap again.