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.

MSP430F67771: Global variable Initialization failed

Part Number: MSP430F67771
Other Parts Discussed in Thread: MSP-FET

Hi Team,

Customer is doing the global variable initialization on MSP430F67771, but find the initialized value of global variable is volatile.  The test code is as below:

uint32_t test_value1 = 150;

uint32_t test_value2 = 300;

int main()

{

   system_pre_init();

   SystemCLK_init();                                                     //configuration to system clock

                                                                                 //ACLK=32.768KHz, MCLK=24.576MHz, SMCLK=12.288MHz

   Watchdog_init();                                                     //disable watch dog during firmware initialization

   GPIO_init();                                                           //peripheral initialization to GPIO

     while(1)

     {

       if (test_value1 == 150)

       {

           LED1_ON;

       }

       else

       {

           LED1_OFF;

       }

       if (test_value2 == 300)

       {

           LED2_ON;

       }

       else

       {

           LED2_OFF;

       }

       LED3_OFF;

       __delay_cycles(1000000);

       LED3_ON;

       __delay_cycles(1000000);

     }

}

Customer use LED1 and LED2 to monitor if the global variable test_value1/2 is the value of the initialization 150/300. Then use LED3 to monitor the main()  loop.

Problem:

1. When the board is connected with debugger, and debugged in CCS 8.2.0, LED1 and LED2 turn on, LED3 blink. It seems that everything goes well;

2. If disconnect the debugger, and re-power on MCU, sometimes LED1& LED2 turn on, sometimes turn off, but LED3 is blinking.  So it seems that the global variable initialization is not correct, and the value of test_value1/2 is  random.

After check with customer, the optimization level is 0, even add the 'volatile',  the issue is still exist. But if they modify the global variable to local variable, everything seems all right. 

So do you have any comments about the issue? Thanks a lot.

 

 

 

  • > system_pre_init();
    Is this the exact code (no transcription errors) being used?

    If this function were named "_system_pre_init", I would guess that it was written to not return a result, so it sometimes returns 0, sometimes not. [Ref CCS cc User Guide (SLAU132T) Sec 6.9.1]. Without the leading "_", that guess doesn't apply.
  • Hi Bruce,
    Appreciate your reply. After double check, actually it's a copy issue. In fact, the code customer tested has the leading "_".
    Are there any more comments? Thanks.
  • The library (boot.c) will call a function by that name, and, based on the return value, will either initialize .bss/.data or not [I encourage you to read CCS cc User Guide (SLAU132T) Sec 6.9.1]. If it does not explicitly return a value, boot.c will get whatever junk is left over in R12, and may or may not initialize .bss/.data.

    That function should be changed to explicitly return the value 1 (actually anything non-0).
  • Hi David,

    I test below code on my MSP67791 board and it works well. The P1.0 is blinking both on debug mode with MSP-FET connected and free run mode with only the VCC&GND supplied. Could you share me the whole project with which the customer met the issue? I would like to reproduce the issue on my board so that I could look into where goes wrong.

    #include <msp430.h>
    #include <stdint.h>
    
    uint32_t test_value1 = 150;
    uint32_t test_value2 = 300;
    
    void main(void)
    {
        WDTCTL = WDTPW | WDTHOLD;               // Stop WDT
    
        P1DIR |= BIT0;
        P1OUT &= ~BIT0;
    
        while(1)
            {
              if ((test_value1 == 150)&&(test_value2 == 300))
              {
                  P1OUT ^= BIT0;
              }
              else
              {
                  while(1)
                  {
                  P1OUT &= ~BIT0;
                  }
              }
              __delay_cycles(500000);
    
            }
    }

  • Hi David,

    Since we discussed this issue offline, I would like to close this thread here.

  • Hi Wei,

    Thanks for your help.

    Yes, customer have found the root cause: in their project configuration, they choose Initialization model -- Link using RAM autoinitialization model (--ram_model, -cr). When they choose the other Initialization model -- Link using ROM autoinitialization model (--rom_model, -cr), everything is ok.  

    David

**Attention** This is a public forum