Skip to main content
aboutsummaryrefslogtreecommitdiffstats
blob: 011a0ee4867ba91d88fc3204d1ca223e20c61ff8 (plain) (blame)
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
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML lang=en-us>
<HEAD>
<TITLE>Target Communication Framework</TITLE>
</HEAD>

<BODY>

<H1>Target Communication Framework project</H1>

<P>
<H2><A name='Index'></A>Index</H2>

<UL>
  <LI><A href="#Summary">Summary</A>
  <LI><A href="#Goals">Goals</A>
  <LI><A href="#Features">Features</A>
  <LI><A href="#Agent">Reference implementation of a target agent</A>
  <LI><A href="#Debugger">Prototype of a debugger based on Eclipse Debug Framework and TCF</A>
  <LI><A href="#RSE">Prototype of a system monitor and remote file access based on Remote System Explorer and TCF</A>
</UL>

<P>
<H2><A name='Summary'></A>Summary </H2>

<P>Today almost every device software development tool on the market has its own
method of communication with target system. Communication methods often conflict
with each other, require individual setup, configuration and maintenance, impose
all kinds of unnecessary limitations. Target Communication Framework is designed
to establish common ground in the area of communication protocols between
development tools and embedded devices.

<P>
<H2><A name='Goals'></A>Goals </H2>
<P>
<UL>
  <LI>Universal, extensible, simple, lightweight, vendor agnostic framework for
  tools and targets to communicate for purpose of debugging, profiling, code
  patching and other device software development needs.
  <LI>Single configuration per target (not per tool per target as today in most
  cases), or no configuration when possible.
  <LI>Small overhead and footprint on target side. </LI></UL>
<P>

<H2><A name='Features'></A>Features </H2>
<P><A href="TCF Specification.html">Target Communication Framework Specification</A> is a document
describing design goals, requirements and format of TCF communication protocol,
as well as framework API and software design considerations.
<P>TCF communication model is based on the idea of services. A service is a group
of related commands, events and semantics. A service can be discovered,
added or removed as a group at communication endpoint. Service definitions are
not part of the framework specification, and new services are expected to be
defined by developers of tools and target agents. However, standardization of
common services is needed to achieve certain level of compatibility of
tools/targets, see <A href="TCF Services.html">TCF Services Specification</A>
as starting point of this work.

<H2><A name='Agent'></A>Reference implementation of a target agent</H2>

<P>Current reference implementation of TCF target agents is fully functional,
can run on Windows, Linux and VxWorks.  On Linux it is implemented
using PTRACE, on VxWorks is uses vxdbgLib, on Windows it uses Debug API and dbghelp.dll.
The agent provides the following services:
<UL>
    <LI>Run Control - provides threads and processes run control functionality.

    <LI>Breakpoints - provides debugger breakpoints support.

    <LI>Registers - allows inspection and modification of CPU registers.

    <LI>Stack Trace - thread stack back-tracing.

    <LI>Memory - program memory access.

        <LI>Expressions - expression evaluation on remote target.

        <LI>Memory Map - information about executable modules (files) mapped (loaded) into target memory.

        <LI>Path Map - manages file path translation across systems.

        <LI>Symbols - debugger symbols information.

    <LI>Processes - provides access to the target OS's process
    information, allows starting new and terminating existing processes,
    and allows attaching and detaching processes for debugging.

    <LI>Line Numbers - provides mapping between locations in the source files
    and corresponding machine instruction addresses in the executable object.
    Implemented for Linux and Windows, not supported on VxWorks.

    <LI>Sys Monitor - provides list of processes, process attributes and
    CPU/memory utilization data. On Linux it is implemented using /proc file
    system, on Windows and VxWorks it is not currently supported.

    <LI>File System - provides access to remote file system.

    <LI>Streams - a generic service to support streaming of data between host and target.

    <LI>Diagnostics - allows testing of communication channel and agent
    functionality.
</UL>

<P>The agent code is designed to be easily extensible by adding new command
handler implementations. The code separates machine dependences, common TCF
logic and service implementations, which allows easy porting to a new OS or a
target and reconfiguring of the agent for specific needs. The code is written in
ANSI C. See <A href="TCF Linux Agent Prototype.html">TCF Linux Agent Prototype</A>
for more details about the agent code.

<H2><A name='Debugger'></A>Prototype of a debugger based on Eclipse Debug Framework and TCF</H2>

<P>The prototype code connects Eclipse Debug Framework and Target Communication
Framework. It allows to launch Eclipse debug session by connecting to a target
running TCF agent, and then perform basic debugging tasks, like resuming,
suspending, single-stepping, setting/removing breakpoints, etc.
<P>The prototype launch configuration autodetects TCF targets on a local network
and allows a user to connect to a target by simply selecting it from a list
without a need for any further configuration or setup. TCF launch configuration
dialog also offers controls to run a built-in diagnostics on a selecting target,
which perform stress testing of communication channel, agent and target itself:
<P><IMG alt="TCF launch configuration dialog" src="TCF_Launch_Dialog.jpg">

<P>The prototype makes use of flexible debug model element hierarchy support,
which is available in Eclipse debug framework since Eclipse 3.2. The flexible
hierarchy allows debugger views to be "data driven" or, in other words, dynamically
adapt to a given targets capabilities and structure, without a need to modify
debugger code to support a new target.

<H2><A name='RSE'></A>Prototype of a system monitor and remote file access based on Remote System Explorer and TCF</H2>

<P>Remote System Explorer is an Eclipse based component that allows users to
create connections to remote machines and explore their file systems, see list
of processes and access some other resources, like remote shells. Remote System
Explorer has been designed as a flexible, extensible framework to which Eclipse
plug-in developers can contribute their own system definitions, actions, etc.
<P>The prototype enables use of Processes and Files subsystems of Remote System
Explorer over TCF. It also extends Processes subsystem to include CPU
utilization data and some other process attributes in RSE views:
<P><IMG alt="Remote System Explorer: Files subsystem over TCF" src="TCF_RSE_Files.jpg">
<P><IMG alt="Remote System Explorer: Processes subsystem over TCF" src="TCF_RSE_Processes.jpg">

</BODY>
</HTML>

Back to the top