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.

MSP430F5438A: Hardware debugging results are inconsistent with offline operation when using Timer B

Part Number: MSP430F5438A


Hi there,

    There is problem troubling me for several days.

    When I am debugging my msp430f5438a board with timer B using MSP-FET430UIF, I find every thing is fine. But after I download the code into the chip, I find it seems that I can not enter timer B ISR. Part of the code is below.

/*
*  this is my initializing function
*/
#define Init_TimerB() \
  do{                 \
    P4SEL |= BIT1;    /*P4.1 option select*/ \
      P4DIR |= BIT1;   /*P4.1 outputs*/ \
        P4DS |= BIT1;   /*P4.1 full drive strength, it seems it is not necessary*/ \
          TBCCR0 = TBCCR0_INIT - 1;         \
            TBCCTL0 = CCIE;                   /*enable CCR0 interrupt*/ \
              TBCCTL1 = 0x0200 | OUTMOD_4;     /*TBxCLn loads when TBxR counts to 0*/ \
                TBCCR1 = TBCCR1_NORMAL;           \
                  TBCTL = TBSSEL_2 + MC_3 + TBCLR + TBIE;  /*SMCLK, up/down mode, clear TBR, enable TBIFG*/ \
  }while(0);
  
/*
*  this is my main function
*/
int main(void) {
  STOP_WDT();   // Stop watchdog timer
  Init_Port();  // had better to be the 2nd
  Init_MAX_Clock(); // For simulator debugging, please comment this line
  
  Init_4keys_keyboard();
  Init_driver_EN();
  Init_Relay_Protection();
  Init_ADC();
  
  Init_My_Nokia_5110();
  My_LCD_write_cmd(0x40);
  My_LCD_write_cmd(0x80);
  __delay_cycles(DELAY_CYCLES_BETWEEN_CMD_AND_DATA);
  My_LCD_write_string(Set_voltage);
  
  My_LCD_write_cmd(0x41);
  My_LCD_write_cmd(0x80);
  __delay_cycles(DELAY_CYCLES_BETWEEN_CMD_AND_DATA);
  My_LCD_write_string(Real_voltage);
  
  Wait_for_USCI_A0_TX_buffer_ready();     // Wait for USCI A0 X buffer ready
  UCA0TXBUF = 0x00;
  
  // about LED
  P10DIR |= 0x0F;
  P10OUT &= ~0x0F;
  
  
  Init_TimerB();
  __EINT();  // my macro: #define __EINT() __enable_interrupt()
  for(;;) {
    LED3_ON(); // for test
    if(Display_data_changed){
    Update_LCD_num_content(); 
    LCD_display_update();       
    Display_data_changed = 0;
    LED1_ON();
    //__NOP();  // for debugging
    }
  }
}

/*
*   Timer B ISR
*/
// Timer B0 interrupt service routine
#pragma vector = TIMERB0_VECTOR
__interrupt void TIMERB0_ISR(void){
  LED2_ON();  // for test
  ADC_Sample_times++;
  if(ADC_Sample_times <= Num_of_Results){
    Start_ADC12();
    ADC_RESULT_OBTAINED_FLAG = 1;
  }
  if(ADC_Sample_times == 25){    // 20 changed to 40
    ADC_Sample_times = 0;
    
  }
}

// Timer_B1 Interrupt Vector (TBIV) handler
#pragma vector=TIMERB1_VECTOR
__interrupt void TIMERB1_ISR(void)
{
  /* Any access, read or write, of the TBIV register automatically resets the
  highest "pending" interrupt flag. */
  switch( __even_in_range(TBIV,14) )
  {
  case 14: 
    if(ADC_RESULT_OBTAINED_FLAG){
      PERMMIT_GET_ADC_DATA();              // overflow
    }
    break;
  case  0: break;                          // No interrupt
  case  2: break;                          // CCR1 not used
  case  4: break;                          // CCR2 not used
  case  6: break;                          // CCR3 not used
  case  8: break;                          // CCR4 not used
  case 10: break;                          // CCR5 not used
  case 12: break;                          // CCR6 not used
  default: break;
  }
}

   When I debugged the code using MSP-FET430UIF, I found both LED3 and LED2 can light. But after I downloaded the code into the chip and reset my chip in hardware, I found LED2 could not work. What I can confirm is that all the LEDs are not damaged. Hence it seems that I did not enter Timer B ISR, which seems weird. I am closed to crushed. If anyone could help me, I would be rather grateful.

   The whole project could be seen on My github rep(https://github.com/eexu/27_Parallel_Operation_of_Two_Buck)

  • Do you see the same failure when the FET is connected but you don't have an active debugging session? If not, that suggests something about power -- slow ramp-up or Vcc too low for your PMMVCORE setting.

    Another possibility is LPM, though I don't see any usage of LPM in your code. The debugger sometimes prevents going into the lower-power modes, so any bugs there would be hidden.

    I worry a little about nesting your ADC interrupt, though this usually isn't the sort of thing that is affected by the debugger.

  • Bruce asked some good questions.  Will be useful to understand if the issue only once the programmer is physically removed?  Does the issue happen when "free-running" the code?  

    Also, Are you using an MSP430F5438A EVM or is this on a custom board?  

    Thanks,

    JD

  • Wow! It is the power! I used to use FET's Vcc to power my core board, but today when I power it from USB,  everything becomes normal! Thank you very much!

**Attention** This is a public forum