Forums

Re: Olimex LPC-E2468 JTAG Debug: Update

Started by michael brown November 12, 2008
Bruce Paterson wrote:
> Hmmm
>
> All is still not fine with ARM-USB-OCD. For some reason I can't get it
> to breakpoint on main reliably. I usually set a temporary breakpoint
> there as part of the startup of gdb, but if I do this, it never gets
> there. If I just let it halt at random when gdb starts, then I can
> put a breakpoint on main and it can get there OK.
> Is there an openocd guru who can tell me what I should do here
> instead ?
>
> Here is my gdb startup:
>
> target remote localhost:3333
> monitor soft_reset_halt
> monitor arm7_9 force_hw_bkpts enable
> symbol-file bin/track.elf
> thbreak main <- Have to remove this line and continue to get it to
> work with ARM-USB-OCD.
> continue

I'm not saying it's right, but this is what I use:
target remote localhost:3333
monitor reset
monitor sleep 500
monitor poll
monitor soft_reset_halt
monitor arm7_9 sw_bkpts enable
monitor mww 0xE01FC040 0x0002
monitor mdw 0xE01FC040
break main
break Reset_Handler
load
continue

An Engineer's Guide to the LPC2100 Series

OK.
Some steps forwards and then backwards !
I now get openocd to reliably see the uP JTAG. The fault beforehand was
the code somehow turning off JTAG when it crashed.

Now, I cannot get reliable HALT after reset from openocd. Gdb is not
even involved at this stage.
I have tried all sorts of combinations of start-up delays, CPU clocks
and openocd script file changes, and cannot get it working.
Behaviour is now the same with ARM-USB-OCD and JTAGKey. The code is
running, because it flashes a LED (at the expected speed). When openocd
is started, you can see the reset occur, because the :ED flashing ceases
for a moment, but then it cariess on Flashing and openocd eventually
reports it cannot halt-after-reset.

Is there something about the LPC2468 that isn't the same as the LPC2148
I'm missing ? (besides the bootloader using the PLL, but I can't see why
that would matter for this problem).

Here is my openocd script file:

#daemon configuration
telnet_port 4444
gdb_port 3333

# tell gdb our flash memory map
# and enable flash programming
gdb_memory_map enable
gdb_flash_program enable

#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003
jtag_speed 3

#use combined on interfaces or targets that can't set TRST/SRST
separately
reset_config trst_and_srst srst_pulls_trst

#LPCs need reset pulled while RTCK is low. 0 to activate JTAG, power-on
reset is not enough
#jtag_reset 1 1 <---- If I don't comment out these 2 lines openocd can
never connect with JTAG at all.
#jtag_reset 0 0

#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_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30

working_area 0 0x40000000 0x4000 nobackup

#flash bank lpc2000 0 0
flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum

# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger

Cheers,
Bruce
-----Original Message-----
From: l... [mailto:l...] On Behalf
Of michael brown
Sent: Thursday, 13 November 2008 12:23 AM
To: l...
Subject: Re: [lpc2000] Olimex LPC-E2468 JTAG Debug: Update

Bruce Paterson wrote:
> Hmmm
>
> All is still not fine with ARM-USB-OCD. For some reason I can't get it
> to breakpoint on main reliably. I usually set a temporary breakpoint
> there as part of the startup of gdb, but if I do this, it never gets
> there. If I just let it halt at random when gdb starts, then I can
> put a breakpoint on main and it can get there OK.
> Is there an openocd guru who can tell me what I should do here
> instead ?
>
> Here is my gdb startup:
>
> target remote localhost:3333
> monitor soft_reset_halt
> monitor arm7_9 force_hw_bkpts enable
> symbol-file bin/track.elf
> thbreak main <- Have to remove this line and continue to get it to
> work with ARM-USB-OCD.
> continue

I'm not saying it's right, but this is what I use:
target remote localhost:3333
monitor reset
monitor sleep 500
monitor poll
monitor soft_reset_halt
monitor arm7_9 sw_bkpts enable
monitor mww 0xE01FC040 0x0002
monitor mdw 0xE01FC040
break main
break Reset_Handler
load
continue

funky things such as stepping back and forwards
while debugging is usually a sign of trying to debug
optimized code.

--Ray

