EmbeddedRelated.com
Forums

(wiggler) openocd configuration for LPC2148?

Started by ino-...@spotteswoode.dnsalias.org August 17, 2006
i recently upgraded my openocd copy to revision 86, and i know the
commands and options have gotten more detailed over time.

after googling for "openocd lpc2000" i found a few links:

http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/index.html

this URL is for the LPC2138 on keil LPC2130 board, though. yagarto.de
provides a number of files, but they are contained in a windows
installer instead of a simple .zip file. no go for my freebsd system.

my problem is that there's no comprehensive list of commands and options
to use in a configuration file, and i cannot get gdb and openocd to work
anymore.

could people please post their known-to-work configurations for LPC2148
or at least 214x parts?

are openocd configuration commands dependant on the order they are
encountered in the configuration file by chance?

what is the exact meaning of the options for the following commands:

1. jtag_device
2. target
3. daemon_startup
4. working_area
5. flash bank

currently i see the board reset, but i cannot get it to run using
breakpoints.

also, which .gdbinit configuration is most appropriate? i am using the
command line gdb and a wiggler, a sample session would be welcome.

thanks,

clemens

An Engineer's Guide to the LPC2100 Series

--- In l..., ino-news@... wrote:

*********************SNIP****************************************8
>
> what is the exact meaning of the options for the following commands:
>
> 1. jtag_device
> 2. target
> 3. daemon_startup
> 4. working_area
> 5. flash bank
>
All of those questions appear to be answered in usage notes here:
http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger

--Dave
Hello Clemens,

On Thursday 17 August 2006 17:21, i...@spotteswoode.dnsalias.org wrote:
> i recently upgraded my openocd copy to revision 86, and i know the
> commands and options have gotten more detailed over time.
>
> after googling for "openocd lpc2000" i found a few links:
>
>
> http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/openocd_intro/i
>ndex.html
>
> this URL is for the LPC2138 on keil LPC2130 board, though. yagarto.de
> provides a number of files, but they are contained in a windows
> installer instead of a simple .zip file. no go for my freebsd system.
>
The LPC2138 should be very similar if not identical with regard to debugging,
so you should be save using the stuff provided by Martin Thomas as a starting
point.

> my problem is that there's no comprehensive list of commands and options
> to use in a configuration file, and i cannot get gdb and openocd to work
> anymore.
>
As dave pointed out this information is located in the OpenOCD at Berlios
Openfacts. Since r85, a link to the Wiki is also included in the README. I
know that the documentation still isn't the best, but it should be useable.
Feel free to ask, either here, in the OpenOCD forum at sparkfun.com or via
email if you need something clarified.

> could people please post their known-to-work configurations for LPC2148
> or at least 214x parts?
>
Unfortunately, the only LPC I have is a LPC-H2294 board from Olimex. The
arm7_xxx.cfg examples in the doc/configs/ directory are tested specifically
with that LPC board.

