server: add support for pipes

[openocd.git] / doc / openocd.texi

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 3cf5bfeebf68e57279c50b690b3a28b4dbcb5923..77a0ad3b73f7ea19eb7073b7f28f8a1f6d258705 100644 (file)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -574,7 +574,6 @@ bash$ openocd --help
 --debug      | -d       set debug level <0-3>
 --log_output | -l       redirect log output to file <name>
 --command    | -c       run <command>
---pipe       | -p       use pipes when talking to gdb
 @end verbatim
 
 If you don't give any @option{-f} or @option{-c} options,
@@ -2259,11 +2258,11 @@ default values are used.
 Currently, only one @var{vid}, @var{pid} pair may be given, e.g. for
 Altera USB-Blaster (default):
 @example
-ft2232_vid_pid 0x09FB 0x6001
+usb_blaster_vid_pid 0x09FB 0x6001
 @end example
 The following VID/PID is for Kolja Waschk's USB JTAG:
 @example
-ft2232_vid_pid 0x16C0 0x06AD
+usb_blaster_vid_pid 0x16C0 0x06AD
 @end example
 @end deffn
 
@@ -6390,6 +6389,15 @@ the @code{xscale debug_handler} command.  The allowed locations for the
 debug handler are either (0x800 - 0x1fef800) or (0xfe000800 -
 0xfffff800). The default value is 0xfe000800.
 
+XScale has resources to support two hardware breakpoints and two
+watchpoints.  However, the following restrictions on watchpoint
+functionality apply: (1) the value and mask arguments to the @code{wp}
+command are not supported, (2) the watchpoint length must be a
+power of two and not less than four, and can not be greater than the
+watchpoint address, and (3) a watchpoint with a length greater than
+four consumes all the watchpoint hardware resources.  This means that
+at any one time, you can have enabled either two watchpoints with a
+length of four, or one watchpoint with a length greater than four.
 
 These commands are available to XScale based CPUs,
 which are implementations of the ARMv5TE architecture.
@@ -6592,6 +6600,21 @@ must also be explicitly enabled.
 This finishes by listing the current vector catch configuration.
 @end deffn
 
+@deffn Command {cortex_m3 reset_config} (@option{srst}|@option{sysresetreq}|@option{vectreset})
+Control reset handling. The default @option{srst} is to use srst if fitted,
+otherwise fallback to @option{vectreset}.
+@itemize @minus
+@item @option{srst} use hardware srst if fitted otherwise fallback to @option{vectreset}.
+@item @option{sysresetreq} use NVIC SYSRESETREQ to reset system.
+@item @option{vectreset} use NVIC VECTRESET to reset system.
+@end itemize
+Using @option{vectreset} is a safe option for all current Cortex-M3 cores.
+This however has the disadvantage of only resetting the core, all peripherals
+are uneffected. A solution would be to use a @code{reset-init} event handler to manually reset
+the peripherals.
+@xref{Target Events}.
+@end deffn
+
 @anchor{Software Debug Messages and Tracing}
 @section Software Debug Messages and Tracing
 @cindex Linux-ARM DCC support
@@ -7028,11 +7051,12 @@ This would cause GDB to connect to the gdbserver on the local pc using port 3333
 @item
 A pipe connection is typically started as follows:
 @example
-target remote | openocd --pipe
+target remote | openocd -c "gdb_port pipe; log_output openocd.log"
 @end example
 This would cause GDB to run OpenOCD and communicate using pipes (stdin/stdout).
 Using this method has the advantage of GDB starting/stopping OpenOCD for the debug
-session.
+session. log_output sends the log output to a file to ensure that the pipe is
+not saturated when using higher debug level outputs.
 @end enumerate
 
 To list the available OpenOCD commands type @command{monitor help} on the