Motherboard Forums


Reply
Thread Tools Display Modes

IAR compiler & MSP430 problem

 
 
halong
Guest
Posts: n/a
 
      12-09-2009, 01:55 PM
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,
 
Reply With Quote
 
 
 
 
Thad Smith
Guest
Posts: n/a
 
      12-09-2009, 02:16 PM
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
 
Reply With Quote
 
 
 
 
Mark Borgerson
Guest
Posts: n/a
 
      12-09-2009, 03:08 PM
In article <4b1fb161$0$77534$(E-Mail Removed) s.com>,
(E-Mail Removed) 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

 
Reply With Quote
 
halong
Guest
Posts: n/a
 
      12-09-2009, 03:10 PM
On Dec 9, 9:08*am, Mark Borgerson <(E-Mail Removed)> wrote:
> In article <4b1fb161$0$77534$(E-Mail Removed) s.com>,
> (E-Mail Removed) 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.
//
 
Reply With Quote
 
halong
Guest
Posts: n/a
 
      12-09-2009, 03:21 PM
On Dec 9, 9:08*am, Mark Borgerson <(E-Mail Removed)> wrote:
> In article <4b1fb161$0$77534$(E-Mail Removed) s.com>,
> (E-Mail Removed) 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,
 
Reply With Quote
 
halong
Guest
Posts: n/a
 
      12-09-2009, 03:24 PM
On Dec 9, 8:16*am, Thad Smith <(E-Mail Removed)> 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.
//
 
Reply With Quote
 
halong
Guest
Posts: n/a
 
      12-09-2009, 04:09 PM
On Dec 9, 9:24*am, halong <(E-Mail Removed)> wrote:
> On Dec 9, 8:16*am, Thad Smith <(E-Mail Removed)> 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




 
Reply With Quote
 
Mark Borgerson
Guest
Posts: n/a
 
      12-09-2009, 07:25 PM
In article <078cd534-bac7-4cd6-940d-2b76ee6fb672
@m38g2000yqd.googlegroups.com>, (E-Mail Removed) says...
> On Dec 9, 9:24*am, halong <(E-Mail Removed)> wrote:
> > On Dec 9, 8:16*am, Thad Smith <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: IAR MSP430 compiler problem Niklas Holsti Embedded 20 12-01-2009 06:23 PM
Re: IAR MSP430 compiler problem larwe Embedded 0 11-25-2009 10:54 PM
Re: IAR MSP430 compiler problem 42Bastian Schick Embedded 0 11-24-2009 06:58 AM
Proteus 6 Professional, labcenter.co.uk, IAR visualSTATE v5.0.7.88, IAR Embedded.Workbench for 68HC12.V2.44A, ARM.V4.11A, Atmel.AVR.V3.20A, CR16C.V2.10A, H8.V1.53I, MCS-51.V6.10A, Mitsubishi.740.V2.16A, Mitsubishi.M32C.V2.11A, MSP430.V3.20A, NEC.V850 alfa_omega Embedded 0 11-06-2004 06:39 PM
4k limit of IAR's MSP430 C compiler Michael Embedded 5 01-26-2004 02:30 AM


All times are GMT. The time now is 02:37 AM.


Welcome!
Welcome to Motherboard Point
 

Advertisment