Bruce Paterson wrote:
>
> OK.
> Some steps forwards and then backwards !
> I now get openocd to reliably see the uP JTAG. The fault beforehand was
> the code somehow turning off JTAG when it crashed.
>
> Now, I cannot get reliable HALT after reset from openocd. Gdb is not
> even involved at this stage.
> I have tried all sorts of combinations of start-up delays, CPU clocks
> and openocd script file changes, and cannot get it working.
> Behaviour is now the same with ARM-USB-OCD and JTAGKey. The code is
> running, because it flashes a LED (at the expected speed). When openocd
> is started, you can see the reset occur, because the :ED flashing ceases
> for a moment, but then it cariess on Flashing and openocd eventually
> reports it cannot halt-after-reset.
>
> Is there something about the LPC2468 that isn't the same as the LPC2148
> I'm missing ? (besides the bootloader using the PLL, but I can't see why
> that would matter for this problem).
>
> Here is my openocd script file:
>
> #daemon configuration
> telnet_port 4444
> gdb_port 3333
>
> # tell gdb our flash memory map
> # and enable flash programming
> gdb_memory_map enable
> gdb_flash_program enable
>
> #interface
> interface ft2232
> ft2232_device_desc "Olimex OpenOCD JTAG A"
> ft2232_layout "olimex-jtag"
> ft2232_vid_pid 0x15BA 0x0003
> jtag_speed 3
>
> #use combined on interfaces or targets that can't set TRST/SRST
> separately
> reset_config trst_and_srst srst_pulls_trst
>
> #LPCs need reset pulled while RTCK is low. 0 to activate JTAG, power-on
> reset is not enough
> #jtag_reset 1 1 <---- If I don't comment out these 2 lines openocd can
> never connect with JTAG at all.
> #jtag_reset 0 0
>
> #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_halt 0 arm7tdmi-s_r4
> run_and_halt_time 0 30
>
> working_area 0 0x40000000 0x4000 nobackup
>
> #flash bank lpc2000 0 0
> flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum
>
> # For more information about the configuration files, take a look at:
> #
> http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger
> Cheers,
> Bruce
>
> -----Original Message-----
> From: l...
> [mailto:l... ] On
> Behalf
> Of michael brown
> Sent: Thursday, 13 November 2008 12:23 AM
> To: l...
> Subject: Re: [lpc2000] Olimex LPC-E2468 JTAG Debug: Update
>
> Bruce Paterson wrote:
> > Hmmm
> >
> > All is still not fine with ARM-USB-OCD. For some reason I can't get it
> > to breakpoint on main reliably. I usually set a temporary breakpoint
> > there as part of the startup of gdb, but if I do this, it never gets
> > there. If I just let it halt at random when gdb starts, then I can
> > put a breakpoint on main and it can get there OK.
> > Is there an openocd guru who can tell me what I should do here
> > instead ?
> >
> > Here is my gdb startup:
> >
> > target remote localhost:3333
> > monitor soft_reset_halt
> > monitor arm7_9 force_hw_bkpts enable
> > symbol-file bin/track.elf
> > thbreak main <- Have to remove this line and continue to get it to
> > work with ARM-USB-OCD.
> > continue
>
> I'm not saying it's right, but this is what I use:
> target remote localhost:3333
> monitor reset
> monitor sleep 500
> monitor poll
> monitor soft_reset_halt
> monitor arm7_9 sw_bkpts enable
> monitor mww 0xE01FC040 0x0002
> monitor mdw 0xE01FC040
> break main
> break Reset_Handler
> load
> continue
>
>
Sighs. Not what I meant !
I'm fully familiar with code stepping with optimization.
This is an openocd issue; I'm not even in a debugger yet !

Cheers,
Bruce

-----Original Message-----
From: l... [mailto:l...] On Behalf
Of Ray Molenkamp
Sent: Monday, 17 November 2008 2:40 PM
To: l...
Subject: Re: [lpc2000] renamed: openocd problems

funky things such as stepping back and forwards
while debugging is usually a sign of trying to debug
optimized code.

--Ray

