some newbie questions

[Ed Sutter]

Take baby steps.
If init68360.c is the first C function called, then yea start
there; however, I'm guessing it's not.  Start by initializing
your unique variable to something unlikely to be there by
accident, then go from there.  When it hangs, display the variable
content. If it isn't what you expect, then it hung before your
trace.  If it is what you expected, then it hung after.  Sooner
or later you'll isolate the problem.
It's painful, but it works.
Ed

BTW...
This whole discussion assumes you don't have a BDM or JTAG
tool at your disposal.

sebastian ssmoller wrote:
> 
> this makes sense :) ok it's getting late for me so i will try ur approach
> tomorrow.
> 
> what do u guess is a good starting point for debugging ? i thought off
> init68360.c and then going further ?
> 
> thank u again
> regards,
> seb
> 
> On Wed, 18 Feb 2004 13:58:42 -0500
> Ed Sutter <els at emailbox.hdtv.lucent.com> wrote:
> 
> > Seb,
> > Well, beleive it or not, that makes sense.  Here's why...
> >
> > One thing to realize when using a monitor to debug that way...
> > The monitor is using facilities in the CPU that the RTOS wants
> > to control; hence, there is a conflict of interest here so
> > you need to be careful.  For example, I'm guessing that "VBR"
> > is VectorBaseRegister.  That instruction is changing the
> > base of the vector table, so any further single stepping by
> > the monitor will get hosed because the exception table just
> > moved (hence, the trace exception needed for single stepping
> > is lost).  It's better to try to use a simpler means of debugging
> > at this level of RTOS startup simply because the RTOS is likely
> > to use all of the facilities that the CPU has to offer, but
> > the monitor-based-debugger is also likely to want to use them
> > to be able to do the fancier, cpu-dependent debugging.
> > Ed
> >
> (...)