@itemize @bullet
@item Copyright @copyright{} 2008 The OpenOCD Project
@item Copyright @copyright{} 2007-2008 Spencer Oliver @email{spen@@spen-soft.co.uk}
-@item Copyright @copyright{} 2008 Oyvind Harboe @email{oyvind.harboe@@zylin.com}
+@item Copyright @copyright{} 2008-2010 Oyvind Harboe @email{oyvind.harboe@@zylin.com}
@item Copyright @copyright{} 2008 Duane Ellis @email{openocd@@duaneellis.com}
@item Copyright @copyright{} 2009-2010 David Brownell
@end itemize
are many types of debug adapter, and little uniformity in what
they are called. (There are also product naming differences.)
-These adapters are sometimes packaged as discrete dongles. which
+These adapters are sometimes packaged as discrete dongles, which
may generically be called @dfn{hardware interface dongles}.
Some development boards also integrate them directly, which may
let the development board can be directly connected to the debug
other one is used to provide a debug adapter.
Also, some development boards integrate an FT2232 chip to serve as
-a built-in low coast debug adapter and usb-to-serial solution.
+a built-in low cost debug adapter and usb-to-serial solution.
@itemize @bullet
@item @b{usbjtag}
JIM-Tcl commands, and (older) the orginal command interpreter.
@item @b{Commands}
-@* At the OpenOCD telnet command line (or via the GDB mon command) one
+@* At the OpenOCD telnet command line (or via the GDB monitor command) one
can type a Tcl for() loop, set variables, etc.
Some of the commands documented in this guide are implemented
as Tcl scripts, from a @file{startup.tcl} file internal to the server.
--debug | -d set debug level <0-3>
--log_output | -l redirect log output to file <name>
--command | -c run <command>
---pipe | -p use pipes when talking to gdb
@end verbatim
If you don't give any @option{-f} or @option{-c} options,
@enumerate
@item the current directory,
@item any search dir specified on the command line using the @option{-s} option,
+@item any search dir specified using the @command{add_script_search_dir} command,
@item @file{$HOME/.openocd} (not on Windows),
@item the site wide script library @file{$pkgdatadir/site} and
@item the OpenOCD-supplied script library @file{$pkgdatadir/scripts}.
@deffn {Command} gdb_port [number]
@cindex GDB server
-Specify or query the first port used for incoming GDB connections.
-The GDB port for the
-first target will be gdb_port, the second target will listen on gdb_port + 1, and so on.
+Normally gdb listens to a TCP/IP port, but GDB can also
+communicate via pipes(stdin/out or named pipes). The name
+"gdb_port" stuck because it covers probably more than 90% of
+the normal use cases.
+
+No arguments reports GDB port. "pipe" means listen to stdin
+output to stdout, an integer is base port number, "disable"
+disables the gdb server.
+
+When using "pipe", also use log_output to redirect the log
+output to a file so as not to flood the stdin/out pipes.
+
+The -p/--pipe option is deprecated and a warning is printed
+as it is equivalent to passing in -c "gdb_port pipe; log_output openocd.log".
+
+Any other string is interpreted as named pipe to listen to.
+Output pipe is the same name as input pipe, but with 'o' appended,
+e.g. /var/gdb, /var/gdbo.
+
+The GDB port for the first target will be the base port, the
+second target will listen on gdb_port + 1, and so on.
When not specified during the configuration stage,
the port @var{number} defaults to 3333.
-When specified as zero, GDB remote access ports are not activated.
@end deffn
@deffn {Command} tcl_port [number]
Intended as a machine interface.
When not specified during the configuration stage,
the port @var{number} defaults to 6666.
-When specified as zero, this port is not activated.
+
@end deffn
@deffn {Command} telnet_port [number]
@end deffn
@deffn Command {interface_list}
-List the interface drivers that have been built into
+List the debug adapter drivers that have been built into
the running copy of OpenOCD.
@end deffn
+@deffn Command {interface transports} transport_name+
+Specifies the transports supported by this debug adapter.
+The adapter driver builds-in similar knowledge; use this only
+when external configuration (such as jumpering) changes what
+the hardware can support.
+@end deffn
+
-@deffn Command {jtag interface}
-Returns the name of the interface driver being used.
+
+@deffn Command {adapter_name}
+Returns the name of the debug adapter driver being used.
@end deffn
@section Interface Drivers
Currently, only one @var{vid}, @var{pid} pair may be given, e.g. for
Altera USB-Blaster (default):
@example
-ft2232_vid_pid 0x09FB 0x6001
+usb_blaster_vid_pid 0x09FB 0x6001
@end example
The following VID/PID is for Kolja Waschk's USB JTAG:
@example
-ft2232_vid_pid 0x16C0 0x06AD
+usb_blaster_vid_pid 0x16C0 0x06AD
@end example
@end deffn
@deffn {Interface Driver} {ZY1000}
This is the Zylin ZY1000 JTAG debugger.
+@end deffn
@quotation Note
This defines some driver-specific commands,
No arguments: print status.
@end deffn
-@end deffn
+@section Transport Configuration
+As noted earlier, depending on the version of OpenOCD you use,
+and the debug adapter you are using,
+several transports may be available to
+communicate with debug targets (or perhaps to program flash memory).
+@deffn Command {transport list}
+displays the names of the transports supported by this
+version of OpenOCD.
+@end deffn
+
+@deffn Command {transport select} transport_name
+Select which of the supported transports to use in this OpenOCD session.
+The transport must be supported by the debug adapter hardware and by the
+version of OPenOCD you are using (including the adapter's driver).
+No arguments: returns name of session's selected transport.
+@end deffn
+
+@subsection JTAG Transport
+JTAG is the original transport supported by OpenOCD, and most
+of the OpenOCD commands support it.
+JTAG transports expose a chain of one or more Test Access Points (TAPs),
+each of which must be explicitly declared.
+JTAG supports both debugging and boundary scan testing.
+Flash programming support is built on top of debug support.
+@subsection SWD Transport
+SWD (Serial Wire Debug) is an ARM-specific transport which exposes one
+Debug Access Point (DAP, which must be explicitly declared.
+(SWD uses fewer signal wires than JTAG.)
+SWD is debug-oriented, and does not support boundary scan testing.
+Flash programming support is built on top of debug support.
+(Some processors support both JTAG and SWD.)
+@subsection SPI Transport
+The Serial Peripheral Interface (SPI) is a general purpose transport
+which uses four wire signaling. Some processors use it as part of a
+solution for flash programming.
@anchor{JTAG Speed}
@section JTAG Speed
requirements that all reset pulses last for at least a
certain amount of time; and reset buttons commonly have
hardware debouncing.
-Use the @command{jtag_nsrst_delay} and @command{jtag_ntrst_delay}
+Use the @command{adapter_nsrst_delay} and @command{jtag_ntrst_delay}
commands to say when extra delays are needed.
@item @emph{Drive type} ... Reset lines often have a pullup
@section Commands for Handling Resets
-@deffn {Command} jtag_nsrst_assert_width milliseconds
+@deffn {Command} adapter_nsrst_assert_width milliseconds
Minimum amount of time (in milliseconds) OpenOCD should wait
after asserting nSRST (active-low system reset) before
allowing it to be deasserted.
@end deffn
-@deffn {Command} jtag_nsrst_delay milliseconds
+@deffn {Command} adapter_nsrst_delay milliseconds
How long (in milliseconds) OpenOCD should wait after deasserting
nSRST (active-low system reset) before starting new JTAG operations.
When a board has a reset button connected to SRST line it will
@item @code{arm11} -- this is a generation of ARMv6 cores
@item @code{arm720t} -- this is an ARMv4 core with an MMU
@item @code{arm7tdmi} -- this is an ARMv4 core
-@item @code{arm920t} -- this is an ARMv5 core with an MMU
+@item @code{arm920t} -- this is an ARMv4 core with an MMU
@item @code{arm926ejs} -- this is an ARMv5 core with an MMU
@item @code{arm966e} -- this is an ARMv5 core
@item @code{arm9tdmi} -- this is an ARMv4 core
@item @code{fa526} -- resembles arm920 (w/o Thumb)
@item @code{feroceon} -- resembles arm926
@item @code{mips_m4k} -- a MIPS core. This supports one variant:
-@itemize @minus
-@item @code{ejtag_srst} ... Use this when debugging targets that do not
-provide a functional SRST line on the EJTAG connector. This causes
-OpenOCD to instead use an EJTAG software reset command to reset the
-processor.
-You still need to enable @option{srst} on the @command{reset_config}
-command to enable OpenOCD hardware reset functionality.
-@end itemize
@item @code{xscale} -- this is actually an architecture,
not a CPU type. It is based on the ARMv5 architecture.
There are several variants defined:
mychip.cpu configure -event gdb-attach my_attach_proc
mychip.cpu configure -event gdb-attach @{
echo "Reset..."
- reset halt
+ # To make flash probe and gdb load to flash work we need a reset init.
+ reset init
@}
@end example
@* Currently not used (goal: when JTAG examine starts)
@end ignore
@item @b{gdb-attach}
-@* When GDB connects
+@* When GDB connects. This is before any communication with the target, so this
+can be used to set up the target so it is possible to probe flash. Probing flash
+is necessary during gdb connect if gdb load is to write the image to flash. Another
+use of the flash memory map is for GDB to automatically hardware/software breakpoints
+depending on whether the breakpoint is in RAM or read only memory.
@item @b{gdb-detach}
@* When GDB disconnects
@item @b{gdb-end}
The @var{num} parameter is a value shown by @command{flash banks}.
@end deffn
-@deffn Command {flash erase_address} [@option{pad}] address length
+@deffn Command {flash erase_address} [@option{pad}] [@option{unlock}] address length
Erase sectors starting at @var{address} for @var{length} bytes.
Unless @option{pad} is specified, @math{address} must begin a
flash sector, and @math{address + length - 1} must end a sector.
the specified length must stay within that bank.
As a special case, when @var{length} is zero and @var{address} is
the start of the bank, the whole flash is erased.
+If @option{unlock} is specified, then the flash is unprotected
+before erase starts.
@end deffn
@deffn Command {flash fillw} address word length
@deffn Command {flash info} num
Print info about flash bank @var{num}
The @var{num} parameter is a value shown by @command{flash banks}.
-The information includes per-sector protect status, which may be
-incorrect (outdated) unless you first issue a
-@command{flash protect_check num} command.
+This command will first query the hardware, it does not print cached
+and possibly stale information.
@end deffn
@anchor{flash protect}
The @var{num} parameter is a value shown by @command{flash banks}.
@end deffn
-@deffn Command {flash protect_check} num
-Check protection state of sectors in flash bank @var{num}.
-The @var{num} parameter is a value shown by @command{flash banks}.
-@comment @option{flash erase_sector} using the same syntax.
-This updates the protection information displayed by @option{flash info}.
-(Code execution may have invalidated any state records kept by OpenOCD.)
-@end deffn
-
@anchor{Flash Driver List}
@section Flash Driver List
As noted above, the @command{flash bank} command requires a driver name,
wide on a sixteen bit bus:
@example
-flash bank cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
-flash bank cfi 0x01000000 0x01000000 2 2 $_TARGETNAME
+flash bank $_FLASHNAME cfi 0x00000000 0x01000000 2 2 $_TARGETNAME
+flash bank $_FLASHNAME cfi 0x01000000 0x01000000 2 2 $_TARGETNAME
@end example
To configure one bank of 32 MBytes
to create a thirty-two bit (four byte) bus with doubled throughput:
@example
-flash bank cfi 0x00000000 0x02000000 2 4 $_TARGETNAME
+flash bank $_FLASHNAME cfi 0x00000000 0x02000000 2 4 $_TARGETNAME
@end example
@c "cfi part_id" disabled
@end deffn
+@deffn {Flash Driver} stmsmi
+@cindex STMicroelectronics Serial Memory Interface
+@cindex SMI
+@cindex stmsmi
+Some devices form STMicroelectronics (e.g. STR75x MCU family,
+SPEAr MPU family) include a proprietary
+``Serial Memory Interface'' (SMI) controller able to drive external
+SPI flash devices.
+Depending on specific device and board configuration, up to 4 external
+flash devices can be connected.
+
+SMI makes the flash content directly accessible in the CPU address
+space; each external device is mapped in a memory bank.
+CPU can directly read data, execute code and boot from SMI banks.
+Normal OpenOCD commands like @command{mdw} can be used to display
+the flash content.
+
+The setup command only requires the @var{base} parameter in order
+to identify the memory bank.
+All other parameters are ignored. Additional information, like
+flash size, are detected automatically.
+
+@example
+flash bank $_FLASHNAME stmsmi 0xf8000000 0 0 0 $_TARGETNAME
+@end example
+
+@end deffn
+
@subsection Internal Flash (Microcontrollers)
@deffn {Flash Driver} aduc702x
since all devices in this family have the same memory layout.
@example
-flash bank aduc702x 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME aduc702x 0 0 0 0 $_TARGETNAME
@end example
@end deffn
@example
# Flash bank 0 - all chips
-flash bank at91sam3 0x00080000 0 1 1 $_TARGETNAME
+flash bank $_FLASHNAME at91sam3 0x00080000 0 1 1 $_TARGETNAME
# Flash bank 1 - only 256K chips
-flash bank at91sam3 0x00100000 0 1 1 $_TARGETNAME
+flash bank $_FLASHNAME at91sam3 0x00100000 0 1 1 $_TARGETNAME
@end example
Internally, the AT91SAM3 flash memory is organized as follows.
register, and autoconfigures itself.
@example
-flash bank at91sam7 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME at91sam7 0 0 0 0 $_TARGETNAME
@end example
For chips which are not recognized by the controller driver, you must
LPC flashes don't require the chip and bus width to be specified.
@example
-flash bank lpc2000 0x0 0x7d000 0 0 $_TARGETNAME \
+flash bank $_FLASHNAME lpc2000 0x0 0x7d000 0 0 $_TARGETNAME \
lpc2000_v2 14765 calc_checksum
@end example
LPC flashes don't require the chip and bus width to be specified.
@example
-flash bank lpc288x 0 0 0 0 $_TARGETNAME 12000000
+flash bank $_FLASHNAME lpc288x 0 0 0 0 $_TARGETNAME 12000000
@end example
@end deffn
Example for a 125 MHz clock frequency:
@example
-flash bank lpc2900 0 0 0 0 $_TARGETNAME 125000
+flash bank $_FLASHNAME lpc2900 0 0 0 0 $_TARGETNAME 125000
@end example
Some @code{lpc2900}-specific commands are defined. In the following command list,
@emph{No idea what this is, other than using some arm7/arm9 core.}
@example
-flash bank ocl 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME ocl 0 0 0 0 $_TARGETNAME
@end example
@end deffn
@deffn {Flash Driver} pic32mx
The PIC32MX microcontrollers are based on the MIPS 4K cores,
and integrate flash memory.
-@emph{The current implementation is incomplete.}
@example
-flash bank pix32mx 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME pix32mx 0x1fc00000 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME pix32mx 0x1d000000 0 0 0 $_TARGETNAME
@end example
@comment numerous *disabled* commands are defined:
Programs the specified 32-bit @var{value} at the given @var{address}
in the specified chip @var{bank}.
@end deffn
+@deffn Command {pic32mx unlock} bank
+Unlock and erase specified chip @var{bank}.
+This will remove any Code Protection.
+@end deffn
@end deffn
@deffn {Flash Driver} stellaris
standard @command{flash erase_address} command.}
@example
-flash bank stellaris 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME stellaris 0 0 0 0 $_TARGETNAME
@end example
@end deffn
the chip identification register, and autoconfigures itself.
@example
-flash bank stm32x 0 0 0 0 $_TARGETNAME
+flash bank $_FLASHNAME stm32x 0 0 0 0 $_TARGETNAME
@end example
Some stm32x-specific commands
which is either @code{STR71x}, @code{STR73x} or @code{STR75x}.
@example
-flash bank str7x 0x40000000 0x00040000 0 0 $_TARGETNAME STR71x
+flash bank $_FLASHNAME str7x 0x40000000 0x00040000 0 0 $_TARGETNAME STR71x
@end example
@deffn Command {str7x disable_jtag} bank
the @command{str9x flash_config} command prior to Flash programming.
@example
-flash bank str9x 0x40000000 0x00040000 0 0 $_TARGETNAME
+flash bank $_FLASHNAME str9x 0x40000000 0x00040000 0 0 $_TARGETNAME
str9x flash_config 0 4 2 0 0x80000
@end example
@end deffn
@end deffn
+@deffn {Flash Driver} virtual
+This is a special driver that maps a previously defined bank to another
+address. All bank settings will be copied from the master physical bank.
+
+The @var{virtual} driver defines one mandatory parameters,
+
+@itemize
+@item @var{master_bank} The bank that this virtual address refers to.
+@end itemize
+
+So in the following example addresses 0xbfc00000 and 0x9fc00000 refer to
+the flash bank defined at address 0x1fc00000. Any cmds executed on
+the virtual banks are actually performed on the physical banks.
+@example
+flash bank $_FLASHNAME pic32mx 0x1fc00000 0 0 0 $_TARGETNAME
+flash bank vbank0 virtual 0xbfc00000 0 0 0 $_TARGETNAME $_FLASHNAME
+flash bank vbank1 virtual 0x9fc00000 0 0 0 $_TARGETNAME $_FLASHNAME
+@end example
+@end deffn
+
@subsection str9xpec driver
@cindex str9xpec
Example for s3c2440 mflash where @var{RST pin} is GPIO B1:
@example
-mflash bank s3c2440 0x10000000 1b 0
+mflash bank $_FLASHNAME s3c2440 0x10000000 1b 0
@end example
Example for pxa270 mflash where @var{RST pin} is GPIO 43:
@example
-mflash bank pxa270 0x08000000 43 0
+mflash bank $_FLASHNAME pxa270 0x08000000 43 0
@end example
@end deffn
@section Other NAND commands
@cindex NAND other commands
-@deffn Command {nand check_bad_blocks} [offset length]
+@deffn Command {nand check_bad_blocks} num [offset length]
Checks for manufacturer bad block markers on the specified NAND
device. If no parameters are provided, checks the whole
device; otherwise, starts at the specified @var{offset} and
@xref{Running}.
@end deffn
-@deffn Command fast (@option{enable}|@option{disable})
-Default disabled.
-Set default behaviour of OpenOCD to be "fast and dangerous".
-
-At this writing, this only affects the defaults for two ARM7/ARM9 parameters:
-fast memory access, and DCC downloads. Those parameters may still be
-individually overridden.
-
-The target specific "dangerous" optimisation tweaking options may come and go
-as more robust and user friendly ways are found to ensure maximum throughput
-and robustness with a minimum of configuration.
-
-Typically the "fast enable" is specified first on the command line:
-
-@example
-openocd -c "fast enable" -c "interface dummy" -f target/str710.cfg
-@end example
-@end deffn
-
-@deffn Command echo message
+@deffn Command echo [-n] message
Logs a message at "user" priority.
Output @var{message} to stdout.
+Option "-n" suppresses trailing newline.
@example
echo "Downloading kernel -- please wait"
@end example
the initial log output channel is stderr.
@end deffn
+@deffn Command add_script_search_dir [directory]
+Add @var{directory} to the file/script search path.
+@end deffn
+
@anchor{Target State handling}
@section Target State handling
@cindex reset
@end deffn
@anchor{load_image}
-@deffn Command {load_image} filename address [@option{bin}|@option{ihex}|@option{elf}]
-Load image from file @var{filename} to target memory at @var{address}.
+@deffn Command {load_image} filename address [[@option{bin}|@option{ihex}|@option{elf}] @option{min_addr} @option{max_length}]
+Load image from file @var{filename} to target memory offset by @var{address} from its load address.
The file format may optionally be specified
-(@option{bin}, @option{ihex}, or @option{elf})
+(@option{bin}, @option{ihex}, or @option{elf}).
+In addition the following arguments may be specifed:
+@var{min_addr} - ignore data below @var{min_addr} (this is w.r.t. to the target's load address + @var{address})
+@var{max_length} - maximum number of bytes to load.
+@example
+proc load_image_bin @{fname foffset address length @} @{
+ # Load data from fname filename at foffset offset to
+ # target at address. Load at most length bytes.
+ load_image $fname [expr $address - $foffset] bin $address $length
+@}
+@end example
@end deffn
@deffn Command {test_image} filename [address [@option{bin}|@option{ihex}|@option{elf}]]
mini-IC is marked valid, which makes the CPU fetch all exception
handlers from the mini-IC, ignoring the code in RAM.
-OpenOCD currently does not sync the mini-IC entries with the RAM
-contents (which would fail anyway while the target is running), so
-the user must provide appropriate values using the @code{xscale
-vector_table} command.
+To address this situation, OpenOCD provides the @code{xscale
+vector_table} command, which allows the user to explicity write
+individual entries to either the high or low vector table stored in
+the mini-IC.
It is recommended to place a pc-relative indirect branch in the vector
table, and put the branch destination somewhere in memory. Doing so
.long real_fiq_handler
@end example
+Alternatively, you may choose to keep some or all of the mini-IC
+vector table entries synced with those written to memory by your
+system software. The mini-IC can not be modified while the processor
+is executing, but for each vector table entry not previously defined
+using the @code{xscale vector_table} command, OpenOCD will copy the
+value from memory to the mini-IC every time execution resumes from a
+halt. This is done for both high and low vector tables (although the
+table not in use may not be mapped to valid memory, and in this case
+that copy operation will silently fail). This means that you will
+need to briefly halt execution at some strategic point during system
+start-up; e.g., after the software has initialized the vector table,
+but before exceptions are enabled. A breakpoint can be used to
+accomplish this once the appropriate location in the start-up code has
+been identified. A watchpoint over the vector table region is helpful
+in finding the location if you're not sure. Note that the same
+situation exists any time the vector table is modified by the system
+software.
+
The debug handler must be placed somewhere in the address space using
the @code{xscale debug_handler} command. The allowed locations for the
debug handler are either (0x800 - 0x1fef800) or (0xfe000800 -
0xfffff800). The default value is 0xfe000800.
+XScale has resources to support two hardware breakpoints and two
+watchpoints. However, the following restrictions on watchpoint
+functionality apply: (1) the value and mask arguments to the @code{wp}
+command are not supported, (2) the watchpoint length must be a
+power of two and not less than four, and can not be greater than the
+watchpoint address, and (3) a watchpoint with a length greater than
+four consumes all the watchpoint hardware resources. This means that
+at any one time, you can have enabled either two watchpoints with a
+length of four, or one watchpoint with a length greater than four.
These commands are available to XScale based CPUs,
which are implementations of the ARMv5TE architecture.
This finishes by listing the current vector catch configuration.
@end deffn
+@deffn Command {cortex_m3 reset_config} (@option{srst}|@option{sysresetreq}|@option{vectreset})
+Control reset handling. The default @option{srst} is to use srst if fitted,
+otherwise fallback to @option{vectreset}.
+@itemize @minus
+@item @option{srst} use hardware srst if fitted otherwise fallback to @option{vectreset}.
+@item @option{sysresetreq} use NVIC SYSRESETREQ to reset system.
+@item @option{vectreset} use NVIC VECTRESET to reset system.
+@end itemize
+Using @option{vectreset} is a safe option for all current Cortex-M3 cores.
+This however has the disadvantage of only resetting the core, all peripherals
+are uneffected. A solution would be to use a @code{reset-init} event handler to manually reset
+the peripherals.
+@xref{Target Events}.
+@end deffn
+
@anchor{Software Debug Messages and Tracing}
@section Software Debug Messages and Tracing
@cindex Linux-ARM DCC support
@item
A pipe connection is typically started as follows:
@example
-target remote | openocd --pipe
+target remote | openocd -c "gdb_port pipe; log_output openocd.log"
@end example
This would cause GDB to run OpenOCD and communicate using pipes (stdin/stdout).
Using this method has the advantage of GDB starting/stopping OpenOCD for the debug
-session.
+session. log_output sends the log output to a file to ensure that the pipe is
+not saturated when using higher debug level outputs.
@end enumerate
To list the available OpenOCD commands type @command{monitor help} on the
is the low level API upon which @command{flash banks} is implemented.
@itemize @bullet
-@item @b{ocd_mem2array} <@var{varname}> <@var{width}> <@var{addr}> <@var{nelems}>
+@item @b{mem2array} <@var{varname}> <@var{width}> <@var{addr}> <@var{nelems}>
Read memory and return as a Tcl array for script processing
-@item @b{ocd_array2mem} <@var{varname}> <@var{width}> <@var{addr}> <@var{nelems}>
+@item @b{array2mem} <@var{varname}> <@var{width}> <@var{addr}> <@var{nelems}>
Convert a Tcl array to memory locations and write the values
@item @b{ocd_flash_banks} <@var{driver}> <@var{base}> <@var{size}> <@var{chip_width}> <@var{bus_width}> <@var{target}> [@option{driver options} ...]
@item @b{LPC2000 Flash} In the configuration file in the section where flash device configurations
are described, there is a parameter for specifying the clock frequency
-for LPC2000 internal flash devices (e.g. @option{flash bank lpc2000
-0x0 0x40000 0 0 0 lpc2000_v1 14746 calc_checksum}), which must be
+for LPC2000 internal flash devices (e.g. @option{flash bank $_FLASHNAME lpc2000
+0x0 0x40000 0 0 $_TARGETNAME lpc2000_v1 14746 calc_checksum}), which must be
specified in kilohertz. However, I do have a quartz crystal of a
frequency that contains fractions of kilohertz (e.g. 14,745,600 Hz,
i.e. 14,745.600 kHz). Is it possible to specify real numbers for the
projects / openocd / blobdiff