Reply by Bruce Paterson●November 17, 20082008-11-17
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
>
>
Reply by Bruce Paterson●November 17, 20082008-11-17
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
Reply by Peter Vidler●November 17, 20082008-11-17
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
Reply by kanoop2k●November 17, 20082008-11-17
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
>
>
Reply by Xiaofan Chen●November 17, 20082008-11-17
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
# 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
Reply by Bruce Paterson●November 16, 20082008-11-16
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
>
>
Reply by Ray Molenkamp●November 16, 20082008-11-16
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
>
>
Reply by Bruce Paterson●November 16, 20082008-11-16
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).
#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
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
Reply by michael brown●November 12, 20082008-11-12
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