Bruce Paterson wrote:
>
> OK.
> Some steps forwards and then backwards !
> I now get openocd to reliably see the uP JTAG. The fault beforehand
was
> the code somehow turning off JTAG when it crashed.
>
> Now, I cannot get reliable HALT after reset from openocd. Gdb is not
> even involved at this stage.
> I have tried all sorts of combinations of start-up delays, CPU clocks
> and openocd script file changes, and cannot get it working.
> Behaviour is now the same with ARM-USB-OCD and JTAGKey. The code is
> running, because it flashes a LED (at the expected speed). When
openocd
> is started, you can see the reset occur, because the :ED flashing
ceases
> for a moment, but then it cariess on Flashing and openocd eventually
> reports it cannot halt-after-reset.
>
> Is there something about the LPC2468 that isn't the same as the
LPC2148
> I'm missing ? (besides the bootloader using the PLL, but I can't see
why
> that would matter for this problem).
>
> Here is my openocd script file:
>
> #daemon configuration
> telnet_port 4444
> gdb_port 3333
>
> # tell gdb our flash memory map
> # and enable flash programming
> gdb_memory_map enable
> gdb_flash_program enable
>
> #interface
> interface ft2232
> ft2232_device_desc "Olimex OpenOCD JTAG A"
> ft2232_layout "olimex-jtag"
> ft2232_vid_pid 0x15BA 0x0003
> jtag_speed 3
>
> #use combined on interfaces or targets that can't set TRST/SRST
> separately
> reset_config trst_and_srst srst_pulls_trst
>
> #LPCs need reset pulled while RTCK is low. 0 to activate JTAG,
power-on
> reset is not enough
> #jtag_reset 1 1 <---- If I don't comment out these 2 lines openocd can
> never connect with JTAG at all.
> #jtag_reset 0 0
>
> #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_halt 0 arm7tdmi-s_r4
> run_and_halt_time 0 30
>
> working_area 0 0x40000000 0x4000 nobackup
>
> #flash bank lpc2000 0 0
> flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum
>
> # For more information about the configuration files, take a look at:
> #
> http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger

>
Cheers,
> Bruce
>
> -----Original Message-----
> From: l...
> [mailto:l... ] On

> Behalf
> Of michael brown
> Sent: Thursday, 13 November 2008 12:23 AM
> To: l...
> Subject: Re: [lpc2000] Olimex LPC-E2468 JTAG Debug: Update
>
> Bruce Paterson wrote:
> > Hmmm
> >
> > All is still not fine with ARM-USB-OCD. For some reason I can't get
it
> > to breakpoint on main reliably. I usually set a temporary breakpoint
> > there as part of the startup of gdb, but if I do this, it never gets
> > there. If I just let it halt at random when gdb starts, then I can
> > put a breakpoint on main and it can get there OK.
> > Is there an openocd guru who can tell me what I should do here
> > instead ?
> >
> > Here is my gdb startup:
> >
> > target remote localhost:3333
> > monitor soft_reset_halt
> > monitor arm7_9 force_hw_bkpts enable
> > symbol-file bin/track.elf
> > thbreak main <- Have to remove this line and continue to get it to
> > work with ARM-USB-OCD.
> > continue
>
> I'm not saying it's right, but this is what I use:
> target remote localhost:3333
> monitor reset
> monitor sleep 500
> monitor poll
> monitor soft_reset_halt
> monitor arm7_9 sw_bkpts enable
> monitor mww 0xE01FC040 0x0002
> monitor mdw 0xE01FC040
> break main
> break Reset_Handler
> load
> continue
>
>
On Mon, Nov 17, 2008 at 11:58 AM, Bruce Paterson
wrote:
> Sighs. Not what I meant !
> I'm fully familiar with code stepping with optimization.
> This is an openocd issue; I'm not even in a debugger yet !

Openocd evolves very fast. Did you try the latest SVN
version?

I do not have the debugger you have. But as part
of the experiment with Hitex LPC-Stick (LPC2468),
I build the SVN code and it seems to connect with
the board well. But I dare not to try the flashing since
I do not want to destroy the board.

I've built the SVN version of OpenOCD under Cygwin
using the instruction here.
http://forum.sparkfun.com/viewtopic.php?t221
Config file (may not be that correct, especially the
flash part)
######################
# OpenOCD Telnet Port
telnet_port 4444

############################
# GDB Port for First Target
gdb_port 3333

