DPRG List  

[DPRG] Re: 68HC11 stack problem resolved

Subject: [DPRG] Re: 68HC11 stack problem resolved
From: Dan Miner miner at centtech.com
Date: Thu Jun 21 23:00:49 CDT 2001

> From: David P. Anderson [mailto:dpa at io.isem.smu.edu]
> Sent: Thursday, June 21, 2001 8:36 PM
> Howdy DPRG,
> Mike McCarty wrote:
> > I think nearly everyone has used that technique at some 
> > time. I usually use $DEADBABE to fill memory, though!
> That's hilarious!  What a hoot!!!!

We were just discussing this at lunch.  Other popular values
in a 32 bit processor world are:
  $DEADBEEF   (hamburger)
  $FEEDFACE   (what you do with the hamburger)
and for when the machine is really in trouble:
(and yes, a person could waste a lot of hours coming up 
 with others especially if you include
  zero = o
  one  = i
  two  = z
  five = s
 but please, let's not clog the list with a ton of these...)

But on an 8 bit machine, I still prefer $55.

> > It is more arduous though more reliable to trace through 
> > the code and see how deeply one can go.
> True.  Dan's comment about rare interrupt events, who's timing is hard
> to predict, especially for multiple nested interrupts, makes this
> especially tough.  "Worst case" scenarios might in fact never happen.

Yes.  Usually, I avoid nested interrupts like the plague so
this isn't an issue for me.  In my opinion, all interrupt 
service routines should be as short as reasonably possible
and only save time critical data that will be processed
further in the main loop.  And never allow nested interrupts.
The only exception should be a non-maskable interrupt can
interrupt a maskable interrupt service routine.

That way the manual analysis is easier - figure out the stack 
usage with the deepest nested subroutines then add an interrupt 
stack frame (or 2 if you use non-maskable interrupts).  Done.

However, in Clay's situation, he's using C and doesn't know
for sure how much stack the libraries use.  Thus my suggestion
of filling the stack with $55 and determining it emprically.

				- Dan Miner

More information about the DPRG mailing list