X-Git-Url: https://review.openocd.org/gitweb?a=blobdiff_plain;ds=sidebyside;f=doc%2Fopenocd.texi;h=8156de4d19b092da9ebe54b223e1cfeb755bb59c;hb=40ac8d775375bd96b06a5a54cdd9829f60c8ebc4;hp=e4609e40a66025d608d24468629d1434a0b164a1;hpb=2e210ee48fa5a2dfc1ddc3b47c1aef4da814ca25;p=openocd.git

diff --git a/doc/openocd.texi b/doc/openocd.texi
index e4609e40a6..8156de4d19 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -845,6 +845,54 @@ the main bootloader code (which won't fit into that SRAM).
 Other helper scripts might be used to write production system images,
 involving considerably more than just a three stage bootloader.
 
+@section Target Software Changes
+
+Sometimes you may want to make some small changes to the software
+you're developing, to help make JTAG debugging work better.
+For example, in C or assembly language code you might
+use @code{#ifdef JTAG_DEBUG} (or its converse) around code
+handling issues like:
+
+@itemize @bullet
+
+@item @b{ARM Wait-For-Interrupt}...
+Many ARM chips synchronize the JTAG clock using the core clock.
+Low power states which stop that core clock thus prevent JTAG access.
+Idle loops in tasking environments often enter those low power states
+via the @code{WFI} instruction (or its coprocessor equivalent, before ARMv7).
+
+You may want to @emph{disable that instruction} in source code,
+or otherwise prevent using that state,
+to ensure you can get JTAG access at any time.
+For example, the OpenOCD @command{halt} command may not
+work for an idle processor otherwise.
+
+@item @b{Delay after reset}...
+Not all chips have good support for debugger access
+right after reset; many LPC2xxx chips have issues here.
+Similarly, applications that reconfigure pins used for
+JTAG access as they start will also block debugger access.
+
+To work with boards like this, @emph{enable a short delay loop}
+the first thing after reset, before "real" startup activities.
+For example, one second's delay is usually more than enough
+time for a JTAG debugger to attach, so that
+early code execution can be debugged
+or firmware can be replaced.
+
+@item @b{Debug Communications Channel (DCC)}...
+Some processors include mechanisms to send messages over JTAG.
+Many ARM cores support these, as do some cores from other vendors.
+(OpenOCD may be able to use this DCC internally, speeding up some
+operations like writing to memory.)
+
+Your application may want to deliver various debugging messages
+over JTAG, by @emph{linking with a small library of code}
+provided with OpenOCD and using the utilities there to send
+various kinds of message.
+@xref{Software Debug Messages and Tracing}.
+
+@end itemize
 
 @node Config File Guidelines
 @chapter Config File Guidelines
@@ -1205,7 +1253,7 @@ to source such a config file twice, with different
 values for @code{CHIPNAME}, so
 it adds a different TAP each time.
 
-If there are one or more nonzero @option{-expected-id} values,
+If there are nonzero @option{-expected-id} values,
 OpenOCD attempts to verify the actual tap id against those values.
 It will issue error messages if there is mismatch, which
 can help to pinpoint problems in OpenOCD configurations.
@@ -2325,11 +2373,13 @@ You may use @code{-enable} to highlight the default state
 (the TAP is linked in).
 @xref{Enabling and Disabling TAPs}.
 @item @code{-expected-id} @var{number}
-@*A non-zero value represents the expected 32-bit IDCODE
-found when the JTAG chain is examined.
+@*A non-zero @var{number} represents a 32-bit IDCODE
+which you expect to find when the scan chain is examined.
 These codes are not required by all JTAG devices.
 @emph{Repeat the option} as many times as required if more than one
 ID code could appear (for example, multiple versions).
+Specify @var{number} as zero to suppress warnings about IDCODE
+values that were found but not included in the list.
 @item @code{-ircapture} @var{NUMBER}
 @*The bit pattern loaded by the TAP into the JTAG shift register
 on entry to the @sc{ircapture} state, such as 0x01.
@@ -2378,12 +2428,18 @@ The TAP events currently defined are:
 @itemize @bullet
 @item @b{post-reset}
 @* The TAP has just completed a JTAG reset.
-For the first such handler called, the tap is still
-in the JTAG @sc{reset} state.
+The tap may still be in the JTAG @sc{reset} state.
+Handlers for these events might perform initialization sequences
+such as issuing TCK cycles, TMS sequences to ensure
+exit from the ARM SWD mode, and more.
+
 Because the scan chain has not yet been verified, handlers for these events
 @emph{should not issue commands which scan the JTAG IR or DR registers}
 of any particular target.
 @b{NOTE:} As this is written (September 2009), nothing prevents such access.
+@item @b{setup}
+@* The scan chain has been reset and verified.
+This handler may enable TAPs as needed.
 @item @b{tap-disable}
 @* The TAP needs to be disabled.  This handler should
 implement @command{jtag tapdisable}
@@ -2400,7 +2456,7 @@ contents to be accurate), you might:
 
 @example
 jtag configure CHIP.jrc -event post-reset @{
-  echo "Reset done"
+  echo "JTAG Reset done"
   ... non-scan jtag operations to be done after reset
 @}
 @end example
@@ -2443,26 +2499,36 @@ does include a kind of JTAG router functionality.
 In OpenOCD, tap enabling/disabling is invoked by the Tcl commands
 shown below, and is implemented using TAP event handlers.
 So for example, when defining a TAP for a CPU connected to
-a JTAG router, you should define TAP event handlers using
+a JTAG router, your @file{target.cfg} file
+should define TAP event handlers using
 code that looks something like this:
 
 @example
 jtag configure CHIP.cpu -event tap-enable @{
-  echo "Enabling CPU TAP"
   ... jtag operations using CHIP.jrc
 @}
 jtag configure CHIP.cpu -event tap-disable @{
-  echo "Disabling CPU TAP"
   ... jtag operations using CHIP.jrc
 @}
 @end example
 
+Then you might want that CPU's TAP enabled almost all the time:
+
+@example
+jtag configure $CHIP.jrc -event setup "jtag tapenable $CHIP.cpu"
+@end example
+
+Note how that particular setup event handler declaration
+uses quotes to evaluate @code{$CHIP} when the event is configured.
+Using brackets @{ @} would cause it to be evaluated later,
+at runtime, when it might have a different value.
+
 @deffn Command {jtag tapdisable} dotted.name
 If necessary, disables the tap
 by sending it a @option{tap-disable} event.
 Returns the string "1" if the tap
 specified by @var{dotted.name} is enabled,
-and "0" if it is disbabled.
+and "0" if it is disabled.
 @end deffn
 
 @deffn Command {jtag tapenable} dotted.name
@@ -2470,13 +2536,13 @@ If necessary, enables the tap
 by sending it a @option{tap-enable} event.
 Returns the string "1" if the tap
 specified by @var{dotted.name} is enabled,
-and "0" if it is disbabled.
+and "0" if it is disabled.
 @end deffn
 
 @deffn Command {jtag tapisenabled} dotted.name
 Returns the string "1" if the tap
 specified by @var{dotted.name} is enabled,
-and "0" if it is disbabled.
+and "0" if it is disabled.
 
 @quotation Note
 Humans will find the @command{scan_chain} command more helpful
@@ -4841,7 +4907,7 @@ Displays information about the current target's ETM.
 @end deffn
 
 @deffn Command {etm status}
-Displays status of the current target's ETM:
+Displays status of the current target's ETM and trace port driver:
 is the ETM idle, or is it collecting data?
 Did trace data overflow?
 Was it triggered?
@@ -4854,19 +4920,43 @@ When the configuration changes, tracing is stopped
 and any buffered trace data is invalidated.
 
 @itemize
-@item @var{type} ... one of
+@item @var{type} ... describing how data accesses are traced,
+when they pass any ViewData filtering that that was set up.
+The value is one of
 @option{none} (save nothing),
 @option{data} (save data),
 @option{address} (save addresses),
 @option{all} (save data and addresses)
 @item @var{context_id_bits} ... 0, 8, 16, or 32
 @item @var{cycle_accurate} ...  @option{enable} or @option{disable}
-@item @var{branch_output} ...  @option{enable} or @option{disable}
+cycle-accurate instruction tracing.
+Before ETMv3, enabling this causes much extra data to be recorded.
+@item @var{branch_output} ...  @option{enable} or @option{disable}.
+Disable this unless you need to try reconstructing the instruction
+trace stream without an image of the code.
 @end itemize
 @end deffn
 
-@deffn Command {etm trigger_percent} percent
-@emph{Buggy and effectively a NOP ... @var{percent} from 2..100}
+@deffn Command {etm trigger_percent} [percent]
+This displays, or optionally changes, the trace port driver's
+behavior after the ETM's configured @emph{trigger} event fires.
+It controls how much more trace data is saved after the (single)
+trace trigger becomes active.
+
+@itemize
+@item The default corresponds to @emph{trace around} usage,
+recording 50 percent data before the event and the rest
+afterwards.
+@item The minimum value of @var{percent} is 2 percent,
+recording almost exclusively data before the trigger.
+Such extreme @emph{trace before} usage can help figure out
+what caused that event to happen.
+@item The maximum value of @var{percent} is 100 percent,
+recording data almost exclusively after the event.
+This extreme @emph{trace after} usage might help sort out
+how the event caused trouble.
+@end itemize
+@c REVISIT allow "break" too -- enter debug mode.
 @end deffn
 
 @subsection ETM Trace Operation
@@ -5446,10 +5536,23 @@ If @var{value} is defined, first assigns that.
 @deffn Command {arm11 step_irq_enable}  [value]
 Displays the value of the flag controlling whether
 IRQs are enabled during single stepping;
-they is disabled by default.
+they are disabled by default.
 If @var{value} is defined, first assigns that.
 @end deffn
 
+@deffn Command {arm11 vcr} [value]
+@cindex vector_catch
+Displays the value of the @emph{Vector Catch Register (VCR)},
+coprocessor 14 register 7.
+If @var{value} is defined, first assigns that.
+
+Vector Catch hardware provides dedicated breakpoints
+for certain hardware events.
+The specific bit values are core-specific (as in fact is using
+coprocessor 14 register 7 itself) but all current ARM11
+cores @emph{except the ARM1176} use the same six bits.
+@end deffn
+
 @section ARMv7 Architecture
 @cindex ARMv7
 
@@ -5600,7 +5703,7 @@ as used by Linux with CONFIG_DEBUG_ICEDCC;
 otherwise the libdcc format is used.
 @end deffn
 
-@deffn Command {trace history} (@option{clear}|count)
+@deffn Command {trace history} [@option{clear}|count]
 With no parameter, displays all the trace points that have triggered
 in the order they triggered.
 With the parameter @option{clear}, erases all current trace history records.
@@ -5608,7 +5711,7 @@ With a @var{count} parameter, allocates space for that many
 history records.
 @end deffn
 
-@deffn Command {trace point} (@option{clear}|identifier)
+@deffn Command {trace point} [@option{clear}|identifier]
 With no parameter, displays all trace point identifiers and how many times
 they have been triggered.
 With the parameter @option{clear}, erases all current trace point counters.