###############################
# JTAG Interface Configuration
interface ft2232
# FT2232 Options
ft2232_device_desc "LPC-Stick A"
ft2232_layout comstick
ft2232_vid_pid 0x0640 0x0026
jtag_speed 1

# slow and verbose during init:
debug_level 3
fast disable
jtag_speed 100

# delays on reset lines
jtag_nsrst_delay 200
jtag_ntrst_delay 200

# use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst srst_pulls_trst

## jtag scan chain
jtag_device 4 0x1 0xf 0xe

# target settings
target arm7tdmi little 0 arm7tdmi-s_r4

#
# scipts/macros/user commands - this is TCL (variant JIM):
#
proc mt_internal_rc {} {
jtag_khz 100
reset run
sleep 100
reset halt
wait_halt 2
# PLL disconnect PLLCON
mww 0xE01FC080 0x01
mww 0xE01FC08C 0xAA
mww 0xE01FC08C 0x55
# PLL disable PLLCON
mww 0xE01FC080 0x00
mww 0xE01FC08C 0xAA
mww 0xE01FC08C 0x55
# no prescaler CCLKCFG
mww 0xE01FC104 0x00
# internal RC CLKSRCSEL
mww 0xE01FC10C 0x00
#### main oscil. CLKSRCSEL
#### mww 0xE01FC10C 0x01
# remap to internal flash
mww 0xE01FC040 0x01
sleep 100
jtag_khz 500
flash probe 0
}

proc mt_flash_bin {IMGFILE OFFSET} {
mt_internal_rc
flash write_image erase $IMGFILE $OFFSET
sleep 100
verify_image $IMGFILE $OFFSET
sleep 100
}

proc mt_flash {IMGFILE} {
mt_internal_rc
flash write_image erase $IMGFILE
sleep 100
verify_image $IMGFILE
sleep 100
}

# mthomas - note taken from the lpc2148 file in the OpenOCD target library:
# NOTE!!! LPCs need reset pulled while RTCK is low. 0 to activate
# JTAG, power-on reset is not enough, i.e. you need to perform a
# reset before being able to talk to the LPC2148, attach is not
# possible.
proc target_0_post_reset {} {
# Force target into ARM state
soft_reset_halt
# do not remap 0x0000-0x0020 to anything but the flash
mwb 0xE01FC040 0x01
}
# working area in RAM
working_area 0 0x40000000 0x10000 nobackup

#flash bank lpc2000 0 0 [calc_checksum]
# n.b.: the target is switched to the internal RC (nom. 4MHz)
# before flashing with the supplied commands so this is the frequency
# given as parameter
flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 4000 calc_checksum
gdb_flash_program enable

init

fast enable
jtag_khz 500
debug_level 1
Regards,
Xiaofan
http://mcuee.blogspot.com

Hi Bruce,

Have you tried increasing the jtag_speed parameter? I get similar
behaviour on the EA 2468 board unless I set the parameter to 12 or
higher.

- Niels

