[cdt-dev] Debugging embedded evironments using JTAG devices [long]

[Øyvind Harboe <oyvind.harboe@xxxxxxxxx>]

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