KEIL versus IAR JTAG debugging...?

I'm currently evaulating the the IAR tools that came with ATMEL's AT91SAM7S-EK eval kit(which uses the AT91SAM7S64). The IAR tools (using a Segger J-Link tool) don't appear to be able to debug ISR's very well, if at all.

Before I go through all the hoops to get several $1000 to spend on evaulating the JTAG debugger enabled version of the KEIL tools, I was wondering if anyone out there who's using them would mind commenting on how well they work when debugging ISR's.

Parents
  • It's typical for ARM JTAG debuggers to support only two hardware breakpoints. This number is a limitation of the ARM implementation at hand, not the debugger itself. You're at the mercy of the chip designer including extra logic to support software debugging. (The JTAG interface itself is essentially just a fast serial port that lets the debugger read and write the processor registers and some associated logic.)

    I've even used an ARM processor that only implemented one hardware breakpoint. I've never had the luxury of using a core that included the trace module.

    You really want two hardware breakpoints for debugging ISRs. The first breakpoint gets used to stop at the desired point in the code. The next you need to single-step. You can live with just one if you always remember to delete your "stop here" breakpoint before clicking "step", but that's frustrating in practice.

    Software breakpoints are usually implemented by replacing an instruction with a software interrupt or trap instruction of some kind. So, you can have an unlimited number of them, but you also have to have the ability to overwrite the executing code -- that is, run out of RAM.

Reply
  • It's typical for ARM JTAG debuggers to support only two hardware breakpoints. This number is a limitation of the ARM implementation at hand, not the debugger itself. You're at the mercy of the chip designer including extra logic to support software debugging. (The JTAG interface itself is essentially just a fast serial port that lets the debugger read and write the processor registers and some associated logic.)

    I've even used an ARM processor that only implemented one hardware breakpoint. I've never had the luxury of using a core that included the trace module.

    You really want two hardware breakpoints for debugging ISRs. The first breakpoint gets used to stop at the desired point in the code. The next you need to single-step. You can live with just one if you always remember to delete your "stop here" breakpoint before clicking "step", but that's frustrating in practice.

    Software breakpoints are usually implemented by replacing an instruction with a software interrupt or trap instruction of some kind. So, you can have an unlimited number of them, but you also have to have the ability to overwrite the executing code -- that is, run out of RAM.

Children
More questions in this forum