@menu
* About:: About OpenOCD
* Developers:: OpenOCD Developers
-* Building OpenOCD:: Building OpenOCD From SVN
* JTAG Hardware Dongles:: JTAG Hardware Dongles
* About JIM-Tcl:: About JIM-Tcl
* Running:: Running OpenOCD
@b{Flash Programing:} Flash writing is supported for external CFI
compatible NOR flashes (Intel and AMD/Spansion command set) and several
-internal flashes (LPC2000, AT91SAM7, AT91SAM3U, STR7x, STR9x, LM3, and
+internal flashes (LPC1700, LPC2000, AT91SAM7, AT91SAM3U, STR7x, STR9x, LM3, and
STM32x). Preliminary support for various NAND flash controllers
(LPC3180, Orion, S3C24xx, more) controller is included.
@section OpenOCD Subversion Repository
-The ``Building From Source'' section provides instructions to retrieve
-and and build the latest version of the OpenOCD source code.
-@xref{Building OpenOCD}.
+You can download the current SVN version with an SVN client of your
+choice from the following repositories:
+
+ @uref{svn://svn.berlios.de/openocd/trunk}
+
+or
+
+ @uref{http://svn.berlios.de/svnroot/repos/openocd/trunk}
+
+Using the SVN command line client, you can use the following command to
+fetch the latest version (make sure there is no (non-svn) directory
+called "openocd" in the current directory):
+
+ svn checkout svn://svn.berlios.de/openocd/trunk openocd
+
+If you prefer GIT based tools, the @command{git-svn} package works too:
+
+ git svn clone -s svn://svn.berlios.de/openocd
+
+The ``README'' file contains the instructions for building the project
+from the repository.
Developers that want to contribute patches to the OpenOCD system are
@b{strongly} encouraged to base their work off of the most recent trunk
@uref{https://lists.berlios.de/mailman/listinfo/openocd-svn}
-@node Building OpenOCD
-@chapter Building OpenOCD
-@cindex building
-
-@section Pre-Built Tools
-If you are interested in getting actual work done rather than building
-OpenOCD, then check if your interface supplier provides binaries for
-you. Chances are that that binary is from some SVN version that is more
-stable than SVN trunk where bleeding edge development takes place.
-
-@section Packagers Please Read!
-
-You are a @b{PACKAGER} of OpenOCD if you
-
-@enumerate
-@item @b{Sell dongles} and include pre-built binaries
-@item @b{Supply tools} i.e.: A complete development solution
-@item @b{Supply IDEs} like Eclipse, or RHIDE, etc.
-@item @b{Build packages} i.e.: RPM files, or DEB files for a Linux Distro
-@end enumerate
-
-As a @b{PACKAGER}, you will experience first reports of most issues.
-When you fix those problems for your users, your solution may help
-prevent hundreds (if not thousands) of other questions from other users.
-
-If something does not work for you, please work to inform the OpenOCD
-developers know how to improve the system or documentation to avoid
-future problems, and follow-up to help us ensure the issue will be fully
-resolved in our future releases.
-
-That said, the OpenOCD developers would also like you to follow a few
-suggestions:
-
-@enumerate
-@item Send patches, including config files, upstream.
-@item Always build with printer ports enabled.
-@item Use libftdi + libusb for FT2232 support.
-@end enumerate
-
-@section Building From Source
-
-You can download the current SVN version with an SVN client of your choice from the
-following repositories:
-
- @uref{svn://svn.berlios.de/openocd/trunk}
-
-or
-
- @uref{http://svn.berlios.de/svnroot/repos/openocd/trunk}
-
-Using the SVN command line client, you can use the following command to fetch the
-latest version (make sure there is no (non-svn) directory called "openocd" in the
-current directory):
-
-@example
- svn checkout svn://svn.berlios.de/openocd/trunk openocd
-@end example
-
-If you prefer GIT based tools, the @command{git-svn} package works too:
-
-@example
- git svn clone -s svn://svn.berlios.de/openocd
-@end example
-
-Building OpenOCD from a repository requires a recent version of the
-GNU autotools (autoconf >= 2.59 and automake >= 1.9).
-For building on Windows,
-you have to use Cygwin. Make sure that your @env{PATH} environment variable contains no
-other locations with Unix utils (like UnxUtils) - these can't handle the Cygwin
-paths, resulting in obscure dependency errors (This is an observation I've gathered
-from the logs of one user - correct me if I'm wrong).
-
-You further need the appropriate driver files, if you want to build support for
-a FTDI FT2232 based interface:
-
-@itemize @bullet
-@item @b{ftdi2232} libftdi (@uref{http://www.intra2net.com/opensource/ftdi/})
-@item @b{ftd2xx} libftd2xx (@uref{http://www.ftdichip.com/Drivers/D2XX.htm}),
-or the Amontec version (from @uref{http://www.amontec.com}),
-for easier support of JTAGkey's vendor and product IDs.
-@end itemize
-
-libftdi is supported under Windows. Do not use versions earlier than 0.14.
-To use the newer FT2232H chips, supporting RTCK and USB high speed (480 Mbps),
-you need libftdi version 0.16 or newer.
-
-Some people say that FTDI's libftd2xx code provides better performance.
-However, it is binary-only, while OpenOCD is licenced according
-to GNU GPLv2 without any exceptions.
-That means that @emph{distributing} copies of OpenOCD built with
-the FTDI code would violate the OpenOCD licensing terms.
-You may, however, build such copies for personal use.
-
-To build OpenOCD (on both Linux and Cygwin), use the following commands:
-
-@example
- ./bootstrap
-@end example
-
-Bootstrap generates the configure script, and prepares building on your system.
-
-@example
- ./configure [options, see below]
-@end example
-
-Configure generates the Makefiles used to build OpenOCD.
-
-@example
- make
- make install
-@end example
-
-Make builds OpenOCD, and places the final executable in ./src/, the last step, ``make install'' is optional.
-
-The configure script takes several options, specifying which JTAG interfaces
-should be included (among other things):
-
-@itemize @bullet
-@item
-@option{--enable-parport} - Enable building the PC parallel port driver.
-@item
-@option{--enable-parport_ppdev} - Enable use of ppdev (/dev/parportN) for parport.
-@item
-@option{--enable-parport_giveio} - Enable use of giveio for parport instead of ioperm.
-@item
-@option{--enable-amtjtagaccel} - Enable building the Amontec JTAG-Accelerator driver.
-@item
-@option{--enable-ecosboard} - Enable building support for eCosBoard based JTAG debugger.
-@item
-@option{--enable-ioutil} - Enable ioutil functions - useful for standalone OpenOCD implementations.
-@item
-@option{--enable-httpd} - Enable builtin httpd server - useful for standalone OpenOCD implementations.
-@item
-@option{--enable-ep93xx} - Enable building support for EP93xx based SBCs.
-@item
-@option{--enable-at91rm9200} - Enable building support for AT91RM9200 based SBCs.
-@item
-@option{--enable-gw16012} - Enable building support for the Gateworks GW16012 JTAG programmer.
-@item
-@option{--enable-ft2232_ftd2xx} - Support FT2232-family chips using
-the closed-source library from FTDICHIP.COM
-(result not for re-distribution).
-@item
-@option{--enable-ft2232_libftdi} - Support FT2232-family chips using
-a GPL'd ft2232 support library (result OK for re-distribution).
-@item
-@option{--with-ftd2xx-win32-zipdir=PATH} - If using FTDICHIP.COM ft2232c driver,
-give the directory where the Win32 FTDICHIP.COM 'CDM' driver zip file was unpacked.
-@item
-@option{--with-ftd2xx-linux-tardir=PATH} - If using FTDICHIP.COM ft2232c driver
-on Linux, give the directory where the Linux driver's TAR.GZ file was unpacked.
-@item
-@option{--with-ftd2xx-lib=shared|static} - Linux only. Default: static.
-Specifies how the FTDICHIP.COM libftd2xx driver should be linked.
-Note: 'static' only works in conjunction with @option{--with-ftd2xx-linux-tardir}.
-The 'shared' value is supported, however you must manually install the required
-header files and shared libraries in an appropriate place.
-@item
-@option{--enable-presto_libftdi} - Enable building support for ASIX Presto programmer using the libftdi driver.
-@item
-@option{--enable-presto_ftd2xx} - Enable building support for ASIX Presto programmer using the FTD2XX driver.
-@item
-@option{--enable-usbprog} - Enable building support for the USBprog JTAG programmer.
-@item
-@option{--enable-oocd_trace} - Enable building support for the OpenOCD+trace ETM capture device.
-@item
-@option{--enable-jlink} - Enable building support for the Segger J-Link JTAG programmer.
-@item
-@option{--enable-vsllink} - Enable building support for the Versaloon-Link JTAG programmer.
-@item
-@option{--enable-rlink} - Enable building support for the Raisonance RLink JTAG programmer.
-@item
-@option{--enable-arm-jtag-ew} - Enable building support for the Olimex ARM-JTAG-EW programmer.
-@item
-@option{--enable-dummy} - Enable building the dummy port driver.
-@end itemize
-
-@section Parallel Port Dongles
-
-If you want to access the parallel port using the PPDEV interface you have to specify
-both the @option{--enable-parport} AND the @option{--enable-parport_ppdev} option since
-the @option{--enable-parport_ppdev} option actually is an option to the parport driver
-(see @uref{http://forum.sparkfun.com/viewtopic.php?t=3795} for more info).
-
-The same is true for the @option{--enable-parport_giveio} option, you have to
-use both the @option{--enable-parport} AND the @option{--enable-parport_giveio} option if you want to use giveio instead of ioperm parallel port access method.
-
-@section FT2232C Based USB Dongles
-
-There are 2 methods of using the FTD2232, either (1) using the
-FTDICHIP.COM closed source driver, or (2) the open (and free) driver
-libftdi. Some claim the (closed) FTDICHIP.COM solution is faster,
-which is the motivation for supporting it even though its licensing
-restricts it to non-redistributable OpenOCD binaries, and it is
-not available for all operating systems used with OpenOCD.
-
-The FTDICHIP drivers come as either a (win32) ZIP file, or a (Linux)
-TAR.GZ file. You must unpack them ``some where'' convient. As of this
-writing FTDICHIP does not supply means to install these
-files ``in an appropriate place''.
-As a result, there are two
-``./configure'' options that help.
-
-Below is an example build process:
-
-@enumerate
-@item Check out the latest version of ``openocd'' from SVN.
-
-@item If you are using the FTDICHIP.COM driver, download
-and unpack the Windows or Linux FTD2xx drivers
-(@uref{http://www.ftdichip.com/Drivers/D2XX.htm}).
-If you are using the libftdi driver, install that package
-(e.g. @command{apt-get install libftdi} on systems with APT).
-
-@example
-/home/duane/ftd2xx.win32 => the Cygwin/Win32 ZIP file contents
-/home/duane/libftd2xx0.4.16 => the Linux TAR.GZ file contents
-@end example
-
-@item Configure with options resembling the following.
-
-@enumerate a
-@item Cygwin FTDICHIP solution:
-@example
-./configure --prefix=/home/duane/mytools \
- --enable-ft2232_ftd2xx \
- --with-ftd2xx-win32-zipdir=/home/duane/ftd2xx.win32
-@end example
-
-@item Linux FTDICHIP solution:
-@example
-./configure --prefix=/home/duane/mytools \
- --enable-ft2232_ftd2xx \
- --with-ft2xx-linux-tardir=/home/duane/libftd2xx0.4.16
-@end example
-
-@item Cygwin/Linux LIBFTDI solution ... assuming that
-@itemize
-@item For Windows -- that the Windows port of LIBUSB is in place.
-@item For Linux -- that libusb has been built/installed and is in place.
-@item That libftdi has been built and installed (relies on libusb).
-@end itemize
-
-Then configure the libftdi solution like this:
-
-@example
-./configure --prefix=/home/duane/mytools \
- --enable-ft2232_libftdi
-@end example
-@end enumerate
-
-@item Then just type ``make'', and perhaps ``make install''.
-@end enumerate
-
-
-@section Miscellaneous Configure Options
-
-@itemize @bullet
-@item
-@option{--disable-option-checking} - Ignore unrecognized @option{--enable} and @option{--with} options.
-@item
-@option{--enable-gccwarnings} - Enable extra gcc warnings during build.
-Default is enabled.
-@item
-@option{--enable-release} - Enable building of an OpenOCD release, generally
-this is for developers. It simply omits the svn version string when the
-openocd @option{-v} is executed.
-@end itemize
-
@node JTAG Hardware Dongles
@chapter JTAG Hardware Dongles
@cindex dongles
@* Link @url{http://www.hs-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html}
@item @b{jtagkey}
@* See: @url{http://www.amontec.com/jtagkey.shtml}
+@item @b{jtagkey2}
+@* See: @url{http://www.amontec.com/jtagkey2.shtml}
@item @b{oocdlink}
@* See: @url{http://www.oocdlink.com} By Joern Kaipf
@item @b{signalyzer}
@* See: @url{http://www.signalyzer.com}
@item @b{evb_lm3s811}
@* See: @url{http://www.luminarymicro.com} - The Stellaris LM3S811 eval board has an FTD2232C chip built in.
+@item @b{luminary_icdi}
+@* See: @url{http://www.luminarymicro.com} - Luminary In-Circuit Debug Interface (ICDI) Board, included in the Stellaris LM3S9B90 and LM3S9B92 Evaluation Kits.
@item @b{olimex-jtag}
@* See: @url{http://www.olimex.com}
@item @b{flyswatter}
@item @b{Commands}
@* At the OpenOCD telnet command line (or via the GDB mon 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.
@item @b{Historical Note}
@* JIM-Tcl was introduced to OpenOCD in spring 2008.
@item
You may may need to write some C code.
-It may be as simple as a supporting a new new ft2232 or parport
+It may be as simple as a supporting a new ft2232 or parport
based dongle; a bit more involved, like a NAND or NOR flash
controller driver; or a big piece of work like supporting
a new chip architecture.
When you write config files, separate the reusable parts
(things every user of that interface, chip, or board needs)
from ones specific to your environment and debugging approach.
+@itemize
+@item
For example, a @code{gdb-attach} event handler that invokes
the @command{reset init} command will interfere with debugging
early boot code, which performs some of the same actions
that the @code{reset-init} event handler does.
+
+@item
Likewise, the @command{arm9tdmi vector_catch} command (or
-its @command{xscale vector_catch} sibling) can be a timesaver
+@cindex vector_catch
+its siblings @command{xscale vector_catch}
+and @command{cortex_m3 vector_catch}) can be a timesaver
during some debug sessions, but don't make everyone use that either.
Keep those kinds of debugging aids in your user config file,
along with messaging and tracing setup.
(@xref{Software Debug Messages and Tracing}.)
+@item
+You might need to override some defaults.
+For example, you might need to move, shrink, or back up the target's
+work area if your application needs much SRAM.
+
+@item
TCP/IP port configuration is another example of something which
is environment-specific, and should only appear in
a user config file. @xref{TCP/IP Ports}.
+@end itemize
@section Project-Specific Utilities
@section Configuration Stage
@cindex configuration stage
-@cindex configuration command
+@cindex config command
When the OpenOCD server process starts up, it enters a
@emph{configuration stage} which is the only time that
certain commands, @emph{configuration commands}, may be issued.
-Those configuration commands include declaration of TAPs
+In this manual, the definition of a configuration command is
+presented as a @emph{Config Command}, not as a @emph{Command}
+which may be issued interactively.
+
+Those configuration commands include declaration of TAPs,
+flash banks,
+the interface used for JTAG communication,
and other basic setup.
The server must leave the configuration stage before it
may access or activate TAPs.
breakpoints if the memory map has been set up for flash regions.
@end deffn
-@deffn {Config command} gdb_detach (@option{resume}|@option{reset}|@option{halt}|@option{nothing})
+@deffn {Config Command} gdb_detach (@option{resume}|@option{reset}|@option{halt}|@option{nothing})
Configures what OpenOCD will do when GDB detaches from the daemon.
Default behaviour is @option{resume}.
@end deffn
@anchor{gdb_flash_program}
-@deffn {Config command} gdb_flash_program (@option{enable}|@option{disable})
+@deffn {Config Command} gdb_flash_program (@option{enable}|@option{disable})
Set to @option{enable} to cause OpenOCD to program the flash memory when a
vFlash packet is received.
The default behaviour is @option{enable}.
@end deffn
-@deffn {Config command} gdb_memory_map (@option{enable}|@option{disable})
+@deffn {Config Command} gdb_memory_map (@option{enable}|@option{disable})
Set to @option{enable} to cause OpenOCD to send the memory configuration to GDB when
requested. GDB will then know when to set hardware breakpoints, and program flash
using the GDB load command. @command{gdb_flash_program enable} must also be enabled
@xref{gdb_flash_program}.
@end deffn
-@deffn {Config command} gdb_report_data_abort (@option{enable}|@option{disable})
+@deffn {Config Command} gdb_report_data_abort (@option{enable}|@option{disable})
Specifies whether data aborts cause an error to be reported
by GDB memory read packets.
The default behaviour is @option{disable};
in case the vendor provides unique IDs and more than one FT2232 device
is connected to the host.
If not specified, serial numbers are not considered.
+(Note that USB serial numbers can be arbitrary Unicode strings,
+and are not restricted to containing only decimal digits.)
@end deffn
@deffn {Config Command} {ft2232_layout} name
@item @b{evb_lm3s811} Luminary Micro EVB_LM3S811 as a JTAG interface,
either for the local Cortex-M3 (SRST only)
or in a passthrough mode (neither SRST nor TRST)
+@item @b{luminary_icdi} Luminary In-Circuit Debug Interface (ICDI) Board
@item @b{flyswatter} Tin Can Tools Flyswatter
@item @b{icebear} ICEbear JTAG adapter from Section 5
@item @b{jtagkey} Amontec JTAGkey and JTAGkey-Tiny (and compatibles)
+@item @b{jtagkey2} Amontec JTAGkey2 (and compatibles)
@item @b{m5960} American Microsystems M5960
@item @b{olimex-jtag} Olimex ARM-USB-OCD and ARM-USB-Tiny
@item @b{oocdlink} OOCDLink
@defun jtag_rclk fallback_speed_kHz
@cindex RTCK
-This Tcl proc (defined in startup.tcl) attempts to enable RTCK/RCLK.
+This Tcl proc (defined in @file{startup.tcl}) attempts to enable RTCK/RCLK.
If that fails (maybe the interface, board, or target doesn't
support it), falls back to the specified frequency.
@example
@option{str912}, to support more than one chip of each type.
@xref{Config File Guidelines}.
-At this writing there is only a single command to work with
-scan chains, and there is no support for enumerating
-TAPs or examining their attributes.
+@deffn Command {jtag names}
+Returns the names of all current TAPs in the scan chain.
+Use @command{jtag cget} or @command{jtag tapisenabled}
+to examine attributes and state of each TAP.
+@example
+foreach t [jtag names] @{
+ puts [format "TAP: %s\n" $t]
+@}
+@end example
+@end deffn
@deffn Command {scan_chain}
Displays the TAPs in the scan chain configuration,
each TAP's instruction register can also change.
@end deffn
-@c FIXME! there should be commands to enumerate TAPs
-@c and get their attributes, like there are for targets.
-@c "jtag cget ..." will handle attributes.
-@c "jtag names" for enumerating TAPs, maybe.
+@c FIXME! "jtag cget" should be able to return all TAP
+@c attributes, like "$target_name cget" does for targets.
@c Probably want "jtag eventlist", and a "tap-reset" event
@c (on entry to RESET state).
In older code, JTAG TAPs were numbered from 0..N.
This feature is still present.
However its use is highly discouraged, and
-should not be counted upon.
-Update all of your scripts to use TAP names rather than numbers.
+should not be relied on; it will be removed by mid-2010.
+Update all of your scripts to use TAP names rather than numbers,
+by paying attention to the runtime warnings they trigger.
Using TAP numbers in target configuration scripts prevents
reusing those scripts on boards with multiple targets.
@end quotation
@itemize @bullet
@item @code{-ircapture} @var{NUMBER}
-@*The IDCODE capture command, such as 0x01.
+@*The bit pattern loaded by the TAP into the JTAG shift register
+on entry to the @sc{ircapture} state, such as 0x01.
+JTAG requires the two LSBs of this value to be 01.
+The value is used to verify that instruction scans work correctly.
@item @code{-irlen} @var{NUMBER}
@*The length in bits of the
instruction register, such as 4 or 5 bits.
@deffn Command {jtag cget} dotted.name @option{-event} name
@deffnx Command {jtag configure} dotted.name @option{-event} name string
-At this writing this mechanism is used only for event handling,
-and the only two events relate to TAP enabling and disabling.
+At this writing this mechanism is used only for event handling.
+Three events are available. Two events relate to TAP enabling
+and disabling, one to post reset handling.
The @code{configure} subcommand assigns an event handler,
a TCL string which is evaluated when the event is triggered.
The @code{cget} subcommand returns that handler.
-The two possible values for an event @var{name}
-are @option{tap-disable} and @option{tap-enable}.
+The three possible values for an event @var{name} are @option{tap-disable}, @option{tap-enable} and @option{post-reset}.
So for example, when defining a TAP for a CPU connected to
a JTAG router, you should define TAP event handlers using
... jtag operations using CHIP.jrc
@}
@end example
+
+If you need some post reset action, you can do:
+
+@example
+jtag configure CHIP.cpu -event post-reset @{
+ echo "Reset done"
+ ... jtag operations to be done after reset
+@}
+@end example
@end deffn
@deffn Command {jtag tapdisable} dotted.name
Several commands let you examine the list of targets:
@deffn Command {target count}
+@emph{Note: target numbers are deprecated; don't use them.
+They will be removed shortly after August 2010, including this command.
+Iterate target using @command{target names}, not by counting.}
+
Returns the number of targets, @math{N}.
The highest numbered target is @math{N - 1}.
@example
@end deffn
@deffn Command {target number} number
+@emph{Note: target numbers are deprecated; don't use them.
+They will be removed shortly after August 2010, including this command.}
+
The list of targets is numbered starting at zero.
This command returns the name of the target at index @var{number}.
@example
which OpenOCD needs to know about.
@item @code{-work-area-backup} (@option{0}|@option{1}) -- says
-whether the work area gets backed up; by default, it doesn't.
+whether the work area gets backed up; by default,
+@emph{it is not backed up.}
When possible, use a working_area that doesn't need to be backed up,
since performing a backup slows down operations.
+For example, the beginning of an SRAM block is likely to
+be used by most build systems, but the end is often unused.
@item @code{-work-area-size} @var{size} -- specify/set the work area
all the targets you might use something like this:
@example
-for @{ set x 0 @} @{ $x < [target count] @} @{ incr x @} @{
- set name [target number $x]
+foreach name [target names] @{
set y [$name cget -endian]
set z [$name cget -type]
puts [format "Chip %d is %s, Endian: %s, type: %s" \
@subsection Internal Flash (Microcontrollers)
@deffn {Flash Driver} aduc702x
-The ADUC702x analog microcontrollers from ST Micro
+The ADUC702x analog microcontrollers from Analog Devices
include internal flash and use ARM7TDMI cores.
The aduc702x flash driver works with models ADUC7019 through ADUC7028.
The setup command only requires the @var{target} argument
readers/updaters: Please remove this worrysome comment after other
chips are confirmed.}
-The AT91SAM3U4[E/C] (256K) chips have 2 flash banks, the other chips
-(3U[1/2][E/C]) have 1 flash bank. In all cases the flash banks are at
+The AT91SAM3U4[E/C] (256K) chips have two flash banks; most other chips
+have one flash bank. In all cases the flash banks are at
the following fixed locations:
@example
@end deffn
@deffn {Flash Driver} lpc2000
-Most members of the LPC2000 microcontroller family from NXP
-include internal flash and use ARM7TDMI cores.
+Most members of the LPC1700 and LPC2000 microcontroller families from NXP
+include internal flash and use Cortex-M3 (LPC1700) or ARM7TDMI (LPC2000) cores.
The @var{lpc2000} driver defines two mandatory and one optional parameters,
which must appear in the following order:
@itemize
@item @var{variant} ... required, may be
@var{lpc2000_v1} (older LPC21xx and LPC22xx)
-or @var{lpc2000_v2} (LPC213x, LPC214x, LPC210[123], LPC23xx and LPC24xx)
+@var{lpc2000_v2} (LPC213x, LPC214x, LPC210[123], LPC23xx and LPC24xx)
+or @var{lpc1700} (LPC175x and LPC176x)
@item @var{clock_kHz} ... the frequency, in kiloHertz,
at which the core is running
@item @var{calc_checksum} ... optional (but you probably want to provide this!),
Exits the current telnet session.
@end deffn
+@c note EXTREMELY ANNOYING word wrap at column 75
+@c even when lines are e.g. 100+ columns ...
+@c coded in startup.tcl
+@deffn {Command} help [string]
+With no parameters, prints help text for all commands.
+Otherwise, prints each helptext containing @var{string}.
+Not every command provides helptext.
+@end deffn
+
@deffn Command sleep msec [@option{busy}]
Wait for at least @var{msec} milliseconds before resuming.
If @option{busy} is passed, busy-wait instead of sleeping.
that is not currently supported in OpenOCD.)
@end deffn
-@deffn Command {armv4_5 disassemble} address count [thumb]
+@deffn Command {armv4_5 disassemble} address [count [@option{thumb}]]
@cindex disassemble
Disassembles @var{count} instructions starting at @var{address}.
-If @option{thumb} is specified, Thumb (16-bit) instructions are used;
+If @var{count} is not specified, a single instruction is disassembled.
+If @option{thumb} is specified, or the low bit of the address is set,
+Thumb (16-bit) instructions are used;
else ARM (32-bit) instructions are used.
(Processors may also support the Jazelle state, but
those instructions are not currently understood by OpenOCD.)
Control use of the EmbeddedIce DBGRQ signal to force entry into debug mode,
instead of breakpoints. This should be
safe for all but ARM7TDMI--S cores (like Philips LPC).
+This feature is enabled by default on most ARM9 cores,
+including ARM9TDMI, ARM920T, and ARM926EJ-S.
@end deffn
@deffn Command {arm7_9 dcc_downloads} (@option{enable}|@option{disable})
@anchor{arm9tdmi vector_catch}
@deffn Command {arm9tdmi vector_catch} [@option{all}|@option{none}|list]
+@cindex vector_catch
Vector Catch hardware provides a sort of dedicated breakpoint
for hardware events such as reset, interrupt, and abort.
You can use this to conserve normal breakpoint resources,
@subsection XScale specific commands
@cindex XScale
+Some notes about the debug implementation on the XScale CPUs:
+
+The XScale CPU provides a special debug-only mini-instruction cache
+(mini-IC) in which exception vectors and target-resident debug handler
+code are placed by OpenOCD. In order to get access to the CPU, OpenOCD
+must point vector 0 (the reset vector) to the entry of the debug
+handler. However, this means that the complete first cacheline in the
+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.
+
+It is recommended to place a pc-relative indirect branch in the vector
+table, and put the branch destination somewhere in memory. Doing so
+makes sure the code in the vector table stays constant regardless of
+code layout in memory:
+@example
+_vectors:
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ ldr pc,[pc,#0x100-8]
+ .org 0x100
+ .long real_reset_vector
+ .long real_ui_handler
+ .long real_swi_handler
+ .long real_pf_abort
+ .long real_data_abort
+ .long 0 /* unused */
+ .long real_irq_handler
+ .long real_fiq_handler
+@end example
+
+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.
+
+
These commands are available to XScale based CPUs,
which are implementations of the ARMv5TE architecture.
@anchor{xscale vector_catch}
@deffn Command {xscale vector_catch} [mask]
+@cindex vector_catch
Display a bitmask showing the hardware vectors to catch.
If the optional parameter is provided, first set the bitmask to that value.
+
+The mask bits correspond with bit 16..23 in the DCSR:
+@example
+0x01 Trap Reset
+0x02 Trap Undefined Instructions
+0x04 Trap Software Interrupt
+0x08 Trap Prefetch Abort
+0x10 Trap Data Abort
+0x20 reserved
+0x40 Trap IRQ
+0x80 Trap FIQ
+@end example
+@end deffn
+
+@anchor{xscale vector_table}
+@deffn Command {xscale vector_table} [<low|high> <index> <value>]
+@cindex vector_table
+
+Set an entry in the mini-IC vector table. There are two tables: one for
+low vectors (at 0x00000000), and one for high vectors (0xFFFF0000), each
+holding the 8 exception vectors. @var{index} can be 1-7, because vector 0
+points to the debug handler entry and can not be overwritten.
+@var{value} holds the 32-bit opcode that is placed in the mini-IC.
+
+Without arguments, the current settings are displayed.
+
@end deffn
@section ARMv6 Architecture
@subsection ARM11 specific commands
@cindex ARM11
-@deffn Command {arm11 mcr} p1 p2 p3 p4 p5
-Read coprocessor register
+@deffn Command {arm11 mcr} pX opc1 CRn CRm opc2 value
+Write @var{value} to a coprocessor @var{pX} register
+passing parameters @var{CRn},
+@var{CRm}, opcodes @var{opc1} and @var{opc2},
+and the MCR instruction.
+(The difference beween this and the MCR2 instruction is
+one bit in the encoding, effecively a fifth parameter.)
@end deffn
@deffn Command {arm11 memwrite burst} [value]
If @var{value} is defined, first assigns that.
@end deffn
-@deffn Command {arm11 mrc} p1 p2 p3 p4 p5 value
-Write coprocessor register
+@deffn Command {arm11 mrc} pX opc1 CRn CRm opc2
+Read a coprocessor @var{pX} register passing parameters @var{CRn},
+@var{CRm}, opcodes @var{opc1} and @var{opc2},
+and the MRC instruction.
+(The difference beween this and the MRC2 instruction is
+one bit in the encoding, effecively a fifth parameter.)
+Displays the result.
@end deffn
@deffn Command {arm11 no_increment} [value]
If @var{value} is defined, first assigns that.
@end deffn
+@subsection ARMv7-A specific commands
+@cindex ARMv7-A
+
+@deffn Command {armv7a disassemble} address [count [@option{thumb}]]
+@cindex disassemble
+Disassembles @var{count} instructions starting at @var{address}.
+If @var{count} is not specified, a single instruction is disassembled.
+If @option{thumb} is specified, or the low bit of the address is set,
+Thumb2 (mixed 16/32-bit) instructions are used;
+else ARM (32-bit) instructions are used.
+With a handful of exceptions, ThumbEE instructions are the same as Thumb2;
+ThumbEE disassembly currently has no explicit support.
+(Processors may also support the Jazelle state, but
+those instructions are not currently understood by OpenOCD.)
+@end deffn
+
+
@subsection Cortex-M3 specific commands
@cindex Cortex-M3
+@deffn Command {cortex_m3 disassemble} address [count]
+@cindex disassemble
+Disassembles @var{count} Thumb2 instructions starting at @var{address}.
+If @var{count} is not specified, a single instruction is disassembled.
+@end deffn
+
@deffn Command {cortex_m3 maskisr} (@option{on}|@option{off})
Control masking (disabling) interrupts during target step/resume.
@end deffn
+@deffn Command {cortex_m3 vector_catch} [@option{all}|@option{none}|list]
+@cindex vector_catch
+Vector Catch hardware provides dedicated breakpoints
+for certain hardware events.
+
+Parameters request interception of
+@option{all} of these hardware event vectors,
+@option{none} of them,
+or one or more of the following:
+@option{hard_err} for a HardFault exception;
+@option{mm_err} for a MemManage exception;
+@option{bus_err} for a BusFault exception;
+@option{irq_err},
+@option{state_err},
+@option{chk_err}, or
+@option{nocp_err} for various UsageFault exceptions; or
+@option{reset}.
+If NVIC setup code does not enable them,
+MemManage, BusFault, and UsageFault exceptions
+are mapped to HardFault.
+UsageFault checks for
+divide-by-zero and unaligned access
+must also be explicitly enabled.
+
+This finishes by listing the current vector catch configuration.
+@end deffn
+
@anchor{Software Debug Messages and Tracing}
@section Software Debug Messages and Tracing
@cindex Linux-ARM DCC support
@end itemize
OpenOCD commands can consist of two words, e.g. "flash banks". The
-startup.tcl "unknown" proc will translate this into a Tcl proc
+@file{startup.tcl} "unknown" proc will translate this into a Tcl proc
called "flash_banks".
@section OpenOCD specific Global Variables
time. One can set a break point or halt the system in the deep power
down code, slow step out until the system speeds up.
+Note that adaptive clocking may also need to work at the board level,
+when a board-level scan chain has multiple chips.
+Parallel clock voting schemes are good way to implement this,
+both within and between chips, and can easily be implemented
+with a CPLD.
+It's not difficult to have logic fan a module's input TCK signal out
+to each TAP in the scan chain, and then wait until each TAP's RTCK comes
+back with the right polarity before changing the output RTCK signal.
+Texas Instruments makes some clock voting logic available
+for free (with no support) in VHDL form; see
+@url{http://tiexpressdsp.com/index.php/Adaptive_Clocking}
+
@b{Solution #2 - Always works - but may be slower}
Often this is a perfectly acceptable solution.
Code Review / openocd.git / blobdiff