The extra word is probably the watchdog timer clear value, which is
initialized on reset. You can exclude it by using -mdisable-watchdog.
mspgcc uses different sections than AVR, and for mspgcc .noinit is not
merged with .bss. With the default linker script .noinit is between the
bottom of the stack and the top of .bss.
You can use msp430-objdump -x app.elf to see the list of sections available
and what's in them (at what address). That information can tell you what's
going to be below the stack, hence the first thing that would get
overwritten when it overruns.
#include <sys/crtld.h> provides declarations for common symbols related to
where things are in memory. Most of those come from the generic linker
scripts, but a couple (e.g. info section addresses) from the MCU-specific
memory.x linker scripts; all linker scripts are in
installdir/msp430/lib/ldscripts/.
Peter
On Mon, Jul 29, 2013 at 5:28 PM, Wayne Uroda <w.ur...@gmail.com> wrote:
> Hi Daniel,
>
> Yesterday I was looking at just this and to my surprise there was one
> extra word allocated to ".noinit". I had never seen this before in all my
> years, and I was almost filling over it with a pattern to measure my stack
> usage. My point is that one should add the size of bss and data and noinit
> to find the statically allocated area, or is this incorrect?
>
> At runtime you can find the address of the last of the static data by
> taking the address of _end, which is provided by the linker script,
> something like:
>
> void *_end;
> UInt16 endAddr = (UInt16)&_end;
>
> (Please let me know if there is a better/preferred way to do this).
>
> You can also get the current stack pointer by doing something like this:
> UInt16 sp;
>
> __volatile__ __asm__ (" mov r1, %0" : "=g" (sp));
>
> This tells the compiler to move the stack pointer into the variable sp
> using any method it chooses (register or memory).
>
> Then you can simply loop from one address to the other and fill with a
> pattern like 0x55 or similar.
>
> I used this only in a debug environment and wouldn't trust to have it run
> in a production environment because it was something I threw together real
> quick.
>
> - Wayne
>
> On 30/07/2013, at 6:22, Daniel Beer <dlb...@gmail.com> wrote:
>
> > On Mon, Jul 29, 2013 at 12:56:31PM -0700, ravim wrote:
> >> My apologies if I am asking something irrelevant to this forum. We are
> using
> >> mspgcc and mspdebug for our project. We are facing some issues with
> what we
> >> assume might be stack overflow. The timer interrupts stops working after
> >> around 2 hours, however device still receives packets. Also, when we
> reset
> >> the device after timer gets stuck, they never turn back on unless we
> >> re-install the code. We are trying to debug.
> >>
> >> I wanted to know if there is any possible way we can know the size of
> global
> >> variables in the binary? This will help us narrow down a few specifics.
> We
> >> know there is something in TinyOs when we make, it let us know size of
> >> global variables, we are looking for something similar in mspdebug.
> >>
> >> We would really appreciate any help.
> >
> > Try "size <filename.elf>". Add "data" and "bss" to get the total size of
> > statically allocated data. You can also use size on the individual
> > object files if you want to narrow down your search, but remember to use
> > --common if you need global (non-static) variables to be counted.
> >
> > Cheers,
> > Daniel
> >
> > --
> > Daniel Beer <dlb...@gmail.com> www.dlbeer.co.nz
> > IRC: inittab (Freenode) PGP key: 2048D/160A553B
> >
> >
> ------------------------------------------------------------------------------
> > Get your SQL database under version control now!
> > Version control is standard for application code, but databases havent
> > caught up. So what steps can you take to put your SQL databases under
> > version control? Why should you start doing it? Read more to find out.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
