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