ARM GDB debugging.

In theory, yes, if you wanted to write a debug monitor for the board that would talk to GDB.

Because it's cheap and easy.

I don't know. Maybe, but you'd have to make that debug stub.

JTAG. If you don't want to buy an Olimex debugger, buy a FTDI chip and whip one up yourself.

There is trace support on every ARM chip made, through the JTAG debugger port.

Most ARM development tools come with their own, or a range of, debugging options. Most development boards, and prototype hardware, will have a hardware debugging interface. If you post which chip, which development board, and which compiler/toolchain you are using - or read the literature that came with such, you will get a better answer.

It is very rare, unless you work for a tools company, that you would ever actually see the GDB interface, as it will be (effectively) abstracted away by a higher level interface.

Regards, Richard.

• formatting link
  Designed for Microcontrollers. More than 7000 downloads per month.

I fully agree with this. We need to know exactly what the OP's environment is before we can help further, and in particular we need to understand why the OP doesn't consider JTAG to be cost effective.

Speaking as a hobbyist, and hence very cost sensitive, I have found the cost of the low end JTAG hardware to be just fine for me so far when working with the Olimex boards.

Actually I do use the gdb interface itself on a regular basis both on native code and cross compiled embedded ARM projects.

I use the ddd frontend to gdb. This gives me the ability to do all the usual breakpoint and other stuff using a GUI, but I also can (and do) drop into GDB itself to issue custom commands as required.

Simon.

Yes.

Install a gdb stub on your board.

• Almost all ARM parts have JTAG interfaces.
• JTAG interfaces are dirt cheap ( and up).
• JTAG doesn't require any software be installed on the board (nor any working memory for that matter), and can be used to not only debug software but also to troubleshoot and bring up new boards.

Yes.

JTAG.

Trace and debug are two different things. You can debug via JTAG even without a trace port.

Not true. In the past, trace support was pretty rare on low-end parts. Very few ARM7 parts had trace support -- they only had JTAG. Even on the earlier ARM9 parts, many didn't have trace support.

Trace support is becoming much more common, and most recent ARM9 and Cortex parts have both JTAG and trace ports.

By "see the GDB interface" do you mean look at remote protocol packets? Or are you saying nobody uses the GDB command line?

If you mean almost nobody messes with the remote protocol packets directly, that's probably true. But, I think there are still plenty of people that use the gdb command mode.

OK, I guess I was oversimplifying.

Mostly I was trying to impress on the OP that JTAG debugging _is_ the reasonable way to go, assuming that you have a part that has JTAG debugging built in. Certainly if it's a Cortex M3 part, it's a no- brainer.

Am I mistaken in believing that the D in TDMI implies trace support?

I like the gdb command line, and use it for several processors. Like all command lines, it takes a bit longer to learn to use than a nice gui, but for some uses it is much faster. In particular, it is good for writing macros for repetitive tasks, or for when you need relatively little interaction. I often have a "make run" makefile target that uses command-line gdb to set up the microcontroller/processor, download the code, and start it running.

Another trick I've used a lot is to have some volatile variables declared in the program. A gdb script downloads the code, then puts in some breakpoints at specific places. The target code runs and stops at the breakpoint, then the debugger script changes the volatiles and re-starts the code. With some synchronisation between the gdb scripts and the code, and a little imagination, you can make automated test procedures, flash programmers, etc.

Yes. Most commercially available ARMv4T ARM7 MCU's were and are ARM7TDMI-S where TDMI = Thumb+Debug+Multiplier+ICE.

Apparently 'D' means it has a JTAG TAP-controller with debug extensions (halt command, etc.)

Apparently 'I' means the ICEBreaker or EmbeddedICE macrocell which implements watchpoints and a communications channel.

In ARM7/9, tracing is typically implemented by an ETM (embedded trace marcocell).

And the -S suffix indicates that the core IP is Synthesizable (customizable by the mfgr) vice delivered as a netlist "black box."

The D stands for "Debug extensions", I'm not sure exactly what that implies, but plenty of TDMI parts didn't have trace support.

I too use gdb macros extensively. I can't believe that would willing people sit there and click dozens of buttons and menus and whatnot over and over again instead of typing a single command. I guess that's what happens to you if you were raised on "Windows" -- you just don't know there's a better way.

I've written entire board test and programming systems using a small shell script and a handful of gdb macros. I hate to imagine somebody sitting there at a bench doing all that clicking in a GUI.