1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
+OpenOCD and CoreSight Tracing
+
Many recent ARM chips (Using e..g. Cortex-M3 and
Cortex-M4 cores) support CoreSight debug/trace.
This note sketches an approach currently planned for those cores
with OpenOCD.
This tracing data can help debug and tune ARM software, but not
all cores support tracing. Some support more extensive tracing
other cores with trace support +should be able to use the same
approach and maybe some of the same analysis code.
+the Cortex-M3 is assumed here to be the
+core in use, for simplicity and to reflect current OpenOCD users.
This note summarizes a software model to generate, collect, and
analyze such trace data . That is not fully implemented as of early
January 2011, +and thus is not *yet* usable.
+
+
+Some microcontroller cores support a low pin-count Single-wire trace,
with a mode where +trace data is emitted (usually to a UART. To use
this mode, +SWD must be in use.
+At this writing, OpenOCD SWD support is not yet complete either.
(There are also multi-wire trace ports requiring more complex debug
adapters than OpenOCD currently supports, and offering richer data.
+
+
+* ENABLING involves activating SWD and (single wire) trace.
+
+current expectations are that OpenOCD itself will handle enabling;
activating single wire trace involves a debug adapter interaction, and
collecting that trace data requires particular (re)wiring.
+
+* CONFIGURATION involves setting up ITM and/or ETM modules to emit the
+desired data from the Cortex core. (This might include dumping
+event counters printf-style messages; code profiling; and more. Not all
+cores offer the same trace capabilities.
+
+current expectations are that Tcl scripts will be used to configure these
+modules for the desired tracing, by direct writes to registers. In some
+cases (as with RTOS event tracking and similar messaging, this might
+be augmented or replaced by user code running on the ARM core.
+
+COLLECTION involves reading that trace data, probably through UART, and
+saving it in a useful format to analyse For now, deferred analysis modes
are assumed, not than real-time or interactive ones.
+
+
+current expectations are to to dump data in text using contrib/itmdump.c
+or derived tools, and to post-process it into reports. Such reports might
+include program messaging (such as application data streams via ITM, maybe
+using printf type messaging; code coverage analysis or so forth. Recent
+versions of CMSIS software reserve some ITM codespace for RTOS event
tracing and include ITM messaging support.
Clearly some of that data would be valuable for interactive debugging.
+
+Should someone get ambitious, GUI reports should be possible. GNU tools
+for simpler reports like gprof may be simpler to support at first.
+In any case, OpenOCD is not currently GUI-oriented. Accordingly, we now
+expect any such graphics to come from postprocessing.
measurments for RTOS event timings should also be easy to collect.
+Examples include context and message switch times, as well as times
for application interactions.
+
|
