RE: Debugging in exception handlers

> Mot importantly, if you are executing our of RAM, the debugger uses an
> illegal instruction when setting a breakpoint. The debugger expects an
> exception to be hit. Once hit, it will check to see which address the
> illegal instruction occurred at, and if it is in its table of
> breakpoints, the real instruction will be put back, and the debugger
> will break. I think most debuggers deal with breakpoints our of RAM this
> way.

At least some versions of SingleStep offer an option to change this default
behavior.  Look for an option to set a "hardware instruction" breakpoint
instead of a "software instruction" breakpoint.  However, I don't believe
that's the problem here.

> Unfortunately, since you have already generated an exception, the state
> of the machine has changed and the illegal instruction that you then hit
> (which is really the breakpoint you set) is not seen by SingleStep. I
> cannot remember the specific issue that keeps SingleStep from seeing it.

There is a bit in the MSR to indicate whether an exception would be
recoverable or not.  Called the RI bit, it's cleared by each exception, and
breakpoints will normally not happen unless it has been set again by the
exception prologue code (normally after saving enough of the machine state
to recover it later).  This is required since breakpoints are also
exceptions, and hence also overwrite the contents of SRR0 and SRR1.

> However, I do know that if you let the exception handler set up its
> stack frame and its exception state, you can set a breakpoint after
> that, within the exception handler, and things will work as expected.

That is, assuming that the exception handler prologue sets RI.  If you've
rolled your own, it may not.  You can use either an EIE (enable interrupts)
or EID (disable interrupts) instruction to set RI.  Then set your breakpoint
after that instruction, and it should work.  However, if you want to see the
contents of SRR0 and SRR1 when the exception occurred, you'll have to look
at the values saved to RAM by the exception prologue code.  The actual
register contents are lost when the breakpoint exception occurs.

There is a bit in the debug control registers that changes the default
behavior and allows breakpoints when RI is cleared, but I don't think
SingleStep offers an option to set it.

HTH
Randall



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/dN_tlB/TM
--------------------------------------------------------------------~-> 

-----------------------------------------------------------
To learn more about Freescale Microcontrollers, please visit
http://www.freescale.com/mcu


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/MPC500/

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/