diff options
author | dbrownell <dbrownell@b42882b7-edfa-0310-969c-e2dbd0fdcd60> | 2009-10-02 09:19:03 +0000 |
---|---|---|
committer | dbrownell <dbrownell@b42882b7-edfa-0310-969c-e2dbd0fdcd60> | 2009-10-02 09:19:03 +0000 |
commit | 1033633321056d3e20c125e21d48723fc6f8705f (patch) | |
tree | 55c5f3c1bcbda447a3d2d3185c1603aa295d5abe /doc | |
parent | d340906476950dc62201009b6fb8aeb15b211b38 (diff) | |
download | openocd_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.texi | 34 |
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 |