Nicolas Pitre listed some more devices.

git-svn-id: svn://svn.berlios.de/openocd/trunk@356 b42882b7-edfa-0310-969c-e2dbd0fdcd60

2 files changed, 2044 insertions, 2040 deletions

diff --git a/README b/README
index 3c93424e..4e790117 100644
--- a/README
+++ b/README
@@ -1,129 +1,132 @@
-                                    OpenOCD
-
-			 Free and Open On-Chip Debugging, In-System Programming 
-						   and Boundary-Scan Testing
-				  Copyright (c) 2004-2007 Dominic Rath
-
-The debugger uses an IEEE 1149-1 compliant JTAG TAP bus master to access on-chip
-debug functionality available on ARM7 and ARM9 based microcontrollers /
-system-on-chip solutions.
-
-User interaction is realized through a telnet command line interface and a gdb
-(The GNU Debugger) remote protocol server.
-
-1. JTAG hardware
-
-Currently, OpenOCD supports the following JTAG interfaces:
-
-- Parallel port wigglers. These devices connect to a PC's parallel port,
-providing direct access to the JTAG lines. The OpenOCD contains descriptions
-of a few Wiggler layouts, including the original 'Wiggler' design. Other
-layouts (i.e. mapping of parallel port pins to JTAG lines) can be added easily.
-Typical Wiggler speeds are around 12kByte/s code download to an ARM7's RAM.
-
-The list of supported parallel port devices includes:
-
-  * Macraigor Wiggler JTAG cable
-  * Gateworks GW16012 JTAG programmer
-  * Xilinx DLC5 JTAG parallel cable III
-  * Ka-Ro TRITON starterkit II JTAG cable
-  * Lattice parallel port JTAG cable
-  * ST FlashLINK programming cable
-
-- The Amontec JTAG Accelerator. This is a configuration for Amontec's Chameleon
-dongle, a parallel port interface based on a Xilinx CoolRunner CPLD. It uses
-the IEEE1284 EPP parallel port specification, providing many times the
-performance achievable with wiggler-style devices. Additional information is
-available on www.amontec.com.
-Typical JTAG Accelerator speeds are around 120-160kByte/s to an ARM7's RAM.
-
-- FTDI FT2232 based USB devices. The FT2232 (but not FT232 or FT245) features a
-multi-protocol synchronous serial engine (MPSSE) that can be used to run the
-serial JTAG protocol. There are several implemenations of FT2232 based devices:
-
-* USBJTAG: http://www.fh-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html
-The USBJTAG was designed by Prof. Hubert Hoegl to provide a high-speed USB
-interface for use with the OpenOCD. Schematics are available at the USBJTAG
-website, and a homebrew device can easily be built using the FTDI evaluation
-module DLP2232M.
-
-* OOCD-Link: http://www.joernonline.de/dw/doku.php?id=en:projects:oocdlink
-Similar to the USBJTAG, this design comes with free schematics, too.
-
-* Amontec JTAGkey: www.amontec.com
-The Amontec JTAGkey offers support for a wide variety of target voltages from
-1.4V to 5V. It also allows the JTAG lines and reset signals to be tri-stated,
-allowing easy interfacing with a wide variety of targets.
-
-* Amontec JTAGkey-Tiny: www.amontec.com
-The Amontec JTAGkey offers support for a wide variety of target voltages from
-2.8V to 5V. It also allows the reset signals to be tri-stated, allowing easy
-interfacing with a wide variety of targets.
-
-* Olimex ARM-USB-OCD: www.olimex.com
-The Olimex ARM-USB-OCD offers support for a wide vriety of target voltages from
-2.0V to 5V. It also allows targets to be powered from the ARM-USB-OCD and
-features and additional RS232 UART.
-
-* eVerve Signalyzer: www.signalyzer.com
-The Signalyzer offers support for a wide variety of target voltages from 1.2V to
-5.5V. A second connector provides access to a TTL level UART.
-
-* TinCanTools 'Flyswatter' USB JTAG programmer.
-
-* Turtelizer 2: http://www.ethernut.de/en/hardware/turtelizer/index.html
-Another USB JTAG programmer, with freely available schematics. It supports
-target voltages from 1.65V to 5.5V.
-
-* Hitex STR9-comSTICK: http://www.ehitex.de/p_info.php?products_id=292
-A STR912FW44x microcontroller "board" with USB and JTAG functionality.
-
-* Luminary Micro development board evb_lm3s811 JTAG interface.
-
-* ASIX PRESTO: http://www.asix-tools.com/prg_presto.htm
-The ASIX PRESTO is a USB JTAG programmer for a wide range of components, e.g.
-microcontrollers, serial EEPROM and Flash memory chips, CPLDs and others.
-
-* usbprog: http://www.embedded-projects.net/index.php?page_id=165
-The usbprog is a freely programmable USB adapter, which can (among other
-things) use a firmware which turns it into a JTAG programmer/debugger.
-
-All FT2232 based devices may be accessed using either FTDI's proprietary FTD2XX
-library (www.ftdichip.com) or using an open-source replacement from
-http://www.intra2net.com/de/produkte/opensource/ftdi/index.php, also included
-with many Linux distributions.
-
-2. Supported cores
-
-This version of openocd supports the following ARM7/9 cores:
-
-- ARM7TDMI(-s)
-- ARM9TDMI
-- ARM920t
-- ARM922t
-- ARM926ej-s
-- ARM966e
-- Cortex-M3
-
-Support for Intel XScale CPUs is also included:
-
-- PXA25x
-- PXA27x
-- IXP42x
-
-3. Host platforms
-
-OpenOCD was originally developed on x86-Linux, but has since then been ported
-to run on Windows/Cygwin, native Windows with MinGW, FreeBSD, IA64-Linux,
-AMD64-Linux, Alpha-Linux, ARM-Linux, and PowerPC OS-X.
-
-4. Documentation
-
-Documentation for the OpenOCD is hosted in the Berlios OpenFacts Wiki at
-http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger.
-
-5. Licensing
-
-OpenOCD is licensed under the terms of the GNU General Public License, see the
-file COPYING for details.
-
+                                    OpenOCD

+

+			 Free and Open On-Chip Debugging, In-System Programming 

+						   and Boundary-Scan Testing

+				  Copyright (c) 2004-2007 Dominic Rath

+

+The debugger uses an IEEE 1149-1 compliant JTAG TAP bus master to access on-chip

+debug functionality available on ARM7 and ARM9 based microcontrollers /

+system-on-chip solutions.

+

+User interaction is realized through a telnet command line interface and a gdb

+(The GNU Debugger) remote protocol server.

+

+1. JTAG hardware

+

+Currently, OpenOCD supports the following JTAG interfaces:

+

+- Parallel port wigglers. These devices connect to a PC's parallel port,

+providing direct access to the JTAG lines. The OpenOCD contains descriptions

+of a few Wiggler layouts, including the original 'Wiggler' design. Other

+layouts (i.e. mapping of parallel port pins to JTAG lines) can be added easily.

+Typical Wiggler speeds are around 12kByte/s code download to an ARM7's RAM.

+

+The list of supported parallel port devices includes:

+

+  * Macraigor Wiggler JTAG cable

+  * Gateworks GW16012 JTAG programmer

+  * Xilinx DLC5 JTAG parallel cable III

+  * Ka-Ro TRITON starterkit II JTAG cable

+  * Lattice parallel port JTAG cable

+  * ST FlashLINK programming cable

+

+- The Amontec JTAG Accelerator. This is a configuration for Amontec's Chameleon

+dongle, a parallel port interface based on a Xilinx CoolRunner CPLD. It uses

+the IEEE1284 EPP parallel port specification, providing many times the

+performance achievable with wiggler-style devices. Additional information is

+available on www.amontec.com.

+Typical JTAG Accelerator speeds are around 120-160kByte/s to an ARM7's RAM.

+

+- FTDI FT2232 based USB devices. The FT2232 (but not FT232 or FT245) features a

+multi-protocol synchronous serial engine (MPSSE) that can be used to run the

+serial JTAG protocol. There are several implemenations of FT2232 based devices:

+

+* USBJTAG: http://www.fh-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html

+The USBJTAG was designed by Prof. Hubert Hoegl to provide a high-speed USB

+interface for use with the OpenOCD. Schematics are available at the USBJTAG

+website, and a homebrew device can easily be built using the FTDI evaluation

+module DLP2232M.

+

+* OOCD-Link: http://www.joernonline.de/dw/doku.php?id=en:projects:oocdlink

+Similar to the USBJTAG, this design comes with free schematics, too.

+

+* Amontec JTAGkey: www.amontec.com

+The Amontec JTAGkey offers support for a wide variety of target voltages from

+1.4V to 5V. It also allows the JTAG lines and reset signals to be tri-stated,

+allowing easy interfacing with a wide variety of targets.

+

+* Amontec JTAGkey-Tiny: www.amontec.com

+The Amontec JTAGkey offers support for a wide variety of target voltages from

+2.8V to 5V. It also allows the reset signals to be tri-stated, allowing easy

+interfacing with a wide variety of targets.

+

+* Olimex ARM-USB-OCD: www.olimex.com

+The Olimex ARM-USB-OCD offers support for a wide vriety of target voltages from

+2.0V to 5V. It also allows targets to be powered from the ARM-USB-OCD and

+features and additional RS232 UART.

+

+* eVerve Signalyzer: www.signalyzer.com

+The Signalyzer offers support for a wide variety of target voltages from 1.2V to

+5.5V. A second connector provides access to a TTL level UART.

+

+* TinCanTools 'Flyswatter' USB JTAG programmer.

+

+* Turtelizer 2: http://www.ethernut.de/en/hardware/turtelizer/index.html

+Another USB JTAG programmer, with freely available schematics. It supports

+target voltages from 1.65V to 5.5V.

+

+* Hitex STR9-comSTICK: http://www.ehitex.de/p_info.php?products_id=292

+A STR912FW44x microcontroller "board" with USB and JTAG functionality.

+

+* Luminary Micro development board evb_lm3s811 JTAG interface.

+

+* ASIX PRESTO: http://www.asix-tools.com/prg_presto.htm

+The ASIX PRESTO is a USB JTAG programmer for a wide range of components, e.g.

+microcontrollers, serial EEPROM and Flash memory chips, CPLDs and others.

+

+* usbprog: http://www.embedded-projects.net/index.php?page_id=165

+The usbprog is a freely programmable USB adapter, which can (among other

+things) use a firmware which turns it into a JTAG programmer/debugger.

+

+All FT2232 based devices may be accessed using either FTDI's proprietary FTD2XX

+library (www.ftdichip.com) or using an open-source replacement from

+http://www.intra2net.com/de/produkte/opensource/ftdi/index.php, also included

+with many Linux distributions.

+

+2. Supported cores

+

+This version of openocd supports the following ARM7/9 cores:

+

+- ARM7TDMI(-s)

+- ARM9TDMI

+- ARM920t

+- ARM922t

+- ARM926ej-s

+- ARM966e

+- Cortex-M3

+

+Support for Intel XScale CPUs is also included:

+

+- PXA25x

+- PXA27x

+- IXP42x

+

+And support for the Marvell Feroceon CPU core as found in the

+Orion SOC family is included as well.

+

+3. Host platforms

+

+OpenOCD was originally developed on x86-Linux, but has since then been ported

+to run on Windows/Cygwin, native Windows with MinGW, FreeBSD, IA64-Linux,

+AMD64-Linux, Alpha-Linux, ARM-Linux, and PowerPC OS-X.

+

+4. Documentation

+

+Documentation for the OpenOCD is hosted in the Berlios OpenFacts Wiki at

+http://openfacts.berlios.de/index-en.phtml?title=Open_On-Chip_Debugger.

+

+5. Licensing

+

+OpenOCD is licensed under the terms of the GNU General Public License, see the

+file COPYING for details.

+

