Reply by Dominic Rath●September 22, 20062006-09-22
On Friday 22 September 2006 13:12, Dominic Rath wrote: > > I am using the information at :
http://www.ixbat.de/index.php?page_id
> > as a starting point along with Jim Lynch's excellent tutorial. I
am
> > using svn rev98 of OpenOCD that I built on Cygwin.
> >
> > The Makefile for the blinker program is modified with -O0 (optimization
> > off) and I can program the LPC2103 flash using OpenOCD and the command
> > listed at the website (via telnet).
>
> Source-level-debugging the blinker program has often failed for me. GDB
> seems to have problems with the empty for-loops used for the delay.
To clarify myself: There's not a general problem with
source-level-debugging
empty for-loops, but a problem with stepping these lines - what worked for me
is placing a breakpoint after the delay loop, and using continue to step over
it.
Reply by Dominic Rath●September 22, 20062006-09-22
Hi,
On Friday 22 September 2006 10:46, Yahuh Blowz wrote: > Hi everyone,
>
> I'm just getting started with OpenOCD and an LPC2103 (Olimex dev board).
> I'm not new to ARMs or GCC but I am to OpenOCD + Eclipse. I have a
few
> questions related to OpenOCD and Eclipse, I hope someone will take the time
> to respond.
>
> 1. Is anyone able to debug their LPC2103 or 210x with OpenOCD + Wiggler?
> While I don't have a 2103 myself I'm confident it works -
people have
definitely used it for that purpose.
> I am using the information at :
http://www.ixbat.de/index.php?page_id as
> a starting point along with Jim Lynch's excellent tutorial. I am
using
> svn rev98 of OpenOCD that I built on Cygwin.
>
> The Makefile for the blinker program is modified with -O0 (optimization
> off) and I can program the LPC2103 flash using OpenOCD and the command
> listed at the website (via telnet).
> Source-level-debugging the blinker program has often failed for me. GDB
seems
to have problems with the empty for-loops used for the delay.
> When I try to debug my application, on step-over or
step-into I get:
>
> Warning: arm7_9_common.c:785 arm7_9_halt(): target was already halted
> Error: arm7_9_common.c:1771 arm7_9_read_memory(): memory read caused data
> abort Error: arm7_9_common.c:1771 arm7_9_read_memory(): memory read
> caused data abort Error: arm7_9_common.c:1771 arm7_9_read_memory():
> memory read caused data abort
> The data aborts are likely caused by GDB trying to trace the stack
frames,
which don't exist. Guess it should be possible to present GDB with a stack
that allows it to finish tracing, but I don't remember where I've seen
this.
Maybe some WinARM example.
> Each time I step, I get those error messages, and
then it dies (stops
> responding) on line 23 of main.c
>
> I then get the following error : "Cannot find bounds of current function"
> and debugging is stopped working and the LED no longer blinks.
> That might be related to the stackframes, too.
> I've tried everything I can think of, including
slowing down my Wiggler
> speed to "10".
> If the communication fails you'll get other errors.
> If you do have this setup working, will you e-mail me
your OpenOCD .cfg
> file?
>
> 2. Has anyone come up with a clever way of automating the programming of
> your LPC part using OpenOCD after a build, within Eclipse?
>
> I typically load OpenOCD right after loading Eclipse. So, I think using a
> program like "netcat" one could, after a "build", issue the commands to the
> OpenOCD daemon to flash program the part. Is there a better way?
It's
> obviously required that a code-change/compile means the part has to be
> re-programmed.
> Martin Thomas (the WinARM guy) did: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html
This page explains how he uses the OpenOCD with a init-script to flash and
terminate the OpenOCD afterwards. You should be able to call this from within
Eclipse.
> 3. Is there a clean way in Eclipse to re-build your
program and re-debug
> if you're already in the debug perspective?
Sorry, I don't use Eclipse for this stuff.
Regards,
Dominic
Reply by Yahuh Blowz●September 22, 20062006-09-22
Hi everyone,
I'm just getting started with OpenOCD and an LPC2103 (Olimex dev board).
I'm not new to ARMs or GCC but I am to OpenOCD + Eclipse. I have a few
questions related to OpenOCD and Eclipse, I hope someone will take the time to
respond.
1. Is anyone able to debug their LPC2103 or 210x with OpenOCD + Wiggler?
I am using the information at : http://www.ixbat.de/index.php?page_id as a
starting point along with Jim Lynch's excellent tutorial. I am using svn
rev98 of OpenOCD that I built on Cygwin.
The Makefile for the blinker program is modified with -O0 (optimization off) and
I can program the LPC2103 flash using OpenOCD and the command listed at the
website (via telnet).
When I try to debug my application, on step-over or step-into I get:
Warning: arm7_9_common.c:785 arm7_9_halt(): target was already halted
Error: arm7_9_common.c:1771 arm7_9_read_memory(): memory read caused data
abort
Error: arm7_9_common.c:1771 arm7_9_read_memory(): memory read caused data
abort
Error: arm7_9_common.c:1771 arm7_9_read_memory(): memory read caused data
abort
Each time I step, I get those error messages, and then it dies (stops
responding) on line 23 of main.c
I then get the following error : "Cannot find bounds of current function" and
debugging is stopped working and the LED no longer blinks.
I've tried everything I can think of, including slowing down my Wiggler
speed to "10".
If you do have this setup working, will you e-mail me your OpenOCD .cfg file?
2. Has anyone come up with a clever way of automating the programming of your
LPC part using OpenOCD after a build, within Eclipse?
I typically load OpenOCD right after loading Eclipse. So, I think using a
program like "netcat" one could, after a "build", issue the commands to the
OpenOCD daemon to flash program the part. Is there a better way? It's
obviously required that a code-change/compile means the part has to be
re-programmed.
3. Is there a clean way in Eclipse to re-build your program and re-debug if
you're already in the debug perspective?
Once I do a build, I switch to debug and arm-gdb connects with OpenOCD, etc,
etc. However, if I'm in the debug perspective and I issue a build clean or
whatever, it fails because the debug perspective is holding onto the .elf file.
This is annoying and requires me to quit the debug perspective each time I want
to do a build. I would think there is a cleaner solution -- I have to imagine
Eclipse isn't that stupid.
If there are any other hints or tricks/tips on using Eclipse/OpenOCD I welcome
them. I'd like to collect these and hopefully we can centralize this
information and/or add it to Jim's tutorial. I'm sure I'm not
the only one who has faced these issues.
#use combined on interfaces or targets that can't set TRST/SRST
separately
reset_config trst_and_srst trst_pulls_srst
#reset_config trst_and_srst srst_pulls_trst
#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe
