Hint:

Put a flag on memmove() at the beginning test to see if it is set, if
not, set it, at the end clear it.

If When you come in, it is set, you are doing it recursively,
unknowingly( I would assume).

From: m... [mailto:m...] On Behalf
Of david_mcminn
Sent: Monday, November 19, 2012 4:17 AM
To: m...
Subject: [msp430] Re: how to debug reset caused by WDTCTL security key
violation

Hi Matthias,

> >> However it is really a problem that the stack space is not
> >> protected in the MSP's (or almost any other controller). I also
> >> do not know a tool that calculates maximal stack usage (this is
> >> possible in case recursion is not used). It is something like
> >> "ok it is running - so stack space seem sufficient" - some kind
> >> of hope based design ;-).
> >
> > IAR can give you that information in the linker output. In the
> > linker options for your project switch to the "List" tab and
> > check the "Static Overlay Map" option. In your output .map file
> > there is a section titled "Call Graph" which shows stack usage
> > for all your function calls. If you go right to the bottom of
> > that section you can see the maximum stack usage.
>
> Thx. Is there some kind of warning in case the maximum stack usage
> is larger than the free RAM?

It does not give you a warning when you exceed the size of the stack you
set in the project options, nor when you exceed the size of ram space.
So it looks like you would need to manually check.

As I was checking this I noticed lines that said "Recursive system
consisting of" when I had used memmove(), so perhaps this still does not
give a true picture if you have (perhaps unknowingly) used a recursive
library call.

> What is "static overlay map"? Is there a separate RAM space used
> for the local variables used in the functions and the stack is used
> only for return adresses? (I remember the keil C51 compiler is
> doing it that way, because stack space is quite limited in the 8051)

According to the manual, you cannot choose to use static overlay (which
is as you describe) with the MSP430 version of IAR, I guess because
there is enough RAM. However, you can still turn on the output, the
static overlay map, which shows how much RAM would be used by local
variables.

I guess (I haven't used IAR compilers for other targets) that the map
when using static overlay for real would show you the address in RAM and
what local variables it is used for.

Beginning Microcontrollers with the MSP430

Hi Matthias,

> >> However it is really a problem that the stack space is not
> >> protected in the MSP's (or almost any other controller). I also
> >> do not know a tool that calculates maximal stack usage (this is
> >> possible in case recursion is not used). It is something like
> >> "ok it is running - so stack space seem sufficient" - some kind
> >> of hope based design ;-).
> >
> > IAR can give you that information in the linker output. In the
> > linker options for your project switch to the "List" tab and
> > check the "Static Overlay Map" option. In your output .map file
> > there is a section titled "Call Graph" which shows stack usage
> > for all your function calls. If you go right to the bottom of
> > that section you can see the maximum stack usage.
>
> Thx. Is there some kind of warning in case the maximum stack usage
> is larger than the free RAM?

It does not give you a warning when you exceed the size of the stack you set in the project options, nor when you exceed the size of ram space. So it looks like you would need to manually check.

As I was checking this I noticed lines that said "Recursive system consisting of" when I had used memmove(), so perhaps this still does not give a true picture if you have (perhaps unknowingly) used a recursive library call.

> What is "static overlay map"? Is there a separate RAM space used
> for the local variables used in the functions and the stack is used
> only for return adresses? (I remember the keil C51 compiler is
> doing it that way, because stack space is quite limited in the 8051)

According to the manual, you cannot choose to use static overlay (which is as you describe) with the MSP430 version of IAR, I guess because there is enough RAM. However, you can still turn on the output, the static overlay map, which shows how much RAM would be used by local variables.

