Forums

IAR compiler & MSP430 problem

Started by halong December 9, 2009
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 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
In article <4b1fb161$0$77534$892e0abb@auth.newsreader.octanews.com>, 
ThadSmith@acm.org 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
On Dec 9, 9:08=A0am, Mark Borgerson <mborger...@comcast.net> wrote:
> In article <4b1fb161$0$77534$892e0...@auth.newsreader.octanews.com>, > ThadSm...@acm.org says... > > > halong wrote: > > > > However, I've now reached the point that if I add one more row of dat=
a
> > > (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. =A0With my use it assumed that all > > interrupts enabled were nested, which produced a prediction of stack us=
e
> > worse than actually required (I backed out the nested interrupt portion > > of stack use). > > It would help to know which MSP430 variant you =A0are using. =A0Different > chips have different memory resources. =A0 If your chip has 4K of RAM, > you could be getting into trouble. =A0 From the fact that both the > CONST and DATA memory increased by 128, =A0I assume that you added an > initialized row to the array. =A0With only about 600 bytes of RAM left > for both the heap and stack, you could be getting into trouble, =A0 > particularly if you either use dynamically =A0allocated memory on the hea=
p
> or =A0use 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. =A0If 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) // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D // // 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) // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D // // 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=3D200 //-D_HEAP_SIZE=3D300 // --------------------------------------------------------- // Define cpu. // -cmsp430 // --------------------------------------------------------- // RAM memory. // -Z(DATA)DATA16_I,DATA16_Z,DATA16_N,HEAP+_HEAP_SIZE=3D1100-30FF -Z(DATA)CSTACK+_STACK_SIZE# // --------------------------------------------------------- // Read only memory. // // ------------------------------------------------------------------- // Information memory (FLASH) // ------------------------------------------------------------------- -Z(CODE)INFO=3D1000-10FF -Z(CODE)INFOA=3D1080-10FF -Z(CODE)INFOB=3D1000-107F // ----------------------------------------------- // Constant data. -Z(CONST)DATA16_C,DATA16_ID,DIFUNCT=3D3100-FFBE // ----------------------------------------------- // Code. -Z(CODE)CSTART,ISR_CODE,IVCODE=3D3100-FFBE -P(CODE)CODE=3D3100-FFBE,10000-1FFFF // ----------------------------------------------- // Interrupt vector. -Z(CODE)INTVEC=3DFFC0-FFFF -Z(CODE)RESET=3DFFFE-FFFF // --------------------------------------------------------- // The end. //
On Dec 9, 9:08=A0am, Mark Borgerson <mborger...@comcast.net> wrote:
> In article <4b1fb161$0$77534$892e0...@auth.newsreader.octanews.com>, > ThadSm...@acm.org says... > > > halong wrote: > > > > However, I've now reached the point that if I add one more row of dat=
a
> > > (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. =A0With my use it assumed that all > > interrupts enabled were nested, which produced a prediction of stack us=
e
> > worse than actually required (I backed out the nested interrupt portion > > of stack use). > > It would help to know which MSP430 variant you =A0are using. =A0Different > chips have different memory resources. =A0 If your chip has 4K of RAM, > you could be getting into trouble. =A0 From the fact that both the > CONST and DATA memory increased by 128, =A0I assume that you added an > initialized row to the array. =A0With only about 600 bytes of RAM left > for both the heap and stack, you could be getting into trouble, =A0 > particularly if you either use dynamically =A0allocated memory on the hea=
p
> or =A0use 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. =A0If 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,
On Dec 9, 8:16=A0am, Thad Smith <ThadSm...@acm.org> 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. =A0With 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) // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D // // 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) // =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D // // 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=3D200 //-D_HEAP_SIZE=3D300 // --------------------------------------------------------- // Define cpu. // -cmsp430 // --------------------------------------------------------- // RAM memory. // -Z(DATA)DATA16_I,DATA16_Z,DATA16_N,HEAP+_HEAP_SIZE=3D1100-30FF -Z(DATA)CSTACK+_STACK_SIZE# // --------------------------------------------------------- // Read only memory. // // ------------------------------------------------------------------- // Information memory (FLASH) // ------------------------------------------------------------------- -Z(CODE)INFO=3D1000-10FF -Z(CODE)INFOA=3D1080-10FF -Z(CODE)INFOB=3D1000-107F // ----------------------------------------------- // Constant data. -Z(CONST)DATA16_C,DATA16_ID,DIFUNCT=3D3100-FFBE // ----------------------------------------------- // Code. -Z(CODE)CSTART,ISR_CODE,IVCODE=3D3100-FFBE -P(CODE)CODE=3D3100-FFBE,10000-1FFFF // ----------------------------------------------- // Interrupt vector. -Z(CODE)INTVEC=3DFFC0-FFFF -Z(CODE)RESET=3DFFFE-FFFF // --------------------------------------------------------- // The end. //
On Dec 9, 9:24=A0am, halong <cco...@netscape.net> wrote:
> On Dec 9, 8:16=A0am, Thad Smith <ThadSm...@acm.org> wrote: > > > > > halong wrote: > > > However, I've now reached the point that if I add one more row of dat=
a
> > > (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. =A0With my use it assumed that all > > interrupts enabled were nested, which produced a prediction of stack us=
e
> > 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. =A0Most 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) > > //***************************************************************** > // =A0The following segments are defined in this linker command file: > // > // =A0Data read/write segments (RAM) > // =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> // > // =A0segment =A0 =A0 address range =A0 usage > // =A0------- =A0 =A0 ------------- =A0 -------------------------- > // =A0DATA16_I =A0 =A01100-30FF =A0 =A0 =A0 Initialized variables > // =A0DATA16_Z =A0 =A01100-30FF =A0 =A0 =A0 Zero initialized variables > // =A0DATA16_N =A0 =A01100-30FF =A0 =A0 =A0 Uninitialized variables > // =A0CSTACK =A0 =A0 =A01100-30FF =A0 =A0 =A0 Run-time stack/auto variabl=
es
> // =A0HEAP =A0 =A0 =A0 =A01100-30FF =A0 =A0 =A0 The heap used by malloc a=
nd free
> // > // > // =A0Program and non-volatile segments (FLASH) > // =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> // > // =A0segment =A0 =A0 address range =A0 usage > // =A0------- =A0 =A0 ------------- =A0 -------------------------- > // =A0INFO =A0 =A0 =A0 =A01000-10FF =A0 =A0 =A0 Information memory > // =A0CSTART =A0 =A0 =A03100-FFDF =A0 =A0 =A0 cstartup program code > // =A0 =A0 =A0 =A0 =A0 =A0 =A010000-1FFFF > // =A0CODE =A0 =A0 =A0 =A03100-FFBE =A0 =A0 =A0 Program code > // =A0 =A0 =A0 =A0 =A0 =A0 =A010000-1FFFF > // =A0ISR_CODE =A0 =A03100-FFDF =A0 =A0 =A0 Interrupt service routines, m=
ust be
> placed in 16-bit > // =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0memory > // =A0 =A0 =A0 =A0 =A0 =A0 =A010000-1FFFF > // =A0TAIVINT =A0 =A0 3100-FFDF =A0 =A0 =A0 Timer A interrupt vector gene=
rator
> support code > // =A0DATA16_C =A0 =A03100-FFDF =A0 =A0 =A0 Constant "const" variables AN=
D String
> literals > // =A0 =A0 =A0 =A0 =A0 =A0 =A010000-1FFFF > // =A0DATA16_ID =A0 3100-FFDF =A0 =A0 =A0 Initializers for DATA16_I > // =A0 =A0 =A0 =A0 =A0 =A0 =A010000-1FFFF > // =A0DIFUNCT =A0 =A0 3100-FFDF =A0 =A0 =A0 Dynamic initialization vector=
used by
> C > ++ > // =A0 =A0 =A0 =A0 =A0 =A0 =A010000-1FFFF > // =A0CHECKSUM =A0 =A03100-FFDF =A0 =A0 =A0 The linker places the checksu=
m byte(s)
> in this segment, > // =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0when the -J=
linker command line option
> is used. > // > // =A0INTVEC =A0 =A0 =A0FFC0-FFFF =A0 =A0 =A0 Interrupt vectors > // > // =A0NOTE: > // =A0It is not possible to pack the CSTART segment by using the XLINK - > P option > // =A0Special function registers and peripheral modules occupy addresses > 0-01FFh > // =A0Be sure to use end values for the defined addresses > //***************************************************************** > > // ------------------------------------------------------------------- > // Stack size and heap size > // ------------------------------------------------------------------- > > // Uncomment for command line use > //-D_STACK_SIZE=3D200 > //-D_HEAP_SIZE=3D300 > > // --------------------------------------------------------- > // Define cpu. > // > > -cmsp430 > > // --------------------------------------------------------- > // RAM memory. > // > > -Z(DATA)DATA16_I,DATA16_Z,DATA16_N,HEAP+_HEAP_SIZE=3D1100-30FF > -Z(DATA)CSTACK+_STACK_SIZE# > > // --------------------------------------------------------- > // Read only memory. > // > > // ------------------------------------------------------------------- > // =A0Information memory (FLASH) > // ------------------------------------------------------------------- > > -Z(CODE)INFO=3D1000-10FF > -Z(CODE)INFOA=3D1080-10FF > -Z(CODE)INFOB=3D1000-107F > > // ----------------------------------------------- > // Constant data. > > -Z(CONST)DATA16_C,DATA16_ID,DIFUNCT=3D3100-FFBE > > // ----------------------------------------------- > // Code. > > -Z(CODE)CSTART,ISR_CODE,IVCODE=3D3100-FFBE > -P(CODE)CODE=3D3100-FFBE,10000-1FFFF > > // ----------------------------------------------- > // Interrupt vector. > > -Z(CODE)INTVEC=3DFFC0-FFFF > -Z(CODE)RESET=3DFFFE-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
In article <078cd534-bac7-4cd6-940d-2b76ee6fb672
@m38g2000yqd.googlegroups.com>, ccon67@netscape.net says...
> On Dec 9, 9:24=A0am, halong <cco...@netscape.net> wrote: > > On Dec 9, 8:16=A0am, Thad Smith <ThadSm...@acm.org> wrote: > > > > > > > > > halong wrote: > > > > However, I've now reached the point that if I add one more row of d=
ata
> > > > (128 bytes per each row), the compiler STILL compiler with no warni=
ng
> > > > 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 therefor=
e
> > > 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, b=
ut
> > > you have to explicitly reserve it. =A0With 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 porti=
on
> > > of stack use). > > > > > -- > > > Thad > >
<<SNIP>>
>=20 > Oh, thank you Thad and Mark, I've solved it. >=20 > 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=20 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.
>=20 > 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 >=20 >
Mark Borgerson