Re: Debugging in exception handlers

David Wybo <[email protected]>
Newsgroups gmane.comp.hardware.motorola.microcontrollers
Organization RealTime Consultants, Inc.
Message-ID <[email protected]>
Unfortunately, debugging exception handler code is not that easy. there 
are several reasons why you may not hit the breakpoint at address 0xc00.

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.

With SingleStep, there was a way to tell it to flag any exceptions. 
Alternatively, you could tell it to ignore specific exceptions and let 
the code handle them. I think there is a more elegant way within 
SingleStep to tell it to ignore an exception, rather than modifying the 
DER register directly in the config file, but apparently your way works 
as well.

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. 
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.

For example, I have exception handlers written in C, which I can debug 
with SingleStep. However, I cannot set a breakpoint within the exception 
table directly, I need to wait until the exception frame is properly set 
up by the exception handler. Then just prior to it calling the C 
exception routine, I can successfully set a breakpoint.

Maybe others can enlighten us all as to what in particular needs to be 
set up for things to work, its just been a while since I debugged 
exception handlers and I do not remember the exact reason for why things 
behave this way.

Hope this helps.

prashanth_feb9 wrote:

>Hi All,
>      I am working on Phycore MPC565 board with single step debugger.
>In the configuration file of single step the DER register value was
>0x73e67c0f. Whenever an exception was generated the debugger used to
>display popup messages. To avoid the popup i have reset the bits in
>the DER register.
>
>As an example, I have reset the system call exception bit in DER to
>check that whenever the exception occurs it branches to the exception
>handler (Address 0xC00)
>
>But when I generate a system call exception using a sc instruction and
>apply a breakpoint at 0xC00 it does not stop at the breakpoint (This
>address is in the internal Flash).
>Please let me know why the breakpoint is not activated at 0xC00 and
>debug the exception handler code.
>
>Thanks and Regards,
>Prashanth
>
>
>
>
>
>
>
>
>-----------------------------------------------------------
>To learn more about Freescale Microcontrollers, please visit
>http://www.freescale.com/mcu
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

-- 
David Wybo                    mailto:[email protected]
RealTime Consultants, Inc.    Phone: 248.345.6160
www.realtimeconsultantsinc.com





------------------------ Yahoo! Groups Sponsor --------------------~--> 
Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life.
http://us.click.yahoo.com/A77XvD/vlQLAA/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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.