summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authordbrownell <dbrownell@b42882b7-edfa-0310-969c-e2dbd0fdcd60>2009-10-02 09:19:03 +0000
committerdbrownell <dbrownell@b42882b7-edfa-0310-969c-e2dbd0fdcd60>2009-10-02 09:19:03 +0000
commit1033633321056d3e20c125e21d48723fc6f8705f (patch)
tree55c5f3c1bcbda447a3d2d3185c1603aa295d5abe /doc
parentd340906476950dc62201009b6fb8aeb15b211b38 (diff)
downloadopenocd_libswd-1033633321056d3e20c125e21d48723fc6f8705f.tar.gz
openocd_libswd-1033633321056d3e20c125e21d48723fc6f8705f.tar.bz2
openocd_libswd-1033633321056d3e20c125e21d48723fc6f8705f.tar.xz
openocd_libswd-1033633321056d3e20c125e21d48723fc6f8705f.zip
Minor ETB and ETM bugfixes and doc updates
- ETB * report _actual_ hardware status, not just expected status * add a missing diagnostic on a potential ETB setup error * prefix any diagnostics with "ETB" - ETM * make "etm status" show ETM hardware status too, instead of just traceport status (which previously was fake, sigh) - Docs * flesh out "etm tracemode" docs a bit * clarify "etm status" ... previously it was traceport status * explain "etm trigger_percent" as a *traceport* option ETM+ETB tracing still isn't behaving, but now I can see that part of the reason is that the ETB turns itself off almost immediately after being enabled, and before collecting any data. git-svn-id: svn://svn.berlios.de/openocd/trunk@2790 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Diffstat (limited to 'doc')
-rw-r--r--doc/openocd.texi34
1 files changed, 29 insertions, 5 deletions
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 28ec4a5d..32797fb3 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -4891,7 +4891,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?
@@ -4904,19 +4904,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