This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
ARM7 debugging
- To: ecos-discuss at sources dot redhat dot com
- Subject: [ECOS] ARM7 debugging
- From: Ilko Iliev <iliev at caretec dot at>
- Date: Mon, 15 Jan 2001 18:16:27 +0100
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