如果我使用超过25个元素的数组，则msp430g2211（launchpad）在启动时停滞

Question

I'm working with TI Launchpad (msp430g2211) in a Linux environment (Ubuntu, msp430-gcc 4.6.3).

I have a strange problem: when I try to allocate more than a fixed quantity of memory the micro-controller stalls at start-up.

To be more precise: I have an array of 25 elements in main(), created as follow:

color img0[25] = {


            off, cyan, cyan, cyan, off,
            cyan, red, violet, orange, cyan,
            cyan, red, violet, orange, cyan,
            off, cyan, cyan, cyan, off,
            off, off, off, off, off,

        };

(for completeness:

typedef struct color {
    uint8_t r;
    uint8_t g;
    uint8_t b;
    } color;


static color red = {25, 0, 0}; ...

)

Everything works but If I try to use 30 (or any number greater than 25) elements instead of 25 the uC seems dead. (no errors during compilation and programming)

In TI Wiki I found this, which seems to meet what I'm experiencing:

WDT fires during C startup code

Another most common problem if the application is written in C language is the watchdog timeout during startup. Per default watchdog timer on all MSP430 is set to active after startup. Therefore it is necessary to turn off the WDT if not needed right at the beggining of the application code. If the application code is using large variables which are needed to be initialized during startup, this could cause that the watchdog timer already fires during startup and the code will never be run.

The solution for this problem is to use the compiler's low level C initialization function which is called even prior to the initialization of C variables. In CCS compiler, it is called "int _system_pre_init(void)", while in IAR, the function is called int __low_level_init(void). The return value is used to determine whether or not C/C++ global data initialization will be performed (return value of 0 to bypass C/C++ auto-initialization). Refer to the MSP430 Software Coding Techniques Appication Report, chapter 3.6 "Using a Low-Level Initialization Function" for more detailed information regarding this issue.

So I tried to add the following function (in order to stop the WDT prior to allocating the memory):

__attribute__((naked, section(".init5"))) void __low_level_init()
{
     WDTCTL = WDTPW + WDTHOLD; //Stop WDT
} 

but the problem is still there...

Other tests I have done: - changed the compiler's version - split the array in two or more of 15 elements - stop the WDT in main function or in ".init3", ".init1", ".init7"

Any idea ? Thank you.

EDIT: As suggested, I analysed the GCC output ASM code (commented with "##" the not working version):

    .file   "main.c"
    .arch msp430g2211
    .cpu 430
    .mpy none

    .text
.Ltext0:
    .comm dir,2,2
    .comm colors,2,2
    .section    .init9,"ax",@progbits
    .p2align 1,0
.global main
    .type   main,@function
/***********************
 * Function `main' 
 ***********************/
main:
.LFB0:
    .file 1 "main.c"
    .loc 1 61 0
    mov r1, r4
.LCFI0:
    add #2, r4
.LCFI1:
    add #llo(-100), r1             ## add   #llo(-150), r1
.LCFI2:
    .loc 1 63 0
    mov #23168, &__WDTCTL
    .loc 1 66 0
    mov.b   &__CALBC1_1MHZ, r15
    mov.b   r15, &__BCSCTL1
    .loc 1 67 0
    mov.b   &__CALDCO_1MHZ, r15
    mov.b   r15, &__DCOCTL
    .loc 1 68 0
    mov.b   &__P1DIR, r15
    bis.b   #127, r15
    mov.b   r15, &__P1DIR
    .loc 1 90 0
    mov r4, r15
    add #llo(-102), r15            ## add   #llo(-152), r15
    mov #100, r14                  ## mov   #150, r14
    mov r14, r13
    mov #0, r14
    call    #memset
    mov.b   #llo(-64), -102(r4)        ## mov.b #llo(-64), -152(r4)
    mov.b   #llo(-64), -101(r4)        ## mov.b #llo(-64), -151(r4)
    ...

diff command says also:

106c106
<   add #llo(-102), r15
---
>   add #llo(-152), r15
187c187
<   cmp #20, r15
---
>   cmp #30, r15
193c193
<   add #llo(-100), r15
---
>   add #llo(-150), r15
541c541
<   .sleb128 -102
---
>   .sleb128 -152
548c548
<   .byte   0x63
---
>   .byte   0x95

I'm not an ASM expert but the WDT instructions seem to be there, in the right place. I can't understand where is the problem... Thank you.

Answer 1

Sounds like a compiler bug, in which case it might be obvious what is going wrong if you look at the asm GCC generates.

I had a look at the asm after you posted it, and it occurred to me that you only have 128 bytes of SRAM to work with. I'm not familiar with the assembler of this uC, but it seems to me that it is exceeded. Not with the allocation of the colour array alone, but in combination with the stack?