public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Ilko Iliev <iliev@caretec.at>
To: ecos-discuss@sources.redhat.com
Subject: [ECOS] ARM7 debugging
Date: Mon, 15 Jan 2001 09:17:00 -0000	[thread overview]
Message-ID: <4.3.2.7.2.20010115181356.00b8d078@mbox> (raw)

Hi all,

I try to find the right way to debug eCOS (ATEB01).
I have JTAG Wiggler from Macraigor and JEENI from EPI.
I use the gnu suite for Linux (RedHat 7.0) and Windows2000 (cygwin) - 
gcc2.95, Insight 5.0
I didn't find big difference between Linux and Windows version.


After some expirements with Wiggler and JEENI I found the next problems:


1. With JTAG Wiggler and software (Insight 5.0) from www.ocdemon.com
	- when I use windows interface: in the menu File/Target miss option for 
setting ocdemon. To
solve this problem I use gbd.ini with current settings. When I startting 
gdb I reveive the
unlogical message "Unable to Read Instructions at 0x2018060". When I select 
manual the debugging
file then it can be debugged (sometimes :-). When the user program have no 
breakpoints it can't be
stopped (the STOP button didn't work). The only way to restart the user 
program is to kill gdb
process and start it again.

2. With JEENI from EPI.
	- when I use no windows interface gdb connected to target:
gdb> target rdi e=192.168.1.100
A user program can be downloaded and executed.
	- when I use windows interface: in File/Target Settings I try each 
possibility with
ethernet interface, but I can't succeed. By the connection settings I have 
seen port option - no
where I can't find description of it. To solve the problem I use gdb.ini 
file with current
settings. The result was the same : "Unable to Read Instructions at 
0x2018060". When I select
manual the debugging file then it can be debugged. In the first 
cyg_thread_delay() from the
twothreads example it hang up - obviously the scheduler didn't work. The 
same exapmle work fine
with JTAG Wiggler.
	- same as the JTAG Wiggler it can't be halted (with windows interface). 
The only way to
restart the user program is to kill gdb process and start it again.


I don't know to much debuggers for embedded CPUs, but I can say that the 
SDS SingleStep for
ColdFire for example, is far far ahead in the right way in comparing with gdb.

Or I make something wrong with gdb?


best regards
Ilko Iliev

             reply	other threads:[~2001-01-15  9:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-15  9:17 Ilko Iliev [this message]
2001-01-15  9:30 ` Grant Edwards
2001-01-16  7:04   ` Ilko Iliev
2001-01-16  7:20     ` Grant Edwards

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4.3.2.7.2.20010115181356.00b8d078@mbox \
    --to=iliev@caretec.at \
    --cc=ecos-discuss@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).