IDE hangs when I debug thru an intreuppt enabled code

[sanjucolumbus]

Im using Processor:MPC860,Board:Custom,Codewarrior IDE:Ver 8.6   

I stuck up with the below problem :-

 When debugging through codewarrior IDE with interrupts enabled. The moment I step through the interrupts enabling code in debug mode, the IDE either hangs or does not return to next line.

note: Im note step into my interrupt code

Thankz in advance for suggestion...

[Black]

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.