Hi, List.
Now that I am the veteran of one successful project using the MSP430F149, I
am designing my second using
the MSP430F1121 for a legitimate low power app: a battery powered remote
control RF widget.
I started constructing the transmitter end, beginning with the LED
flasher demo suppiled with the IAR C compiler. (Did I mention this is
presently being developed in C?)
As soon as I added a few small functions in a second C source file, the
stack size jumped up to what you see below, obviously bigger than available
RAM. Even when no functions are called, the stack size does not change, and
I can't get C-SPY to position correctly on the first line of the program
when it loads, it just runs immediately.
I looked at the lnk430C1121.xcl file and inside it is the following line:
-Z(DATA)CSTACK#0200-0300
As I understand it, this ought to position the stack at 300 (shouldn't this
be 2ff? It must decrement the SP before the push, I guess...) and it should
grow downward.
What you see below is what I got when I compiled it.
******(begin paste)
****************************************
*
*
* SEGMENTS IN ADDRESS ORDER *
*
*
****************************************
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE
ALIGN
======= ===== ============= =========== ====
=======IDATA0 0200 rel
1
UDATA0 0200 - 0203 4 rel 1
ECSTR 0204 rel 1
CSTACK 0204 - 0303 100 rel 1
NO_INIT 7000 dse 0
CSTR FE9C dse 0
CONST FE9C dse 0
CDATA0 FE9C rel 1
CCSTR FE9C rel 1
CODE FE9C - FFDF 144 rel 1
INTVEC FFE0 - FFFF 20 com 1
****************************************
*
*
* END OF CROSS REFERENCE *
*
*
****************************************
356 bytes of CODE memory
260 bytes of DATA memory
Errors: none
Warnings: none
*******(end paste)
As you can see, CSTACK is located from 204 to 303. Why is it so big, and,
why does it extend above 300?
Could it be that a program in a MSP430 with this small amount of ram needs
to
be written in assembly because C consumes too much of it's resources?
I'm stuck, and will have to restart in ASM if I don't figure it out
soon.
TIA,
Mark
Using C with ...1121; stack size?
Started by ●February 14, 2003
Reply by ●February 14, 20032003-02-14
Possibly you have an array that you are not declaring as a const? If you
do
something like:
char *messages [] {
"message 1",
"message 2",
"message 3",
};
etc, the pointers to the strings will be in RAM. I got bit the other day by
having a CRC table that I forgot to declare const suck up everything.
--John
-----Original Message-----
From: Mark Skeels [mailto:meskeels@mesk...]
Sent: Friday, February 14, 2003 10:16
To: MSP430 List
Subject: [msp430] Using C with ...1121; stack size?
Hi, List.
Now that I am the veteran of one successful project using the MSP430F149,
I
am designing my second using
the MSP430F1121 for a legitimate low power app: a battery powered remote
control RF widget.
I started constructing the transmitter end, beginning with the LED
flasher demo suppiled with the IAR C compiler. (Did I mention this is
presently being developed in C?)
As soon as I added a few small functions in a second C source file, the
stack size jumped up to what you see below, obviously bigger than
available
RAM. Even when no functions are called, the stack size does not change,
and
I can't get C-SPY to position correctly on the first line of the program
when it loads, it just runs immediately.
I looked at the lnk430C1121.xcl file and inside it is the following line:
-Z(DATA)CSTACK#0200-0300
As I understand it, this ought to position the stack at 300 (shouldn't
this
be 2ff? It must decrement the SP before the push, I guess...) and it
should
grow downward.
What you see below is what I got when I compiled it.
******(begin paste)
****************************************
*
*
* SEGMENTS IN ADDRESS ORDER *
*
*
****************************************
SEGMENT SPACE START ADDRESS END ADDRESS SIZE TYPE
ALIGN
======= ===== ============= =========== ==== === ====
IDATA0 0200 rel 1
UDATA0 0200 - 0203 4 rel 1
ECSTR 0204 rel
1
CSTACK 0204 - 0303 100 rel 1
NO_INIT 7000 dse 0
CSTR FE9C dse
0
CONST FE9C dse 0
CDATA0 FE9C rel 1
CCSTR FE9C rel 1
CODE FE9C - FFDF 144 rel
1
INTVEC FFE0 - FFFF 20 com 1
****************************************
*
*
* END OF CROSS REFERENCE *
*
*
****************************************
356 bytes of CODE memory
260 bytes of DATA memory
Errors: none
Warnings: none
*******(end paste)
As you can see, CSTACK is located from 204 to 303. Why is it so big, and,
why does it extend above 300?
Could it be that a program in a MSP430 with this small amount of ram needs
to
be written in assembly because C consumes too much of it's resources?
I'm stuck, and will have to restart in ASM if I don't figure it out
soon.
TIA,
Mark
.
Reply by ●February 14, 20032003-02-14
Mark,
> ----- Original Message -----
> From: "J.C.Wren" <jcwren@jcwr...>
> To: <msp430@msp4...>
> Sent: Friday, February 14, 2003 10:12 AM
> Subject: RE: [msp430] Using C with ...1121; stack size?
>
>
> > Possibly you have an array that you are not declaring as a
> const? If
> > you
> do
> > something like:
> >
>
>
> Thanks, John, but nope, no arrays; in fact, I've hardly used
> any RAM thus far.....
>
Have you inadvertently set the stack size in the cstartup.s43 file using
something like...
RSEG CSTACK
DS 256
If you've done this, then it will take up RAM. What you need is the
original DS 0.
-- Paul.
Reply by ●February 14, 20032003-02-14
----- Original Message ----- From: "J.C.Wren" <jcwren@jcwr...> To: <msp430@msp4...> Sent: Friday, February 14, 2003 10:12 AM Subject: RE: [msp430] Using C with ...1121; stack size? > Possibly you have an array that you are not declaring as a const? If you do > something like: > Thanks, John, but nope, no arrays; in fact, I've hardly used any RAM thus far..... Mark
Reply by ●February 14, 20032003-02-14
Ok, sorry for taking up the bandwidth; I had neglected to configure the override setting under XLINK in EW. As soon as I selected the proper .xcl file, the ram usag dropped to 4 bytes. The .xcl file used appears in the .map file at the very beginnign, but I didn't read it...:-( Thanks for reading. Mark
Reply by ●February 15, 20032003-02-15
--- In msp430@msp4..., "Mark Skeels" <meskeels@e...> wrote:
> Thanks for reading.
A few days ago I debugged a Salvo customer's application that worked
on a '149 but failed on a '123 ... to make a long story short, it
turned out that one of his functions had one or more bad pointer
writes, and was overwriting some other data. I guess it overwrote
different regions on the '149 than the '123. Now that the function is
fixed and well-behaved, everything works fine.
Anyway, how does this relate to the thread? Well, as a matter of
course I took a look at the stack usage since there's always a
possibility that one has stack overflow. Here's the end of the map
file:
****************************************
* *
* SEGMENTS IN ADDRESS ORDER *
* *
****************************************
SEGMENT SPACE START ADDRESS END ADDRESS SIZE
TYPE ALIGN
======= ===== ============= =========== =======
====UDATA0 0200 - 0253 54
rel 1
IDATA0 0254 - 025F C
rel 1
ECSTR 0260
rel 1
CSTACK 0300
rel 1
CODE E000 - ED33 D34
rel 1
CONST ED34 - ED5B 28
rel 1
CSTR ED5C
dse 0
CDATA0 ED5C - ED67 C
rel 1
CCSTR ED68
rel 1
INTVEC FFE0 - FFFF 20
com 1
****************************************
* *
* END OF CROSS REFERENCE *
* *
****************************************
3 464 bytes of CODE memory
96 bytes of DATA memory
By filling the stack area with 00 and running in IAR's CSpy, I was
able to deduce that he was only using down to 0x2CE in the stack area.
That was with 3 tasks, 3 events, one ISR, and a variety of good-sized
functions, a few with decent-sized parameter lists.
What does all this mean? I don't know. :-) Maybe just that 256 bytes
of stack on the MSP430 is enough to do some plenty sophisticated
applications.
Andrew E. Kalman aek ... at ... pumpkininc ... dot ... com
