EmbeddedRelated.com
Forums

ARM GDB debugging.

Started by premjithav March 13, 2012
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?
3. I found results about gdb stubs for some non arm architecture. is there
any stub for arm without a external hardware or JTAG unit.
4. 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 http://www.EmbeddedRelated.com
On Tue, 13 Mar 2012 20:42:32 -0500, premjithav wrote:

> 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?
In theory, yes, if you wanted to write a debug monitor for the board that would talk to GDB.
> 2. All search results about the arm debugging are related with some > kind of external hardware and JTAG why?
Because it's cheap and easy.
> 3. I found results about gdb stubs for some non arm architecture. is > there any stub for arm without a external hardware or JTAG unit.
I don't know. Maybe, but you'd have to make that debug stub.
> 4. How we can debug an arm board with cost effective method.
JTAG. If you don't want to buy an Olimex debugger, buy a FTDI chip and whip one up yourself.
> 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.
There is trace support on every ARM chip made, through the JTAG debugger port. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
On 14/03/2012 01:42, premjithav wrote:
> 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? > 3. I found results about gdb stubs for some non arm architecture. is there > any stub for arm without a external hardware or JTAG unit. > 4. 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.
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. + http://www.FreeRTOS.org Designed for Microcontrollers. More than 7000 downloads per month.
On 2012-03-14, FreeRTOS info <noemail@given.com> wrote:
> On 14/03/2012 01:42, premjithav wrote: >> 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? >> 3. I found results about gdb stubs for some non arm architecture. is there >> any stub for arm without a external hardware or JTAG unit. >> 4. 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. > > 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. >
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.
> 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. >
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
On 2012-03-14, premjithav <premjithav@n_o_s_p_a_m.gmail.com> wrote:
> 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?
Yes.
> how?
Install a gdb stub on your board.
> 2. All search results about the arm debugging are related with some kind of > external hardware and JTAG why?
* Almost all ARM parts have JTAG interfaces. * JTAG interfaces are dirt cheap ($20 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.
> 3. I found results about gdb stubs for some non arm architecture. is > there any stub for arm without a external hardware or JTAG unit.
Yes.
> 4. How we can debug an arm board with cost effective method.
JTAG.
> 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.
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 gmail.com REAL GOOD!!
On 2012-03-14, Tim Wescott <tim@seemywebsite.please> wrote:
> On Tue, 13 Mar 2012 20:42:32 -0500, premjithav wrote: > >> 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? > > In theory, yes, if you wanted to write a debug monitor for the board that > would talk to GDB. > >> 2. All search results about the arm debugging are related with some >> kind of external hardware and JTAG why? > > Because it's cheap and easy. > >> 3. I found results about gdb stubs for some non arm architecture. is >> there any stub for arm without a external hardware or JTAG unit. > > I don't know. Maybe, but you'd have to make that debug stub. > >> 4. How we can debug an arm board with cost effective method. > > JTAG. If you don't want to buy an Olimex debugger, buy a FTDI chip and > whip one up yourself. > >> 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. > > There is trace support on every ARM chip made, through the JTAG > debugger 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. -- Grant Edwards grant.b.edwards Yow! OVER the underpass! at UNDER the overpass! gmail.com Around the FUTURE and BEYOND REPAIR!!
On 2012-03-14, FreeRTOS info <noemail@given.com> wrote:

> 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.
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 gmail.com
On Wed, 14 Mar 2012 14:03:32 +0000, Grant Edwards wrote:

> On 2012-03-14, Tim Wescott <tim@seemywebsite.please> wrote: >> On Tue, 13 Mar 2012 20:42:32 -0500, premjithav wrote: >> >>> 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? >> >> In theory, yes, if you wanted to write a debug monitor for the board >> that would talk to GDB. >> >>> 2. All search results about the arm debugging are related with some >>> kind of external hardware and JTAG why? >> >> Because it's cheap and easy. >> >>> 3. I found results about gdb stubs for some non arm architecture. is >>> there any stub for arm without a external hardware or JTAG unit. >> >> I don't know. Maybe, but you'd have to make that debug stub. >> >>> 4. How we can debug an arm board with cost effective method. >> >> JTAG. If you don't want to buy an Olimex debugger, buy a FTDI chip and >> whip one up yourself. >> >>> 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. >> >> There is trace support on every ARM chip made, through the JTAG >> debugger 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.
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. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
On Wed, 14 Mar 2012 14:03:32 +0000, Grant Edwards wrote:

> On 2012-03-14, Tim Wescott <tim@seemywebsite.please> wrote:
>> There is trace support on every ARM chip made, through the JTAG >> debugger 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.
Am I mistaken in believing that the D in TDMI implies trace support?
On 14/03/2012 15:24, Grant Edwards wrote:
> On 2012-03-14, FreeRTOS info<noemail@given.com> wrote: > >> 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. > > 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. >
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.