Reply by Mark Borgerson●December 9, 20092009-12-09
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
Reply by halong●December 9, 20092009-12-09
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=
> 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
Reply by halong●December 9, 20092009-12-09
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.
//
Reply by halong●December 9, 20092009-12-09
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,
Reply by halong●December 9, 20092009-12-09
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.
//
Reply by Mark Borgerson●December 9, 20092009-12-09
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
Reply by Thad Smith●December 9, 20092009-12-09
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 by halong●December 9, 20092009-12-09
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,