[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdt-dev] Debugging embedded evironments using JTAG devices [long]
|
I've seen some discussions on the CDT GDB interface, and
I thought I'd pitch in my 2 cents. I didn't know what
to put in and what to leave out, but here goes
anyway.
Short story:
CDT probably does everything I need. It just needs
to know where to do less.
Long story:
I have used Eclipse for a while now for Java projects and
I'd love to use it for the embedded end of our project as
well, but I'm having problems figuring out how to get the
CDT debugger interface up and running(I'd like to replace
Insight to get a smoother development cycle).
First I'll describe what I'm trying to debug and how this
works with Insight, then I'll describe a bit on what I've
tried with Eclipse.
- I have an evaluation board (Atmel AT91 EB40a) and I'm
using eCos to compile my applications(http://sources.redhat.com/ecos).
eCos is an embedded operating system, which comes with
a precompiled GNU toolchain. Very nice.
- I build an application with eCos which results in an
arm-elf image. This image I convert to binary format and
upload to the flash on the evaluation board. At this point,
I can run my application directly out of flash.
- I have a JTAG debugger(Wiggler). This is a device which
connects to the parallel port and attaches to the CPU. The
JTAG device is basically a way to talk to the CPU at a very low level.
- I have an application I run called OcdLibRemote. This
application listens on a TCP/IP port for GDB ("target remote
mymachine:8888")
commands and translates them to JTAG commands which are
transferred via the JTAG debugger.
To debug an app, I do the following with arm-elf-gdb and Insight:
- First I build my app.
- Then I write the binary image to flash using Redboot. The
image is written to a fixed address and is relocated before
the image written to flash. The application is not copied
to ram, but run directly from flash. My environment has
2MB flash and 256kb ram and runs at 66MHz(gives a rough idea
of the HW involved).
- I then launch arm-elf-gdb in windowed mode(i.e. Insight)
arm-elf-gdb -w
- Now I have to connect to my target and I execute from the GDB console
target remote mymachine:8888
- We are now connected to the evaulation board (which may be
running the app at this point). In order to debug sensibly,
we need sybmols. We do not load the app, only the symbols.
symbol-file myapp.elf
- At this point I can debug my app. However, since we are speaking
directly with the CPU via JTAG and our app is in flash, things are
quite different than when debugging e.g. a Windows/Linux app.
- No list of threads(eCos supports threads) or other OS resources.
I'm still
familiarizing myself with eCos and GDB, and it may be possible to
use eCos debugging support to enumerate threads, etc.
- I can talk directly to the hardware, e.g. execute a reset of the
CPU
("monitor reset"), etc.
- Setting breakpoints isn't straightforward. Since the flash can not
be
modified, the default method for setting breakpoints doesn't work.
I believe the ARM CPU has supports setting debug breakpoints in
flash, but I haven't gotten that far yet.
From Eclipse, I'd like to see a new debug/launch type(perhaps it exists,
and just needs to be better marketed). Same as C/C++ local, but:
- Remove "Main" tab. I see no need for the embedded scenario to
tie a debug session to a project. Leave symbol file loading and
application upload to the developer who will probably use a
combination of GDB scripts and proprietary flash programming tools.
- Remove "Arguments" tab. All of this is irrelevant (or handled by the
developer).
- I don't know what the "Environment" tab is for, so I can't
really comment. Presumably irrelevant for this embedded debug scenario.
- "Debugger" tab needs to change. CDT should not assume that
it is causing the application to be launched. The developer
will write a GDB script which loads or connects to the evaluation
board and loads symbols.
- I presume the "Source" tab is fine.
- I don't know what the "Common" tab is for.
- The "Debugger" tab will not have any entries in the drop down list,
unless you go
in and modify the plugin.xml. I don't understand whats involved here,
but I've seen discussions on this(which is where I learnt about it).
Other features:
- There should be a gdb console window as there is in Insight. This
will be used to execute commands that do not make sense to support
in the GUI since they are to specific to each environment, e.g.
"remote reset" to reset the board via JTAG. (I don't know much about
the CDT debug environment,
since I haven't worked much with it yet, so execuse me for repeating
if this feature is there already implemented).
- Configure what information that CDT has available, e.g. disable
threads.
Here is what I tried for Eclipse so far:
The closest thing to what I need I suppose is the
"Debugger" -> "GDB server", but "Attach to running process"
nor "Run program in debugger" is approperiate for my embedded
JTAG based development environment. eCos does not have
processes and the app is already running.
Øyvind