I recommend creating a stationery project with CodeWarrior EPPC New Project Wizard for your evaluation board/processor for an example of ISR implementation. You will find in the eppc_exception.asm file from this stationery project the following code, for example, for the system call exception:
##############################################################################
#
# 0x0C00 System Call
#
##############################################################################
.org 0xC00
isr_prologue
li r3,0x0C00
lis r4,InterruptHandler@h
ori r4,r4,InterruptHandler@l
mtlr r4
blrl
isr_epilogue
You cannot debug the isr_prologue and the isr_epilogue code as this code interferes with the registers used by the debugger. You can copy directly this isr_prologue and the isr_epilogue code from the stationery project and add your other code in the interrupt handler. The recommended approach is to set a hardware breakpoint for the ROM target of your project in your interrupt handler (InterruptHandler function from the interrupt.c in the stationery project) and debug from here.
The behavior that you noticed was because you tried to debug your isr_prologue or isr_epilogue code which should be not possible because of the register usage interfering between debugger and ISR code.
The eppc_exeception.asm is mapped in the elf file at a ROM location, but the exception vectors are relocated in RAM at 0x0000_0000 after the RAM memory initialization. If you set the breakpoints in the disassembly code (you can also use the View Memory window in a debug session for this) at the right addresses in RAM (starting with 0xC00 for example), they will be correctly hit both in isr_prologue and epilogue. This is an expected behavior because of the exception vectors relocation in RAM.