I guess (I haven't used IAR compilers for other targets) that the map when using static overlay for real would show you the address in RAM and what local variables it is used for.

"david_mcminn" :

> Hi Matthias,
>
>> However it is really a problem that the stack space is not protected
>> in the MSP's (or almost any other controller). I also do not know a
>> tool that calculates maximal stack usage (this is possible in case
>> recursion is not used). It is something like "ok it is running - so
>> stack space seem sufficient" - some kind of hope based design ;-).
>
> IAR can give you that information in the linker output. In the linker
> options for your project switch to the "List" tab and check the "Static
> Overlay Map" option. In your output .map file there is a section titled
> "Call Graph" which shows stack usage for all your function calls. If you
> go right to the bottom of that section you can see the maximum stack
> usage.

Thx. Is there some kind of warning in case the maximum stack usage is
larger than the free RAM?
What is "static overlay map"? Is there a separate RAM space used for the
local variables used in the functions and the stack is used only for return
adresses? (I remember the keil C51 compiler is doing it that way, because
stack space is quite limited in the 8051)

> I guess other compilers might have a similar feature.

It seems my Crossworks compiler/linker does not have this feature. The Map-
File is quite simple...

M.

DeadBeef is better, its 2 - 16 bit words

DecafBad is 20 – 12 bits, not an exact split.

From: m... [mailto:m...] On Behalf Of Jon Kirwan

Sent: Wednesday, November 14, 2012 4:49 AM

To: MSP430 List

Subject: Re: [msp430] Re: how to debug reset caused by WDTCTL security key violation

On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:

>Hi Xiaohui,

>

>a litte suggestion:.

>

>Xiaohui Liu >:

>

>> 2) Watchdog timer security key violation.

>

>Probably stack overflow. Fill your RAM with a simple pattern (e.g.

>0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by the

>startupcode) and after the next break after reset take a look in the RAM

>space. If there is no 0xDeadBeef anymore you have a problem. :-)

I suggested what amounts to that a few days ago, without

meaningful response yet. It's possible it's still a work in

progress.

Jon

Hi Matthias,

> However it is really a problem that the stack space is not protected
> in the MSP's (or almost any other controller). I also do not know a
> tool that calculates maximal stack usage (this is possible in case
> recursion is not used). It is something like "ok it is running - so
> stack space seem sufficient" - some kind of hope based design ;-).

IAR can give you that information in the linker output. In the linker options for your project switch to the "List" tab and check the "Static Overlay Map" option. In your output .map file there is a section titled "Call Graph" which shows stack usage for all your function calls. If you go right to the bottom of that section you can see the maximum stack usage.

I guess other compilers might have a similar feature.

Assembler? Never any problems with stack space.

Al

On 16/11/2012 6:09 PM, Matthias Weingart wrote:
> Yeah.
> However it is really a problem that the stack space is not protected in the
> MSP's (or almost any other controller). I also do not know a tool that
> calculates maximal stack usage (this is possible in case recursion is not
> used). It is something like "ok it is running - so stack space seem
> sufficient" - some kind of hope based design ;-).
>
> M.
>
> Xiaohui Liu :
>
>> Thank all for your help. It IS stack overflow. After I reduce my RAM
>> usage by ~2 KB, it works like a charm.
>>
>> -Xiaohui Liu
>>
>> On Wed, Nov 14, 2012 at 4:48 AM, Jon Kirwan
>> wrote:
>>
>>> **
>>>
>>>
>>> On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:
>>>
>>>> Hi Xiaohui,
>>>>
>>>> a litte suggestion:.
>>>>
>>>> Xiaohui Liu :
>>>>
>>>>> 2) Watchdog timer security key violation.
>>>> Probably stack overflow. Fill your RAM with a simple pattern (e.g.
>>>> 0xDeadBeef), put a breakpoint at reset (before the RAM is initialized
>>>> by
>>> the
>>>> startupcode) and after the next break after reset take a look in the
>>>> RAM space. If there is no 0xDeadBeef anymore you have a problem. :-)
>>> I suggested what amounts to that a few days ago, without
>>> meaningful response yet. It's possible it's still a work in
>>> progress.
>>>
>>> Jon
>>>
>

