KEIL versus IAR JTAG debugging...?

Dave;
The PKARM supports the Segger J-LINK. Also, Keil has several interrupt examples for the SAM7 eval board.
Why don't you contact Keil to see if the ARM eval toolset will support the J-LINK.
I have briefly used the U-LINK with the SAM7 board running the interrupt examples with no great difficulty.
A couple of suggestions:
Don't attempt to 'single step' in an isr routine. Use the 'run to cursor' step option instead.
Wrap your isr with an interrupt disable/enable while debugging the isr.

Dave;
Just hooked-up my Sam7 to U-LINK. Was able to run the examples with no problems. Had full control of the interrupt conditions on my target board. Of course had to Halt Run while I changed most conditions but that is normal for running on a target such as the Sam7 eval. With the Advanced Interrupt Controller dialog I had all the control required for debug.
Suggest that you download the ARM eval and run some of the board examples in the simulator. Open the peripherals dialog and check out the control you have over your debug environment either in the simulator or on a target board.

Thanks Al.

If I understand you correctly, you were able to set breakpoints in ISR's and the debugger would stop when they were triggered and you could step through ISR code, or 'run' the debugger again, all with no problems. Is that right?

Dave.

Dave;
Yes that is correct. But I do have to halt the run mode to enter a breakpoint on the target. Then I can create an interrupt via the dialog or via the programmed hardware switch.
I hit the breakpoint, stop and step through the ISR.
I believe this device supports only two hardware breakpoints. I will have to investigate additional software breakpoints later.

Thanks. The IAR tools only support two breakpoints when you're running the code from flash ROM. I usually run the code from RAM, which then supports an unlimited number of breakpoints. Do the KEIL tools make it easy to build/load the code into either ROM or RAM?

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.

Dave;
Keil tools makes it about as easy as ARM can get to remap to either RAM or ROM. Keil furnishes a number of startup files for remapping. These will autoload with your permission when you create a project.
Also, Keil has a number of examples of ram initialization. All you have to do is replace memory addresses with your target memory map. For the Samt7s64 eval board, all of this is furnished. Also, there is a startup wizard that allows you to modify existing startup via the wizard or via text entry.
Once again, I suggest that you download the ARM eval and look at the examples. The simulator is not just an instruction simulator. It simulates most of the device on chip peripherals. NO stinking macros to write just to look at port I/O or Interrupts or Timers, etc., etc.,etc.
The eval is fully functional with limited code size. I'm talking about the PKARM which has the CARM compiler. Not the GCC compiler which is also supported somewhat.

Thanks Al & Drew... I appreciate your comments.

I've used KEIL tools for a few years on other processors (C167 and 8051). There are a couple of other developers here who took a stab at using an earlier version of the KEIL tools with a U-Link debugger on a Philips ARM based eval board (and later with an LPC2114 board of our own design). They had dismal results, and were of the opinion that the KEIL debugger was unusable. I'm somewhat reluctant to concede that using a simulator will give the same results as real hardware.

I've got a couple U-Link and a couple J-Link debuggers along with a current version of the KEIL eval. Unfortunately, the KEIL eval will not allow you to use a JTAG debugger. Not sure why. The debugger is a critical part of the tool, and the eval isn't worth all that much to me without it.

It's very difficult for me to get my company to spend several thousand dollars just to do a tool eval. That's why I'm anxious to hear from other folks as to their results with these tools when debugging real code on real boards. So far, it looks like there are at least two folks who think the KEIL tools are okay to develop/debug ARM based projects. It's also encouraging to see that there haven't been any folks chiming in to rant that the tools are junk.

Unfortunately, the KEIL eval will not allow you to use a JTAG debugger. Not sure why. That's beacuse the usual crap about considering the IDE the holy grail. Most likely your JTAG debugger will work just fine if loaded separately even with Keil files. For instance in the '51 world you can use the SILabs JTAG debugger loaded as "the SILabs JTAG debugger" just fine.

It's very difficult for me to get my company to spend several thousand dollars just to do a tool eval. If you are "a reputable company" it should be possible to have a full Keil for a short while for eval. When I were in the market for 12 sets, they loaned me one.

Erik

CORRECTION: I have a pile of "USB to JTAG conversion boxes designed for ARM cores", not JTAG debuggers. The only ARM debugger I have is the one that came with the IAR/ATMEL eval kit. I was trying to use one of these conversion boxes with the KEIL eval to try out the KEIL debugger.

Even though we've purchased several products from KEIL over the years, when I inquiried about evaluating the ARM debugger the response was "you must buy it to try it... if you don't like it then we'll give you a full refund".

However, I'm not trying to buy a pile of licenses either. I'm just a lone developer on a one man team project.

Just a clearfication: ULINK allows full debugging even in an Eval version. The Eval version only has code size limits.

I do not know why it did not work for you.

Reinhard

Thank you Mr. Keil, and sorry for my mistake.

I had incorrectly assumed that the dialog box that popped up when I clicked on the start debug button meant that the debugger wasn't working.

Dialog box text:

uVision3
MISSING DEVICE (SECURITY KEY NOT FOUND)
Running in Eval Mode

The interrupt example worked as-is, right out of the box too. I was able to set a breakpoint in the timer ISR that toggled the state of an LED, and every time program flow broke there I could click the run button and the state of the LED would change... just like you'd expect it to.

Wonderful, just wonderful.

Dave.