--- In l..., "Bruce Paterson"
wrote:
>
> OK.
> Some steps forwards and then backwards !
> I now get openocd to reliably see the uP JTAG. The fault beforehand
was
> the code somehow turning off JTAG when it crashed.
>
> Now, I cannot get reliable HALT after reset from openocd. Gdb is not
> even involved at this stage.
> I have tried all sorts of combinations of start-up delays, CPU
clocks
> and openocd script file changes, and cannot get it working.
> Behaviour is now the same with ARM-USB-OCD and JTAGKey. The code is
> running, because it flashes a LED (at the expected speed). When
openocd
> is started, you can see the reset occur, because the :ED flashing
ceases
> for a moment, but then it cariess on Flashing and openocd eventually
> reports it cannot halt-after-reset.
>
> Is there something about the LPC2468 that isn't the same as the
LPC2148
> I'm missing ? (besides the bootloader using the PLL, but I can't see
why
> that would matter for this problem).
>
> Here is my openocd script file:
>
> #daemon configuration
> telnet_port 4444
> gdb_port 3333
>
> # tell gdb our flash memory map
> # and enable flash programming
> gdb_memory_map enable
> gdb_flash_program enable
>
> #interface
> interface ft2232
> ft2232_device_desc "Olimex OpenOCD JTAG A"
> ft2232_layout "olimex-jtag"
> ft2232_vid_pid 0x15BA 0x0003
> jtag_speed 3
>
> #use combined on interfaces or targets that can't set TRST/SRST
> separately
> reset_config trst_and_srst srst_pulls_trst
>
> #LPCs need reset pulled while RTCK is low. 0 to activate JTAG,
power-on
> reset is not enough
> #jtag_reset 1 1 <---- If I don't comment out these 2 lines openocd
can
> never connect with JTAG at all.
> #jtag_reset 0 0
>
> #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_halt 0 arm7tdmi-s_r4
> run_and_halt_time 0 30
>
> working_area 0 0x40000000 0x4000 nobackup
>
> #flash bank lpc2000 0 0
> flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum
>
> # For more information about the configuration files, take a look
at:
> # http://openfacts.berlios.de/index-en.phtml?title=Open+On-
Chip+Debugger
>
> Cheers,
> Bruce
> -----Original Message-----
> From: l... [mailto:l...] On
Behalf
> Of michael brown
> Sent: Thursday, 13 November 2008 12:23 AM
> To: l...
> Subject: Re: [lpc2000] Olimex LPC-E2468 JTAG Debug: Update
>
> Bruce Paterson wrote:
> > Hmmm
> >
> > All is still not fine with ARM-USB-OCD. For some reason I can't
get it
> > to breakpoint on main reliably. I usually set a temporary
breakpoint
> > there as part of the startup of gdb, but if I do this, it never
gets
> > there. If I just let it halt at random when gdb starts, then I can
> > put a breakpoint on main and it can get there OK.
> > Is there an openocd guru who can tell me what I should do here
> > instead ?
> >
> > Here is my gdb startup:
> >
> > target remote localhost:3333
> > monitor soft_reset_halt
> > monitor arm7_9 force_hw_bkpts enable
> > symbol-file bin/track.elf
> > thbreak main <- Have to remove this line and continue to get it
to
> > work with ARM-USB-OCD.
> > continue
>
> I'm not saying it's right, but this is what I use:
> target remote localhost:3333
> monitor reset
> monitor sleep 500
> monitor poll
> monitor soft_reset_halt
> monitor arm7_9 sw_bkpts enable
> monitor mww 0xE01FC040 0x0002
> monitor mdw 0xE01FC040
> break main
> break Reset_Handler
> load
> continue
>
>
Bruce Paterson wrote:
> flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum

Is that last number correct? I haven't been following this thread
from the beginning, so I don't know what hardware you're using, but
14.7456 MHz is a common crystal and that would usually give 14745
there...

It might not be the cause of any problems, but OpenOCD is quite flakey
about these things so you never know.

Pete
Hi Pete,

I'm sure it would be a problem if I was trying to use the flash
programming, but at this stage still using flash-magic till I get the
debugger part working. I will, however, change it to 120000 when I
attempt flashing.

Thanks,
Bruce

-----Original Message-----
From: l... [mailto:l...] On Behalf
Of Peter Vidler
Sent: Tuesday, 18 November 2008 8:23 AM
To: l...
Subject: [lpc2000] Re:renamed: openocd problems

Bruce Paterson wrote:
> flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum

Is that last number correct? I haven't been following this thread
from the beginning, so I don't know what hardware you're using, but
14.7456 MHz is a common crystal and that would usually give 14745
there...

It might not be the cause of any problems, but OpenOCD is quite flakey
about these things so you never know.

Pete
Yay ! That was it.
Changing JTAG speed to 12, and setting both reset times to 200 make it a
reliable connection.
I did try earlier increasing this figure, but not as high as 12.

The flash programming sections from Peter Vidler (Thanks Peter) must
apply to the lastest SVN build, so if I get time I will experiment with
Flash loading using latest openocd as well, but at least for now I'm
working.

PS: With Eclipse, is there any way to get it to access memory from the
memory dump window with "longword" access rather than "byte" access ?
I'm not referring to the presentation which you can vary, but the
underlying memory access.
Why ? Well it seems Ethernet ram (and of course many of the IO
registers) can only be longword accessed whereas ordinary RAM can be
accessed any width.

My workaround for now: Set up an expression in the watch window to look
at memory locations of interest forcing a longword access by casting
pointer types (eg *(unsigned long *)0x4f000000). Works but it's
cumbersome.

