1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

IAR compiler & MSP430 problem

Discussion in 'Embedded' started by halong, Dec 9, 2009.

  1. halong

    halong Guest

    Hi All,

    Need your help, I have problem /w IAR compiler working with MSP430.

    I've got the project or "work space"from co-worker and I continue to
    develop the it. In the project we have a 2d array,... so far the it
    compiler and works properly.

    However, I've now reached the point that if I add one more row of data
    (128 bytes per each row), the compiler STILL compiler with no warning
    or error, but the program won't run at all at power up (lost start
    point)

    I've tried to set the project property such as data model to large,
    medium or small (current setting), and other parameters with no luck

    Currently we use the TI's MSP-FET JTAG programmer running with the
    FET-Pro430 Lite software, I doubt if this could limit the code space
    to download to the chip or something... something else that we missed


    btw, the output map file summary of the running program, it looks
    like this

    24 566 bytes of code memory
    3 246 bytes of DATA memory (+ 63 absolute)
    15 129 bytes of CONST memory


    when I added one more row to the array, the program won't run at all,
    and the output map file looks like this

    24 566 bytes of code memory
    3 374 bytes of DATA memory (+ 63 absolute)
    15 257 bytes of CONST memory



    TIA,
     
    halong, Dec 9, 2009
    #1
    1. Advertising

  2. halong

    Thad Smith Guest

    halong wrote:

    > However, I've now reached the point that if I add one more row of data
    > (128 bytes per each row), the compiler STILL compiler with no warning
    > or error, but the program won't run at all at power up (lost start
    > point)


    I suspect that you haven't reserved enough RAM for stack and therefore
    the linker isn't telling you when you have run our of RAM.

    My recollection is that the linker map gives a call tree analysis
    showing the worst-case stack use, assuming no function pointer use, but
    you have to explicitly reserve it. With my use it assumed that all
    interrupts enabled were nested, which produced a prediction of stack use
    worse than actually required (I backed out the nested interrupt portion
    of stack use).

    --
    Thad
     
    Thad Smith, Dec 9, 2009
    #2
    1. Advertising

  3. In article <4b1fb161$0$77534$>,
    says...
    > halong wrote:
    >
    > > However, I've now reached the point that if I add one more row of data
    > > (128 bytes per each row), the compiler STILL compiler with no warning
    > > or error, but the program won't run at all at power up (lost start
    > > point)

    >
    > I suspect that you haven't reserved enough RAM for stack and therefore
    > the linker isn't telling you when you have run our of RAM.
    >
    > My recollection is that the linker map gives a call tree analysis
    > showing the worst-case stack use, assuming no function pointer use, but
    > you have to explicitly reserve it. With my use it assumed that all
    > interrupts enabled were nested, which produced a prediction of stack use
    > worse than actually required (I backed out the nested interrupt portion
    > of stack use).
    >
    >

    It would help to know which MSP430 variant you are using. Different
    chips have different memory resources. If your chip has 4K of RAM,
    you could be getting into trouble. From the fact that both the
    CONST and DATA memory increased by 128, I assume that you added an
    initialized row to the array. With only about 600 bytes of RAM left
    for both the heap and stack, you could be getting into trouble,
    particularly if you either use dynamically allocated memory on the heap
    or use local structures or arrays in your functions.

    Look through the code for the 'new' keyword and check out memory needed
    for local variables in each function. If there is no dynamic memory
    allocation and reasonable stack usage for local variables, 600 bytes
    ought to be enough for the stack.



    Mark Borgerson
     
    Mark Borgerson, Dec 9, 2009
    #3
  4. halong

    halong Guest

    On Dec 9, 9:08 am, Mark Borgerson <> wrote:
    > In article <4b1fb161$0$77534$>,
    > says...
    >
    > > halong wrote:

    >
    > > > However, I've now reached the point that if I add one more row of data
    > > > (128 bytes per each row), the compiler STILL compiler with no warning
    > > > or error, but the program won't run at all at power up (lost start
    > > > point)

    >
    > > I suspect that you haven't reserved enough RAM for stack and therefore
    > > the linker isn't telling you when you have run our of RAM.

    >
    > > My recollection is that the linker map gives a call tree analysis
    > > showing the worst-case stack use, assuming no function pointer use, but
    > > you have to explicitly reserve it.  With my use it assumed that all
    > > interrupts enabled were nested, which produced a prediction of stack use
    > > worse than actually required (I backed out the nested interrupt portion
    > > of stack use).

    >
    > It would help to know which MSP430 variant you  are using.  Different
    > chips have different memory resources.   If your chip has 4K of RAM,
    > you could be getting into trouble.   From the fact that both the
    > CONST and DATA memory increased by 128,  I assume that you added an
    > initialized row to the array.  With only about 600 bytes of RAM left
    > for both the heap and stack, you could be getting into trouble,  
    > particularly if you either use dynamically  allocated memory on the heap
    > or  use local structures or arrays in your functions.
    >
    > Look through the code for the 'new' keyword and check out memory needed
    > for local variables in each function.  If there is no dynamic memory
    > allocation and reasonable stack usage for local variables, 600 bytes
    > ought to be enough for the stack.
    >
    > Mark Borgerson




    Oh Thank you thank you for the answer, that rings the bell although
    I'm new to this IDE.

    The IAR uses linker command file *.xcl to define for such things such
    as stack, RAM, constant data, etc...

    I'm using the default linker file for this micro controller, which
    come /w the IDE software. Most of the content in the file are
    comments and notes, and yes the notes said the constant data is limit
    to a certain amount, as well as RAM and stack....

    Below is the content of the file, I'm not sure which parameter(s) need
    to changed to increase the reseverd RAM size, please help (view better
    with fixed font)


    //*****************************************************************
    // The following segments are defined in this linker command file:
    //
    // Data read/write segments (RAM)
    // ==============================
    //
    // segment address range usage
    // ------- ------------- --------------------------
    // DATA16_I 1100-30FF Initialized variables
    // DATA16_Z 1100-30FF Zero initialized variables
    // DATA16_N 1100-30FF Uninitialized variables
    // CSTACK 1100-30FF Run-time stack/auto variables
    // HEAP 1100-30FF The heap used by malloc and free
    //
    //
    // Program and non-volatile segments (FLASH)
    // =========================================
    //
    // segment address range usage
    // ------- ------------- --------------------------
    // INFO 1000-10FF Information memory
    // CSTART 3100-FFDF cstartup program code
    // 10000-1FFFF
    // CODE 3100-FFBE Program code
    // 10000-1FFFF
    // ISR_CODE 3100-FFDF Interrupt service routines, must be
    placed in 16-bit
    // memory
    // 10000-1FFFF
    // TAIVINT 3100-FFDF Timer A interrupt vector generator
    support code
    // DATA16_C 3100-FFDF Constant "const" variables AND String
    literals
    // 10000-1FFFF
    // DATA16_ID 3100-FFDF Initializers for DATA16_I
    // 10000-1FFFF
    // DIFUNCT 3100-FFDF Dynamic initialization vector used by C
    ++
    // 10000-1FFFF
    // CHECKSUM 3100-FFDF The linker places the checksum byte(s)
    in this segment,
    // when the -J linker command line option
    is used.
    //
    // INTVEC FFC0-FFFF Interrupt vectors
    //
    // NOTE:
    // It is not possible to pack the CSTART segment by using the XLINK -
    P option
    // Special function registers and peripheral modules occupy addresses
    0-01FFh
    // Be sure to use end values for the defined addresses
    //*****************************************************************

    // -------------------------------------------------------------------
    // Stack size and heap size
    // -------------------------------------------------------------------

    // Uncomment for command line use
    //-D_STACK_SIZE=200
    //-D_HEAP_SIZE=300


    // ---------------------------------------------------------
    // Define cpu.
    //

    -cmsp430


    // ---------------------------------------------------------
    // RAM memory.
    //

    -Z(DATA)DATA16_I,DATA16_Z,DATA16_N,HEAP+_HEAP_SIZE=1100-30FF
    -Z(DATA)CSTACK+_STACK_SIZE#


    // ---------------------------------------------------------
    // Read only memory.
    //

    // -------------------------------------------------------------------
    // Information memory (FLASH)
    // -------------------------------------------------------------------

    -Z(CODE)INFO=1000-10FF
    -Z(CODE)INFOA=1080-10FF
    -Z(CODE)INFOB=1000-107F

    // -----------------------------------------------
    // Constant data.

    -Z(CONST)DATA16_C,DATA16_ID,DIFUNCT=3100-FFBE

    // -----------------------------------------------
    // Code.

    -Z(CODE)CSTART,ISR_CODE,IVCODE=3100-FFBE
    -P(CODE)CODE=3100-FFBE,10000-1FFFF

    // -----------------------------------------------
    // Interrupt vector.

    -Z(CODE)INTVEC=FFC0-FFFF
    -Z(CODE)RESET=FFFE-FFFF

    // ---------------------------------------------------------
    // The end.
    //
     
    halong, Dec 9, 2009
    #4
  5. halong

    halong Guest

    On Dec 9, 9:08 am, Mark Borgerson <> wrote:
    > In article <4b1fb161$0$77534$>,
    > says...
    >
    > > halong wrote:

    >
    > > > However, I've now reached the point that if I add one more row of data
    > > > (128 bytes per each row), the compiler STILL compiler with no warning
    > > > or error, but the program won't run at all at power up (lost start
    > > > point)

    >
    > > I suspect that you haven't reserved enough RAM for stack and therefore
    > > the linker isn't telling you when you have run our of RAM.

    >
    > > My recollection is that the linker map gives a call tree analysis
    > > showing the worst-case stack use, assuming no function pointer use, but
    > > you have to explicitly reserve it.  With my use it assumed that all
    > > interrupts enabled were nested, which produced a prediction of stack use
    > > worse than actually required (I backed out the nested interrupt portion
    > > of stack use).

    >
    > It would help to know which MSP430 variant you  are using.  Different
    > chips have different memory resources.   If your chip has 4K of RAM,
    > you could be getting into trouble.   From the fact that both the
    > CONST and DATA memory increased by 128,  I assume that you added an
    > initialized row to the array.  With only about 600 bytes of RAM left
    > for both the heap and stack, you could be getting into trouble,  
    > particularly if you either use dynamically  allocated memory on the heap
    > or  use local structures or arrays in your functions.
    >
    > Look through the code for the 'new' keyword and check out memory needed
    > for local variables in each function.  If there is no dynamic memory
    > allocation and reasonable stack usage for local variables, 600 bytes
    > ought to be enough for the stack.
    >
    > Mark Borgerson


    Thanks Mark for the response, it's the MSP430-FG4618. In the datasheet
    it says MSP430xG4618 has 8K of RAM, so it gives me little hope
    here ;-)

    So far I've known there's no usage of dynamic memory allocation
    memory. The arrays I mention above is the initialized hard code only

    TIA,
     
    halong, Dec 9, 2009
    #5
  6. halong

    halong Guest

    On Dec 9, 8:16 am, Thad Smith <> wrote:
    > halong wrote:
    > > However, I've now reached the point that if I add one more row of data
    > > (128 bytes per each row), the compiler STILL compiler with no warning
    > > or error, but the program won't run at all at power up (lost start
    > > point)

    >
    > I suspect that you haven't reserved enough RAM for stack and therefore
    > the linker isn't telling you when you have run our of RAM.
    >
    > My recollection is that the linker map gives a call tree analysis
    > showing the worst-case stack use, assuming no function pointer use, but
    > you have to explicitly reserve it.  With my use it assumed that all
    > interrupts enabled were nested, which produced a prediction of stack use
    > worse than actually required (I backed out the nested interrupt portion
    > of stack use).
    >
    > --
    > Thad


    Oh Thank you thank you for the answer, that rings the bell although
    I'm new to this IDE.

    The IAR uses linker command file *.xcl to define for such things such
    as stack, RAM, constant data, etc...

    I'm using the default linker file for this micro controller, which
    come /w the IDE software. Most of the content in the file are
    comments and notes, and yes the notes said the constant data is limit
    to a certain amount, as well as RAM and stack....

    Below is the content of the file, I'm not sure which parameter(s) need
    to changed to increase the reseverd RAM size, please help (view better
    with fixed font)

    //*****************************************************************
    // The following segments are defined in this linker command file:
    //
    // Data read/write segments (RAM)
    // ==============================
    //
    // segment address range usage
    // ------- ------------- --------------------------
    // DATA16_I 1100-30FF Initialized variables
    // DATA16_Z 1100-30FF Zero initialized variables
    // DATA16_N 1100-30FF Uninitialized variables
    // CSTACK 1100-30FF Run-time stack/auto variables
    // HEAP 1100-30FF The heap used by malloc and free
    //
    //
    // Program and non-volatile segments (FLASH)
    // =========================================
    //
    // segment address range usage
    // ------- ------------- --------------------------
    // INFO 1000-10FF Information memory
    // CSTART 3100-FFDF cstartup program code
    // 10000-1FFFF
    // CODE 3100-FFBE Program code
    // 10000-1FFFF
    // ISR_CODE 3100-FFDF Interrupt service routines, must be
    placed in 16-bit
    // memory
    // 10000-1FFFF
    // TAIVINT 3100-FFDF Timer A interrupt vector generator
    support code
    // DATA16_C 3100-FFDF Constant "const" variables AND String
    literals
    // 10000-1FFFF
    // DATA16_ID 3100-FFDF Initializers for DATA16_I
    // 10000-1FFFF
    // DIFUNCT 3100-FFDF Dynamic initialization vector used by
    C
    ++
    // 10000-1FFFF
    // CHECKSUM 3100-FFDF The linker places the checksum byte(s)
    in this segment,
    // when the -J linker command line option
    is used.
    //
    // INTVEC FFC0-FFFF Interrupt vectors
    //
    // NOTE:
    // It is not possible to pack the CSTART segment by using the XLINK -
    P option
    // Special function registers and peripheral modules occupy addresses
    0-01FFh
    // Be sure to use end values for the defined addresses
    //*****************************************************************

    // -------------------------------------------------------------------
    // Stack size and heap size
    // -------------------------------------------------------------------

    // Uncomment for command line use
    //-D_STACK_SIZE=200
    //-D_HEAP_SIZE=300

    // ---------------------------------------------------------
    // Define cpu.
    //

    -cmsp430

    // ---------------------------------------------------------
    // RAM memory.
    //

    -Z(DATA)DATA16_I,DATA16_Z,DATA16_N,HEAP+_HEAP_SIZE=1100-30FF
    -Z(DATA)CSTACK+_STACK_SIZE#

    // ---------------------------------------------------------
    // Read only memory.
    //

    // -------------------------------------------------------------------
    // Information memory (FLASH)
    // -------------------------------------------------------------------

    -Z(CODE)INFO=1000-10FF
    -Z(CODE)INFOA=1080-10FF
    -Z(CODE)INFOB=1000-107F

    // -----------------------------------------------
    // Constant data.

    -Z(CONST)DATA16_C,DATA16_ID,DIFUNCT=3100-FFBE

    // -----------------------------------------------
    // Code.

    -Z(CODE)CSTART,ISR_CODE,IVCODE=3100-FFBE
    -P(CODE)CODE=3100-FFBE,10000-1FFFF

    // -----------------------------------------------
    // Interrupt vector.

    -Z(CODE)INTVEC=FFC0-FFFF
    -Z(CODE)RESET=FFFE-FFFF

    // ---------------------------------------------------------
    // The end.
    //
     
    halong, Dec 9, 2009
    #6
  7. halong

    halong Guest

    On Dec 9, 9:24 am, halong <> wrote:
    > On Dec 9, 8:16 am, Thad Smith <> wrote:
    >
    >
    >
    > > halong wrote:
    > > > However, I've now reached the point that if I add one more row of data
    > > > (128 bytes per each row), the compiler STILL compiler with no warning
    > > > or error, but the program won't run at all at power up (lost start
    > > > point)

    >
    > > I suspect that you haven't reserved enough RAM for stack and therefore
    > > the linker isn't telling you when you have run our of RAM.

    >
    > > My recollection is that the linker map gives a call tree analysis
    > > showing the worst-case stack use, assuming no function pointer use, but
    > > you have to explicitly reserve it.  With my use it assumed that all
    > > interrupts enabled were nested, which produced a prediction of stack use
    > > worse than actually required (I backed out the nested interrupt portion
    > > of stack use).

    >
    > > --
    > > Thad

    >
    > Oh Thank you thank you for the answer, that rings the bell although
    > I'm new to this IDE.
    >
    > The IAR uses linker command file *.xcl to define for such things such
    > as stack, RAM, constant data, etc...
    >
    > I'm using the default linker file for this micro controller, which
    > come /w the IDE software.  Most of the content in the file are
    > comments and notes, and yes the notes said the constant data is limit
    > to a certain amount, as well as RAM and stack....
    >
    > Below is the content of the file, I'm not sure which parameter(s) need
    > to changed to increase the reseverd RAM size, please help (view better
    > with fixed font)
    >
    > //*****************************************************************
    > //  The following segments are defined in this linker command file:
    > //
    > //  Data read/write segments (RAM)
    > //  ==============================
    > //
    > //  segment     address range   usage
    > //  -------     -------------   --------------------------
    > //  DATA16_I    1100-30FF       Initialized variables
    > //  DATA16_Z    1100-30FF       Zero initialized variables
    > //  DATA16_N    1100-30FF       Uninitialized variables
    > //  CSTACK      1100-30FF       Run-time stack/auto variables
    > //  HEAP        1100-30FF       The heap used by malloc and free
    > //
    > //
    > //  Program and non-volatile segments (FLASH)
    > //  =========================================
    > //
    > //  segment     address range   usage
    > //  -------     -------------   --------------------------
    > //  INFO        1000-10FF       Information memory
    > //  CSTART      3100-FFDF       cstartup program code
    > //              10000-1FFFF
    > //  CODE        3100-FFBE       Program code
    > //              10000-1FFFF
    > //  ISR_CODE    3100-FFDF       Interrupt service routines, must be
    > placed in 16-bit
    > //                              memory
    > //              10000-1FFFF
    > //  TAIVINT     3100-FFDF       Timer A interrupt vector generator
    > support code
    > //  DATA16_C    3100-FFDF       Constant "const" variables AND String
    > literals
    > //              10000-1FFFF
    > //  DATA16_ID   3100-FFDF       Initializers for DATA16_I
    > //              10000-1FFFF
    > //  DIFUNCT     3100-FFDF       Dynamic initialization vectorused by
    > C
    > ++
    > //              10000-1FFFF
    > //  CHECKSUM    3100-FFDF       The linker places the checksum byte(s)
    > in this segment,
    > //                              when the -Jlinker command line option
    > is used.
    > //
    > //  INTVEC      FFC0-FFFF       Interrupt vectors
    > //
    > //  NOTE:
    > //  It is not possible to pack the CSTART segment by using the XLINK -
    > P option
    > //  Special function registers and peripheral modules occupy addresses
    > 0-01FFh
    > //  Be sure to use end values for the defined addresses
    > //*****************************************************************
    >
    > // -------------------------------------------------------------------
    > // Stack size and heap size
    > // -------------------------------------------------------------------
    >
    > // Uncomment for command line use
    > //-D_STACK_SIZE=200
    > //-D_HEAP_SIZE=300
    >
    > // ---------------------------------------------------------
    > // Define cpu.
    > //
    >
    > -cmsp430
    >
    > // ---------------------------------------------------------
    > // RAM memory.
    > //
    >
    > -Z(DATA)DATA16_I,DATA16_Z,DATA16_N,HEAP+_HEAP_SIZE=1100-30FF
    > -Z(DATA)CSTACK+_STACK_SIZE#
    >
    > // ---------------------------------------------------------
    > // Read only memory.
    > //
    >
    > // -------------------------------------------------------------------
    > //  Information memory (FLASH)
    > // -------------------------------------------------------------------
    >
    > -Z(CODE)INFO=1000-10FF
    > -Z(CODE)INFOA=1080-10FF
    > -Z(CODE)INFOB=1000-107F
    >
    > // -----------------------------------------------
    > // Constant data.
    >
    > -Z(CONST)DATA16_C,DATA16_ID,DIFUNCT=3100-FFBE
    >
    > // -----------------------------------------------
    > // Code.
    >
    > -Z(CODE)CSTART,ISR_CODE,IVCODE=3100-FFBE
    > -P(CODE)CODE=3100-FFBE,10000-1FFFF
    >
    > // -----------------------------------------------
    > // Interrupt vector.
    >
    > -Z(CODE)INTVEC=FFC0-FFFF
    > -Z(CODE)RESET=FFFE-FFFF
    >
    > // ---------------------------------------------------------
    > // The end.
    > //


    Oh, thank you Thad and Mark, I've solved it.

    Since the array (memory) for initialized data only, that means, I've
    better to add keyword "const" before the "char INIT_ARRAY[][]"

    I'm not sure understand it, but when Mark pointed out the usage of
    dynamic allocate mem. make me think about the "const" data keyword -
    I'm guessing it will put the data and code separated from the low
    memory range
     
    halong, Dec 9, 2009
    #7
  8. In article <078cd534-bac7-4cd6-940d-2b76ee6fb672
    @m38g2000yqd.googlegroups.com>, says...
    > On Dec 9, 9:24 am, halong <> wrote:
    > > On Dec 9, 8:16 am, Thad Smith <> wrote:
    > >
    > >
    > >
    > > > halong wrote:
    > > > > However, I've now reached the point that if I add one more row of data
    > > > > (128 bytes per each row), the compiler STILL compiler with no warning
    > > > > or error, but the program won't run at all at power up (lost start
    > > > > point)

    > >
    > > > I suspect that you haven't reserved enough RAM for stack and therefore
    > > > the linker isn't telling you when you have run our of RAM.

    > >
    > > > My recollection is that the linker map gives a call tree analysis
    > > > showing the worst-case stack use, assuming no function pointer use, but
    > > > you have to explicitly reserve it.  With my use it assumed that all
    > > > interrupts enabled were nested, which produced a prediction of stack use
    > > > worse than actually required (I backed out the nested interrupt portion
    > > > of stack use).

    > >
    > > > --
    > > > Thad

    > >

    <<SNIP>>
    >
    > Oh, thank you Thad and Mark, I've solved it.
    >
    > Since the array (memory) for initialized data only, that means, I've
    > better to add keyword "const" before the "char INIT_ARRAY[][]"


    If you use a const char INIT-ARRAY[][].....

    and actually initialize the arrays and they are never changed, that
    has two beneficial effects:

    1. The arrays are located in flash memory and don't use any of your RAM
    2. The initialization routine doesn't have to copy the initialization
    values from Flash to RAM at program startup.


    On some ARM processors, the code will run faster if the array is in
    RAM, as the RAM doesn't require wait states, but the flash memory
    does. I think the MSP430 series can access flash and RAM at the
    same speed.
    >
    > I'm not sure understand it, but when Mark pointed out the usage of
    > dynamic allocate mem. make me think about the "const" data keyword -
    > I'm guessing it will put the data and code separated from the low
    > memory range
    >
    >


    Mark Borgerson
     
    Mark Borgerson, Dec 9, 2009
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael

    4k limit of IAR's MSP430 C compiler

    Michael, Jan 20, 2004, in forum: Embedded
    Replies:
    5
    Views:
    714
    Michael
    Jan 26, 2004
  2. JS
    Replies:
    11
    Views:
    1,486
    larwe
    Oct 5, 2007
  3. Niklas Holsti

    Re: IAR MSP430 compiler problem

    Niklas Holsti, Nov 23, 2009, in forum: Embedded
    Replies:
    20
    Views:
    693
    Niklas Holsti
    Dec 1, 2009
  4. 42Bastian Schick

    Re: IAR MSP430 compiler problem

    42Bastian Schick, Nov 24, 2009, in forum: Embedded
    Replies:
    0
    Views:
    280
    42Bastian Schick
    Nov 24, 2009
  5. larwe

    Re: IAR MSP430 compiler problem

    larwe, Nov 25, 2009, in forum: Embedded
    Replies:
    0
    Views:
    269
    larwe
    Nov 25, 2009
Loading...

Share This Page