Matthias Weingart wrote:
> Yeah.
> However it is really a problem that the stack space is not protected in the
> MSP's (or almost any other controller). I also do not know a tool that
> calculates maximal stack usage (this is possible in case recursion is not
> used). It is something like "ok it is running - so stack space seem
> sufficient" - some kind of hope based design ;-).

I guess it is what our target is. Last I wrote an astronomical clock,
fits inside a 2253 fine. But we lay down an 2453 for a few cents more
and plenty of room for an os that can do this. but then we have a half
of k of ram and never have to worry about an overflow! But why worry
about an overflow if the code is right? I'll use the space for expansion.

The struggle is what you write. If the stack is in question I would
think we are expecting box performance on an embedded, I don't depend on
an os of unknown quality for the likes of the msp. I'll expect handling
on the box side of an app, not the msp.

BTW, I have never use recursive calls; not in going on 40 some years.
Create your own stack inside the call and you don't have to worry about
what the compiler does; you are in control. There is no good reason to
go recursive and create unneeded waste.

Best, Dan.

--
"If they can get you asking the wrong questions, they dont
have to worry about answers."

-- Thomas Pynchon

Yeah.
However it is really a problem that the stack space is not protected in the
MSP's (or almost any other controller). I also do not know a tool that
calculates maximal stack usage (this is possible in case recursion is not
used). It is something like "ok it is running - so stack space seem
sufficient" - some kind of hope based design ;-).

M.

Xiaohui Liu :

> Thank all for your help. It IS stack overflow. After I reduce my RAM
> usage by ~2 KB, it works like a charm.
>
> -Xiaohui Liu
>
> On Wed, Nov 14, 2012 at 4:48 AM, Jon Kirwan
> wrote:
>
>> **
>> On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:
>>
>> >Hi Xiaohui,
>> >
>> >a litte suggestion:.
>> >
>> >Xiaohui Liu :
>> >
>> >> 2) Watchdog timer security key violation.
>> >
>> >Probably stack overflow. Fill your RAM with a simple pattern (e.g.
>> >0xDeadBeef), put a breakpoint at reset (before the RAM is initialized
>> >by
>> the
>> >startupcode) and after the next break after reset take a look in the
>> >RAM space. If there is no 0xDeadBeef anymore you have a problem. :-)
>>
>> I suggested what amounts to that a few days ago, without
>> meaningful response yet. It's possible it's still a work in
>> progress.
>>
>> Jon
>>

Thank all for your help. It IS stack overflow. After I reduce my RAM usage
by ~2 KB, it works like a charm.

-Xiaohui Liu

On Wed, Nov 14, 2012 at 4:48 AM, Jon Kirwan wrote:

> **
> On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:
>
> >Hi Xiaohui,
> >
> >a litte suggestion:.
> >
> >Xiaohui Liu :
> >
> >> 2) Watchdog timer security key violation.
> >
> >Probably stack overflow. Fill your RAM with a simple pattern (e.g.
> >0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by
> the
> >startupcode) and after the next break after reset take a look in the RAM
> >space. If there is no 0xDeadBeef anymore you have a problem. :-)
>
> I suggested what amounts to that a few days ago, without
> meaningful response yet. It's possible it's still a work in
> progress.
>
> Jon
>
>
>

On Wed, 14 Nov 2012 08:17:33 +0000 (UTC), you wrote:

>Hi Xiaohui,
>
>a litte suggestion:.
>
>Xiaohui Liu :
>
>> 2) Watchdog timer security key violation.
>
>Probably stack overflow. Fill your RAM with a simple pattern (e.g.
>0xDeadBeef), put a breakpoint at reset (before the RAM is initialized by the
>startupcode) and after the next break after reset take a look in the RAM
>space. If there is no 0xDeadBeef anymore you have a problem. :-)

I suggested what amounts to that a few days ago, without
meaningful response yet. It's possible it's still a work in
progress.

Jon