ARM GDB debugging.

i'm a newbie in Embedded world.

I need some clarification about the arm gdb debugging.

  1. Is there any options to debug the board through serial port ? how?
  2. All search results about the arm debugging are related with some kind of external hardware and JTAG why?

  1. I found results about gdb stubs for some non arm architecture. is there any stub for arm without a external hardware or JTAG unit.

  2. How we can debug an arm board with cost effective method.
5.If there is no trace port support in the board , how we can debug? is there any other options , thru serial port or ethernet.

Thank you Premjith

--------------------------------------- Posted through

formatting link

Reply to
premjithav
Loading thread data ...

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.

--
Tim Wescott
Control system and signal processing consulting
 Click to see the full signature
Reply to
Tim Wescott

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.
Reply to
FreeRTOS info

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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

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.

--
Grant Edwards               grant.b.edwards        Yow! Was my SOY LOAF left
                                  at               out in th'RAIN?  It tastes
 Click to see the full signature
Reply to
Grant Edwards

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.

--
Grant Edwards               grant.b.edwards        Yow! OVER the underpass!
                                  at               UNDER the overpass!
 Click to see the full signature
Reply to
Grant Edwards

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.

--
Grant Edwards               grant.b.edwards        Yow! I demand IMPUNITY!
                                  at               
 Click to see the full signature
Reply to
Grant Edwards

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.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
Przemek Klosowski

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.

Reply to
David Brown

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).

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
 Click to see the full signature
Reply to
Boudewijn Dijkstra

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

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

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

--
Grant Edwards               grant.b.edwards        Yow! I'm not an Iranian!!
                                  at               I voted for Dianne
 Click to see the full signature
Reply to
Grant Edwards

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.

--
Grant Edwards               grant.b.edwards        Yow! I feel like a wet
                                  at               parking meter on Darvon!
 Click to see the full signature
Reply to
Grant Edwards

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.