Hi all,
Is there any way to detect a Stack Overflow while debuggin with
codewarrior 3.1 on a HCS12 DP256?
(other than expending a lot of time searching where some of your RAM
variables have been overwritten)
thanks
How to detect Stack Overflow
Started by ●July 6, 2006
Reply by ●July 7, 20062006-07-07
Hallo,
you can fill the stackrange in your memory with a pattern like 0xaa55 before
you run your program.
After you run your program for a defined time, you can look at the RAM and
you will see if there is a a stackoverflow.
hope this helps
--
Patrick Gempeler
ProEda AG Datenmanagement
Bollstr. 32, CH-3076 Worb
Tel +41 31 838 45 00, Fax +41 31 838 45 40
----- Original Message -----
From: "apedroso11"
Newsgroups: gmane.comp.hardware.microcontrollers.hc12
Sent: Thursday, July 06, 2006 9:28 AM
Subject: How to detect Stack Overflow
> Hi all,
>
> Is there any way to detect a Stack Overflow while debuggin with
> codewarrior 3.1 on a HCS12 DP256?
>
> (other than expending a lot of time searching where some of your RAM
> variables have been overwritten)
>
> thanks
>
you can fill the stackrange in your memory with a pattern like 0xaa55 before
you run your program.
After you run your program for a defined time, you can look at the RAM and
you will see if there is a a stackoverflow.
hope this helps
--
Patrick Gempeler
ProEda AG Datenmanagement
Bollstr. 32, CH-3076 Worb
Tel +41 31 838 45 00, Fax +41 31 838 45 40
----- Original Message -----
From: "apedroso11"
Newsgroups: gmane.comp.hardware.microcontrollers.hc12
Sent: Thursday, July 06, 2006 9:28 AM
Subject: How to detect Stack Overflow
> Hi all,
>
> Is there any way to detect a Stack Overflow while debuggin with
> codewarrior 3.1 on a HCS12 DP256?
>
> (other than expending a lot of time searching where some of your RAM
> variables have been overwritten)
>
> thanks
>
Reply by ●July 7, 20062006-07-07
Another method would be to use a spare timer interrupt vector running at a
higher rate than any other timers for debug that will peek at the stack
pointer and report it.
_____
From: 6... [mailto:6...] On Behalf Of
Patrick Gempeler
Sent: Friday, July 07, 2006 12:44 AM
To: 6...
Subject: [68HC12] Re: How to detect Stack Overflow
Hallo,
you can fill the stackrange in your memory with a pattern like 0xaa55 before
you run your program.
After you run your program for a defined time, you can look at the RAM and
you will see if there is a a stackoverflow.
hope this helps
--
Patrick Gempeler
proeda.ch>
ProEda AG Datenmanagement ch/>
Bollstr. 32, CH-3076 Worb
Tel +41 31 838 45 00, Fax +41 31 838 45 40
----- Original Message -----
From: "apedroso11" com>
Newsgroups: gmane.comp.hardware.microcontrollers.hc12
Sent: Thursday, July 06, 2006 9:28 AM
Subject: How to detect Stack Overflow
> Hi all,
>
> Is there any way to detect a Stack Overflow while debuggin with
> codewarrior 3.1 on a HCS12 DP256?
>
> (other than expending a lot of time searching where some of your RAM
> variables have been overwritten)
>
> thanks
>
higher rate than any other timers for debug that will peek at the stack
pointer and report it.
_____
From: 6... [mailto:6...] On Behalf Of
Patrick Gempeler
Sent: Friday, July 07, 2006 12:44 AM
To: 6...
Subject: [68HC12] Re: How to detect Stack Overflow
Hallo,
you can fill the stackrange in your memory with a pattern like 0xaa55 before
you run your program.
After you run your program for a defined time, you can look at the RAM and
you will see if there is a a stackoverflow.
hope this helps
--
Patrick Gempeler
proeda.ch>
ProEda AG Datenmanagement ch/>
Bollstr. 32, CH-3076 Worb
Tel +41 31 838 45 00, Fax +41 31 838 45 40
----- Original Message -----
From: "apedroso11" com>
Newsgroups: gmane.comp.hardware.microcontrollers.hc12
Sent: Thursday, July 06, 2006 9:28 AM
Subject: How to detect Stack Overflow
> Hi all,
>
> Is there any way to detect a Stack Overflow while debuggin with
> codewarrior 3.1 on a HCS12 DP256?
>
> (other than expending a lot of time searching where some of your RAM
> variables have been overwritten)
>
> thanks
>
Reply by ●July 7, 20062006-07-07
Another method would be to use a spare timer interrupt vector running at a
higher rate than any other timers for debug that will peek at the stack
pointer and report it.
_____
From: 6... [mailto:6...] On Behalf Of
Patrick Gempeler
Sent: Friday, July 07, 2006 12:44 AM
To: 6...
Subject: [68HC12] Re: How to detect Stack Overflow
Hallo,
you can fill the stackrange in your memory with a pattern like 0xaa55 before
you run your program.
After you run your program for a defined time, you can look at the RAM and
you will see if there is a a stackoverflow.
hope this helps
--
Patrick Gempeler
proeda.ch>
ProEda AG Datenmanagement ch/>
Bollstr. 32, CH-3076 Worb
Tel +41 31 838 45 00, Fax +41 31 838 45 40
----- Original Message -----
From: "apedroso11" com>
Newsgroups: gmane.comp.hardware.microcontrollers.hc12
Sent: Thursday, July 06, 2006 9:28 AM
Subject: How to detect Stack Overflow
> Hi all,
>
> Is there any way to detect a Stack Overflow while debuggin with
> codewarrior 3.1 on a HCS12 DP256?
>
> (other than expending a lot of time searching where some of your RAM
> variables have been overwritten)
>
> thanks
>
higher rate than any other timers for debug that will peek at the stack
pointer and report it.
_____
From: 6... [mailto:6...] On Behalf Of
Patrick Gempeler
Sent: Friday, July 07, 2006 12:44 AM
To: 6...
Subject: [68HC12] Re: How to detect Stack Overflow
Hallo,
you can fill the stackrange in your memory with a pattern like 0xaa55 before
you run your program.
After you run your program for a defined time, you can look at the RAM and
you will see if there is a a stackoverflow.
hope this helps
--
Patrick Gempeler
proeda.ch>
ProEda AG Datenmanagement ch/>
Bollstr. 32, CH-3076 Worb
Tel +41 31 838 45 00, Fax +41 31 838 45 40
----- Original Message -----
From: "apedroso11" com>
Newsgroups: gmane.comp.hardware.microcontrollers.hc12
Sent: Thursday, July 06, 2006 9:28 AM
Subject: How to detect Stack Overflow
> Hi all,
>
> Is there any way to detect a Stack Overflow while debuggin with
> codewarrior 3.1 on a HCS12 DP256?
>
> (other than expending a lot of time searching where some of your RAM
> variables have been overwritten)
>
> thanks
>
Reply by ●July 7, 20062006-07-07
At 01:28 AM 7/6/2006, you wrote:
>(other than expending a lot of time searching where some of your RAM
>variables have been overwritten)
Oh, you're so close.
You can arrange to put a flag value in the next location below the
stack. Set the flag to a particular value that is unlikely to happen
in your program (probably 0 and 0xff are not good values). When the
stack overflows, the flag value will change value.
In your mainline, check to see that the flag has the proper value, if
not halt the system.
The larger this flag is, the less likely it is that the stack
overflowed value will match the flag. On an 8 bit value you have a 1
in 256 chance of having an undetected stack overflow. With 16 bits,
it would be 1 in 65536...
Another way is to set the stack to a certain value (like DEAD BEEF or
FEED C0DE), run the system through its paces and do a post-mortem to
see what the high water mark was. Hopefully you find the way to
generate the longest call chain during your run.
The final way it to completely understand your program and map out
the call sequences to find the longest call chain in the system with
the most parameters and local variables. This will determine what
size of stack you need.
If your question is actually "Help, I'm smashing the stack and I
can't figure out why!", look for subroutines that have some big local
variables that are not declared static. When the subroutine is
called, these "automatic" variables are allocated on the stack.
A transmission buffer of 512 bytes will do nasty things to a 256 byte
stack when it is allocated.
Andrei
------------------------------
Andrei Chichak
Systems Developer
CBF Systems
#3054, 8308-114 Street
Edmonton, Alberta
Canada T6G 2E1
V: (780) 628-2072
F: (780) 628-5542
>(other than expending a lot of time searching where some of your RAM
>variables have been overwritten)
Oh, you're so close.
You can arrange to put a flag value in the next location below the
stack. Set the flag to a particular value that is unlikely to happen
in your program (probably 0 and 0xff are not good values). When the
stack overflows, the flag value will change value.
In your mainline, check to see that the flag has the proper value, if
not halt the system.
The larger this flag is, the less likely it is that the stack
overflowed value will match the flag. On an 8 bit value you have a 1
in 256 chance of having an undetected stack overflow. With 16 bits,
it would be 1 in 65536...
Another way is to set the stack to a certain value (like DEAD BEEF or
FEED C0DE), run the system through its paces and do a post-mortem to
see what the high water mark was. Hopefully you find the way to
generate the longest call chain during your run.
The final way it to completely understand your program and map out
the call sequences to find the longest call chain in the system with
the most parameters and local variables. This will determine what
size of stack you need.
If your question is actually "Help, I'm smashing the stack and I
can't figure out why!", look for subroutines that have some big local
variables that are not declared static. When the subroutine is
called, these "automatic" variables are allocated on the stack.
A transmission buffer of 512 bytes will do nasty things to a 256 byte
stack when it is allocated.
Andrei
------------------------------
Andrei Chichak
Systems Developer
CBF Systems
#3054, 8308-114 Street
Edmonton, Alberta
Canada T6G 2E1
V: (780) 628-2072
F: (780) 628-5542
Reply by ●July 10, 20062006-07-10
On Fri, Jul 07, 2006 at 01:19:28PM -0600, Andrei Chichak wrote:
> The final way it to completely understand your program and map out
> the call sequences to find the longest call chain in the system with
> the most parameters and local variables.
At least one HC12 compiler (Cosmic C) does this automatically. If you
have the linker generate a .map file, you'll find a table of functions
and stack space used by those functions. One column of the table gives
the cumulative space used by that function and all functions it calls.
If your program has no recursion, looking at main()'s cumulative stack
space will tell you the total stack needed by the program. You'll have
to add interrupt handlers' needs to that number, but you can look up
their stack requirements in the same table. Recursive functions make
things more complicated, of course. :-/
If you use another compiler, take a look in the docs to see if you can
get this kind of data. It's worth the time to find it.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
s...@po.cwru.edu
> The final way it to completely understand your program and map out
> the call sequences to find the longest call chain in the system with
> the most parameters and local variables.
At least one HC12 compiler (Cosmic C) does this automatically. If you
have the linker generate a .map file, you'll find a table of functions
and stack space used by those functions. One column of the table gives
the cumulative space used by that function and all functions it calls.
If your program has no recursion, looking at main()'s cumulative stack
space will tell you the total stack needed by the program. You'll have
to add interrupt handlers' needs to that number, but you can look up
their stack requirements in the same table. Recursive functions make
things more complicated, of course. :-/
If you use another compiler, take a look in the docs to see if you can
get this kind of data. It's worth the time to find it.
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
s...@po.cwru.edu
Reply by ●July 17, 20062006-07-17
Stephen Trier wrote:
> On Fri, Jul 07, 2006 at 01:19:28PM -0600, Andrei Chichak wrote:
> > The final way it to completely understand your program and map out
> > the call sequences to find the longest call chain in the system with
> > the most parameters and local variables.
>
> At least one HC12 compiler (Cosmic C) does this automatically. If you
> have the linker generate a .map file, you'll find a table of functions
> and stack space used by those functions. One column of the table gives
> the cumulative space used by that function and all functions it calls.
> If your program has no recursion, looking at main()'s cumulative stack
> space will tell you the total stack needed by the program. You'll have
> to add interrupt handlers' needs to that number, but you can look up
> their stack requirements in the same table. Recursive functions make
> things more complicated, of course. :-/
>
> If you use another compiler, take a look in the docs to see if you can
> get this kind of data. It's worth the time to find it.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> s...@po.cwru.edu __
> .
That is the most important thing about a compiler clear helpful map
file, and robust compiler. Cosmic beat Metrowerks when I was buy hands
down in both aspects.
Andrew Lohmann AMIIE
Design Engineer
PLEASE NOTE NEW EMAIL ADDRESS IS:
a...@bellinghamandstanley.co.uk
Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com
> _,_._,___
-----------------------------Disclaimer-----------------------------
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail.
-----------------------------Disclaimer-----------------------------
> On Fri, Jul 07, 2006 at 01:19:28PM -0600, Andrei Chichak wrote:
> > The final way it to completely understand your program and map out
> > the call sequences to find the longest call chain in the system with
> > the most parameters and local variables.
>
> At least one HC12 compiler (Cosmic C) does this automatically. If you
> have the linker generate a .map file, you'll find a table of functions
> and stack space used by those functions. One column of the table gives
> the cumulative space used by that function and all functions it calls.
> If your program has no recursion, looking at main()'s cumulative stack
> space will tell you the total stack needed by the program. You'll have
> to add interrupt handlers' needs to that number, but you can look up
> their stack requirements in the same table. Recursive functions make
> things more complicated, of course. :-/
>
> If you use another compiler, take a look in the docs to see if you can
> get this kind of data. It's worth the time to find it.
>
> Stephen
>
> --
> Stephen Trier
> Technical Development Lab
> Cleveland FES Center
> s...@po.cwru.edu __
> .
That is the most important thing about a compiler clear helpful map
file, and robust compiler. Cosmic beat Metrowerks when I was buy hands
down in both aspects.
Andrew Lohmann AMIIE
Design Engineer
PLEASE NOTE NEW EMAIL ADDRESS IS:
a...@bellinghamandstanley.co.uk
Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com
> _,_._,___
-----------------------------Disclaimer-----------------------------
This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer. We accept no liability for any loss or damage suffered by any person arising from use of this e-mail.
-----------------------------Disclaimer-----------------------------