> are openocd configuration commands dependant on the order they are
> encountered in the configuration file by chance?
>
Yes, some commands are dependant on the order, but only as far as a target
depends on a jtag_device (the target takes the number of the jtag_device as
an option). Also commands like run_and_halt_time, that specify a delay for a
certain target require that target to be configured first. Same is true for
flashes (so far, all flashes depend on target, that might change if support
is added for flashes that have a JTAG port of their own.

> what is the exact meaning of the options for the following commands:
>
> 1. jtag_device
> 2. target
> 3. daemon_startup
> 4. working_area
> 5. flash bank
>
They're explained in the Wiki. If something is unclear, feel free to ask. I'll
be happy to update the Wiki with more information if necessary.

> currently i see the board reset, but i cannot get it to run using
> breakpoints.
>
You have to enable breakpoints first with. If no other options are given, the
default for ARM7 targets is to have software breakpoints disabled, as they
would use one of only two hardware comparators. To enable software
breakpoints use "arm7_9 sw_bkpts enable".
The GDB always requests software breakpoints (if you don't explicitly request
a HW breakpoint) - if your code is located in flash, you can configure the
OpenOCD to convert all requested breakpoints to hardware breakpoints
with "arm7_9 force_hw_bkpts enable" (within GDB, use 'monitor' to send the
command to OpenOCDs command handler).

> also, which .gdbinit configuration is most appropriate? i am using the
> command line gdb and a wiggler, a sample session would be welcome.
>
That really depends on what you want to do. Personally I don't use a .gdbinit
at all, and type the commands i want each time I run gdb.

> thanks,
>
> clemens

Regards,

Dominic
On Thu, 17 Aug 2006 16:22:04 -0000 derbaier wrote:

> All of those questions appear to be answered in usage notes here:
> http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger

that is true. last time i checked the info was outdated and i had only
questions, nothing to add to that wiki.

ok, here's a somewhat working configuration. the limitations of this
solution is related to the JTAG implementation used on the LPC214x part:

On JTAG interfaces / targets where system reset and test-logic reset
can't be driven completely independent (like the LPC2000 series), or
where the JTAG interface is unavailable for some time during startup
(like the STR7 series), you can't use 'reset_halt' or 'reset_init'.

#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface parport
parport_port 0x378
parport_cable wiggler
jtag_speed 0
reset_config trst_and_srst
#jtag scan chain
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 333
jtag_ntrst_delay 333
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30
daemon_startup reset
#target_script 0 reset openocd.script
working_area 0 0x40000000 0x4000 nobackup
# flash bank lpc2000 0 0 ['calc_checksum']
flash bank lpc2000 0x0 0x7D000 0 0 lpc2000_v2 0 12000 calc_checksum

i added this configuration as a separate item on a new page in the wiki.

clemens
On Thu, 17 Aug 2006 19:44:52 +0200 Dominic Rath wrote:

> The LPC2138 should be very similar if not identical with regard to
> debugging, so you should be save using the stuff provided by Martin
> Thomas as a starting point.

from martin thomas page i got:

flash bank lpc2000 0x0 0x7D000 0 0 lpc2000_v2 0 12000 calc_checksum

the "12000" should be the _current_ core clock. but the number given is
the xtal frequency. since on LPC2000 targets the JTAG cannot be
controlled right from the start, the target can be running without PLL
right after reset, or it could be running somewhere after initialisation
with any PLL settings.

OTOH, i cannot use anything else than:

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

(given before the "flash" command, of course). do i specify the xtal
frequency or the core clock, which is 60000 kHz in ma case?

> As dave pointed out this information is located in the OpenOCD at
> Berlios Openfacts. Since r85, a link to the Wiki is also included in
> the README. I know that the documentation still isn't the best, but
> it should be useable. Feel free to ask, either here, in the OpenOCD
> forum at sparkfun.com or via email if you need something clarified.

thanks for the offer. i absolutely dislike fora and prefer wikis for
the better structure, wikis are easier to read.

> Yes, some commands are dependant on the order, but only as far as
> a target depends on a jtag_device (the target takes the number of
> the jtag_device as an option). Also commands like run_and_halt_time,
> that specify a delay for a certain target require that target to be
> configured first. Same is true for flashes (so far, all flashes depend
> on target, that might change if support is added for flashes that have
> a JTAG port of their own.

i think this should be pointed out in the wiki, although it sounds like
common sense.

> That really depends on what you want to do. Personally I don't use a
> .gdbinit at all, and type the commands i want each time I run gdb.

ok, here's my .gdbinit. does it look ok?

#set directories $cdir:$cwd:../lcds16x2/
set can-use-hw-watchpoints 2
set complaints 33
set history save
set history size 333
set logging on
set output-radix 0x10
set step-mode on
set trust-readonly-sections on
set verbose on
set watchdog 15

target remote localhost:3333
monitor soft_reset_halt
# only for RAM: monitor arm7_9 sw_bkpts enable
monitor arm7_9 force_hw_bkpts enable
hbreak main
load
continue

regards,

clemens