Looking at Crossworks....

Cheers,
Bruce

-----Original Message-----
From: l... [mailto:l...] On Behalf
Of kanoop2k
Sent: Monday, 17 November 2008 10:31 PM
To: l...
Subject: [lpc2000] Re: renamed: openocd problems

Hi Bruce,

Have you tried increasing the jtag_speed parameter? I get similar
behaviour on the EA 2468 board unless I set the parameter to 12 or
higher.

- Niels

--- In l..., "Bruce Paterson"
wrote:
>
> OK.
> Some steps forwards and then backwards !
> I now get openocd to reliably see the uP JTAG. The fault beforehand
was
> the code somehow turning off JTAG when it crashed.
>
> Now, I cannot get reliable HALT after reset from openocd. Gdb is not
> even involved at this stage.
> I have tried all sorts of combinations of start-up delays, CPU
clocks
> and openocd script file changes, and cannot get it working.
> Behaviour is now the same with ARM-USB-OCD and JTAGKey. The code is
> running, because it flashes a LED (at the expected speed). When
openocd
> is started, you can see the reset occur, because the :ED flashing
ceases
> for a moment, but then it cariess on Flashing and openocd eventually
> reports it cannot halt-after-reset.
>
> Is there something about the LPC2468 that isn't the same as the
LPC2148
> I'm missing ? (besides the bootloader using the PLL, but I can't see
why
> that would matter for this problem).
>
> Here is my openocd script file:
>
> #daemon configuration
> telnet_port 4444
> gdb_port 3333
>
> # tell gdb our flash memory map
> # and enable flash programming
> gdb_memory_map enable
> gdb_flash_program enable
>
> #interface
> interface ft2232
> ft2232_device_desc "Olimex OpenOCD JTAG A"
> ft2232_layout "olimex-jtag"
> ft2232_vid_pid 0x15BA 0x0003
> jtag_speed 3
>
> #use combined on interfaces or targets that can't set TRST/SRST
> separately
> reset_config trst_and_srst srst_pulls_trst
>
> #LPCs need reset pulled while RTCK is low. 0 to activate JTAG,
power-on
> reset is not enough
> #jtag_reset 1 1 <---- If I don't comment out these 2 lines openocd
can
> never connect with JTAG at all.
> #jtag_reset 0 0
>
> #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_halt 0 arm7tdmi-s_r4
> run_and_halt_time 0 30
>
> working_area 0 0x40000000 0x4000 nobackup
>
> #flash bank lpc2000 0 0
> flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v2 14765 calc_checksum
>
> # For more information about the configuration files, take a look
at:
> # http://openfacts.berlios.de/index-en.phtml?title=Open+On-
Chip+Debugger
>
> Cheers,
> Bruce
> -----Original Message-----
> From: l... [mailto:l...] On
Behalf
> Of michael brown
> Sent: Thursday, 13 November 2008 12:23 AM
> To: l...
> Subject: Re: [lpc2000] Olimex LPC-E2468 JTAG Debug: Update
>
> Bruce Paterson wrote:
> > Hmmm
> >
> > All is still not fine with ARM-USB-OCD. For some reason I can't
get it
> > to breakpoint on main reliably. I usually set a temporary
breakpoint
> > there as part of the startup of gdb, but if I do this, it never
gets
> > there. If I just let it halt at random when gdb starts, then I can
> > put a breakpoint on main and it can get there OK.
> > Is there an openocd guru who can tell me what I should do here
> > instead ?
> >
> > Here is my gdb startup:
> >
> > target remote localhost:3333
> > monitor soft_reset_halt
> > monitor arm7_9 force_hw_bkpts enable
> > symbol-file bin/track.elf
> > thbreak main <- Have to remove this line and continue to get it
to
> > work with ARM-USB-OCD.
> > continue
>
> I'm not saying it's right, but this is what I use:
> target remote localhost:3333
> monitor reset
> monitor sleep 500
> monitor poll
> monitor soft_reset_halt
> monitor arm7_9 sw_bkpts enable
> monitor mww 0xE01FC040 0x0002
> monitor mdw 0xE01FC040
> break main
> break Reset_Handler
> load
> continue
>
>