- add guess-rev.sh and contrib/libdcc to dist

[openocd.git] / doc / openocd.texi

diff --git a/doc/openocd.texi b/doc/openocd.texi
index 63ab6fedf62a0e0d271a65ee57da583a9b9589ea..1866fa0e046fd17c4dab1590d8b0d2656dc0124e 100644 (file)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -1517,8 +1517,6 @@ Creates the tap ``foobar.tap'' with the instruction register (IR) is 7
 bits long, during Capture-IR 0x42 is loaded into the IR, and bits
 [6,4,2,0] are checked.
 
-FIXME: The IDCODE - this was not used in the old code, it should be?
-Right? -Duane.
 @item @b{Optional configparams}
 @comment START Optional
 @itemize @bullet
@@ -1613,13 +1611,13 @@ have the taps created in the proper order.
 @* @b{Removed: 28/nov/2008} This command has been removed and replaced
 by the ``jtag newtap'' command. The documentation remains here so that
 one can easily convert the old syntax to the new syntax. About the old
-syntax: The old syntax is positional, ie: The 4th parameter is the
+syntax: The old syntax is positional, ie: The 3rd parameter is the
 ``irmask''. The new syntax requires named prefixes, and supports
-additional options, for example ``-irmask 4''. Please refer to the
+additional options, for example ``-expected-id 0x3f0f0f0f''. Please refer to the
 @b{jtag newtap} command for details.
 @example
-OLD: jtag_device 8 0x01 0x0e3 0xfe
-NEW: jtag newtap CHIPNAME TAPNAME -irlen 8 -ircapture 0xe3 -irmask 0xfe
+OLD: jtag_device 8 0x01 0xe3 0xfe
+NEW: jtag newtap CHIPNAME TAPNAME -irlen 8 -ircapture 0x01 -irmask 0xe3
 @end example
 
 @section Enable/Disable Taps
@@ -2990,10 +2988,11 @@ 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 --pipe
 @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 debug session.
+Using this method has the advantage of GDB starting/stopping OpenOCD for the debug
+session.
 @end enumerate
 
 @*To see a list of available OpenOCD commands type @option{monitor help} on the
@@ -3185,24 +3184,29 @@ halt
 @*
 
 In digital circuit design it is often refered to as ``clock
-syncronization'' the JTAG interface uses one clock (TCK or TCLK)
+synchronisation'' the JTAG interface uses one clock (TCK or TCLK)
 operating at some speed, your target is operating at another.  The two
-clocks are not syncronized, they are ``asynchronous''
+clocks are not synchronised, they are ``asynchronous''
 
-In order for the two to work together they must syncronize. Otherwise
+In order for the two to work together they must be synchronised. Otherwise
 the two systems will get out of sync with each other and nothing will
-work. There are 2 basic options. @b{1.} use a special circuit or
-@b{2.}  one clock must be some multile slower the the other.
+work. There are 2 basic options.
+@enumerate
+@item
+Use a special circuit.
+@item
+One clock must be some multiple slower the the other.
+@end enumerate
 
 @b{Does this really matter?} For some chips and some situations, this
-is a non-issue (ie: A 500mhz ARM926) but for others - for example some
-ATMEL SAM7 and SAM9 chips start operation from reset at 32khz -
+is a non-issue (ie: A 500MHz ARM926) but for others - for example some
+ATMEL SAM7 and SAM9 chips start operation from reset at 32kHz -
 program/enable the oscillators and eventually the main clock. It is in
 those critical times you must slow the jtag clock to sometimes 1 to
-4khz.
+4kHz.
 
-Imagine debugging that 500mhz arm926 hand held battery powered device
-that ``deep sleeps'' at 32khz between every keystroke. It can be
+Imagine debugging that 500MHz ARM926 hand held battery powered device
+that ``deep sleeps'' at 32kHz between every keystroke. It can be
 painful.
 
 @b{Solution #1 - A special circuit} 
@@ -3214,14 +3218,14 @@ The RTCK signal often found in some ARM chips is used to help with
 this problem. ARM has a good description of the problem described at
 this link: @url{http://www.arm.com/support/faqdev/4170.html} [checked
 28/nov/2008]. Link title: ``How does the jtag synchronisation logic
-work? / how does adaptive clocking working?''.
+work? / how does adaptive clocking work?''.
 
 The nice thing about adaptive clocking is that ``battery powered hand
 held device example'' - the adaptiveness works perfectly all the
 time. One can set a break point or halt the system in the deep power
 down code, slow step out until the system speeds up.
 
-@b{Solution #2 - Always works - but is slower}
+@b{Solution #2 - Always works - but may be slower}
 
 Often this is a perfectly acceptable solution.
 
@@ -3231,7 +3235,7 @@ depending upon the chips on your board. @b{ARM Rule of thumb} Most ARM
 based systems require an 8:1 division. @b{Xilinx Rule of thumb} is
 1/12 the clock speed.
 
-Note: Many FTDI2232C based JTAG dongles are limited to 6mhz.
+Note: Many FTDI2232C based JTAG dongles are limited to 6MHz.
 
 You can still debug the 'lower power' situations - you just need to
 manually adjust the clock speed at every step. While painful and
@@ -3245,7 +3249,7 @@ this way.
 To set the JTAG frequency use the command:
 
 @example
-        # Example: 1.234mhz
+        # Example: 1.234MHz
         jtag_khz 1234
 @end example
 
@@ -3391,7 +3395,7 @@ You can use the ``scan_chain'' command to verify and display the tap order.
 
 Many newer devices have multiple JTAG taps. For example: ST
 Microsystems STM32 chips have two taps, a ``boundary scan tap'' and
-``cortexM3'' tap.  Example: The STM32 reference manual, Document ID:
+``CortexM3'' tap.  Example: The STM32 reference manual, Document ID:
 RM0008, Section 26.5, Figure 259, page 651/681, the ``TDI'' pin is
 connected to the Boundary Scan Tap, which then connects to the
 CortexM3 Tap, which then connects to the TDO pin.