diff --git a/doc/openocd.texi b/doc/openocd.texi
index d19a09ee..e42c33cb 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1,1911 +1,1912 @@
-\input texinfo	@c -*-texinfo-*-
-@c %**start of header
-@setfilename openocd.info
-@settitle Open On-Chip Debugger (openocd)
-@c %**end of header
-
-@include version.texi
-
-@titlepage
-@title Open On-Chip Debugger (openocd)
-@subtitle Edition @value{EDITION} for openocd version @value{VERSION}
-@subtitle @value{UPDATED}
-@page
-@vskip 0pt plus 1filll
-@end titlepage
-
-@contents
-
-@node Top, About, , (dir)
-@top OpenOCD
-
-This is edition @value{EDITION} of the openocd manual for version
-@value{VERSION}, @value{UPDATED}
-
-@menu
-* About::             About Openocd.
-* Developers::        
-* Building::          Building Openocd
-* Running::           Running Openocd
-* Configuration::     Openocd Configuration.
-* Commands::          Openocd Commands
-* Sample Scripts::    Sample Target Scripts
-* GDB and Openocd::   Using GDB and Openocd
-* FAQ::               Frequently Asked Questions
-* License::           GNU Free Documentation License
-* Index::             Main index.
-@end menu
-
-@node About
-@unnumbered About
-@cindex about
-
-The Open On-Chip Debugger (openocd) aims to provide debugging, in-system programming
-and boundary-scan testing for embedded target devices. The targets are interfaced
-using JTAG (IEEE 1149.1) compliant hardware, but this may be extended to other
-connection types in the future.
-
-Openocd currently supports Wiggler (clones), FTDI FT2232 based JTAG interfaces, the
-Amontec JTAG Accelerator, and the Gateworks GW1602. It allows ARM7 (ARM7TDMI and ARM720t),
-ARM9 (ARM920t, ARM922t, ARM926ej--s, ARM966e--s), XScale (PXA25x, IXP42x) and
-Cortex-M3 (Luminary Stellaris LM3 and ST STM32) based cores to be debugged.
-
-Flash writing is supported for external CFI compatible flashes (Intel and AMD/Spansion
-command set) and several internal flashes (LPC2000, AT91SAM7, STR7x, STR9x, LM3
-and STM32x). Preliminary support for using the LPC3180's NAND flash controller is included.
-
-@node Developers
-@chapter Developers
-@cindex developers
-
-Openocd has been created by Dominic Rath as part of a diploma thesis written at the
-University of Applied Sciences Augsburg (@uref{http://www.fh-augsburg.de}).
-Others interested in improving the state of free and open debug and testing technology
-are welcome to participate.
-
-Other developers have contributed support for additional targets and flashes as well
-as numerous bugfixes and enhancements. See the AUTHORS file for regular contributors. 
-
-@node Building
-@chapter Building
-@cindex building openocd
-
-You can download the current SVN version with 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 could use the following command to fetch the
-latest version (make sure there is no (non-svn) directory called "openocd" in the
-current directory):
-
-@smallexample
- svn checkout svn://svn.berlios.de/openocd/trunk
-@end smallexample
-
-Building the OpenOCD requires a recent version of the GNU autotools.
-On my build system, I'm using autoconf 2.13 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})
-@item When using the Amontec JTAGkey, you have to get the drivers from the Amontec
-homepage (@uref{www.amontec.com}), as the JTAGkey uses a non-standard VID/PID. 
-@end itemize
-
-Please note that the ftdi2232 variant (using libftdi) isn't supported under Cygwin.
-You have to use the ftd2xx variant (using FTDI's D2XX) on Cygwin.
-
-In general, the D2XX driver provides superior performance (several times as fast),
-but has the draw-back of being binary-only - though that isn't as worse, as it isn't
-a kernel module, only a user space library.
-
-To build OpenOCD (on both Linux and Cygwin), use the following commands:
-@smallexample
- ./bootstrap 
-@end smallexample
-Bootstrap generates the configure script, and prepares building on your system.
-@smallexample
- ./configure 
-@end smallexample
-Configure generates the Makefiles used to build OpenOCD
-@smallexample
- make 
-@end smallexample
-Make builds the OpenOCD, and places the final executable in ./src/
-
-The configure script takes several options, specifying which JTAG interfaces
-should be included:
-
-@itemize @bullet
-@item
---enable-parport
-@item
---enable-parport_ppdev
-@item
---enable-amtjtagaccel
-@item
---enable-ft2232_ftd2xx
-@footnote{Using the latest D2XX drivers from FTDI and following their installation
-instructions, I had to use @option{--enable-ft2232_libftd2xx} for the OpenOCD to
-build properly}
-@item
---enable-ft2232_libftdi
-@item
---with-ftd2xx=/path/to/d2xx/
-@end itemize
-
-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).
-
-Cygwin users have to specify the location of the FTDI D2XX package. This should be an
-absolute path containing no spaces.
-
-Linux users should copy the various parts of the D2XX package to the appropriate
-locations, i.e. /usr/include, /usr/lib. 
-
-@node Running
-@chapter Running
-@cindex running openocd
-@cindex --configfile
-@cindex --debug_level
-@cindex --logfile
-@cindex --search
-The OpenOCD runs as a daemon, waiting for connections from clients (Telnet or GDB).
-Run with @option{--help} or @option{-h} to view the available command line arguments.
-
-It reads its configuration by default from the file openocd.cfg located in the current
-working directory. This may be overwritten with the @option{-f <configfile>} command line
-switch.
-
-To enable debug output (when reporting problems or working on OpenOCD itself), use
-the @option{-d} command line switch. This sets the debug_level to "3", outputting
-the most information, including debug messages. The default setting is "2", outputting
-only informational messages, warnings and errors. You can also change this setting
-from within a telnet or gdb session (@option{debug_level <n>}).
-
-You can redirect all output from the daemon to a file using the @option{-l <logfile>} switch.
-
-Search paths for config/script files can be added to openocd by using
-the @option{-s <search>} switch.
-
-@node Configuration
-@chapter Configuration
-@cindex configuration
-The Open On-Chip Debugger (OpenOCD) runs as a daemon, and reads it current configuration
-by default from the file openocd.cfg in the current directory. A different configuration
-file can be specified with the  @option{-f <conf.file>} given at the openocd command line.
-
-The configuration file is used to specify on which ports the daemon listens for new
-connections, the JTAG interface used to connect to the target, the layout of the JTAG
-chain, the targets that should be debugged, and connected flashes.
-
-@section Daemon configuration
-
-@itemize @bullet
-@item @b{telnet_port} <@var{number}>
-@cindex telnet_port
-Port on which to listen for incoming telnet connections 
-@item @b{gdb_port} <@var{number}>
-@cindex gdb_port
-First port on which to listen 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. 
-@item @b{gdb_detach} <@var{resume|reset|halt|nothing}>
-@cindex gdb_detach
-Configures what openocd will do when gdb detaches from the daeman.
-Default behaviour is <@var{resume}>
-@item @b{gdb_memory_map} <@var{enable|disable}>
-@cindex gdb_memory_map
-Set to <@var{enable}> so that openocd will 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. @option{gdb_flash_program enable} will also need enabling
-for flash programming to work.
-Default behaviour is <@var{disable}>
-@item @b{gdb_flash_program} <@var{enable|disable}>
-@cindex gdb_flash_program
-Set to <@var{enable}> so that openocd will program the flash memory when a
-vFlash packet is received.
-Default behaviour is <@var{disable}>
-@item @b{daemon_startup} <@var{mode}> either @samp{attach} or @samp{reset}
-@cindex daemon_startup
-Tells the OpenOCD whether it should reset the target when the daemon is launched, or
-if it should just attach to the target. 
-@end itemize
-
-@section JTAG interface configuration
-
-@itemize @bullet
-@item @b{interface} <@var{name}>
-@cindex interface
-Use the interface driver <@var{name}> to connect to the target. Currently supported
-interfaces are
-@itemize @minus
-@item parport
-PC parallel port bit-banging (Wigglers, PLD download cable, ...)
-@end itemize
-@itemize @minus
-@item amt_jtagaccel
-Amontec Chameleon in its JTAG Accelerator configuration connected to a PC's EPP
-mode parallel port
-@end itemize
-@itemize @minus
-@item ft2232
-FTDI FT2232 based devices using either the open-source libftdi or the binary only
-FTD2XX driver. The FTD2XX is superior in performance, but not available on every
-platform. The libftdi uses libusb, and should be portable to all systems that provide
-libusb.
-@end itemize
-@itemize @minus
-@item ep93xx
-Cirrus Logic EP93xx based single-board computer bit-banging (in development)
-@end itemize
-@end itemize
-
-@itemize @bullet
-@item @b{jtag_speed} <@var{number}>
-@cindex jtag_speed
-Limit the maximum speed of the JTAG interface. Usually, a value of zero means maximum
-speed. The actual effect of this option depends on the JTAG interface used.
-
-@itemize @minus
-@item wiggler: maximum speed / @var{number}
-@item ft2232: 6MHz / (@var{number}+1)
-@item amt jtagaccel: 8 / 2**@var{number}
-@end itemize
-
-Note: Make sure the jtag clock is no more than @math{1/6th × CPU-Clock}. This is
-especially true for synthesized cores (-S).
-
-@item @b{reset_config} <@var{signals}> [@var{combination}] [@var{trst_type}] [@var{srst_type}]
-@cindex reset_config
-The configuration of the reset signals available on the JTAG interface AND the target.
-If the JTAG interface provides SRST, but the target doesn't connect that signal properly,
-then OpenOCD can't use it. <@var{signals}> can be @samp{none}, @samp{trst_only},
-@samp{srst_only} or @samp{trst_and_srst}.
-[@var{combination}] is an optional value specifying broken reset signal implementations.
-@samp{srst_pulls_trst} states that the testlogic is reset together with the reset of
-the system (e.g. Philips LPC2000, "broken" board layout), @samp{trst_pulls_srst} says
-that the system is reset together with the test logic (only hypothetical, I haven't
-seen hardware with such a bug, and can be worked around).
-
-The [@var{trst_type}] and [@var{srst_type}] parameters allow the driver type of the
-reset lines to be specified. Possible values are @samp{trst_push_pull} (default)
-and @samp{trst_open_drain} for the test reset signal, and @samp{srst_open_drain}
-(default) and @samp{srst_push_pull} for the system reset. These values only affect
-JTAG interfaces with support for different drivers, like the Amontec JTAGkey and JTAGAccelerator. 
-
-@item @b{jtag_device} <@var{IR length}> <@var{IR capture}> <@var{IR mask}> <@var{IDCODE instruction}>
-@cindex jtag_device
-Describes the devices that form the JTAG daisy chain, with the first device being
-the one closest to TDO. The parameters are the length of the instruction register
-(4 for all ARM7/9s), the value captured during Capture-IR (0x1 for ARM7/9), and a mask
-of bits that should be validated when doing IR scans (all four bits (0xf) for ARM7/9).
-The IDCODE instruction will in future be used to query devices for their JTAG
-identification code. This line is the same for all ARM7 and ARM9 devices.
-Other devices, like CPLDs, require different parameters. An example configuration
-line for a Xilinx XC9500 CPLD would look like this:
-@smallexample
-jtag_device 8 0x01 0x0e3 0xfe
-@end smallexample
-The instruction register (IR) is 8 bits long, during Capture-IR 0x01 is loaded into
-the IR, but only bits 0-1 and 5-7 should be checked, the others (2-4) might vary.
-The IDCODE instruction is 0xfe.
-
-@item @b{jtag_nsrst_delay} <@var{ms}>
-@cindex jtag_nsrst_delay
-How long (in miliseconds) the OpenOCD should wait after deasserting nSRST before
-starting new JTAG operations. 
-@item @b{jtag_ntrst_delay} <@var{ms}>
-@cindex jtag_ntrst_delay
-How long (in miliseconds) the OpenOCD should wait after deasserting nTRST before
-starting new JTAG operations. 
-
-The jtag_n[st]rst_delay options are useful if reset circuitry (like a reset supervisor,
-or on-chip features) keep a reset line asserted for some time after the external reset
-got deasserted.
-@end itemize
-
-@section parport options
-
-@itemize @bullet
-@item @b{parport_port} <@var{number}>
-@cindex parport_port
-Either the address of the I/O port (default: 0x378 for LPT1) or the number of
-the @file{/dev/parport} device
-
-When using PPDEV to access the parallel port, use the number of the parallel port:
-@option{parport_port 0} (the default). If @option{parport_port 0x378} is specified
-you may encounter a problem.
-@item @b{parport_cable} <@var{name}>
-@cindex parport_cable
-The layout of the parallel port cable used to connect to the target.
-Currently supported cables are 
-@itemize @minus
-@item wiggler
-@cindex wiggler
-Original Wiggler layout, also supported by several clones, such
-as the Olimex ARM-JTAG
-@item old_amt_wiggler
-@cindex old_amt_wiggler
-The Wiggler configuration that comes with Amontec's Chameleon Programmer. The new
-version available from the website uses the original Wiggler layout ('@var{wiggler}')
-@item chameleon
-@cindex chameleon
-Describes the connection of the Amontec Chameleon's CPLD when operated in
-configuration mode. This is only used to program the Chameleon itself, not
-a connected target.
-@item dlc5
-@cindex dlc5
-Xilinx Parallel cable III.
-@item triton
-@cindex triton
-The parallel port adapter found on the 'Karo Triton 1 Development Board'.
-This is also the layout used by the HollyGates design
-(see @uref{http://www.lartmaker.nl/projects/jtag/}).
-@item flashlink
-@cindex flashlink
-ST Parallel cable. 
-@end itemize
-@item @b{parport_write_on_exit} <@var{on|off}>
-@cindex parport_write_on_exit
-This will configure the parallel driver to write a known value to the parallel
-interface on exiting openocd
-@end itemize
-
-@section amt_jtagaccel options
-@itemize @bullet
-@item @b{parport_port} <@var{number}>
-@cindex parport_port
-Either the address of the I/O port (default: 0x378 for LPT1) or the number of the
-@file{/dev/parport} device 
-@end itemize
-@section ft2232 options
-
-@itemize @bullet
-@item @b{ft2232_device_desc} <@var{description}>
-@cindex ft2232_device_desc
-The USB device description of the FTDI FT2232 device. If not specified, the FTDI
-default value is used. This setting is only valid if compiled with FTD2XX support.
-@item @b{ft2232_layout} <@var{name}>
-@cindex ft2232_layout
-The layout of the FT2232 GPIO signals used to control output-enables and reset
-signals. Valid layouts are
-@itemize @minus
-@item usbjtag
-The "USBJTAG-1" layout described in the original OpenOCD diploma thesis
-@item jtagkey
-Amontec JTAGkey and JTAGkey-tiny
-@item signalyzer
-Signalyzer
-@item olimex-jtag
-Olimex ARM-USB-OCD
-@item m5960
-American Microsystems M5960
-@item evb_lm3s811
-Luminary Micro EVB_LM3S811 as a JTAG interface (not onboard processor), no TRST or
-SRST signals on external connector
-@item comstick
-Hitex STR9 comstick 
-@item stm32stick
-Hitex STM32 Performance Stick
-@item flyswatter
-Tin Can Tools Flyswatter
-@item turtelizer2
-egnite Software turtelizer2
-@item oocdlink
-OOCDLink
-@end itemize
-
-@item @b{ft2232_vid_pid} <@var{vid}> <@var{pid}>
-The vendor ID and product ID of the FTDI FT2232 device. If not specified, the FTDI
-default values are used. This command is not available on Windows. 
-@item @b{ft2232_latency} <@var{ms}>
-On some systems using ft2232 based JTAG interfaces the FT_Read function call in
-ft2232_read() fails to return the expected number of bytes. This can be caused by
-USB communication delays and has proved hard to reproduce and debug. Setting the
-FT2232 latency timer to a larger value increases delays for short USB packages but it
-also reduces the risk of timeouts before receiving the expected number of bytes.
-The OpenOCD default value is 2 and for some systems a value of 10 has proved useful. 
-@end itemize
-
-@section ep93xx options
-@cindex ep93xx options
-Currently, there are no options available for the ep93xx interface.
-
-@page
-@section Target configuration
-
-@itemize @bullet
-@item @b{target} <@var{type}> <@var{endianess}> <@var{reset_mode}> <@var{JTAG pos}>
-<@var{variant}>
-@cindex target
-Defines a target that should be debugged. Currently supported types are:
-@itemize @minus
-@item arm7tdmi
-@item arm720t
-@item arm9tdmi
-@item arm920t
-@item arm922t
-@item arm926ejs
-@item arm966e
-@item cortex_m3
-@item xscale 
-@end itemize
-
-If you want to use a target board that is not on this list, see Adding a new
-target board
-
-Endianess may be @option{little} or @option{big}.
-
-The reset_mode specifies what should happen to the target when a reset occurs:
-@itemize @minus
-@item reset_halt
-@cindex reset_halt
-Immediately request a target halt after reset. This allows targets to be debugged
-from the very first instruction. This is only possible with targets and JTAG
-interfaces that correctly implement the reset signals.
-@item reset_init
-@cindex reset_init
-Similar to @option{reset_halt}, but executes the script file defined to handle the
-'reset' event for the target. Like @option{reset_halt} this only works with
-correct reset implementations.
-@item reset_run
-@cindex reset_run
-Simply let the target run after a reset.
-@item run_and_halt
-@cindex run_and_halt
-Let the target run for some time (default: 1s), and then request halt.
-@item run_and_init
-@cindex run_and_init
-A combination of @option{reset_init} and @option{run_and_halt}. The target is allowed
-to run for some time, then halted, and the @option{reset} event script is executed. 
-@end itemize
-
-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
-@option{reset_halt} or @option{reset_init}.
-
-@item @b{target_script} <@var{target#}> <@var{event}> <@var{script_file}>
-@cindex target_script
-Event is either @option{reset}, @option{post_halt}, @option{pre_resume} or @option{gdb_program_config}
-
-TODO: describe exact semantic of events
-@item @b{run_and_halt_time} <@var{target#}> <@var{time_in_ms}>
-@cindex run_and_halt_time
-The amount of time the debugger should wait after releasing reset before it asserts
-a debug request. This is used by the @option{run_and_halt} and @option{run_and_init}
-reset modes. 
-@item @b{working_area} <@var{target#}> <@var{address}> <@var{size}>
-<@var{backup}|@var{nobackup}>
-@cindex working_area
-Specifies a working area for the debugger to use. This may be used to speed-up
-downloads to target memory and flash operations, or to perform otherwise unavailable
-operations (some coprocessor operations on ARM7/9 systems, for example). The last
-parameter decides whether the memory should be preserved <@var{backup}>. If possible, use
-a working_area that doesn't need to be backed up, as that slows down operation. 
-@end itemize
-
-@subsection arm7tdmi options
-@cindex arm7tdmi options
-target arm7tdmi <@var{endianess}> <@var{reset_mode}> <@var{jtag#}>
-The arm7tdmi target definition requires at least one additional argument, specifying
-the position of the target in the JTAG daisy-chain. The first JTAG device is number 0.
-The optional [@var{variant}] parameter has been removed in recent versions.
-The correct feature set is determined at runtime. 
-
-@subsection arm720t options
-@cindex arm720t options
-ARM720t options are similar to ARM7TDMI options.
-
-@subsection arm9tdmi options
-@cindex arm9tdmi options
-ARM9TDMI options are similar to ARM7TDMI options. Supported variants are
-@option{arm920t}, @option{arm922t} and @option{arm940t}.
-This enables the hardware single-stepping support found on these cores.
-
-@subsection arm920t options
-@cindex arm920t options
-ARM920t options are similar to ARM9TDMI options.
-
-@subsection arm966e options
-@cindex arm966e options
-ARM966e options are similar to ARM9TDMI options.
-
-@subsection xscale options
-@cindex xscale options
-Supported variants are @option{ixp42x}, @option{ixp45x}, @option{ixp46x},
-@option{pxa250}, @option{pxa255}, @option{pxa26x}.
-
-@section Flash configuration
-@cindex Flash configuration
-
-@itemize @bullet
-@item @b{flash bank} <@var{driver}> <@var{base}> <@var{size}> <@var{chip_width}>
-<@var{bus_width}> <@var{target#}> [@var{driver_options ...}]
-@cindex flash bank
-Configures a flash bank at <@var{base}> of <@var{size}> bytes and <@var{chip_width}>
-and <@var{bus_width}> bytes using the selected flash <driver>.
-
-@item @b{flash auto_erase} <@option{on}|@option{off}>
-@cindex flash auto_erase
-auto erase flash banks prior to writing. Currently only works when using
-@option{flash write_image} command. Default is @option{off}.
-@end itemize
-
-@subsection lpc2000 options
-@cindex lpc2000 options
-
-@b{flash bank lpc2000} <@var{base}> <@var{size}> 0 0 <@var{target#}> <@var{variant}>
-<@var{clock}> [@var{calc_checksum}]
-LPC flashes don't require the chip and bus width to be specified. Additional
-parameters are the <@var{variant}>, which may be @var{lpc2000_v1} (older LPC21xx and LPC22xx)
-or @var{lpc2000_v2} (LPC213x, LPC214x, LPC210[123], LPC23xx and LPC24xx), the number
-of the target this flash belongs to (first is 0), the frequency at which the core
-is currently running (in kHz - must be an integral number), and the optional keyword
-@var{calc_checksum}, telling the driver to calculate a valid checksum for the exception
-vector table. 
-
-@subsection cfi options
-@cindex cfi options
-
-@b{flash bank cfi} <@var{base}> <@var{size}> <@var{chip_width}> <@var{bus_width}>
-<@var{target#}>
-CFI flashes require the number of the target they're connected to as an additional
-argument. The CFI driver makes use of a working area (specified for the target)
-to significantly speed up operation. 
-
-@var{chip_width} and @var{bus_width} are specified in bytes.
-
-@subsection at91sam7 options
-@cindex at91sam7 options
-
-@b{flash bank at91sam7} 0 0 0 0 <@var{target#}>
-AT91SAM7 flashes only require the @var{target#}, all other values are looked up after
-reading the chip-id and type. 
-
-@subsection str7 options
-@cindex str7 options
-
-@b{flash bank str7x} <@var{base}> <@var{size}> 0 0 <@var{target#}> <@var{variant}>
-variant can be either STR71x, STR73x or STR75x. 
-
-@subsection str9 options
-@cindex str9 options
-
-@b{flash bank str9x} <@var{base}> <@var{size}> 0 0 <@var{target#}>
-The str9 needs the flash controller to be configured prior to Flash programming, eg.
-@smallexample
-str9x flash_config 0 4 2 0 0x80000
-@end smallexample
-This will setup the BBSR, NBBSR, BBADR and NBBADR registers respectively. 
-
-@subsection str9 options (str9xpec driver)
-
-@b{flash bank str9xpec} <@var{base}> <@var{size}> 0 0 <@var{target#}>
-Before using the flash commands the turbo mode will need enabling using str9xpec
-@option{enable_turbo} <@var{num>.}
-
-Only use this driver for locking/unlocking the device or configuring the option bytes.
-Use the standard str9 driver for programming.
-
-@subsection stellaris (LM3Sxxx) options
-@cindex stellaris (LM3Sxxx) options
-
-@b{flash bank stellaris} <@var{base}> <@var{size}> 0 0 <@var{target#}>
-stellaris flash plugin only require the @var{target#}. 
-
-@subsection stm32x options
-@cindex stm32x options
-
-@b{flash bank stm32x} <@var{base}> <@var{size}> 0 0 <@var{target#}>
-stm32x flash plugin only require the @var{target#}. 
-
-@node Commands
-@chapter Commands
-@cindex commands
-
-The Open On-Chip Debugger (OpenOCD) allows user interaction through a telnet interface
-(default: port 4444) and a GDB server (default: port 3333). The command line interpreter
-is available from both the telnet interface and a GDB session. To issue commands to the
-interpreter from within a GDB session, use the @option{monitor} command, e.g. use
-@option{monitor poll} to issue the @option{poll} command. All output is relayed through the
-GDB session.
-
-@section Daemon
-
-@itemize @bullet
-@item @b{sleep} <@var{msec}>
-@cindex sleep
-Wait for n milliseconds before resuming. Useful in connection with script files
-(@var{script} command and @var{target_script} configuration). 
-
-@item @b{shutdown}
-@cindex shutdown
-Close the OpenOCD daemon, disconnecting all clients (GDB, Telnet). 
-
-@item @b{debug_level} [@var{n}]
-@cindex debug_level
-Display or adjust debug level to n<0-3> 
-
-@item @b{log_output} <@var{file}>
-@cindex log_output
-Redirect logging to <file> (default: stderr) 
-
-@item @b{script} <@var{file}>
-@cindex script
-Execute commands from <file> 
-
-@end itemize
-
-@subsection Target state handling
-@itemize @bullet
-@item @b{poll} [@option{on}|@option{off}]
-@cindex poll
-Poll the target for its current state. If the target is in debug mode, architecture
-specific information about the current state are printed. An optional parameter
-allows continuous polling to be enabled and disabled.
-
-@item @b{halt} [@option{ms}]
-@cindex halt
-Send a halt request to the target and waits for it to halt for [@option{ms}].
-Default [@option{ms}] is 5 seconds if no arg given.
-Optional arg @option{ms} is a timeout in milliseconds. Using 0 as the [@option{ms}]
-will stop openocd from waiting.
-
-@item @b{wait_halt} [@option{ms}]
-@cindex wait_halt
-Wait for the target to enter debug mode. Optional [@option{ms}] is
-a timeout in milliseconds. Default [@option{ms}] is 5 seconds if no
-arg given.
-
-@item @b{resume} [@var{address}]
-@cindex resume
-Resume the target at its current code position, or at an optional address.
-Openocd will wait 5 seconds for the target to resume.
-
-@item @b{step} [@var{address}]
-@cindex step
-Single-step the target at its current code position, or at an optional address. 
-
-@item @b{reset} [@option{run}|@option{halt}|@option{init}|@option{run_and_halt}
-|@option{run_and_init}]
-@cindex reset
-Do a hard-reset. The optional parameter specifies what should happen after the reset.
-This optional parameter overwrites the setting specified in the configuration file,
-making the new behaviour the default for the @option{reset} command.
-@itemize @minus
-@item run
-@cindex reset run
-Let the target run.
-@item halt
-@cindex reset halt
-Immediately halt the target (works only with certain configurations).
-@item init
-@cindex reset init
-Immediately halt the target, and execute the reset script (works only with certain
-configurations)
-@item run_and_halt
-@cindex reset run_and_halt
-Let the target run for a certain amount of time, then request a halt.
-@item run_and_init
-@cindex reset run_and_init
-Let the target run for a certain amount of time, then request a halt. Execute the
-reset script once the target entered debug mode.
-@end itemize
-@end itemize
-
-@subsection Memory access commands
-These commands allow accesses of a specific size to the memory system:
-@itemize @bullet
-@item @b{mdw} <@var{addr}> [@var{count}]
-@cindex mdw
-display memory words 
-@item @b{mdh} <@var{addr}> [@var{count}]
-@cindex mdh
-display memory half-words 
-@item @b{mdb} <@var{addr}> [@var{count}]
-@cindex mdb
-display memory bytes 
-@item @b{mww} <@var{addr}> <@var{value}>
-@cindex mww
-write memory word 
-@item @b{mwh} <@var{addr}> <@var{value}>
-@cindex mwh
-write memory half-word 
-@item @b{mwb} <@var{addr}> <@var{value}>
-@cindex mwb
-write memory byte 
-
-@item @b{load_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]
-@cindex load_image
-Load image <@var{file}> to target memory at <@var{address}> 
-@item @b{dump_image} <@var{file}> <@var{address}> <@var{size}>
-@cindex dump_image
-Dump <@var{size}> bytes of target memory starting at <@var{address}> to a
-(binary) <@var{file}>.
-@item @b{verify_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]
-@cindex verify_image
-Verify <@var{file}> to target memory starting at <@var{address}>.
-This will first attempt using a crc checksum, if this fails it will try a binary compare.
-@item @b{load_binary} <@var{file}> <@var{address}> [DEPRECATED]
-@cindex load_binary
-Load binary <@var{file}> to target memory at <@var{address}> 
-@item @b{dump_binary} <@var{file}> <@var{address}> <@var{size}> [DEPRECATED]
-@cindex dump_binary
-Dump <@var{size}> bytes of target memory starting at <@var{address}> to a
-(binary) <@var{file}>.
-@end itemize
-
-@subsection Flash commands
-@cindex Flash commands
-@itemize @bullet
-@item @b{flash banks}
-@cindex flash banks
-List configured flash banks 
-@item @b{flash info} <@var{num}>
-@cindex flash info
-Print info about flash bank <@option{num}> 
-@item @b{flash probe} <@var{num}>
-@cindex flash probe
-Identify the flash, or validate the parameters of the configured flash. Operation
-depends on the flash type. 
-@item @b{flash erase_check} <@var{num}>
-@cindex flash erase_check
-Check erase state of sectors in flash bank <@var{num}>. This is the only operation that
-updates the erase state information displayed by @option{flash info}. That means you have
-to issue an @option{erase_check} command after erasing or programming the device to get
-updated information. 
-@item @b{flash protect_check} <@var{num}>
-@cindex flash protect_check
-Check protection state of sectors in flash bank <num>. 
-
-@item @b{flash erase} <@var{num}> <@var{first}> <@var{last}> [DEPRECATED]
-@cindex flash erase
-Erase sectors at bank <@var{num}>, starting at sector <@var{first}> up to and including
-<@var{last}>. Sector numbering starts at 0. Depending on the flash type, erasing might
-require the protection to be disabled first (e.g. Intel Advanced Bootblock flash using
-the CFI driver). This command was replaced by the new command
-@option{flash erase_sector} using the same syntax. 
-@item @b{flash erase_sector} <@var{num}> <@var{first}> <@var{last}>
-@cindex flash erase_sector
-Erase sectors at bank <@var{num}>, starting at sector <@var{first}> up to and including
-<@var{last}>. Sector numbering starts at 0. Depending on the flash type, erasing might
-require the protection to be disabled first (e.g. Intel Advanced Bootblock flash using
-the CFI driver).
-@item @b{flash erase_address} <@var{address}> <@var{length}>
-@cindex flash erase_address
-Erase sectors starting at <@var{address}> for <@var{length}> number of bytes
-@item @b{flash write} <@var{num}> <@var{file}> <@var{offset}> [DEPRECATED]
-@cindex flash write
-Write the binary <@var{file}> to flash bank <@var{num}>, starting at <@var{offset}>
-bytes from the beginning of the bank. This command was replaced by the new command
-@option{flash write_binary} using the same syntax. 
-@item @b{flash write_binary} <@var{num}> <@var{file}> <@var{offset}>
-@cindex flash write_binary
-Write the binary <@var{file}> to flash bank <@var{num}>, starting at
-<@option{offset}> bytes from the beginning of the bank. 
-@item @b{flash write_image} <@var{file}> [@var{offset}] [@var{type}]
-@cindex flash write_image
-Write the image <@var{file}> to the current target's flash bank(s). A relocation
-[@var{offset}] can be specified and the file [@var{type}] can be specified
-explicitly as @option{bin} (binary), @option{ihex} (Intel hex), @option{elf}
-(ELF file) or @option{s19} (Motorola s19). 
-@item @b{flash protect} <@var{num}> <@var{first}> <@var{last}> <@option{on}|@option{off}>
-@cindex flash protect
-Enable (@var{on}) or disable (@var{off}) protection of flash sectors <@var{first}> to
-<@var{last}> of @option{flash bank} <@var{num}>. 
-@item @b{flash auto_erase} <@var{on}|@var{off}>
-@cindex flash auto_erase
-Enable (@option{on}) to erase flash banks prior to writing using the flash @option{write_image} command
-only. Default is (@option{off}), flash banks have to be erased using @option{flash erase} command. 
-@end itemize
-
-@page
-@section Target Specific Commands
-@cindex Target Specific Commands
-
-@subsection AT91SAM7 specific commands
-@cindex AT91SAM7 specific commands
-The flash configuration is deduced from the chip identification register. The flash
-controller handles erases automatically on a page (128/265 byte) basis so erase is
-not necessary for flash programming. AT91SAM7 processors with less than 512K flash
-only have a single flash bank embedded on chip. AT91SAM7xx512 have two flash planes
-that can be erased separatly.Only an EraseAll command is supported by the controller
-for each flash plane and this is called with
-@itemize @bullet
-@item @b{flash erase} <@var{num}> @var{first_plane} @var{last_plane}
-bulk erase flash planes first_plane to last_plane. 
-@item @b{at91sam7 gpnvm} <@var{num}> <@var{bit}> <@option{set}|@option{clear}>
-@cindex at91sam7 gpnvm
-set or clear a gpnvm bit for the processor 
-@end itemize
-
-@subsection STR9 specific commands
-@cindex STR9 specific commands
-These are flash specific commands when using the str9xpec driver.
-@itemize @bullet
-@item @b{str9xpec enable_turbo} <@var{num}>
-@cindex str9xpec enable_turbo
-enable turbo mode, simply this will remove the str9 from the chain and talk
-directly to the embedded flash controller. 
-@item @b{str9xpec disable_turbo} <@var{num}>
-@cindex str9xpec disable_turbo
-restore the str9 into jtag chain. 
-@item @b{str9xpec lock} <@var{num}>
-@cindex str9xpec lock
-lock str9 device. The str9 will only respond to an unlock command that will
-erase the device. 
-@item @b{str9xpec unlock} <@var{num}>
-@cindex str9xpec unlock
-unlock str9 device. 
-@item @b{str9xpec options_read} <@var{num}>
-@cindex str9xpec options_read
-read str9 option bytes. 
-@item @b{str9xpec options_write} <@var{num}>
-@cindex str9xpec options_write
-write str9 option bytes. 
-@end itemize
-
-@subsection STR9 configuration
-@cindex STR9 configuration
-@itemize @bullet
-@item @b{str9x flash_config} <@var{bank}> <@var{BBSR}> <@var{NBBSR}>
-<@var{BBADR}> <@var{NBBADR}>
-@cindex str9x flash_config
-Configure str9 flash controller.
-@smallexample
-eg. str9x flash_config 0 4 2 0 0x80000
-This will setup
-BBSR - Boot Bank Size register
-NBBSR - Non Boot Bank Size register
-BBADR - Boot Bank Start Address register
-NBBADR - Boot Bank Start Address register
-@end smallexample
-@end itemize
-
-@subsection STR9 option byte configuration
-@cindex STR9 option byte configuration
-@itemize @bullet
-@item @b{str9xpec options_cmap} <@var{num}> <@option{bank0}|@option{bank1}>
-@cindex str9xpec options_cmap
-configure str9 boot bank. 
-@item @b{str9xpec options_lvdthd} <@var{num}> <@option{2.4v}|@option{2.7v}>
-@cindex str9xpec options_lvdthd
-configure str9 lvd threshold. 
-@item @b{str9xpec options_lvdsel} <@var{num}> <@option{vdd}|@option{vdd_vddq}>
-@cindex str9xpec options_lvdsel
-configure str9 lvd source. 
-@item @b{str9xpec options_lvdwarn} <@var{bank}> <@option{vdd}|@option{vdd_vddq}>
-@cindex str9xpec options_lvdwarn
-configure str9 lvd reset warning source. 
-@end itemize
-
-@subsection STM32x specific commands
-@cindex STM32x specific commands
- 
-These are flash specific commands when using the stm32x driver.
-@itemize @bullet
-@item @b{stm32x lock} <@var{num}>
-@cindex stm32x lock
-lock stm32 device. 
-@item @b{stm32x unlock} <@var{num}>
-@cindex stm32x unlock
-unlock stm32 device. 
-@item @b{stm32x options_read} <@var{num}>
-@cindex stm32x options_read
-read stm32 option bytes. 
-@item @b{stm32x options_write} <@var{num}> <@option{SWWDG}|@option{HWWDG}>
-<@option{RSTSTNDBY}|@option{NORSTSTNDBY}> <@option{RSTSTOP}|@option{NORSTSTOP}>
-@cindex stm32x options_write
-write stm32 option bytes. 
-@item @b{stm32x mass_erase} <@var{num}>
-@cindex stm32x mass_erase
-mass erase flash memory. 
-@end itemize
-
-@page
-@section Architecture Specific Commands
-@cindex Architecture Specific Commands
-
-@subsection ARMV4/5 specific commands
-@cindex ARMV4/5 specific commands
-
-These commands are specific to ARM architecture v4 and v5, like all ARM7/9 systems
-or Intel XScale (XScale isn't supported yet).
-@itemize @bullet
-@item @b{armv4_5 reg}
-@cindex armv4_5 reg
-Display a list of all banked core registers, fetching the current value from every
-core mode if necessary. OpenOCD versions before rev. 60 didn't fetch the current
-register value. 
-@item @b{armv4_5 core_mode} [@option{arm}|@option{thumb}]
-@cindex armv4_5 core_mode
-Displays the core_mode, optionally changing it to either ARM or Thumb mode.
-The target is resumed in the currently set @option{core_mode}. 
-@end itemize
-
-@subsection ARM7/9 specific commands
-@cindex ARM7/9 specific commands
-
-These commands are specific to ARM7 and ARM9 targets, like ARM7TDMI, ARM720t,
-ARM920t or ARM926EJ-S.
-@itemize @bullet
-@item @b{arm7_9 sw_bkpts} <@option{enable}|@option{disable}>
-@cindex arm7_9 sw_bkpts
-Enable/disable use of software breakpoints. On ARMv4 systems, this reserves
-one of the watchpoint registers to implement software breakpoints. Disabling
-SW Bkpts frees that register again. 
-@item @b{arm7_9 force_hw_bkpts} <@option{enable}|@option{disable}>
-@cindex arm7_9 force_hw_bkpts
-When @option{force_hw_bkpts} is enabled, the @option{sw_bkpts} support is disabled, and all
-breakpoints are turned into hardware breakpoints.
-@item @b{arm7_9 dbgrq} <@option{enable}|@option{disable}>
-@cindex arm7_9 dbgrq
-Enable use of the DBGRQ bit to force entry into debug mode. This should be
-safe for all but ARM7TDMI--S cores (like Philips LPC). 
-@item @b{arm7_9 fast_writes} <@option{enable}|@option{disable}>
-@cindex arm7_9 fast_writes [DEPRECATED]
-See @option{arm7_9 fast_memory_access} instead. 
-@item @b{arm7_9 fast_memory_access} <@option{enable}|@option{disable}>
-@cindex arm7_9 fast_memory_access
-Allow the OpenOCD to read and write memory without checking completion of
-the operation. This provides a huge speed increase, especially with USB JTAG
-cables (FT2232), but might be unsafe if used with targets running at a very low
-speed, like the 32kHz startup clock of an AT91RM9200. 
-@item @b{arm7_9 dcc_downloads} <@option{enable}|@option{disable}>
-@cindex arm7_9 dcc_downloads
-Enable the use of the debug communications channel (DCC) to write larger (>128 byte)
-amounts of memory. DCC downloads offer a huge speed increase, but might be potentially
-unsafe, especially with targets running at a very low speed. This command was introduced
-with OpenOCD rev. 60. 
-@end itemize
-
-@subsection ARM920T specific commands
-@cindex ARM920T specific commands
-
-@itemize @bullet
-@item @b{arm920t cache_info}
-@cindex arm920t cache_info
-Print information about the caches found. This allows you to see if your target
-is a ARM920T (2x16kByte cache) or ARM922T (2x8kByte cache). 
-@item @b{arm920t md<bhw>_phys} <@var{addr}> [@var{count}]
-@cindex arm920t md<bhw>_phys
-Display memory at physical address addr. 
-@item @b{arm920t mw<bhw>_phys} <@var{addr}> <@var{value}>
-@cindex arm920t mw<bhw>_phys
-Write memory at physical address addr. 
-@item @b{arm920t read_cache} <@var{filename}>
-@cindex arm920t read_cache
-Dump the content of ICache and DCache to a file. 
-@item @b{arm920t read_mmu} <@var{filename}>
-@cindex arm920t read_mmu
-Dump the content of the ITLB and DTLB to a file. 
-@item @b{arm920t virt2phys} <@var{VA}>
-@cindex arm920t virt2phys
-Translate a virtual address to a physical address. 
-@end itemize
-
-@page
-@section Debug commands
-@cindex Debug commands
-The following commands give direct access to the core, and are most likely
-only useful while debugging the OpenOCD.
-@itemize @bullet
-@item @b{arm7_9 write_xpsr} <@var{32-bit value}> <@option{0=cpsr}, @option{1=spsr}>
-@cindex arm7_9 write_xpsr
-Immediately write either the current program status register (CPSR) or the saved
-program status register (SPSR), without changing the register cache (as displayed
-by the @option{reg} and @option{armv4_5 reg} commands). 
-@item @b{arm7_9 write_xpsr_im8} <@var{8-bit value}> <@var{rotate 4-bit}>
-<@var{0=cpsr},@var{1=spsr}>
-@cindex arm7_9 write_xpsr_im8
-Write the 8-bit value rotated right by 2*rotate bits, using an immediate write
-operation (similar to @option{write_xpsr}). 
-@item @b{arm7_9 write_core_reg} <@var{num}> <@var{mode}> <@var{value}>
-@cindex arm7_9 write_core_reg
-Write a core register, without changing the register cache (as displayed by the
-@option{reg} and @option{armv4_5 reg} commands). The <@var{mode}> argument takes the
-encoding of the [M4:M0] bits of the PSR. 
-@end itemize
-
-@page
-@section JTAG commands
-@cindex JTAG commands
-@itemize @bullet
-@item @b{scan_chain}
-@cindex scan_chain
-Print current scan chain configuration. 
-@item @b{jtag_reset}
-@cindex jtag_reset
-Toggle reset lines <@var{trst}> <@var{srst}>. 
-@item @b{endstate} <@var{tap_state}>
-@cindex endstate
-Finish JTAG operations in <@var{tap_state}>. 
-@item @b{runtest} <@var{num_cycles}>
-@cindex runtest
-Move to Run-Test/Idle, and execute <@var{num_cycles}> 
-@item @b{statemove} [@var{tap_state}]
-@cindex statemove
-Move to current endstate or [@var{tap_state}] 
-@item @b{irscan}
-@cindex irscan
-Execute IR scan <@var{device}> <@var{instr}> [@var{dev2}] [@var{instr2}] ... 
-@item @b{drscan}
-@cindex drscan
-Execute DR scan <@var{device}> [@var{dev2}] [@var{var2}] ... 
-@item @b{verify_ircapture}
-@cindex verify_ircapture
-Verify value captured during Capture-IR <@option{enable}|@option{disable}> 
-@item @b{var}
-@cindex var
-Allocate, display or delete variable <@var{name}> [@var{num_fields}|@var{del}] [@var{size1}] ... 
-@item @b{field}
-@cindex field
-Display/modify variable field <@var{var}> <@var{field}> [@var{value}|@var{flip}] 
-@end itemize
-
-@node Sample Scripts
-@chapter Sample Scripts
-@cindex scripts
-
-This page will collect some script examples for different CPUs.
-
-The configuration script can be divided in the following section:
-@itemize @bullet
-@item daemon configuration
-@item interface
-@item jtag scan chain
-@item target configuration
-@item flash configuration 
-@end itemize
-
-Detailed information about each section can be found at OpenOCD configuration 
-
-@section OMAP5912 Flash Debug
-@cindex OMAP5912 Flash Debug
-The following two scripts were used with a wiggler PP and and a TI OMAP5912
-dual core processor - (@uref{http://www.ti.com}), on a OMAP5912 OSK board
-- (@uref{http://www.spectrumdigital.com}).
-@subsection Openocd config
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
-
-#interface
-interface parport
-parport_port 0x378
-parport_cable wiggler
-jtag_speed 0
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
-
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 38 0x0 0x0 0x0
-jtag_device 4  0x1 0x0 0xe
-jtag_device 8  0x0 0x0 0x0
-
-#target configuration
-daemon_startup reset
-
-#target <type> <endianness> <reset mode> <chainpos> <variant>
-target arm926ejs little run_and_init 1 arm926ejs
-target_script 0 reset omap5912_osk.init
-run_and_halt_time 0 30
-
-# omap5912 lcd frame buffer as working area
-working_area 0 0x20000000 0x3e800 nobackup
-
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank cfi 0x00000000 0x1000000 2 2 0
-@end smallexample
-
-@subsection Openocd init
-@smallexample
-#
-# halt target
-#
-poll
-sleep 1
-halt
-wait_halt
-#
-# disable wdt
-#
-mww 0xfffec808 0x000000f5
-mww 0xfffec808 0x000000a0
-
-mww 0xfffeb048 0x0000aaaa
-sleep 500
-mww 0xfffeb048 0x00005555
-sleep 500
-#
-# detect flash
-#
-flash probe 0
-
-@end smallexample
-
-@section STR71x Script
-@cindex STR71x Script
-The following script was used with an Amontec JTAGkey and a STR710 / STR711 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 0
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
- 
-#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 <type> <startup mode>
-#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi
-run_and_halt_time 0 30
-
-working_area 0 0x2000C000 0x4000 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank str7x 0x40000000 0x00040000 0 0 0 STR71x
-@end smallexample
-
-@section STR750 Script
-@cindex STR750 Script
-The following script was used with an Amontec JTAGkey and a STR750 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 19
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-#reset_config trst_and_srst srst_pulls_trst
-reset_config trst_and_srst srst_pulls_trst
-
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 4 0x1 0xf 0xe
-
-#jtag nTRST and nSRST delay
-jtag_nsrst_delay 500
-jtag_ntrst_delay 500
- 
-#target configuration
-daemon_startup reset
- 
-#target <type> <startup mode>
-#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi
-run_and_halt_time 0 30
- 
-working_area 0 0x40000000 0x4000 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank str7x 0x20000000 0x000040000 0 0 0 STR75x
-@end smallexample
-
-@section STR912 Script
-@cindex STR912 Script
-The following script was used with an Amontec JTAGkey and a STR912 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-jtag_speed 1
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
- 
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 8 0x1 0x1 0xfe
-jtag_device 4 0x1 0xf 0xe
-jtag_device 5 0x1 0x1 0x1e
- 
-#target configuration
-daemon_startup reset
- 
-#target <type> <startup mode>
-#target arm966e <endianness> <reset mode> <chainpos> <variant>
-target arm966e little reset_halt 1 arm966e
-run_and_halt_time 0 30
- 
-working_area 0 0x50000000 16384 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank str9x 0x00000000 0x00080000 0 0 0
-@end smallexample
-
-@section STR912 comstick
-@cindex STR912 comstick Script
-The following script was used with a Hitex STR9 Comstick:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "STR9-comStick A"
-ft2232_layout comstick
-jtag_speed 1
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
- 
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 8 0x1 0x1 0xfe
-jtag_device 4 0x1 0xf 0xe
-jtag_device 5 0x1 0x1 0x1e
- 
-#target configuration
-daemon_startup reset
- 
-#target <type> <startup mode>
-#target arm966e <endianness> <reset mode> <chainpos> <variant>
-target arm966e little reset_halt 1 arm966e
-run_and_halt_time 0 30
- 
-working_area 0 0x50000000 16384 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank str9x 0x00000000 0x00080000 0 0 0
-@end smallexample
-
-@section STM32x Script
-@cindex STM32x Script
-The following script was used with an Amontec JTAGkey and a STM32x cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-jtag_speed 10
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
- 
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 4 0x1 0xf 0xe
-jtag_device 5 0x1 0x1 0x1e
- 
-#target configuration
-daemon_startup reset
- 
-#target <type> <startup mode>
-#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>
-target cortex_m3 little run_and_halt 0
-run_and_halt_time 0 30
- 
-working_area 0 0x20000000 16384 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank stm32x 0x08000000 0x00020000 0 0 0
-@end smallexample
-
-@section STM32x Performance Stick
-@cindex STM32x Performance Stick Script
-The following script was used with the Hitex STM32 Performance Stick
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "STM32-PerformanceStick A"
-ft2232_layout stm32stick
-jtag_speed 10
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
- 
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 4 0x1 0xf 0xe
-jtag_device 5 0x1 0x1 0x1e
-jtag_device 4 0x1 0xf 0xe
- 
-#target configuration
-daemon_startup reset
- 
-#target <type> <startup mode>
-#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>
-target cortex_m3 little run_and_halt 0
-run_and_halt_time 0 30
- 
-working_area 0 0x20000000 16384 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank stm32x 0x08000000 0x00020000 0 0 0
-@end smallexample
-
-@section LPC2129 Script
-@cindex LPC2129 Script
-The following script was used with an wiggler PP and a LPC-2129 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface parport
-parport_port 0x378
-parport_cable wiggler
-jtag_speed 0
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
- 
-#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 <type> <startup mode>
-#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
-run_and_halt_time 0 30
- 
-working_area 0 0x40000000 0x4000 nobackup
- 
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
-@end smallexample
-
-@section  LPC2148 Script
-@cindex  LPC2148 Script
-The following script was used with an Amontec JTAGkey and a LPC2148 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 3
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
- 
-#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 <type> <startup mode>
-#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
-run_and_halt_time 0 30
- 
-working_area 0 0x40000000 0x8000 nobackup
- 
-#flash configuration
-flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v1 14765 calc_checksum
-@end smallexample
-
-@section  LPC2294 Script
-@cindex  LPC2294 Script
-The following script was used with an Amontec JTAGkey and a LPC2294 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 3
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst srst_pulls_trst
- 
-#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 <type> <startup mode>
-#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
-run_and_halt_time 0 30
- 
-working_area 0 0x40000000 0x4000 nobackup
- 
-#flash configuration
-flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum
-@end smallexample
-
-@section AT91R40008 Script
-@cindex AT91R40008 Script
-The following script was used with an Amontec JTAGkey and a AT91R40008 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 0
-jtag_nsrst_delay 200
-jtag_ntrst_delay 200
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config srst_only srst_pulls_trst
- 
-#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 <type> <startup mode>
-#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi
-run_and_halt_time 0 30
-@end smallexample
-
-@section AT91SAM7s Script
-@cindex AT91SAM7s Script
-The following script was used with an Olimex ARM-JTAG-OCD and a AT91SAM7S64 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-ft2232_device_desc "Olimex OpenOCD JTAG A"
-ft2232_layout olimex-jtag
-ft2232_vid_pid 0x15BA 0x0003
-jtag_speed 0
-jtag_nsrst_delay 200
-jtag_ntrst_delay 200
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config srst_only srst_pulls_trst
- 
-#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 <type> <startup mode>
-#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>
-target arm7tdmi little run_and_halt 0 arm7tdmi
-run_and_halt_time 0 30
- 
-# flash-options AT91
-working_area 0 0x00200000 0x4000 nobackup
-flash bank at91sam7 0 0 0 0 0
- 
-# Information: 
-# erase command (telnet-interface) for complete flash:
-# flash erase <num> 0 numlockbits-1 (can be seen from output of flash info 0)
-# SAM7S64 with 16 lockbits and bank 0: flash erase 0 0 15
-# set/clear NVM-Bits:
-# at91sam7 gpnvm <num> <bit> <set|clear>
-# disable locking from SAM-BA:
-# flash protect 0 0 1 off
-@end smallexample
-
-@section XSCALE IXP42x Script
-@cindex XSCALE IXP42x Script
-The following script was used with an Amontec JTAGkey-Tiny and a xscale ixp42x cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
-
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 0
-jtag_nsrst_delay 200
-jtag_ntrst_delay 200
- 
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config srst_only srst_pulls_trst
- 
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 7 0x1 0x7f 0x7e
- 
-#target configuration
-daemon_startup reset
- 
-#target <type> <startup mode>
-#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
-target xscale big run_and_halt 0 IXP42x
-run_and_halt_time 0 30
-@end smallexample
-
-@section Cirrus Logic EP9301 Script
-@cindex Cirrus Logic EP9301 Script
-The following script was used with FT2232 based JTAG interfaces and a
-Cirrus Logic EP9301 processor on an Olimex CS-E9301 board.
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
- 
-#interface
-interface ft2232
-
-#Olimex ARM-USB-OCD
-#ft2232_device_desc "Olimex OpenOCD JTAG"
-#ft2232_layout olimex-jtag
-#ft2232_vid_pid 0x15ba 0x0003
- 
-#Amontec JTAGkey (and JTAGkey-Tiny)
-#Serial is only necessary if more than one JTAGkey is connected
-ft2232_device_desc "Amontec JTAGkey A"
-#ft2232_serial AMTJKV31
-#ft2232_serial T1P3S2W8
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
- 
-#wiggler/parallel port interface
-#interface parport
-#parport_port 0x378
-#parport_cable wiggler
-#jtag_speed 0
-jtag_speed 1
-reset_config trst_and_srst
- 
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 4 0x1 0xf 0xe
- 
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
- 
-#target configuration
-daemon_startup attach
- 
-#target <type> <endianess> <reset mode>
-target arm920t little reset_halt 0
-working_area 0 0x80014000 0x1000 backup
- 
-#flash configuration
-#flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...]
-flash bank cfi 0x60000000 0x1000000 2 2 0
-@end smallexample
-
-@section Hilscher netX 100 / 500 Script
-@cindex Hilscher netX 100 / 500 Script
-The following script was used with an Amontec JTAGkey and a Hilscher
-netX 500 cpu:
-@smallexample
-#daemon configuration
-telnet_port 4444
-gdb_port 3333
-
-#interface
-interface ft2232
-ft2232_device_desc "Amontec JTAGkey A"
-ft2232_layout jtagkey
-ft2232_vid_pid 0x0403 0xcff8
-jtag_speed 5
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst
-
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 4 0x1 0xf 0xe
-
-jtag_nsrst_delay 100
-jtag_ntrst_delay 100
-
-#target configuration
-daemon_startup reset
-
-#target <type> <endianness> <startup mode> <chainpos> <variant>
-target arm926ejs little run_and_halt 0 arm926ejs
-run_and_halt_time 0 500
-@end smallexample
-
-@section Marvell/Intel PXA270 Script
-@cindex Marvell/Intel PXA270 Script
-@smallexample
-# config for Intel PXA270
-# not, as of 2007-06-22, openocd only works with the
-# libftd2xx library from ftdi.  libftdi does not work.
-
-telnet_port	3333
-gdb_port	4444
-
-interface ft2232
-ft2232_layout olimex-jtag
-ft2232_vid_pid 0x15BA 0x0003
-ft2232_device_desc "Olimex OpenOCD JTAG"
-jtag_speed 0
-# set jtag_nsrst_delay to the delay introduced by your reset circuit
-# the rest of the needed delays are built into the openocd program
-jtag_nsrst_delay 260
-# set the jtag_ntrst_delay to the delay introduced by a reset circuit
-# the rest of the needed delays are built into the openocd program
-jtag_ntrst_delay 0
-
-#use combined on interfaces or targets that can't set TRST/SRST separately
-reset_config trst_and_srst separate
-
-#jtag scan chain
-#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
-jtag_device 7 0x1 0x7f 0x7e
-
-#target configuration
-daemon_startup reset
-
-target xscale little reset_halt 0 pxa27x
-
-# maps to PXA internal RAM.  If you are using a PXA255
-# you must initialize SDRAM or leave this option off
-working_area 0 0x5c000000 0x10000 nobackup
-
-run_and_halt_time 0 30
-
-#flash bank <driver> <base> <size> <chip_width> <bus_width>
-# works for P30 flash
-flash bank cfi 0x00000000 0x1000000 2 4 0
-@end smallexample
-
-@node GDB and Openocd
-@chapter GDB and Openocd
-@cindex GDB and Openocd
-Openocd complies with the remote gdbserver protocol, and as such can be used
-to debug remote targets.
-
-@section Connecting to gdb
-@cindex Connecting to gdb
-A connection is typically started as follows:
-@smallexample
-target remote localhost:3333
-@end smallexample
-This would cause gdb to connect to the gdbserver on the local pc using port 3333.
-
-To see a list of available openocd commands type @option{monitor help} on the
-gdb commandline.
-
-Openocd supports the gdb @option{qSupported} packet, this enables information
-to be sent by the gdb server (openocd) to gdb. Typical information includes
-packet size and device memory map.
-
-Previous versions of openocd required the following gdb options to increase
-the packet size and speed up gdb communication.
-@smallexample
-set remote memory-write-packet-size 1024
-set remote memory-write-packet-size fixed
-set remote memory-read-packet-size 1024
-set remote memory-read-packet-size fixed
-@end smallexample
-This is now handled in the @option{qSupported} PacketSize.
-
-@section Programming using gdb
-@cindex Programming using gdb
-
-By default the target memory map is not sent to gdb, this can be enabled by
-the following openocd config option:
-@smallexample
-gdb_memory_map enable
-@end smallexample
-For this to function correctly a valid flash config must also be configured
-in openocd. For speed also configure a valid working area.
-
-Informing gdb of the memory map of the target will enable gdb to protect any
-flash area of the target and use hardware breakpoints by default. This means
-that the openocd option @option{arm7_9 force_hw_bkpts} is not required when
-using a memory map.
-
-To view the configured memory map in gdb, use the gdb command @option{info mem}
-All other unasigned addresses within gdb are treated as ram.
-
-If @option{gdb_flash_program enable} is also used, gdb will be able to
-program any flash memory using the vFlash interface.
-
-gdb will look at the target memory map when a load command is given, if any
-areas to be programmed lie within the target flash area the vFlash packets
-will be used.
-
-Incase the target needs configuring before gdb programming, a script can be executed.
-@smallexample
-target_script 0 gdb_program_config config.script
-@end smallexample
-
-To verify any flash programming the gdb command @option{compare-sections}
-can be used.
-
-@node FAQ
-@chapter FAQ
-@cindex faq
-@enumerate
-@item OpenOCD complains about a missing cygwin1.dll
-
-Make sure you have Cygwin installed, or at least a version of OpenOCD that
-claims to come with all the necessary dlls. When using Cygwin, try launching
-the OpenOCD from the Cygwin shell.
-
-@item I'm trying to set a breakpoint using GDB (or a frontend like Insight or
-Eclipse), but OpenOCD complains that "Info: arm7_9_common.c:213
-arm7_9_add_breakpoint(): sw breakpoint requested, but software breakpoints not enabled".
-
-GDB issues software breakpoints when a normal breakpoint is requested, or to implement
-source-line single-stepping. On ARMv4T systems, like ARM7TDMI, ARM720t or ARM920t,
-software breakpoints consume one of the two available hardware breakpoints,
-and are therefor disabled by default. If your code is running from RAM, you
-can enable software breakpoints with the @option{arm7_9 sw_bkpts enable} command. If
-your code resides in Flash, you can't use software breakpoints, but you can force
-OpenOCD to use hardware breakpoints instead: @option{arm7_9 force_hw_bkpts enable}.
-
-@item When erasing or writing LPC2000 on-chip flash, the operation fails sometimes
-and works sometimes fine.
-
-Make sure the core frequency specified in the @option{flash lpc2000} line matches the
-clock at the time you're programming the flash. If you've specified the crystal's
-frequency, make sure the PLL is disabled, if you've specified the full core speed
-(e.g. 60MHz), make sure the PLL is enabled.
-
-@item When debugging using an Amontec Chameleon in its JTAG Accelerator configuration,
-I keep getting "Error: amt_jtagaccel.c:184 amt_wait_scan_busy(): amt_jtagaccel timed
-out while waiting for end of scan, rtck was disabled".
-
-Make sure your PC's parallel port operates in EPP mode. You might have to try several
-settings in your PC Bios (ECP, EPP, and different versions of those).
-
-@item When debugging with the OpenOCD and GDB (plain GDB, Insight, or Eclipse),
-I get lots of "Error: arm7_9_common.c:1771 arm7_9_read_memory():
-memory read caused data abort". 
-
-The errors are non-fatal, and are the result of GDB trying to trace stack frames
-beyond the last valid frame. It might be possible to prevent this by setting up
-a proper "initial" stack frame, if you happen to know what exactly has to
-be done, feel free to add this here.
-
-@item I get the following message in the OpenOCD console (or log file):
-"Warning: arm7_9_common.c:679 arm7_9_assert_reset(): srst resets test logic, too".
-
-This warning doesn't indicate any serious problem, as long as you don't want to
-debug your core right out of reset. Your .cfg file specified @option{jtag_reset
-trst_and_srst srst_pulls_trst} to tell the OpenOCD that either your board,
-your debugger or your target uC (e.g. LPC2000) can't assert the two reset signals
-independently. With this setup, it's not possible to halt the core right out of
-reset, everything else should work fine.
-
-@item When using OpenOCD in conjunction with Amontec JTAGkey and the Yagarto
-Toolchain (Eclipse, arm-elf-gcc, arm-elf-gdb), the debugging seems to be
-unstable. When single-stepping over large blocks of code, GDB and OpenOCD
-quit with an error message. Is there a stability issue with OpenOCD?
-
-No, this is not a stability issue concering OpenOCD. Most users have solved
-this issue by simply using a self-powered USB Hub, which they connect their
-Amontec JTAGkey to. Apparently, some computers do not provide a USB power
-supply stable enough for the Amontec JTAGkey to be operated.
-
-@item When using the Amontec JTAGkey, sometimes OpenOCD crashes with the
-following error messages: "Error: ft2232.c:201 ft2232_read(): FT_Read returned:
-4" and "Error: ft2232.c:365 ft2232_send_and_recv(): couldn't read from FT2232".
-What does that mean and what might be the reason for this?
-
-First of all, the reason might be the USB power supply. Try using a self-powered
-hub instead of a direct connection to your computer. Secondly, the error code 4
-corresponds to an FT_IO_ERROR, which means that the driver for the FTDI USB
-Chip ran into some sort of error - this points us to a USB problem.
-
-@item When using the Amontec JTAGkey, sometimes OpenOCD crashes with the following
-error message: "Error: gdb_server.c:101 gdb_get_char(): read: 10054".
-What does that mean and what might be the reason for this?
-
-Error code 10054 corresponds to WSAECONNRESET, which means that the debugger (GDB)
-has closed the connection to OpenOCD. This might be a GDB issue.
-
-@item 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 lpc2000_v1 0 14746 calc_checksum}),
-which must be sepcified 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 clock frequency?
-
-No. The clock frequency specified here must be given as an integral number.
-However, this clock frequency is used by the In-Application-Programming (IAP)
-routines of the LPC2000 family only, which seems to be very tolerant concerning
-the given clock frequency, so a slight difference between the specified clock
-frequency and the actual clock frequency will not cause any trouble.
-
-@item Do I have to keep a specific order for the commands in the configuration file?
-
-Well, yes and no. Commands can be given in arbitrary order, yet the devices
-listed for the JTAG scan chain must be given in the right order (jtag_device),
-with the device closest to the TDO-Pin being listed first. In general,
-whenever objects of the same type exist which require an index number, then
-these objects must be given in the right order (jtag_devices, targets and flash
-banks - a target references a jtag_device and a flash bank references a target).
-
-@item Sometimes my debugging session terminates with an error. When I look into the
-log file, I can see these error messages: Error: arm7_9_common.c:561
-arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP
-							
-@end enumerate
-
-@include fdl.texi
-
-@node Index
-@unnumbered Index
-
-@printindex cp
-
-@bye
+\input texinfo	@c -*-texinfo-*-

+@c %**start of header

+@setfilename openocd.info

+@settitle Open On-Chip Debugger (openocd)

+@c %**end of header

+

+@include version.texi

+

+@titlepage

+@title Open On-Chip Debugger (openocd)

+@subtitle Edition @value{EDITION} for openocd version @value{VERSION}

+@subtitle @value{UPDATED}

+@page

+@vskip 0pt plus 1filll

+@end titlepage

+

+@contents

+

+@node Top, About, , (dir)

+@top OpenOCD

+

+This is edition @value{EDITION} of the openocd manual for version

+@value{VERSION}, @value{UPDATED}

+

+@menu

+* About::             About Openocd.

+* Developers::        

+* Building::          Building Openocd

+* Running::           Running Openocd

+* Configuration::     Openocd Configuration.

+* Commands::          Openocd Commands

+* Sample Scripts::    Sample Target Scripts

+* GDB and Openocd::   Using GDB and Openocd

+* FAQ::               Frequently Asked Questions

+* License::           GNU Free Documentation License

+* Index::             Main index.

+@end menu

+

+@node About

+@unnumbered About

+@cindex about

+

+The Open On-Chip Debugger (openocd) aims to provide debugging, in-system programming

+and boundary-scan testing for embedded target devices. The targets are interfaced

+using JTAG (IEEE 1149.1) compliant hardware, but this may be extended to other

+connection types in the future.

+

+Openocd currently supports Wiggler (clones), FTDI FT2232 based JTAG interfaces, the

+Amontec JTAG Accelerator, and the Gateworks GW1602. It allows ARM7 (ARM7TDMI and ARM720t),

+ARM9 (ARM920t, ARM922t, ARM926ej--s, ARM966e--s), XScale (PXA25x, IXP42x) and

+Cortex-M3 (Luminary Stellaris LM3 and ST STM32) based cores to be debugged.

+

+Flash writing is supported for external CFI compatible flashes (Intel and AMD/Spansion

+command set) and several internal flashes (LPC2000, AT91SAM7, STR7x, STR9x, LM3

+and STM32x). Preliminary support for using the LPC3180's NAND flash controller is included.

+

+@node Developers

+@chapter Developers

+@cindex developers

+

+Openocd has been created by Dominic Rath as part of a diploma thesis written at the

+University of Applied Sciences Augsburg (@uref{http://www.fh-augsburg.de}).

+Others interested in improving the state of free and open debug and testing technology

+are welcome to participate.

+

+Other developers have contributed support for additional targets and flashes as well

+as numerous bugfixes and enhancements. See the AUTHORS file for regular contributors. 

+

+@node Building

+@chapter Building

+@cindex building openocd

+

+You can download the current SVN version with 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 could use the following command to fetch the

+latest version (make sure there is no (non-svn) directory called "openocd" in the

+current directory):

+

+@smallexample

+ svn checkout svn://svn.berlios.de/openocd/trunk

+@end smallexample

+

+Building the OpenOCD requires a recent version of the GNU autotools.

+On my build system, I'm using autoconf 2.13 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})

+@item When using the Amontec JTAGkey, you have to get the drivers from the Amontec

+homepage (@uref{www.amontec.com}), as the JTAGkey uses a non-standard VID/PID. 

+@end itemize

+

+Please note that the ftdi2232 variant (using libftdi) isn't supported under Cygwin.

+You have to use the ftd2xx variant (using FTDI's D2XX) on Cygwin.

+

+In general, the D2XX driver provides superior performance (several times as fast),

+but has the draw-back of being binary-only - though that isn't as worse, as it isn't

+a kernel module, only a user space library.

+

+To build OpenOCD (on both Linux and Cygwin), use the following commands:

+@smallexample

+ ./bootstrap 

+@end smallexample

+Bootstrap generates the configure script, and prepares building on your system.

+@smallexample

+ ./configure 

+@end smallexample

+Configure generates the Makefiles used to build OpenOCD

+@smallexample

+ make 

+@end smallexample

+Make builds the OpenOCD, and places the final executable in ./src/

+

+The configure script takes several options, specifying which JTAG interfaces

+should be included:

+

+@itemize @bullet

+@item

+--enable-parport

+@item

+--enable-parport_ppdev

+@item

+--enable-amtjtagaccel

+@item

+--enable-ft2232_ftd2xx

+@footnote{Using the latest D2XX drivers from FTDI and following their installation

+instructions, I had to use @option{--enable-ft2232_libftd2xx} for the OpenOCD to

+build properly}

+@item

+--enable-ft2232_libftdi

+@item

+--with-ftd2xx=/path/to/d2xx/

+@end itemize

+

+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).

+

+Cygwin users have to specify the location of the FTDI D2XX package. This should be an

+absolute path containing no spaces.

+

+Linux users should copy the various parts of the D2XX package to the appropriate

+locations, i.e. /usr/include, /usr/lib. 

+

+@node Running

+@chapter Running

+@cindex running openocd

+@cindex --configfile

+@cindex --debug_level

+@cindex --logfile

+@cindex --search

+The OpenOCD runs as a daemon, waiting for connections from clients (Telnet or GDB).

+Run with @option{--help} or @option{-h} to view the available command line arguments.

+

+It reads its configuration by default from the file openocd.cfg located in the current

+working directory. This may be overwritten with the @option{-f <configfile>} command line

+switch.

+

+To enable debug output (when reporting problems or working on OpenOCD itself), use

+the @option{-d} command line switch. This sets the debug_level to "3", outputting

+the most information, including debug messages. The default setting is "2", outputting

+only informational messages, warnings and errors. You can also change this setting

+from within a telnet or gdb session (@option{debug_level <n>}).

+

+You can redirect all output from the daemon to a file using the @option{-l <logfile>} switch.

+

+Search paths for config/script files can be added to openocd by using

+the @option{-s <search>} switch.

+

+@node Configuration

+@chapter Configuration

+@cindex configuration

+The Open On-Chip Debugger (OpenOCD) runs as a daemon, and reads it current configuration

+by default from the file openocd.cfg in the current directory. A different configuration

+file can be specified with the  @option{-f <conf.file>} given at the openocd command line.

+

+The configuration file is used to specify on which ports the daemon listens for new

+connections, the JTAG interface used to connect to the target, the layout of the JTAG

+chain, the targets that should be debugged, and connected flashes.

+

+@section Daemon configuration

+

+@itemize @bullet

+@item @b{telnet_port} <@var{number}>

+@cindex telnet_port

+Port on which to listen for incoming telnet connections 

+@item @b{gdb_port} <@var{number}>

+@cindex gdb_port

+First port on which to listen 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. 

+@item @b{gdb_detach} <@var{resume|reset|halt|nothing}>

+@cindex gdb_detach

+Configures what openocd will do when gdb detaches from the daeman.

+Default behaviour is <@var{resume}>

+@item @b{gdb_memory_map} <@var{enable|disable}>

+@cindex gdb_memory_map

+Set to <@var{enable}> so that openocd will 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. @option{gdb_flash_program enable} will also need enabling

+for flash programming to work.

+Default behaviour is <@var{disable}>

+@item @b{gdb_flash_program} <@var{enable|disable}>

+@cindex gdb_flash_program

+Set to <@var{enable}> so that openocd will program the flash memory when a

+vFlash packet is received.

+Default behaviour is <@var{disable}>

+@item @b{daemon_startup} <@var{mode}> either @samp{attach} or @samp{reset}

+@cindex daemon_startup

+Tells the OpenOCD whether it should reset the target when the daemon is launched, or

+if it should just attach to the target. 

+@end itemize

+

+@section JTAG interface configuration

+

+@itemize @bullet

+@item @b{interface} <@var{name}>

+@cindex interface

+Use the interface driver <@var{name}> to connect to the target. Currently supported

+interfaces are

+@itemize @minus

+@item parport

+PC parallel port bit-banging (Wigglers, PLD download cable, ...)

+@end itemize

+@itemize @minus

+@item amt_jtagaccel

+Amontec Chameleon in its JTAG Accelerator configuration connected to a PC's EPP

+mode parallel port

+@end itemize

+@itemize @minus

+@item ft2232

+FTDI FT2232 based devices using either the open-source libftdi or the binary only

+FTD2XX driver. The FTD2XX is superior in performance, but not available on every

+platform. The libftdi uses libusb, and should be portable to all systems that provide

+libusb.

+@end itemize

+@itemize @minus

+@item ep93xx

+Cirrus Logic EP93xx based single-board computer bit-banging (in development)

+@end itemize

+@end itemize

+

+@itemize @bullet

+@item @b{jtag_speed} <@var{number}>

+@cindex jtag_speed

+Limit the maximum speed of the JTAG interface. Usually, a value of zero means maximum

+speed. The actual effect of this option depends on the JTAG interface used.

+

+@itemize @minus

+@item wiggler: maximum speed / @var{number}

+@item ft2232: 6MHz / (@var{number}+1)

+@item amt jtagaccel: 8 / 2**@var{number}

+@end itemize

+

+Note: Make sure the jtag clock is no more than @math{1/6th × CPU-Clock}. This is

+especially true for synthesized cores (-S).

+

+@item @b{reset_config} <@var{signals}> [@var{combination}] [@var{trst_type}] [@var{srst_type}]

+@cindex reset_config

+The configuration of the reset signals available on the JTAG interface AND the target.

+If the JTAG interface provides SRST, but the target doesn't connect that signal properly,

+then OpenOCD can't use it. <@var{signals}> can be @samp{none}, @samp{trst_only},

+@samp{srst_only} or @samp{trst_and_srst}.

+[@var{combination}] is an optional value specifying broken reset signal implementations.

+@samp{srst_pulls_trst} states that the testlogic is reset together with the reset of

+the system (e.g. Philips LPC2000, "broken" board layout), @samp{trst_pulls_srst} says

+that the system is reset together with the test logic (only hypothetical, I haven't

+seen hardware with such a bug, and can be worked around).

+

+The [@var{trst_type}] and [@var{srst_type}] parameters allow the driver type of the

+reset lines to be specified. Possible values are @samp{trst_push_pull} (default)

+and @samp{trst_open_drain} for the test reset signal, and @samp{srst_open_drain}

+(default) and @samp{srst_push_pull} for the system reset. These values only affect

+JTAG interfaces with support for different drivers, like the Amontec JTAGkey and JTAGAccelerator. 

+

+@item @b{jtag_device} <@var{IR length}> <@var{IR capture}> <@var{IR mask}> <@var{IDCODE instruction}>

+@cindex jtag_device

+Describes the devices that form the JTAG daisy chain, with the first device being

+the one closest to TDO. The parameters are the length of the instruction register

+(4 for all ARM7/9s), the value captured during Capture-IR (0x1 for ARM7/9), and a mask

+of bits that should be validated when doing IR scans (all four bits (0xf) for ARM7/9).

+The IDCODE instruction will in future be used to query devices for their JTAG

+identification code. This line is the same for all ARM7 and ARM9 devices.

+Other devices, like CPLDs, require different parameters. An example configuration

+line for a Xilinx XC9500 CPLD would look like this:

+@smallexample

+jtag_device 8 0x01 0x0e3 0xfe

+@end smallexample

+The instruction register (IR) is 8 bits long, during Capture-IR 0x01 is loaded into

+the IR, but only bits 0-1 and 5-7 should be checked, the others (2-4) might vary.

+The IDCODE instruction is 0xfe.

+

+@item @b{jtag_nsrst_delay} <@var{ms}>

+@cindex jtag_nsrst_delay

+How long (in miliseconds) the OpenOCD should wait after deasserting nSRST before

+starting new JTAG operations. 

+@item @b{jtag_ntrst_delay} <@var{ms}>

+@cindex jtag_ntrst_delay

+How long (in miliseconds) the OpenOCD should wait after deasserting nTRST before

+starting new JTAG operations. 

+

+The jtag_n[st]rst_delay options are useful if reset circuitry (like a reset supervisor,

+or on-chip features) keep a reset line asserted for some time after the external reset

+got deasserted.

+@end itemize

+

+@section parport options

+

+@itemize @bullet

+@item @b{parport_port} <@var{number}>

+@cindex parport_port

+Either the address of the I/O port (default: 0x378 for LPT1) or the number of

+the @file{/dev/parport} device

+

+When using PPDEV to access the parallel port, use the number of the parallel port:

+@option{parport_port 0} (the default). If @option{parport_port 0x378} is specified

+you may encounter a problem.

+@item @b{parport_cable} <@var{name}>

+@cindex parport_cable

+The layout of the parallel port cable used to connect to the target.

+Currently supported cables are 

+@itemize @minus

+@item wiggler

+@cindex wiggler

+Original Wiggler layout, also supported by several clones, such

+as the Olimex ARM-JTAG

+@item old_amt_wiggler

+@cindex old_amt_wiggler

+The Wiggler configuration that comes with Amontec's Chameleon Programmer. The new

+version available from the website uses the original Wiggler layout ('@var{wiggler}')

+@item chameleon

+@cindex chameleon

+Describes the connection of the Amontec Chameleon's CPLD when operated in

+configuration mode. This is only used to program the Chameleon itself, not

+a connected target.

+@item dlc5

+@cindex dlc5

+Xilinx Parallel cable III.

+@item triton

+@cindex triton

+The parallel port adapter found on the 'Karo Triton 1 Development Board'.

+This is also the layout used by the HollyGates design

+(see @uref{http://www.lartmaker.nl/projects/jtag/}).

+@item flashlink

+@cindex flashlink

+ST Parallel cable. 

+@end itemize

+@item @b{parport_write_on_exit} <@var{on|off}>

+@cindex parport_write_on_exit

+This will configure the parallel driver to write a known value to the parallel

+interface on exiting openocd

+@end itemize

+

+@section amt_jtagaccel options

+@itemize @bullet

+@item @b{parport_port} <@var{number}>

+@cindex parport_port

+Either the address of the I/O port (default: 0x378 for LPT1) or the number of the

+@file{/dev/parport} device 

+@end itemize

+@section ft2232 options

+

+@itemize @bullet

+@item @b{ft2232_device_desc} <@var{description}>

+@cindex ft2232_device_desc

+The USB device description of the FTDI FT2232 device. If not specified, the FTDI

+default value is used. This setting is only valid if compiled with FTD2XX support.

+@item @b{ft2232_layout} <@var{name}>

+@cindex ft2232_layout

+The layout of the FT2232 GPIO signals used to control output-enables and reset

+signals. Valid layouts are

+@itemize @minus

+@item usbjtag

+The "USBJTAG-1" layout described in the original OpenOCD diploma thesis

+@item jtagkey

+Amontec JTAGkey and JTAGkey-tiny

+@item signalyzer

+Signalyzer

+@item olimex-jtag

+Olimex ARM-USB-OCD

+@item m5960

+American Microsystems M5960

+@item evb_lm3s811

+Luminary Micro EVB_LM3S811 as a JTAG interface (not onboard processor), no TRST or

+SRST signals on external connector

+@item comstick

+Hitex STR9 comstick 

+@item stm32stick

+Hitex STM32 Performance Stick

+@item flyswatter

+Tin Can Tools Flyswatter

+@item turtelizer2

+egnite Software turtelizer2

+@item oocdlink

+OOCDLink

+@end itemize

+

+@item @b{ft2232_vid_pid} <@var{vid}> <@var{pid}>

+The vendor ID and product ID of the FTDI FT2232 device. If not specified, the FTDI

+default values are used. This command is not available on Windows. 

+@item @b{ft2232_latency} <@var{ms}>

+On some systems using ft2232 based JTAG interfaces the FT_Read function call in

+ft2232_read() fails to return the expected number of bytes. This can be caused by

+USB communication delays and has proved hard to reproduce and debug. Setting the

+FT2232 latency timer to a larger value increases delays for short USB packages but it

+also reduces the risk of timeouts before receiving the expected number of bytes.

+The OpenOCD default value is 2 and for some systems a value of 10 has proved useful. 

+@end itemize

+

+@section ep93xx options

+@cindex ep93xx options

+Currently, there are no options available for the ep93xx interface.

+

+@page

+@section Target configuration

+

+@itemize @bullet

+@item @b{target} <@var{type}> <@var{endianess}> <@var{reset_mode}> <@var{JTAG pos}>

+<@var{variant}>

+@cindex target

+Defines a target that should be debugged. Currently supported types are:

+@itemize @minus

+@item arm7tdmi

+@item arm720t

+@item arm9tdmi

+@item arm920t

+@item arm922t

+@item arm926ejs

+@item arm966e

+@item cortex_m3

+@item feroceon 

+@item xscale 

+@end itemize

+

+If you want to use a target board that is not on this list, see Adding a new

+target board

+

+Endianess may be @option{little} or @option{big}.

+

+The reset_mode specifies what should happen to the target when a reset occurs:

+@itemize @minus

+@item reset_halt

+@cindex reset_halt

+Immediately request a target halt after reset. This allows targets to be debugged

+from the very first instruction. This is only possible with targets and JTAG

+interfaces that correctly implement the reset signals.

+@item reset_init

+@cindex reset_init

+Similar to @option{reset_halt}, but executes the script file defined to handle the

+'reset' event for the target. Like @option{reset_halt} this only works with

+correct reset implementations.

+@item reset_run

+@cindex reset_run

+Simply let the target run after a reset.

+@item run_and_halt

+@cindex run_and_halt

+Let the target run for some time (default: 1s), and then request halt.

+@item run_and_init

+@cindex run_and_init

+A combination of @option{reset_init} and @option{run_and_halt}. The target is allowed

+to run for some time, then halted, and the @option{reset} event script is executed. 

+@end itemize

+

+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

+@option{reset_halt} or @option{reset_init}.

+

+@item @b{target_script} <@var{target#}> <@var{event}> <@var{script_file}>

+@cindex target_script

+Event is either @option{reset}, @option{post_halt}, @option{pre_resume} or @option{gdb_program_config}

+

+TODO: describe exact semantic of events

+@item @b{run_and_halt_time} <@var{target#}> <@var{time_in_ms}>

+@cindex run_and_halt_time

+The amount of time the debugger should wait after releasing reset before it asserts

+a debug request. This is used by the @option{run_and_halt} and @option{run_and_init}

+reset modes. 

+@item @b{working_area} <@var{target#}> <@var{address}> <@var{size}>

+<@var{backup}|@var{nobackup}>

+@cindex working_area

+Specifies a working area for the debugger to use. This may be used to speed-up

+downloads to target memory and flash operations, or to perform otherwise unavailable

+operations (some coprocessor operations on ARM7/9 systems, for example). The last

+parameter decides whether the memory should be preserved <@var{backup}>. If possible, use

+a working_area that doesn't need to be backed up, as that slows down operation. 

+@end itemize

+

+@subsection arm7tdmi options

+@cindex arm7tdmi options

+target arm7tdmi <@var{endianess}> <@var{reset_mode}> <@var{jtag#}>

+The arm7tdmi target definition requires at least one additional argument, specifying

+the position of the target in the JTAG daisy-chain. The first JTAG device is number 0.

+The optional [@var{variant}] parameter has been removed in recent versions.

+The correct feature set is determined at runtime. 

+

+@subsection arm720t options

+@cindex arm720t options

+ARM720t options are similar to ARM7TDMI options.

+

+@subsection arm9tdmi options

+@cindex arm9tdmi options

+ARM9TDMI options are similar to ARM7TDMI options. Supported variants are

+@option{arm920t}, @option{arm922t} and @option{arm940t}.

+This enables the hardware single-stepping support found on these cores.

+

+@subsection arm920t options

+@cindex arm920t options

+ARM920t options are similar to ARM9TDMI options.

+

+@subsection arm966e options

+@cindex arm966e options

+ARM966e options are similar to ARM9TDMI options.

+

+@subsection xscale options

+@cindex xscale options

+Supported variants are @option{ixp42x}, @option{ixp45x}, @option{ixp46x},

+@option{pxa250}, @option{pxa255}, @option{pxa26x}.

+

+@section Flash configuration

+@cindex Flash configuration

+

+@itemize @bullet

+@item @b{flash bank} <@var{driver}> <@var{base}> <@var{size}> <@var{chip_width}>

+<@var{bus_width}> <@var{target#}> [@var{driver_options ...}]

+@cindex flash bank

+Configures a flash bank at <@var{base}> of <@var{size}> bytes and <@var{chip_width}>

+and <@var{bus_width}> bytes using the selected flash <driver>.

+

+@item @b{flash auto_erase} <@option{on}|@option{off}>

+@cindex flash auto_erase

+auto erase flash banks prior to writing. Currently only works when using

+@option{flash write_image} command. Default is @option{off}.

+@end itemize

+

+@subsection lpc2000 options

+@cindex lpc2000 options

+

+@b{flash bank lpc2000} <@var{base}> <@var{size}> 0 0 <@var{target#}> <@var{variant}>

+<@var{clock}> [@var{calc_checksum}]

+LPC flashes don't require the chip and bus width to be specified. Additional

+parameters are the <@var{variant}>, which may be @var{lpc2000_v1} (older LPC21xx and LPC22xx)

+or @var{lpc2000_v2} (LPC213x, LPC214x, LPC210[123], LPC23xx and LPC24xx), the number

+of the target this flash belongs to (first is 0), the frequency at which the core

+is currently running (in kHz - must be an integral number), and the optional keyword

+@var{calc_checksum}, telling the driver to calculate a valid checksum for the exception

+vector table. 

+

+@subsection cfi options

+@cindex cfi options

+

+@b{flash bank cfi} <@var{base}> <@var{size}> <@var{chip_width}> <@var{bus_width}>

+<@var{target#}>

+CFI flashes require the number of the target they're connected to as an additional

+argument. The CFI driver makes use of a working area (specified for the target)

+to significantly speed up operation. 

+

+@var{chip_width} and @var{bus_width} are specified in bytes.

+

+@subsection at91sam7 options

+@cindex at91sam7 options

+

+@b{flash bank at91sam7} 0 0 0 0 <@var{target#}>

+AT91SAM7 flashes only require the @var{target#}, all other values are looked up after

+reading the chip-id and type. 

+

+@subsection str7 options

+@cindex str7 options

+

+@b{flash bank str7x} <@var{base}> <@var{size}> 0 0 <@var{target#}> <@var{variant}>

+variant can be either STR71x, STR73x or STR75x. 

+

+@subsection str9 options

+@cindex str9 options

+

+@b{flash bank str9x} <@var{base}> <@var{size}> 0 0 <@var{target#}>

+The str9 needs the flash controller to be configured prior to Flash programming, eg.

+@smallexample

+str9x flash_config 0 4 2 0 0x80000

+@end smallexample

+This will setup the BBSR, NBBSR, BBADR and NBBADR registers respectively. 

+

+@subsection str9 options (str9xpec driver)

+

+@b{flash bank str9xpec} <@var{base}> <@var{size}> 0 0 <@var{target#}>

+Before using the flash commands the turbo mode will need enabling using str9xpec

+@option{enable_turbo} <@var{num>.}

+

+Only use this driver for locking/unlocking the device or configuring the option bytes.

+Use the standard str9 driver for programming.

+

+@subsection stellaris (LM3Sxxx) options

+@cindex stellaris (LM3Sxxx) options

+

+@b{flash bank stellaris} <@var{base}> <@var{size}> 0 0 <@var{target#}>

+stellaris flash plugin only require the @var{target#}. 

+

+@subsection stm32x options

+@cindex stm32x options

+

+@b{flash bank stm32x} <@var{base}> <@var{size}> 0 0 <@var{target#}>

+stm32x flash plugin only require the @var{target#}. 

+

+@node Commands

+@chapter Commands

+@cindex commands

+

+The Open On-Chip Debugger (OpenOCD) allows user interaction through a telnet interface

+(default: port 4444) and a GDB server (default: port 3333). The command line interpreter

+is available from both the telnet interface and a GDB session. To issue commands to the

+interpreter from within a GDB session, use the @option{monitor} command, e.g. use

+@option{monitor poll} to issue the @option{poll} command. All output is relayed through the

+GDB session.

+

+@section Daemon

+

+@itemize @bullet

+@item @b{sleep} <@var{msec}>

+@cindex sleep

+Wait for n milliseconds before resuming. Useful in connection with script files

+(@var{script} command and @var{target_script} configuration). 

+

+@item @b{shutdown}

+@cindex shutdown

+Close the OpenOCD daemon, disconnecting all clients (GDB, Telnet). 

+

+@item @b{debug_level} [@var{n}]

+@cindex debug_level

+Display or adjust debug level to n<0-3> 

+

+@item @b{log_output} <@var{file}>

+@cindex log_output

+Redirect logging to <file> (default: stderr) 

+

+@item @b{script} <@var{file}>

+@cindex script

+Execute commands from <file> 

+

+@end itemize

+

+@subsection Target state handling

+@itemize @bullet

+@item @b{poll} [@option{on}|@option{off}]

+@cindex poll

+Poll the target for its current state. If the target is in debug mode, architecture

+specific information about the current state are printed. An optional parameter

+allows continuous polling to be enabled and disabled.

+

+@item @b{halt} [@option{ms}]

+@cindex halt

+Send a halt request to the target and waits for it to halt for [@option{ms}].

+Default [@option{ms}] is 5 seconds if no arg given.

+Optional arg @option{ms} is a timeout in milliseconds. Using 0 as the [@option{ms}]

+will stop openocd from waiting.

+

+@item @b{wait_halt} [@option{ms}]

+@cindex wait_halt

+Wait for the target to enter debug mode. Optional [@option{ms}] is

+a timeout in milliseconds. Default [@option{ms}] is 5 seconds if no

+arg given.

+

+@item @b{resume} [@var{address}]

+@cindex resume

+Resume the target at its current code position, or at an optional address.

+Openocd will wait 5 seconds for the target to resume.

+

+@item @b{step} [@var{address}]

+@cindex step

+Single-step the target at its current code position, or at an optional address. 

+

+@item @b{reset} [@option{run}|@option{halt}|@option{init}|@option{run_and_halt}

+|@option{run_and_init}]

+@cindex reset

+Do a hard-reset. The optional parameter specifies what should happen after the reset.

+This optional parameter overwrites the setting specified in the configuration file,

+making the new behaviour the default for the @option{reset} command.

+@itemize @minus

+@item run

+@cindex reset run

+Let the target run.

+@item halt

+@cindex reset halt

+Immediately halt the target (works only with certain configurations).

+@item init

+@cindex reset init

+Immediately halt the target, and execute the reset script (works only with certain

+configurations)

+@item run_and_halt

+@cindex reset run_and_halt

+Let the target run for a certain amount of time, then request a halt.

+@item run_and_init

+@cindex reset run_and_init

+Let the target run for a certain amount of time, then request a halt. Execute the

+reset script once the target entered debug mode.

+@end itemize

+@end itemize

+

+@subsection Memory access commands

+These commands allow accesses of a specific size to the memory system:

+@itemize @bullet

+@item @b{mdw} <@var{addr}> [@var{count}]

+@cindex mdw

+display memory words 

+@item @b{mdh} <@var{addr}> [@var{count}]

+@cindex mdh

+display memory half-words 

+@item @b{mdb} <@var{addr}> [@var{count}]

+@cindex mdb

+display memory bytes 

+@item @b{mww} <@var{addr}> <@var{value}>

+@cindex mww

+write memory word 

+@item @b{mwh} <@var{addr}> <@var{value}>

+@cindex mwh

+write memory half-word 

+@item @b{mwb} <@var{addr}> <@var{value}>

+@cindex mwb

+write memory byte 

+

+@item @b{load_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]

+@cindex load_image

+Load image <@var{file}> to target memory at <@var{address}> 

+@item @b{dump_image} <@var{file}> <@var{address}> <@var{size}>

+@cindex dump_image

+Dump <@var{size}> bytes of target memory starting at <@var{address}> to a

+(binary) <@var{file}>.

+@item @b{verify_image} <@var{file}> <@var{address}> [@option{bin}|@option{ihex}|@option{elf}]

+@cindex verify_image

+Verify <@var{file}> to target memory starting at <@var{address}>.

+This will first attempt using a crc checksum, if this fails it will try a binary compare.

+@item @b{load_binary} <@var{file}> <@var{address}> [DEPRECATED]

+@cindex load_binary

+Load binary <@var{file}> to target memory at <@var{address}> 

+@item @b{dump_binary} <@var{file}> <@var{address}> <@var{size}> [DEPRECATED]

+@cindex dump_binary

+Dump <@var{size}> bytes of target memory starting at <@var{address}> to a

+(binary) <@var{file}>.

+@end itemize

+

+@subsection Flash commands

+@cindex Flash commands

+@itemize @bullet

+@item @b{flash banks}

+@cindex flash banks

+List configured flash banks 

+@item @b{flash info} <@var{num}>

+@cindex flash info

+Print info about flash bank <@option{num}> 

+@item @b{flash probe} <@var{num}>

+@cindex flash probe

+Identify the flash, or validate the parameters of the configured flash. Operation

+depends on the flash type. 

+@item @b{flash erase_check} <@var{num}>

+@cindex flash erase_check

+Check erase state of sectors in flash bank <@var{num}>. This is the only operation that

+updates the erase state information displayed by @option{flash info}. That means you have

+to issue an @option{erase_check} command after erasing or programming the device to get

+updated information. 

+@item @b{flash protect_check} <@var{num}>

+@cindex flash protect_check

+Check protection state of sectors in flash bank <num>. 

+

+@item @b{flash erase} <@var{num}> <@var{first}> <@var{last}> [DEPRECATED]

+@cindex flash erase

+Erase sectors at bank <@var{num}>, starting at sector <@var{first}> up to and including

+<@var{last}>. Sector numbering starts at 0. Depending on the flash type, erasing might

+require the protection to be disabled first (e.g. Intel Advanced Bootblock flash using

+the CFI driver). This command was replaced by the new command

+@option{flash erase_sector} using the same syntax. 

+@item @b{flash erase_sector} <@var{num}> <@var{first}> <@var{last}>

+@cindex flash erase_sector

+Erase sectors at bank <@var{num}>, starting at sector <@var{first}> up to and including

+<@var{last}>. Sector numbering starts at 0. Depending on the flash type, erasing might

+require the protection to be disabled first (e.g. Intel Advanced Bootblock flash using

+the CFI driver).

+@item @b{flash erase_address} <@var{address}> <@var{length}>

+@cindex flash erase_address

+Erase sectors starting at <@var{address}> for <@var{length}> number of bytes

+@item @b{flash write} <@var{num}> <@var{file}> <@var{offset}> [DEPRECATED]

+@cindex flash write

+Write the binary <@var{file}> to flash bank <@var{num}>, starting at <@var{offset}>

+bytes from the beginning of the bank. This command was replaced by the new command

+@option{flash write_binary} using the same syntax. 

+@item @b{flash write_binary} <@var{num}> <@var{file}> <@var{offset}>

+@cindex flash write_binary

+Write the binary <@var{file}> to flash bank <@var{num}>, starting at

+<@option{offset}> bytes from the beginning of the bank. 

+@item @b{flash write_image} <@var{file}> [@var{offset}] [@var{type}]

+@cindex flash write_image

+Write the image <@var{file}> to the current target's flash bank(s). A relocation

+[@var{offset}] can be specified and the file [@var{type}] can be specified

+explicitly as @option{bin} (binary), @option{ihex} (Intel hex), @option{elf}

+(ELF file) or @option{s19} (Motorola s19). 

+@item @b{flash protect} <@var{num}> <@var{first}> <@var{last}> <@option{on}|@option{off}>

+@cindex flash protect

+Enable (@var{on}) or disable (@var{off}) protection of flash sectors <@var{first}> to

+<@var{last}> of @option{flash bank} <@var{num}>. 

+@item @b{flash auto_erase} <@var{on}|@var{off}>

+@cindex flash auto_erase

+Enable (@option{on}) to erase flash banks prior to writing using the flash @option{write_image} command

+only. Default is (@option{off}), flash banks have to be erased using @option{flash erase} command. 

+@end itemize

+

+@page

+@section Target Specific Commands

+@cindex Target Specific Commands

+

+@subsection AT91SAM7 specific commands

+@cindex AT91SAM7 specific commands

+The flash configuration is deduced from the chip identification register. The flash

+controller handles erases automatically on a page (128/265 byte) basis so erase is

+not necessary for flash programming. AT91SAM7 processors with less than 512K flash

+only have a single flash bank embedded on chip. AT91SAM7xx512 have two flash planes

+that can be erased separatly.Only an EraseAll command is supported by the controller

+for each flash plane and this is called with

+@itemize @bullet

+@item @b{flash erase} <@var{num}> @var{first_plane} @var{last_plane}

+bulk erase flash planes first_plane to last_plane. 

+@item @b{at91sam7 gpnvm} <@var{num}> <@var{bit}> <@option{set}|@option{clear}>

+@cindex at91sam7 gpnvm

+set or clear a gpnvm bit for the processor 

+@end itemize

+

+@subsection STR9 specific commands

+@cindex STR9 specific commands

+These are flash specific commands when using the str9xpec driver.

+@itemize @bullet

+@item @b{str9xpec enable_turbo} <@var{num}>

+@cindex str9xpec enable_turbo

+enable turbo mode, simply this will remove the str9 from the chain and talk

+directly to the embedded flash controller. 

+@item @b{str9xpec disable_turbo} <@var{num}>

+@cindex str9xpec disable_turbo

+restore the str9 into jtag chain. 

+@item @b{str9xpec lock} <@var{num}>

+@cindex str9xpec lock

+lock str9 device. The str9 will only respond to an unlock command that will

+erase the device. 

+@item @b{str9xpec unlock} <@var{num}>

+@cindex str9xpec unlock

+unlock str9 device. 

+@item @b{str9xpec options_read} <@var{num}>

+@cindex str9xpec options_read

+read str9 option bytes. 

+@item @b{str9xpec options_write} <@var{num}>

+@cindex str9xpec options_write

+write str9 option bytes. 

+@end itemize

+

+@subsection STR9 configuration

+@cindex STR9 configuration

+@itemize @bullet

+@item @b{str9x flash_config} <@var{bank}> <@var{BBSR}> <@var{NBBSR}>

+<@var{BBADR}> <@var{NBBADR}>

+@cindex str9x flash_config

+Configure str9 flash controller.

+@smallexample

+eg. str9x flash_config 0 4 2 0 0x80000

+This will setup

+BBSR - Boot Bank Size register

+NBBSR - Non Boot Bank Size register

+BBADR - Boot Bank Start Address register

+NBBADR - Boot Bank Start Address register

+@end smallexample

+@end itemize

+

+@subsection STR9 option byte configuration

+@cindex STR9 option byte configuration

+@itemize @bullet

+@item @b{str9xpec options_cmap} <@var{num}> <@option{bank0}|@option{bank1}>

+@cindex str9xpec options_cmap

+configure str9 boot bank. 

+@item @b{str9xpec options_lvdthd} <@var{num}> <@option{2.4v}|@option{2.7v}>

+@cindex str9xpec options_lvdthd

+configure str9 lvd threshold. 

+@item @b{str9xpec options_lvdsel} <@var{num}> <@option{vdd}|@option{vdd_vddq}>

+@cindex str9xpec options_lvdsel

+configure str9 lvd source. 

+@item @b{str9xpec options_lvdwarn} <@var{bank}> <@option{vdd}|@option{vdd_vddq}>

+@cindex str9xpec options_lvdwarn

+configure str9 lvd reset warning source. 

+@end itemize

+

+@subsection STM32x specific commands

+@cindex STM32x specific commands

+ 

+These are flash specific commands when using the stm32x driver.

+@itemize @bullet

+@item @b{stm32x lock} <@var{num}>

+@cindex stm32x lock

+lock stm32 device. 

+@item @b{stm32x unlock} <@var{num}>

+@cindex stm32x unlock

+unlock stm32 device. 

+@item @b{stm32x options_read} <@var{num}>

+@cindex stm32x options_read

+read stm32 option bytes. 

+@item @b{stm32x options_write} <@var{num}> <@option{SWWDG}|@option{HWWDG}>

+<@option{RSTSTNDBY}|@option{NORSTSTNDBY}> <@option{RSTSTOP}|@option{NORSTSTOP}>

+@cindex stm32x options_write

+write stm32 option bytes. 

+@item @b{stm32x mass_erase} <@var{num}>

+@cindex stm32x mass_erase

+mass erase flash memory. 

+@end itemize

+

+@page

+@section Architecture Specific Commands

+@cindex Architecture Specific Commands

+

+@subsection ARMV4/5 specific commands

+@cindex ARMV4/5 specific commands

+

+These commands are specific to ARM architecture v4 and v5, like all ARM7/9 systems

+or Intel XScale (XScale isn't supported yet).

+@itemize @bullet

+@item @b{armv4_5 reg}

+@cindex armv4_5 reg

+Display a list of all banked core registers, fetching the current value from every

+core mode if necessary. OpenOCD versions before rev. 60 didn't fetch the current

+register value. 

+@item @b{armv4_5 core_mode} [@option{arm}|@option{thumb}]

+@cindex armv4_5 core_mode

+Displays the core_mode, optionally changing it to either ARM or Thumb mode.

+The target is resumed in the currently set @option{core_mode}. 

+@end itemize

+

+@subsection ARM7/9 specific commands

+@cindex ARM7/9 specific commands

+

+These commands are specific to ARM7 and ARM9 targets, like ARM7TDMI, ARM720t,

+ARM920t or ARM926EJ-S.

+@itemize @bullet

+@item @b{arm7_9 sw_bkpts} <@option{enable}|@option{disable}>

+@cindex arm7_9 sw_bkpts

+Enable/disable use of software breakpoints. On ARMv4 systems, this reserves

+one of the watchpoint registers to implement software breakpoints. Disabling

+SW Bkpts frees that register again. 

+@item @b{arm7_9 force_hw_bkpts} <@option{enable}|@option{disable}>

+@cindex arm7_9 force_hw_bkpts

+When @option{force_hw_bkpts} is enabled, the @option{sw_bkpts} support is disabled, and all

+breakpoints are turned into hardware breakpoints.

+@item @b{arm7_9 dbgrq} <@option{enable}|@option{disable}>

+@cindex arm7_9 dbgrq

+Enable use of the DBGRQ bit to force entry into debug mode. This should be

+safe for all but ARM7TDMI--S cores (like Philips LPC). 

+@item @b{arm7_9 fast_writes} <@option{enable}|@option{disable}>

+@cindex arm7_9 fast_writes [DEPRECATED]

+See @option{arm7_9 fast_memory_access} instead. 

+@item @b{arm7_9 fast_memory_access} <@option{enable}|@option{disable}>

+@cindex arm7_9 fast_memory_access

+Allow the OpenOCD to read and write memory without checking completion of

+the operation. This provides a huge speed increase, especially with USB JTAG

+cables (FT2232), but might be unsafe if used with targets running at a very low

+speed, like the 32kHz startup clock of an AT91RM9200. 

+@item @b{arm7_9 dcc_downloads} <@option{enable}|@option{disable}>

+@cindex arm7_9 dcc_downloads

+Enable the use of the debug communications channel (DCC) to write larger (>128 byte)

+amounts of memory. DCC downloads offer a huge speed increase, but might be potentially

+unsafe, especially with targets running at a very low speed. This command was introduced

+with OpenOCD rev. 60. 

+@end itemize

+

+@subsection ARM920T specific commands

+@cindex ARM920T specific commands

+

+@itemize @bullet

+@item @b{arm920t cache_info}

+@cindex arm920t cache_info

+Print information about the caches found. This allows you to see if your target

+is a ARM920T (2x16kByte cache) or ARM922T (2x8kByte cache). 

+@item @b{arm920t md<bhw>_phys} <@var{addr}> [@var{count}]

+@cindex arm920t md<bhw>_phys

+Display memory at physical address addr. 

+@item @b{arm920t mw<bhw>_phys} <@var{addr}> <@var{value}>

+@cindex arm920t mw<bhw>_phys

+Write memory at physical address addr. 

+@item @b{arm920t read_cache} <@var{filename}>

+@cindex arm920t read_cache

+Dump the content of ICache and DCache to a file. 

+@item @b{arm920t read_mmu} <@var{filename}>

+@cindex arm920t read_mmu

+Dump the content of the ITLB and DTLB to a file. 

+@item @b{arm920t virt2phys} <@var{VA}>

+@cindex arm920t virt2phys

+Translate a virtual address to a physical address. 

+@end itemize

+

+@page

+@section Debug commands

+@cindex Debug commands

+The following commands give direct access to the core, and are most likely

+only useful while debugging the OpenOCD.

+@itemize @bullet

+@item @b{arm7_9 write_xpsr} <@var{32-bit value}> <@option{0=cpsr}, @option{1=spsr}>

+@cindex arm7_9 write_xpsr

+Immediately write either the current program status register (CPSR) or the saved

+program status register (SPSR), without changing the register cache (as displayed

+by the @option{reg} and @option{armv4_5 reg} commands). 

+@item @b{arm7_9 write_xpsr_im8} <@var{8-bit value}> <@var{rotate 4-bit}>

+<@var{0=cpsr},@var{1=spsr}>

+@cindex arm7_9 write_xpsr_im8

+Write the 8-bit value rotated right by 2*rotate bits, using an immediate write

+operation (similar to @option{write_xpsr}). 

+@item @b{arm7_9 write_core_reg} <@var{num}> <@var{mode}> <@var{value}>

+@cindex arm7_9 write_core_reg

+Write a core register, without changing the register cache (as displayed by the

+@option{reg} and @option{armv4_5 reg} commands). The <@var{mode}> argument takes the

+encoding of the [M4:M0] bits of the PSR. 

+@end itemize

+

+@page

+@section JTAG commands

+@cindex JTAG commands

+@itemize @bullet

+@item @b{scan_chain}

+@cindex scan_chain

+Print current scan chain configuration. 

+@item @b{jtag_reset}

+@cindex jtag_reset

+Toggle reset lines <@var{trst}> <@var{srst}>. 

+@item @b{endstate} <@var{tap_state}>

+@cindex endstate

+Finish JTAG operations in <@var{tap_state}>. 

+@item @b{runtest} <@var{num_cycles}>

+@cindex runtest

+Move to Run-Test/Idle, and execute <@var{num_cycles}> 

+@item @b{statemove} [@var{tap_state}]

+@cindex statemove

+Move to current endstate or [@var{tap_state}] 

+@item @b{irscan}

+@cindex irscan

+Execute IR scan <@var{device}> <@var{instr}> [@var{dev2}] [@var{instr2}] ... 

+@item @b{drscan}

+@cindex drscan

+Execute DR scan <@var{device}> [@var{dev2}] [@var{var2}] ... 

+@item @b{verify_ircapture}

+@cindex verify_ircapture

+Verify value captured during Capture-IR <@option{enable}|@option{disable}> 

+@item @b{var}

+@cindex var

+Allocate, display or delete variable <@var{name}> [@var{num_fields}|@var{del}] [@var{size1}] ... 

+@item @b{field}

+@cindex field

+Display/modify variable field <@var{var}> <@var{field}> [@var{value}|@var{flip}] 

+@end itemize

+

+@node Sample Scripts

+@chapter Sample Scripts

+@cindex scripts

+

+This page will collect some script examples for different CPUs.

+

+The configuration script can be divided in the following section:

+@itemize @bullet

+@item daemon configuration

+@item interface

+@item jtag scan chain

+@item target configuration

+@item flash configuration 

+@end itemize

+

+Detailed information about each section can be found at OpenOCD configuration 

+

+@section OMAP5912 Flash Debug

+@cindex OMAP5912 Flash Debug

+The following two scripts were used with a wiggler PP and and a TI OMAP5912

+dual core processor - (@uref{http://www.ti.com}), on a OMAP5912 OSK board

+- (@uref{http://www.spectrumdigital.com}).

+@subsection Openocd config

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+

+#interface

+interface parport

+parport_port 0x378

+parport_cable wiggler

+jtag_speed 0

+

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

+reset_config trst_and_srst

+

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 38 0x0 0x0 0x0

+jtag_device 4  0x1 0x0 0xe

+jtag_device 8  0x0 0x0 0x0

+

+#target configuration

+daemon_startup reset

+

+#target <type> <endianness> <reset mode> <chainpos> <variant>

+target arm926ejs little run_and_init 1 arm926ejs

+target_script 0 reset omap5912_osk.init

+run_and_halt_time 0 30

+

+# omap5912 lcd frame buffer as working area

+working_area 0 0x20000000 0x3e800 nobackup

+

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank cfi 0x00000000 0x1000000 2 2 0

+@end smallexample

+

+@subsection Openocd init

+@smallexample

+#

+# halt target

+#

+poll

+sleep 1

+halt

+wait_halt

+#

+# disable wdt

+#

+mww 0xfffec808 0x000000f5

+mww 0xfffec808 0x000000a0

+

+mww 0xfffeb048 0x0000aaaa

+sleep 500

+mww 0xfffeb048 0x00005555

+sleep 500

+#

+# detect flash

+#

+flash probe 0

+

+@end smallexample

+

+@section STR71x Script

+@cindex STR71x Script

+The following script was used with an Amontec JTAGkey and a STR710 / STR711 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 0

+ 

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

+reset_config trst_and_srst srst_pulls_trst

+ 

+#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 <type> <startup mode>

+#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi

+run_and_halt_time 0 30

+

+working_area 0 0x2000C000 0x4000 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank str7x 0x40000000 0x00040000 0 0 0 STR71x

+@end smallexample

+

+@section STR750 Script

+@cindex STR750 Script

+The following script was used with an Amontec JTAGkey and a STR750 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 19

+ 

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

+#reset_config trst_and_srst srst_pulls_trst

+reset_config trst_and_srst srst_pulls_trst

+

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 4 0x1 0xf 0xe

+

+#jtag nTRST and nSRST delay

+jtag_nsrst_delay 500

+jtag_ntrst_delay 500

+ 

+#target configuration

+daemon_startup reset

+ 

+#target <type> <startup mode>

+#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi

+run_and_halt_time 0 30

+ 

+working_area 0 0x40000000 0x4000 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank str7x 0x20000000 0x000040000 0 0 0 STR75x

+@end smallexample

+

+@section STR912 Script

+@cindex STR912 Script

+The following script was used with an Amontec JTAGkey and a STR912 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+jtag_speed 1

+ 

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

+reset_config trst_and_srst

+ 

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 8 0x1 0x1 0xfe

+jtag_device 4 0x1 0xf 0xe

+jtag_device 5 0x1 0x1 0x1e

+ 

+#target configuration

+daemon_startup reset

+ 

+#target <type> <startup mode>

+#target arm966e <endianness> <reset mode> <chainpos> <variant>

+target arm966e little reset_halt 1 arm966e

+run_and_halt_time 0 30

+ 

+working_area 0 0x50000000 16384 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank str9x 0x00000000 0x00080000 0 0 0

+@end smallexample

+

+@section STR912 comstick

+@cindex STR912 comstick Script

+The following script was used with a Hitex STR9 Comstick:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "STR9-comStick A"

+ft2232_layout comstick

+jtag_speed 1

+

+jtag_nsrst_delay 100

+jtag_ntrst_delay 100

+

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

+reset_config trst_and_srst

+ 

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 8 0x1 0x1 0xfe

+jtag_device 4 0x1 0xf 0xe

+jtag_device 5 0x1 0x1 0x1e

+ 

+#target configuration

+daemon_startup reset

+ 

+#target <type> <startup mode>

+#target arm966e <endianness> <reset mode> <chainpos> <variant>

+target arm966e little reset_halt 1 arm966e

+run_and_halt_time 0 30

+ 

+working_area 0 0x50000000 16384 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank str9x 0x00000000 0x00080000 0 0 0

+@end smallexample

+

+@section STM32x Script

+@cindex STM32x Script

+The following script was used with an Amontec JTAGkey and a STM32x cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+jtag_speed 10

+

+jtag_nsrst_delay 100

+jtag_ntrst_delay 100

+

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

+reset_config trst_and_srst

+ 

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 4 0x1 0xf 0xe

+jtag_device 5 0x1 0x1 0x1e

+ 

+#target configuration

+daemon_startup reset

+ 

+#target <type> <startup mode>

+#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>

+target cortex_m3 little run_and_halt 0

+run_and_halt_time 0 30

+ 

+working_area 0 0x20000000 16384 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank stm32x 0x08000000 0x00020000 0 0 0

+@end smallexample

+

+@section STM32x Performance Stick

+@cindex STM32x Performance Stick Script

+The following script was used with the Hitex STM32 Performance Stick

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "STM32-PerformanceStick A"

+ft2232_layout stm32stick

+jtag_speed 10

+

+jtag_nsrst_delay 100

+jtag_ntrst_delay 100

+

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

+reset_config trst_and_srst

+ 

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 4 0x1 0xf 0xe

+jtag_device 5 0x1 0x1 0x1e

+jtag_device 4 0x1 0xf 0xe

+ 

+#target configuration

+daemon_startup reset

+ 

+#target <type> <startup mode>

+#target cortex_m3 <endianness> <reset mode> <chainpos> <variant>

+target cortex_m3 little run_and_halt 0

+run_and_halt_time 0 30

+ 

+working_area 0 0x20000000 16384 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank stm32x 0x08000000 0x00020000 0 0 0

+@end smallexample

+

+@section LPC2129 Script

+@cindex LPC2129 Script

+The following script was used with an wiggler PP and a LPC-2129 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface parport

+parport_port 0x378

+parport_cable wiggler

+jtag_speed 0

+ 

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

+reset_config trst_and_srst srst_pulls_trst

+ 

+#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 <type> <startup mode>

+#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

+run_and_halt_time 0 30

+ 

+working_area 0 0x40000000 0x4000 nobackup

+ 

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum

+@end smallexample

+

+@section  LPC2148 Script

+@cindex  LPC2148 Script

+The following script was used with an Amontec JTAGkey and a LPC2148 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 3

+ 

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

+reset_config trst_and_srst srst_pulls_trst

+ 

+#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 <type> <startup mode>

+#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

+run_and_halt_time 0 30

+ 

+working_area 0 0x40000000 0x8000 nobackup

+ 

+#flash configuration

+flash bank lpc2000 0x0 0x7d000 0 0 0 lpc2000_v1 14765 calc_checksum

+@end smallexample

+

+@section  LPC2294 Script

+@cindex  LPC2294 Script

+The following script was used with an Amontec JTAGkey and a LPC2294 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 3

+ 

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

+reset_config trst_and_srst srst_pulls_trst

+ 

+#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 <type> <startup mode>

+#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

+run_and_halt_time 0 30

+ 

+working_area 0 0x40000000 0x4000 nobackup

+ 

+#flash configuration

+flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v1 14765 calc_checksum

+@end smallexample

+

+@section AT91R40008 Script

+@cindex AT91R40008 Script

+The following script was used with an Amontec JTAGkey and a AT91R40008 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 0

+jtag_nsrst_delay 200

+jtag_ntrst_delay 200

+ 

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

+reset_config srst_only srst_pulls_trst

+ 

+#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 <type> <startup mode>

+#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi

+run_and_halt_time 0 30

+@end smallexample

+

+@section AT91SAM7s Script

+@cindex AT91SAM7s Script

+The following script was used with an Olimex ARM-JTAG-OCD and a AT91SAM7S64 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+ft2232_device_desc "Olimex OpenOCD JTAG A"

+ft2232_layout olimex-jtag

+ft2232_vid_pid 0x15BA 0x0003

+jtag_speed 0

+jtag_nsrst_delay 200

+jtag_ntrst_delay 200

+ 

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

+reset_config srst_only srst_pulls_trst

+ 

+#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 <type> <startup mode>

+#target arm7tdmi <endianness> <reset mode> <chainpos> <variant>

+target arm7tdmi little run_and_halt 0 arm7tdmi

+run_and_halt_time 0 30

+ 

+# flash-options AT91

+working_area 0 0x00200000 0x4000 nobackup

+flash bank at91sam7 0 0 0 0 0

+ 

+# Information: 

+# erase command (telnet-interface) for complete flash:

+# flash erase <num> 0 numlockbits-1 (can be seen from output of flash info 0)

+# SAM7S64 with 16 lockbits and bank 0: flash erase 0 0 15

+# set/clear NVM-Bits:

+# at91sam7 gpnvm <num> <bit> <set|clear>

+# disable locking from SAM-BA:

+# flash protect 0 0 1 off

+@end smallexample

+

+@section XSCALE IXP42x Script

+@cindex XSCALE IXP42x Script

+The following script was used with an Amontec JTAGkey-Tiny and a xscale ixp42x cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 0

+jtag_nsrst_delay 200

+jtag_ntrst_delay 200

+ 

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

+reset_config srst_only srst_pulls_trst

+ 

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 7 0x1 0x7f 0x7e

+ 

+#target configuration

+daemon_startup reset

+ 

+#target <type> <startup mode>

+#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>

+target xscale big run_and_halt 0 IXP42x

+run_and_halt_time 0 30

+@end smallexample

+

+@section Cirrus Logic EP9301 Script

+@cindex Cirrus Logic EP9301 Script

+The following script was used with FT2232 based JTAG interfaces and a

+Cirrus Logic EP9301 processor on an Olimex CS-E9301 board.

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+ 

+#interface

+interface ft2232

+

+#Olimex ARM-USB-OCD

+#ft2232_device_desc "Olimex OpenOCD JTAG"

+#ft2232_layout olimex-jtag

+#ft2232_vid_pid 0x15ba 0x0003

+ 

+#Amontec JTAGkey (and JTAGkey-Tiny)

+#Serial is only necessary if more than one JTAGkey is connected

+ft2232_device_desc "Amontec JTAGkey A"

+#ft2232_serial AMTJKV31

+#ft2232_serial T1P3S2W8

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+ 

+#wiggler/parallel port interface

+#interface parport

+#parport_port 0x378

+#parport_cable wiggler

+#jtag_speed 0

+jtag_speed 1

+reset_config trst_and_srst

+ 

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 4 0x1 0xf 0xe

+ 

+jtag_nsrst_delay 100

+jtag_ntrst_delay 100

+ 

+#target configuration

+daemon_startup attach

+ 

+#target <type> <endianess> <reset mode>

+target arm920t little reset_halt 0

+working_area 0 0x80014000 0x1000 backup

+ 

+#flash configuration

+#flash bank <driver> <base> <size> <chip_width> <bus_width> [driver_options ...]

+flash bank cfi 0x60000000 0x1000000 2 2 0

+@end smallexample

+

+@section Hilscher netX 100 / 500 Script

+@cindex Hilscher netX 100 / 500 Script

+The following script was used with an Amontec JTAGkey and a Hilscher

+netX 500 cpu:

+@smallexample

+#daemon configuration

+telnet_port 4444

+gdb_port 3333

+

+#interface

+interface ft2232

+ft2232_device_desc "Amontec JTAGkey A"

+ft2232_layout jtagkey

+ft2232_vid_pid 0x0403 0xcff8

+jtag_speed 5

+

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

+reset_config trst_and_srst

+

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 4 0x1 0xf 0xe

+

+jtag_nsrst_delay 100

+jtag_ntrst_delay 100

+

+#target configuration

+daemon_startup reset

+

+#target <type> <endianness> <startup mode> <chainpos> <variant>

+target arm926ejs little run_and_halt 0 arm926ejs

+run_and_halt_time 0 500

+@end smallexample

+

+@section Marvell/Intel PXA270 Script

+@cindex Marvell/Intel PXA270 Script

+@smallexample

+# config for Intel PXA270

+# not, as of 2007-06-22, openocd only works with the

+# libftd2xx library from ftdi.  libftdi does not work.

+

+telnet_port	3333

+gdb_port	4444

+

+interface ft2232

+ft2232_layout olimex-jtag

+ft2232_vid_pid 0x15BA 0x0003

+ft2232_device_desc "Olimex OpenOCD JTAG"

+jtag_speed 0

+# set jtag_nsrst_delay to the delay introduced by your reset circuit

+# the rest of the needed delays are built into the openocd program

+jtag_nsrst_delay 260

+# set the jtag_ntrst_delay to the delay introduced by a reset circuit

+# the rest of the needed delays are built into the openocd program

+jtag_ntrst_delay 0

+

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

+reset_config trst_and_srst separate

+

+#jtag scan chain

+#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)

+jtag_device 7 0x1 0x7f 0x7e

+

+#target configuration

+daemon_startup reset

+

+target xscale little reset_halt 0 pxa27x

+

+# maps to PXA internal RAM.  If you are using a PXA255

+# you must initialize SDRAM or leave this option off

+working_area 0 0x5c000000 0x10000 nobackup

+

+run_and_halt_time 0 30

+

+#flash bank <driver> <base> <size> <chip_width> <bus_width>

+# works for P30 flash

+flash bank cfi 0x00000000 0x1000000 2 4 0

+@end smallexample

+

+@node GDB and Openocd

+@chapter GDB and Openocd

+@cindex GDB and Openocd

+Openocd complies with the remote gdbserver protocol, and as such can be used

+to debug remote targets.

+

+@section Connecting to gdb

+@cindex Connecting to gdb

+A connection is typically started as follows:

+@smallexample

+target remote localhost:3333

+@end smallexample

+This would cause gdb to connect to the gdbserver on the local pc using port 3333.

+

+To see a list of available openocd commands type @option{monitor help} on the

+gdb commandline.

+

+Openocd supports the gdb @option{qSupported} packet, this enables information

+to be sent by the gdb server (openocd) to gdb. Typical information includes

+packet size and device memory map.

+

+Previous versions of openocd required the following gdb options to increase

+the packet size and speed up gdb communication.

+@smallexample

+set remote memory-write-packet-size 1024

+set remote memory-write-packet-size fixed

+set remote memory-read-packet-size 1024

+set remote memory-read-packet-size fixed

+@end smallexample

+This is now handled in the @option{qSupported} PacketSize.

+

+@section Programming using gdb

+@cindex Programming using gdb

+

+By default the target memory map is not sent to gdb, this can be enabled by

+the following openocd config option:

+@smallexample

+gdb_memory_map enable

+@end smallexample

+For this to function correctly a valid flash config must also be configured

+in openocd. For speed also configure a valid working area.

+

+Informing gdb of the memory map of the target will enable gdb to protect any

+flash area of the target and use hardware breakpoints by default. This means

+that the openocd option @option{arm7_9 force_hw_bkpts} is not required when

+using a memory map.

+

+To view the configured memory map in gdb, use the gdb command @option{info mem}

+All other unasigned addresses within gdb are treated as ram.

+

+If @option{gdb_flash_program enable} is also used, gdb will be able to

+program any flash memory using the vFlash interface.

+

+gdb will look at the target memory map when a load command is given, if any

+areas to be programmed lie within the target flash area the vFlash packets

+will be used.

+

+Incase the target needs configuring before gdb programming, a script can be executed.

+@smallexample

+target_script 0 gdb_program_config config.script

+@end smallexample

+

+To verify any flash programming the gdb command @option{compare-sections}

+can be used.

+

+@node FAQ

+@chapter FAQ

+@cindex faq

+@enumerate

+@item OpenOCD complains about a missing cygwin1.dll

+

+Make sure you have Cygwin installed, or at least a version of OpenOCD that

+claims to come with all the necessary dlls. When using Cygwin, try launching

+the OpenOCD from the Cygwin shell.

+

+@item I'm trying to set a breakpoint using GDB (or a frontend like Insight or

+Eclipse), but OpenOCD complains that "Info: arm7_9_common.c:213

+arm7_9_add_breakpoint(): sw breakpoint requested, but software breakpoints not enabled".

+

+GDB issues software breakpoints when a normal breakpoint is requested, or to implement

+source-line single-stepping. On ARMv4T systems, like ARM7TDMI, ARM720t or ARM920t,

+software breakpoints consume one of the two available hardware breakpoints,

+and are therefor disabled by default. If your code is running from RAM, you

+can enable software breakpoints with the @option{arm7_9 sw_bkpts enable} command. If

+your code resides in Flash, you can't use software breakpoints, but you can force

+OpenOCD to use hardware breakpoints instead: @option{arm7_9 force_hw_bkpts enable}.

+

+@item When erasing or writing LPC2000 on-chip flash, the operation fails sometimes

+and works sometimes fine.

+

+Make sure the core frequency specified in the @option{flash lpc2000} line matches the

+clock at the time you're programming the flash. If you've specified the crystal's

+frequency, make sure the PLL is disabled, if you've specified the full core speed

+(e.g. 60MHz), make sure the PLL is enabled.

+

+@item When debugging using an Amontec Chameleon in its JTAG Accelerator configuration,

+I keep getting "Error: amt_jtagaccel.c:184 amt_wait_scan_busy(): amt_jtagaccel timed

+out while waiting for end of scan, rtck was disabled".

+

+Make sure your PC's parallel port operates in EPP mode. You might have to try several

+settings in your PC Bios (ECP, EPP, and different versions of those).

+

+@item When debugging with the OpenOCD and GDB (plain GDB, Insight, or Eclipse),

+I get lots of "Error: arm7_9_common.c:1771 arm7_9_read_memory():

+memory read caused data abort". 

+

+The errors are non-fatal, and are the result of GDB trying to trace stack frames

+beyond the last valid frame. It might be possible to prevent this by setting up

+a proper "initial" stack frame, if you happen to know what exactly has to

+be done, feel free to add this here.

+

+@item I get the following message in the OpenOCD console (or log file):

+"Warning: arm7_9_common.c:679 arm7_9_assert_reset(): srst resets test logic, too".

+

+This warning doesn't indicate any serious problem, as long as you don't want to

+debug your core right out of reset. Your .cfg file specified @option{jtag_reset

+trst_and_srst srst_pulls_trst} to tell the OpenOCD that either your board,

+your debugger or your target uC (e.g. LPC2000) can't assert the two reset signals

+independently. With this setup, it's not possible to halt the core right out of

+reset, everything else should work fine.

+

+@item When using OpenOCD in conjunction with Amontec JTAGkey and the Yagarto

+Toolchain (Eclipse, arm-elf-gcc, arm-elf-gdb), the debugging seems to be

+unstable. When single-stepping over large blocks of code, GDB and OpenOCD

+quit with an error message. Is there a stability issue with OpenOCD?

+

+No, this is not a stability issue concering OpenOCD. Most users have solved

+this issue by simply using a self-powered USB Hub, which they connect their

+Amontec JTAGkey to. Apparently, some computers do not provide a USB power

+supply stable enough for the Amontec JTAGkey to be operated.

+

+@item When using the Amontec JTAGkey, sometimes OpenOCD crashes with the

+following error messages: "Error: ft2232.c:201 ft2232_read(): FT_Read returned:

+4" and "Error: ft2232.c:365 ft2232_send_and_recv(): couldn't read from FT2232".

+What does that mean and what might be the reason for this?

+

+First of all, the reason might be the USB power supply. Try using a self-powered

+hub instead of a direct connection to your computer. Secondly, the error code 4

+corresponds to an FT_IO_ERROR, which means that the driver for the FTDI USB

+Chip ran into some sort of error - this points us to a USB problem.

+

+@item When using the Amontec JTAGkey, sometimes OpenOCD crashes with the following

+error message: "Error: gdb_server.c:101 gdb_get_char(): read: 10054".

+What does that mean and what might be the reason for this?

+

+Error code 10054 corresponds to WSAECONNRESET, which means that the debugger (GDB)

+has closed the connection to OpenOCD. This might be a GDB issue.

+

+@item 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 lpc2000_v1 0 14746 calc_checksum}),

+which must be sepcified 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 clock frequency?

+

+No. The clock frequency specified here must be given as an integral number.

+However, this clock frequency is used by the In-Application-Programming (IAP)

+routines of the LPC2000 family only, which seems to be very tolerant concerning

+the given clock frequency, so a slight difference between the specified clock

+frequency and the actual clock frequency will not cause any trouble.

+

+@item Do I have to keep a specific order for the commands in the configuration file?

+

+Well, yes and no. Commands can be given in arbitrary order, yet the devices

+listed for the JTAG scan chain must be given in the right order (jtag_device),

+with the device closest to the TDO-Pin being listed first. In general,

+whenever objects of the same type exist which require an index number, then

+these objects must be given in the right order (jtag_devices, targets and flash

+banks - a target references a jtag_device and a flash bank references a target).

+

+@item Sometimes my debugging session terminates with an error. When I look into the

+log file, I can see these error messages: Error: arm7_9_common.c:561

+arm7_9_execute_sys_speed(): timeout waiting for SYSCOMP

+							

+@end enumerate

+

+@include fdl.texi

+

+@node Index

+@unnumbered Index

+

+@printindex cp

+

+@bye