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.
Best reagards!
My OpenOCD wiggler config:
-------------------
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface parport
parport_port 0x378
parport_cable old_amt_wiggler
jtag_speed 10
#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
#target configuration
daemon_startup reset
#target
#target arm7tdmi
target arm7tdmi little run_and_init 0 arm7tdmi-s_r4
run_and_halt_time 0 30
working_area 0 0x40000000 0x2000 nobackup
#flash configuration
flash bank lpc2000 0x0 0x40000 0 0 lpc2000_v1 0 14765 calc_checksum
#flash bank cfi 0x80000000 0x400000 2 2 0
---------------------------------
Stay in the know. Pulse on the new Yahoo.com. Check it out.
Some LPC2103 & OpenOCD questions
Started by ●September 22, 2006
Reply by ●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
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 ●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.
Regards,
Dominic
> > 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.
Regards,
Dominic
