CMP Esd0312

E MB E D D E D S Y S T E MS D E S I G N
MARCH 2012
The Official Publication of The Embedded Systems Conferences and Embedded.com
VOLUME 25,
NUMBER 2
Discriminated
unions
9
Debug real-time
SW with logic analyzer
19
Managing multiple
processes in multicore
27
Probing pointers
34
VERIFYING
REQUIREMENTS
AND OBJECT
CODE
12
SAFE
RELIABLE
SECURE
For nearly 30 years the worlds leading industrial companies have trusted Green Hills
Softwares secure and reliable high performance software for safety-critical applications.
From manufacturing automation, to telemetry and control systems, Green Hills Software
has been delivering proven and secure underpinning technology.
To nd out how the worlds most secure and reliable operating system and software
can take the risk out of your industrial project, visit www.ghs.com/s4i
Copyright 2012 Green Hills Software. Green Hills Software and the Green Hills logo are registered trademarks of
Green Hills Software. All other product names are trademarks of their respective holders.
TRUSTED SOFTWARE FOR INDUSTRIAL
AUTOMATION AND CONTROL
Mouser delivers the components you need, on-time. And with local Technical
Support and Customer Service Experts in 19 locations around the world, youll
nd the newest components to launch your new design seamlessly.
The Newest Products for Your Newest Designs
Mouser and Mouser Electronics are registered trademarks of Mouser Electronics, Inc. The Newest Products for Your Newest Designs is a registered trademark of Mouser Electronics, Inc.
mouser.com
Semiconductors and electronic
components for design engineers.
Scan Here
mouser.com
Authorized Distributor
We deliver
ASAP, PDQ
and JIT . So,
you
re never
SOL.
AS9120A
Certified Distributor
THE OFFI CI AL PUBLI CATI ON OF THE EMBEDDED SYSTEMS CONFERENCES AND EMBEDDED. COM
VOLUME 25, NUMBER 2
MARCH 2012
COLUMNS
programming
pointers
9
Discriminated unions
BY DAN SAKS
Discriminated unions can be useful in
some applications, but they also pro-
vide insight into the advantages of
using virtual functions.
break points
34
Probing pointers
BY JACK G. GANSSLE
The wrong probe can either cause your
circuit to fail or even to physically
destroy components. Here are some of
the issues.
DEPARTMENTS
#include
5
Safety threats: from satellites to
pods in you pocket
BY COLIN HOLLAND
DARPA's High-Assurance Cyber
Military Systems program is look-
ing for a synthesizer capable of
producing a machine-checkable
proof that generated code satises
functional specications as well as
security and safety policies.
parity bit
7
Open to interpretation
new products
33
M2M and security
IN PERSON
DesignWest/ESC Silicon Valley
March 1629, 2012
http://esc.eetimes.com/siliconvalley/
ONLINE
www.embedded.com
12
EMBEDDED SYSTEMS DESIGN (ISSN 1558-2493) print; (ISSN 1558-2507 PDF-electronic) is published 10 times a year as follows: Jan/Feb, March, April, May, June,
July/August, Sept., Oct., Nov., Dec. by the EE Times Group, 600 Harrison Street, 5th oor, San Francisco, CA 94107, (415) 947-6000. Please direct advertising and editorial
inquiries to this address. SUBSCRIPTION RATE for the United States is $55 for 10 issues. Canadian/Mexican orders must be accompanied by payment in U.S. funds with addi-
tional postage of $6 per year. All other foreign subscriptions must be prepaid in U.S. funds with additional postage of $15 per year for surface mail and $40 per year for
airmail. POSTMASTER: Send all changes to EMBEDDED SYSTEMS DESIGN, EE Times/ESD, PO Box #3609, Northbrook, IL 60065-3257, embedsys@omeda.com. For cus-
tomer service, telephone toll-free (847) 559-7597. Please allow four to six weeks for change of address to take effect. Periodicals postage paid at San Francisco, CA and additional
mailing ofces. EMBEDDED SYSTEMS DESIGN is a registered trademark owned by the parent company, EE Times Group. All material published in EMBEDDED SYSTEMS
DESIGN is copyright 2010 by EE Times Group. All rights reserved. Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission.
Cover Feature:
Tracing requirements
through to object code verication
BY MARK PITCHFORD
Verifying object code can mean the difference between success
and failure, quality and crap. But skipping the step because a
standard doesnt require it or because it theoretically eats into
prots is a surprisingly common practice. The author postu-
lates that this practice is not only shortsighted but no longer
valid.
19
Troubleshooting real-time software
issues using a logic analyzer
BY DAVID B. STEWART
This logic analyzer technique is a power-tool for the
embedded software engineers toolbox.
28
Manage multiple processes and processors
in a deterministic multicore design
BY CHRIS MAIN
How should processes running on different RTOSes communi-
cate in multi-OS systems? The author suggests you can manage
inter-process communications with global-object networking.
INDUSTRIAL
MEDICAL
AEROSPACE
AVIATION
SYSTEM ON A CHIP
CONSUMER
Express Logic has completed 14 years
of successful business operation,
and our agship product, ThreadX,
has been used in over 1 billion
electronic devices and systems,
ranging from printers to smartphones, from single-chip
SoCs to multiprocessors. Time and time again, when
leading manufacturers put their company on the line,
when their engineering team chooses an RTOS for their
next critical product, they choose ThreadX.
Our ThreadX RTOS is rock-solid, thoroughly eld-proven,
and represents not only the safe choice, but the most
cost-effective choice when your companys product
ThreadX, FileX, and TraceX are registered trademarks, and NetX, USBX, PEGX, StackX, and Certication Pack are trademarks of Express Logic, Inc.
All other trademarks are the property of their respective owners.
Copyright 2010, Express Logic, Inc.
When Your Companys Success, And Your Job, Are On The Line -
You Can Count On Express Logics ThreadX
RTOS
REALLY COUNTS
THREADX: WHEN IT
simply must succeed. Its royalty-free
licensing model helps keep your BOM low,
and its proven dependability helps keep
your support costs down as well. ThreadX
repeatedly tops the time-to-market results
reported by embedded developers like you. All the while,
Express Logic is there to assist you with enhancements,
training, and responsive telephone support.
Join leading organizations like HP, Apple, Marvell, Philips, NASA,
and many more who have chosen ThreadX for use in over 800
million of their products because their products are too
important to rely on anything but the best. Rely on ThreadX,
when it really counts!
Contact Express Logic to nd out more about our ThreadX RTOS, FileX
le system, NetX
Dual IPv4/IPv6 TCP/IP stack, USBX

USB Host/Device/OTG stack, and our PEGX
graphics toolkit for embedded GUI development. Also ask about our TraceX

real-time event trace and analysis tool, and StackX
, our patent-pending stack size analysis tool that makes stack overows a
thing of the past. And if youre developing safety-critical products for aviation, industrial or medical applications, ask
about our new Certication Pack
for ThreadX.
For a free evaluation copy, visit www.rtos.com 1-888-THREADX
Edward L. Lamie
With ThreadX
Second Edition
Now with appendices for ARM, Cold re,
MIPS and PowerPC architectures
Newnes
INCLUDED CD-ROM
REAL-TIME
EMBEDDED
MULTITHREADING
T H R E A D
BY Colin Holland #include
E MB E D D E D S Y S T E MS D E S I G N E MB E D D E D S Y S T E MS D E S I G N
BY Colin Holland #include
Director of Content
Colin Holland
colin.holland@ubm.com
Managing Editor
Susan Rambo
(415) 947-6675
susan.rambo@ubm.com
Acquisitions/Newsletter Editor,
ESD and Embedded.com
Bernard Cole
(928) 525-9087
bccole@acm.org
Contributing Editors
Michael Barr
Jack W. Crenshaw
Jack G. Ganssle
Dan Saks
Art Director
Debee Rommel
debee.rommel@ubm.com
Production Director
Donna Ambrosino
dambrosino@ubm-us.com
Article submissions
After reading our writers guidelines, send
article submissions to Bernard Cole at
bccole@acm.org
Subscriptions/RSS Feeds/Newsletters
www.eetimes.com/electronics-subscriptions
Subscriptions Customer Service (Print)
Embedded Systems Design
PO Box # 3609
Northbrook, IL 60065- 3257
embedsys@omeda.com
(847) 559-7597
Article Reprints, E-prints, and
Permissions
Mike Lander
Wrights Reprints
(877) 652-5295 (toll free)
(281) 419-5725 ext.105
Fax: (281) 419-5712
www.wrightsreprints.com/reprints/index.cfm
?magid=2210
Publisher
David Blaza
(415) 947-6929
david.blaza@ubm.com
Associate Publisher, ESD and EE Times
Bob Dumas
(516) 562-5742
bob.dumas@ubm.com
CorporateUBM Electronics
Paul Miller Chief Executive Ofcer
David Blaza Vice President
Karen Field Senior Vice President, Content
Felicia Hamerman Vice President, Marketing
Brent Pearson Chief Information Ofcer
Jean-Marie Enjuto Vice President, Finance
Amandeep Sandhu Director of Audience Engagement &
Analytics
Barbara Couchois Vice President, Partner Services &
Operations
CorporateUBM LLC
Marie Myers Senior Vice President,
Manufacturing
Pat Nohilly Senior Vice President, Strategic
Development and Business
Administration
Safety threats: from satellites
to pods in your pocket
www.embedded.com | embedded systems design | MARCH 2012 5
T
he spotlight is shining again on
the security of embedded com-
puter systems as the Defense Ad-
vanced Research Projects Agency
(DARPA) sets up its High-Assurance
Cyber Military Systems (HACMS)
program.
Our vision for HACMS is to
adopt a clean-slate, formal method-
based approach to enable semi-auto-
mated code synthesis from executable,
formal specifications, said DARPA
program manager, Kathleen Fisher.
Embedded computer systems play
a part in every aspect of DoDs tech-
nology. The software in these systems
does everything from manage large
physical infrastructures and run pe-
ripherals such as printers and routers,
to control medical devices such as
pacemakers and insulin pumps. Net-
working these embedded computer
systems enables remote retrieval of di-
agnostic information, software up-
dates, and access to innovative features,
but it also introduces vulnerabilities to
the system via remote attack.
In addition to generating code,
HACMS is looking for a synthesizer
capable of producing a machine-
checkable proof that the generated
code satisfies functional specifica-
tions as well as security and safety
policies. A key technical challenge is
the development of techniques to en-
sure that such proofs are composable,
allowing the construction of high-as-
surance systems out of high-assur-
ance components.
Technologies cited as key to
HACMS include semi-automated soft-
ware synthesis systems, verification
tools such as theorem provers and
model checkers, and specification lan-
guages. And opportunities will abound
for industry at large to take advantage
as HACMS aims to produce a set of
publicly available tools integrated into a
high-assurance software workbench,
widely distributed to both defense and
commercial sectors. In the defense sec-
tor, HACMS plans to enable high-as-
surance military systems ranging from
unmanned ground, air and underwater
vehicles, to weapons systems, satellites,
and command and control devices.
Of course, security for embedded
systems is not a new concern. Security
is a major focus throughout this years
Embedded Systems Conference, now
part of DESIGN West. ESC offers two
tracks directly on security and another
on embedded systems disasters, which
will probably touch on the aftermath
of security-related flaws. Also, for the
first time along side ESC, Black Hat is
presenting a one-day version of its
renowned Black Hat Briefings, a series
of technical security conferences that
bring together thought leaders from
the corporate and government sectors
to academic and even underground re-
searchers. On the same day (March
29th) Robert Vamosi, author of When
Gadgets Betray Us: The Dark Side of our
Infatuation with New Technologies, will
examine in his keynote address how, in
the rush to embrace the next new
thing, real concerns about informa-
tion security or personal privacy fall by
the wayside.
I hope to see as many of you as
possible at ESCDESIGN Westfind
out more at www.ubmdesign.com.
Colin Holland
Colin.holland@ubm.com
Colin Holland is the director
of content for Embedded
Systems Design magazine,
Embedded.com, and the
DesignWest and East (which
includes the Embedded
Systems Conferences).
You may reach him at
colin.holland@ubm.com.
INNOVATORS CREATE INTELLIGENT ROBOTS
THAT TRANSFORM MANUFACTURING.
Image supplied by KUKA
When the innovators at KUKA decided to create the foundation for the automation of tomorrow, they decided
to work with Wind River. Building upon the proven reliability and breakthrough performance of our VxWorks and
multi-core platforms, the KUKA team developed their revolutionary KR C4 controllera safer, more powerful,
more exible system that allows all integrated controllers to share a common database and infrastructure. And
by working with Wind River, they did it all with far less risk.
INNOVATORS START HERE.
Please visit http://www.windriver.com/customers to learn more
about how Wind River customers have transformed their devices.
KUKA KR C4
Control system that integrates robot, motion, sequence,
and process control
Built on VxWorks and multi-core operating environments
o
penFlow and Software Defined
Networking exhibit tremendous
promise. (Controlling network
flow with the OpenFlow protocol Daniel
Proch, www.eetimes.com/4235488)! I
hope the open source consortium make
it easier and transparent for small com-
panies and individual like us to get in-
volved, participate, and contribute to its
future success.
Netteligent
Many of the possibilities for network
control described for OpenFlow and
even for existing technologies open
up questions about the motives be-
hind that control. Cable providers
and other ISPs are increasingly get-
ting into providing content, and it is
very easy to see them tilting the table
towards their content and against
competitors (i.e. Netflix). It is also
questionable that centralized control
over all flows works better than a ro-
bust distributed control system. Even
if you argue that centralized control
is necessary to tame rogue data (i.e.
P2P), there is still dependence on
per-packet inspection. Most of these
marking schemes can be spoofed rel-
atively easily. Bottom line, there is
still a lot of work to be done in this
area.
Larry Mittag
I am not sure if vendors like Cisco, Ju-
niper, etc., are really interested in
OpenFlow implementation. Notice,
their routers and switches would per-
form very simple tasksno sophisti-
cated routing/switching any more.
Only simple match-action aproach.
The intelligence is moved to the ex-
ternal manager. New features would
be implemented externally to
router/switches. So their devices
would be easily replaced by any ven-
dor boxes supporting OpenFlow.
bgolab
Stay on target
Although enlightening as always, unfor-
tunately, this story line appears to be
branching away from this topic prema-
turely (Quiet down out there! Jack
Crenshaw, www.eetimes.com/4235490).
Models for Kalman filtering are not
an independent choice that can be
fathomed by examining input/output
data plots. There are two special re-
quirements:
First, the model must be one-step
predictive. Given past and current
data, it must provide a prediction (a
very good one cant hurt!) of what the
next output response will be, given
the next input, but before that new
output is observed.
Second, the model form does not
use x-y past history directly like the
least-squares fitting discussed so far,
but instead, it must reduce past histo-
ry to bare essentials in the form of a
set of state variables (sometimes
without any direct physical interpre-
tation), with model outputs subse-
quently derived from these state vari-
ables, and with new inputs serving to
influence future state variable values.
The key relationships are described
by a matrix of parameters that Ill
call a state matrix for brevity.
Without this matrix model, you cant
calculate the variance propagation
equations, nor Kalman gain correc-
tions to keep the model on-track, and
the ordinary Kalman Filter idea is in
trouble.
Control theory students know
that a state matrix is easily obtained
by looking at the last page of the
homework handout. In real world ap-
plications, however, the problem of
estimating parameter values for the
state matrix is a whole lot harder. I
suspect that most attempts to apply
Kalman filtering are already in trouble
at this point, well before reaching the
less familiar territory of the variance
model. It might be interesting to hear
about difficulties others have had
with this.
I hope that Jack gets back to de-
scribe clear and effective ways to deal
with the tricky model identification
fitting problem, or the rest wont mat-
ter much. Of course, this article was
still just the beginning of the story.
RidgeRat
Open to interpretation
parity bit
Many of the possibilities for
network control described
for OpenFlow and existing
technologies open up ques-
tions about the motives
behind that control.
!
!
!
center of the engineering universe
designwest
Its incoming fast! For the first time, seven summits including ESC converge
at DESIGN West, creating a burst of expert training and education,
hands-on knowledge exchanges, and the latest products and techniques.
Be here, at the center of the engineering universe.
March 26-29, 2012
McEnery Convention Center
San Jose, CA
Sharpen the skills you need now.
(PEHGGHG+:DQG6:GHVLJQ7RWDOV\VWHPVLQWHJUDWLRQ
3RZHUPDQDJHPHQW2SHQVRXUFHVRIWZDUH$QGURLG
(PEHGGHGVHFXULW\/('VDQGVHQVRUV$QGPRUHNH\WRSLFV
designmed
android
/('V
esc
blackhat
multicore
sensors
center of the engineering universe
Everything you need to know
in one location at one time.
g g
re, at the center
Marc
McEnery C
Sa
p
ngineering univ
2012
on Center
CA
ubmdesign.com
Register
Now
C solution using a construct called a
discriminated union, and examine its
limitations.
AN ILLUSTRATIVE PROBLEM
Suppose you have an application that
employs two-dimensional geometric
shapes, such as circles, rectangles, and
triangles. At a minimum, each shape
object contains some linear or angular
distances sufficient to characterize the
physical extent of the shape. For ex-
ample, a circle has a radius, a rectangle
has a height and a width, and a trian-
gle has two sides and an angle. The
shapes may have common attributes
as well, such a position (planar coordi-
nates), or outline and fill colors.
A fairly traditional C implemen-
tation for a shape is a structure with a
nested union, such as:
typedef struct shape shape;
struct shape {
coordinates position;
color outline, fill;
shape_kind kind;
union {
circle_part circle;
rectangle_part rectangle;
triangle_part triangle;
} u;
};
The union member, u, is large enough to hold the largest
of its members, but it can only store the value of one
member at a time.
In this example, each union member has a different
structure type. For a circle, you need to store only the ra-
dius, as in:
typedef struct circle_part circle_part;
struct circle_part {
double radius;
};
For a rectangle, you need the height and width:
O
ff and on for almost two years,
Ive been writing about tech-
niques for representing and
manipulating memory-mapped de-
vices in C and C++. My more recent
columns have been more about C++
than C, focusing on language fea-
tures such as constructors and new-
expressions, which C++ doesnt
share with C.
1, 2
Some readers have suggested that
the C code I presented is preferable to
the C++ code because the C structure
implementations for devices are gen-
erally simpler than their correspon-
ding C++ class implementations. Last
month, I argued that the C++ imple-
mentations are actually better because
theyre easier to use correctly and
harder to use incorrectly.
Other readers have claimed that
my C++ implementations are flawed
because theyre too simplethey dont use inheritance
and preclude the use of virtual functions.
Classes with virtual functions can be very useful, but
they arent the solution to every problem. Classes that
represent memory-mapped devices, such as the ones Ive
presented, work with real hardware specifically because
they dont use virtual functions. The new C++ Standard
acknowledges the usefulness of such classes by defining
categories such as standard layout classes, which avoid fea-
tures such as virtual functions.
In the coming months, Ill explain what virtual func-
tions are. Ill show why they can be useful in some appli-
cations, but undesirable in classes that represent memory-
mapped device registers. Ill also show you how C++
typically implements virtual functions by showing how
you can emulate them in C.
Ill begin this month by looking at the sort of problem
that virtual functions are good at solving. Ill show a typical
By Dan Saks
Dan Saks is president of Saks & Associates, a C/C++
training and consulting company. For more informa-
tion about Dan Saks, visit his website at
www.dansaks.com. Dan also welcomes your feed-
back: e-mail him at dan@dansaks.com.
programming
pointers
can be useful in some
applications, but they
also provide insight into
the advantages of using
virtual functions.
!
!
!
typedef struct rectangle_part rectangle_part;
struct rectangle_part {
double height, width;
};
For a triangle, you need two sides and an adjacent angle:
typedef struct triangle_part triangle_part;
struct triangle_part {
double side1, side2, angle;
};
When the union members have such simple types,
you might find it easier to dispense with the named
structure types and simply define unnamed structures
inside the union, as in:
union {
struct {
double radius;
} circle;
struct {
double height, width;
} rectangle;
struct {
double side1, side2, angle;
} triangle;
} u;
The value of the shapes kind member indicates which
union member is currently in use. The shape_kind type
enumerates the possible values:
enum shape_kind {
sk_circle, sk_rectangle, sk_triangle
};
typedef enum shape_kind shape_kind;
For example, setting a shapes kind member to sk_rec-
tangle indicates that its now OK to access (write to or
read from) the unions rectangle member and its
height and width members.
A union paired with a discrete value that indicates
the active member of the union is called a discriminated
union or a tagged union. Some programming languages
have a similar construct called a variant record. The dis-
crete value is called a discriminator or tag. I prefer the
terms discriminated union and discriminator because tag
already has another meaning in C. The discriminator
typically has an enumeration type, but could have an in-
tegral type.
You can write a small assortment of initialization
functions to properly initialize each kind of shape. For
example:
programming pointers
Listing 1 A function that nds the largest shape in an
array of shapes, using an overt switch statement.
shape const *largest(shape const s[], size_t n) {
shape const *p = NULL;
double max = -1;
size_t i;
for (i = 0; i < n; ++i) {
double area = -1;
switch (s[i].kind) {
case sk_circle:
area = PI * s[i].u.circle.radius
* s[i].u.circle.radius;
break;
case sk_rectangle:
area = s[i].u.rectangle.height
* s[i].u.rectangle.width;
break;
case sk_triangle:
area = sin(s[i].u.triangle.angle)
* s[i].u.triangle.side1
* s[i].u.triangle.side2 / 2;
break;
}
if (area > max) {
max = area;
p = &s[i];
}
}
return p;
}
ANONYMOUS UNIONS
C++ and more recent dialects of C support anony-
mous unions. That is, you can leave the union itself
unnamed and access the union members as if they
were members of the enclosing structure. If you de-
fine the shape structure as:
struct shape {
~~~
union {
circle_part circle;
rectangle_part rectangle;
triangle_part triangle;
}; // union name omitted
};
then you can simplify expressions such as:
s->u.rectangle.height = h;
to just:
s->rectangle.height = h;
My examples dont use anonymous unions be-
cause I tested this code with older C compilers that
dont support them.
10 MARCH 2012 | embedded systems design | www.embedded.com
void rectangle_construct
(shape *s, double h, double w) {
s->kind = sk_rectangle;
s->u.rectangle.height = h;
s->u.rectangle.width = w;
}
initializes a shape as a rectangle with a particular height and
width. You can write similar initialization functions for circle
and triangles. Using these functions, you can create an array
of assorted shapes as follows:
shape sa[4];
~~~
circle_construct(&sa[0], 2);
triangle_construct(&sa[1], 5, 6, asin(0.8));
rectangle_construct(&sa[2], 3, 4);
circle_construct(&sa[3], 3);
Suppose your application needs to determine the shape
with the largest area in a collection of shapes. You can do the
job with the function named largest shown in Listing 1.
Most of the loop body in Listing 1 is a switch statement
that computes the area of a shape. This is arguably a funda-
mental shape operation that would be better packaged as an
operation all by itself:
double shape_area(shape const *s) {
switch (s->kind) {
case sk_circle:
return PI * s->u.circle.radius
* s->u.circle.radius;
case sk_rectangle:
return s->u.rectangle.height
* s->u.rectangle.width;
case sk_triangle:
return sin(s->u.triangle.angle)
* s->u.triangle.side1
* s->u.triangle.side2 / 2;
}
return -1;
}
Using the shape_area function dramatically simplifies the
largest function, as shown in Listing 2.
CORRECTNESS AND MAINTENANCE PROBLEMS
One of the problems with discriminated unions is that it re-
quires a lot of discipline to ensure that you dont access a
union member unless its the currently active member as
indicated by the discriminator. In most cases, this means
you should be scrupulous about wrapping the accesses to
union members inside if- or switch-statements that test the
discriminator.
Unfortunately, nothing in C prevents accidents such as:
case sk_rectangle:
area = s->u.triangle.side1
* s->u.triangle.side2;
~~~
This code will compile and then produce unpredictable, pos-
sibly erroneous, run-time results.
Some languages, such as Ada, have built-in support for
discriminated unions intended to prevent such mishaps. An-
drei Alexandescru showed how you can implement safe dis-
criminated unions in C++ using template metaprogramming
techniques.
3, 4
Another problem with discriminated unions is that they
can easily lead to code thats hard to maintain. For example,
in addition to the shape_area function, your application
might include other shape operations such as
shape_perimeter, shape_resize, or shape_put. Each
function has a similar, if not identical, switch-statement
structure as shape_area. If you add a new shape, or modify
the attributes of an existing shape, you probably have to
change every one of those functions.
Virtual functions provide an alternative to discriminated
unions that are safe, efficient, and often more maintainable.
Ill discuss virtual functions in my upcoming columns.
ENDNOTES:
1. Saks, Dan. Calling constructors with placement new, Embedded Sys-
tems Design, September 2011, p. 9. www.eetimes.com/4219506.
2. Saks, Dan. Using member new to map devices, Embedded.com,
November 2011. www.eetimes.com/4230743.
3. Alexandrescu, Andrei. Discriminated Unions (I), Dr. Dobbs Journal,
April 1, 2002. http://drdobbs.com/184403821.
4. Alexandrescu, Andrei.Discriminated Unions (II), Dr. Dobbs Journal,
June 1, 2002. http://drdobbs.com/184403828.
Listing 2 A function that nds the largest shape in an
array of shapes, using the shape_area function.
shape const *largest(shape const s[], size_t n) {
shape const *p = NULL;
double max = -1;
size_t i;
for (i = 0; i < n; ++i) {
double area = shape_area(&s[i]);
if (area > max) {
max = area;
p = &s[i];
}
}
return p;
}
o longer is it enough to write robust software. The recent
trend in standards development is to prove that a projects
requirements are fulfilled, even if those requirements have
changed during the course of a projects lifecycle. Require-
ments traceability yields a more predictable outcome at
deployment and responds to an increased demand for
sound monitoring and management
techniques during development, par-
ticularly between project phases.
Most requirements traceability
stops short of object code, suggesting
an implied reliance on the faithful ad-
herence of compiled object code to the
intentions expressed by the author of
the source code. This can have critical
consequences, such as putting peoples
lives risk or having a significant impact
on business.
Where an industry standard is en-
forced, a development team will usual-
ly adhere only to the parts of standard
that are relevant to their application.
Object code verification, on the other
hand, ensures that critical parts of an
application are not compromised by
the object code, which in principle is a
desirable outcome for any software
whatever its purpose. However, can ob-
ject code verification be justified as part
of a test regime outside the confines of
its enforcement through the required
adherence to a standardparticularly
in those industries where software fail-
ure brings dire consequences, and yet
standards are less mature.
In this article, I explain why its im-
portant to verify object code and how
its possible to manage requirements so
Tracing requirements
through to object
code verification
cover feature
you can trace them right through to
object-code verification (OCV).
STANDARDS & CERTIFICATIONS
Irrespective of the industry and the
maturity of its safety standards, the
case for software that has been proven
and certified to be reliable through
standards compliance and a require-
ments-traceable process is becoming
ever more compelling.
According to research directed by
the U.S. National Institute of Security
Technology, 64% of software vulnera-
bilities stem from programming errors.
For example, an analysis of 3,140 med-
ical device recalls conducted between
1992 and 1998 by the U.S. Food and
Drug Administration (FDA) revealed
that 242 of the recalls (7.7%) were at-
tributable to software failures. In April
2010, the FDA warned users about
faulty components in defibrillators
manufactured by Cardiac Science
Corp. Unable to remedy the problems
with software patches, Cardiac Science
was forced to replace 24,000 defibrilla-
tors. As a result, Cardiac Sciences
shares were hit; the company reported
a net loss of $18.5 million.
The medical-equipment standard
IEC 62304 is designed specifically to
provide suitable processes to minimize
the likelihood of such problems in
medical devices. Other industries have
similar standards as shown in Table 1.
Although each is tuned to a specif-
ic industry sector, these standards have
much in common. In particular, the
IEC 61508 industrial standard is some-
times used as a basis for other stan-
dards, including all of the others
shown except DO-178B/C.
One example of how this com-
monality of purpose shows itself is in
the use of Safety Integrity Levels. In
each case, a risk assessment is complet-
ed for every software project to assign
the required assessment safety level of
each part of the system. The more de-
manding the safety level, the more rig-
orous and thorough the process and
testing need to be.
REQUIREMENTS MANAGEMENT
AND TRACEABILITY
Requirements traceability is widely ac-
cepted as a development best practice
to ensure that all requirements are im-
plemented and that all development ar-
tifacts can be traced back to one or
more requirements. The automotive in-
dustrys draft standard ISO 26262 re-
quires bidirectional traceability and has
a constant emphasis on the need for the
derivation of one development tier
from the one above it (see sidebar).
While this is a laudable principle,
last minute changes of requirements or
code made to correct problems identi-
fied during test tend to put such ideals
in disarray. Many projects fall into a
pattern of disjointed software develop-
ment in which requirements, design,
implementation, and testing artifacts
are produced from isolated develop-
ment phases. Such isolation results in
tenuous links between requirements,
the development stages, and/or the de-
velopment teams.
Leading safety critical standards and safety integrity levels.
Industry Standard Safety integrity level
Avionics DO-178B (First published 1992) / DO-178C (2012) Level E to Level A
Industrial IEC 61508 (First published 1998, updated 2010) SIL Level 1 to 4
Railway CENELEC EN 50128 (First published 2001) SIL Level 0 to 4
Nuclear IEC 61513 (First published 2001) SIL Level 1 to 4
Automotive ISO 26262 (First published and updated 2011) ASIL A to ASIL D
Medical IEC 62304 (First published 2006) Class A to Class C
Process IEC 61511 (First published 2003) SIL Level 1 to 4
Table 1
MAINTAIN BIDIRECTIONAL TRACEABILITY OF
REQUIREMENTS
The intent of this specific practice is to maintain the bidirectional traceability of re-
quirements for each level of product decomposition. When the requirements are
managed well, traceability can be established from the source requirement to its
lower level requirements and from the lower level requirements back to their
source. Such bidirectional traceability helps determine that all source requirements
have been completely addressed and that all lower level requirements can be
traced to a valid source. Requirements traceability can also cover the relationships
to other entities such as intermediate and final work products, changes in design
documentation, and test plans. Source: ISO 26262
RTM sits at the heart of the project, defining and describing the interaction between the design,
code, test and verification stages of development.
Figure 1
Map requirements
to architecture;
generate defects
Manage requirements;
assign verification and
debug tasks; track defects
Implement requirements;
map to code and verify
design; generate defects
Verifies requirements
against test cases;
generate defects
Model or
design
specification
Software
requirements
and defect
reports
Code base
Requirements
Traceability
Matrix
(RTM)
Test cases
Project managers
Test engineers
Software engineers
Development and
build engineers
cover feature
The traditional view of software de-
velopment shows each phase flowing
into the next, perhaps with feedback to
earlier phases, and a surrounding
framework of configuration manage-
ment and process (e.g., Agile, RUP).
Traceability is assumed to be part of the
relationships between phases. However,
the reality is that while each individual
phase may be conducted efficiently, the
links between development tiers be-
come increasingly poorly maintained
over the duration of projects.
The answer to this conundrum lies
in Requirements Traceability Matrix
(RTM) as shown in Figure 1, which sits
at the heart of any project even if its
not identified as such. Whether the links
are physically recorded and managed or
not, they still exist. For example, a devel-
oper creates a link simply by reading a
design specification and uses that to
drive the implementation.
This alternative view of the develop-
ment landscape illustrates the impor-
tance that should be attached to the
RTM. Due to this fundamental centrali-
ty, its vital that project managers place
sufficient priority on investing in tooling
for RTM construction. The RTM must
also be represented explicitly in any life-
cycle model to emphasise its importance,
as Figure 2 illustrates. With this elevated
focus, the RTM is constructed and main-
tained efficiently and accurately.
When the RTM becomes the center
of the development process, it has an
impact on all stages of design from high-
level requirements through to target-
based deployment and OCV.
The Tier 1 high-level requirements
might consist of a definitive statement of
the system to be developed. This tier
may be subdivided depending on the
scale and complexity of the system.
Tier 2 describes the design of the
system level defined by Tier 1. Above all,
this level must establish links or trace-
ability with Level 1 and begin the
process of constructing the RTM. It in-
volves the capture of low-level require-
ments specific to the design and imple-
mentation and that have no impact on
the functional criteria of the system.
Tier 3s implementation refers to the
source/assembly code developed in ac-
cordance with Tier 2. Verification activi-
ties include code rule checking and qual-
ity analysis. Maintenance of the RTM
presents many challenges at this level, as
tracing requirements to source code files
may not be specific enough and devel-
opers may need to link to individual
functions. In many cases, the system is
likely to involve several functions. Trace-
ability of those functions back to Tier 2
requirements includes many-to-few re-
lationships. Its very easy to overlook
one or more of these relationships in a
manually-managed matrix.
In Tier 4 host-based verification,
formal verification begins. Using a test
The requirements traceability matrix (RTM) plays a central role in a development lifecycle model.
Artifacts at all stages of development are linked directly to the requirements matrix. Changes within
each phase automatically update the RTM so that overall development progress is evident from
design, coding, and test through to object code verification at the 6th tier.
Figure 2
Graphics to high-level
requirements
Low-level to
high-level
requirements
Low-level requirements
to code
Code and quality
review defects
Test cases to
low-level
requirements
Test cases to
low-level
requirements
Tier 1
Tier 2
Tier 3
Tier 4
Tier 5
high-level
requirements
Implementation
(source/assembly code)
Host
Target
Requirements Traceability Matrix
model/
design concepts
Legacy/
hand code
Software
specs
Static and
dynamic
analysis
Automated
test
Object code to
source code
Tier 6
Object code verification
Automated
test
Listing 1
void f_while4( int f_while4_input1, int f_while4_input2 )
{
int f_while4_local1, f_while4_local2 ;
f_while4_local1 = f_while4_input1 ;
f_while4_local2 = f_while4_input2 ;
while( f_while4_local1 < 1 || f_while4_local2 > 1 )
{
f_while4_local1 ++ ;
f_while4_local2 ;
}
}
Listing 2
1 void
1 f_while4 (
1 int f_while4_input1 ,
1 int f_while4_input2 )
1 {
1 int
1 f_while4_local1 ,
1 f_while4_local2 ;
1 f_while4_local1 = f_while4_input1 ;
1 f_while4_local2 = f_while4_input2 ;
-
2 while
2 (
2 f_while4_local1 < 1
2 ||
-
3 f_while4_local2 > 1
-
4 )
-
5 {
5 f_while4_local1 ++ ;
5 f_while4_local2 ;
5 }
-
6 }
strategy that may be top-down, bottom
up, or a combination of both, software
simulation techniques help create auto-
mated test harnesses and test-case gen-
erators as necessary. Test cases should be
repeatable at Tier 5 if required.
At this stage, we confirm that the
software is functioning as intended
within its development environment,
even though there is no guarantee it will
work when in its target environment.
However, testing in the host environ-
ment first allows the time-consuming
target test to confirm that the tests re-
main sound in the target environment.
Tier 5s target-based verification
represents the on-target testing element
of formal verification. This frequently
consists of a simple confirmation that
the host-based verification performed
previously can be duplicated in the tar-
get environment, although some tests
may only be applicable in that environ-
ment itself.
Tier 6 takes the target-based work a
stage further, to tie in the comparison of
the object and source code as part of the
RTM and an extension to it.
OBJECT CODE VERIFICATION
The aerospace DO-178B standard
(6.4.4.2 Structural Coverage Analysis)
defines OCV as:
The structural coverage analysis may
be performed on the source code, unless
the software is Level A and the compiler
generates object code that is not directly
traceable to source code statements.
Then, additional verication should be
performed on the object code to estab-
lish the correctness of such generated
code sequences. A compiler-generated
array bound check in the object code is
an example of object code that is not di-
rectly traceable to the source code.
Object code verification hinges on
how much the control flow structure of
the compiler-generated object code dif-
fers from that of the application source
code from which it was derived.
cover feature
Listing 3
39 _f_while4:
40 push fp
41 ldiu sp,fp
42 addi 2,sp
43 ldi *-fp(2),r0 ; |40|
44 ldiu *-fp(3),r1 ; |41|
45 sti r0,*+fp(1) ; |40|
46 sti r1,*+fp(2) ; |41|
47 ble L3 ; |43| New test 2
48 ;* Branch Occurs to L3 ; |43|
49 ldiu r1,r0
50 cmpi 1,r0 ; |43|
51 ble L5 ; |43|
52 ;* Branch Occurs to L5 ; |43| New test 3
53i
54 L3:
55 ldiu 1,r0 ; |45|
56 ldiu 1,r1 ; |46|
57 addi *+fp(1),r0 ; |45|
58 subri *+fp(2),r1 ; |46|
59 sti r0,*+fp(1) ; |45|
60 cmpi 0,r0 ; |43|
61 sti r1,*+fp(2) ; |46|
62 ble L3 ; |43| New test 1
64 ldiu r1,r0
65 cmpi 1,r0 ; |43|
66 bgt L3 ; |43|
68
69 L5:
70 ldiu *-fp(1),r1
71 bud r1
Free Evaluation Kits: www.smxrtos.com/eval
Free Demos: www.smxrtos.com/demo
Save time and money with embedded
software solutions built to run right out of
the box. Get development started quickly,
with no integration required and full support
for popular tools. With Micro Digital you have
low-cost, no-royalty licensing, full source
code, and direct programmer support. So
get your project off to a great start. Visit us
at www.smxrtos.com today.
Your solution
is here.
www.smxrtos.com
R T O S I N N O V A T O R S
ARM Cortex ColdFire PowerPC x86 IAR EWARM CrossWorks GCC CodeWarrior
Object code control flow versus source
code control flow: Consider the very
simple source code in Listing 1. This C
code can be demonstrated to achieve
100% source code coverage by means of
a single call:
f_while4(0,3);
and can be reformatted to a single oper-
ation per line (shown in Listing 2).
The prefix for each of these reformat-
ted lines of code identifies a basic
blockthat is, a sequence of straight line
code. The resulting flow chart for the
function shows both the structure of the
source code and the coverage attained by
such a test case with the basic blocks iden-
tified on the flow chart nodes (Figure 3).
The object code generated by a com-
piler will depend on the optimization
setting, the compiler vendor, the target,
and a host of other issues. Listing 3
shows just one example of resulting (re-
formatted) assembler code generated by
a widely-used, commercially available
compiler with optimization disabled.
The flow chart looks quite different
for the assembler codeand using the
identical test case generates a quite differ-
ent flow graph both in terms of appear-
ance and in terms of coverage (Figure 4).
Its clear from the flow chart and the
assembler code that more tests are neces-
sary to achieve 100% code coverage.
New test 1. Line 62. End of block 3.

Branch to L3. This ble branch al-
ways evaluates to false with the ex-
isting test data because it only exer-
cises the loop once, and so only one
of the two possible outcomes results
from the test. Adding a new test case
to ensure a second pass around that
loop exercises both true and false
cases. A suitable example can be
provided thus:
f_while4(-1,3);

Branch to L3. This code contains an
or statement in the while loop
conditions. Both the existing test
cases result in the code:
f_while4_local1 < 1
returning a true value. The addi-
tion of a new test case to return a
false value will address that:
f_while4(3,3);

Branch to L5. The remaining unex-
ercised branch is the result of the
fact that if neither of the initial con-
ditions in the while statement is
satisfied then the code within the
loop is bypassed altogether via the
ble branch.
So, the final test is added will
provide such a circumstance:
f_while4(3,0);
This results in 100% statement and
branch coverage of the assembler
code, as shown in Figure 5.
Soto achieve 100% coverage of the

assembler code, four tests are required:
f_while4(0,3);
f_while4(-1,3);
f_while4(3,3);
f_while4(3,0);
WHY VERIFY OBJECT CODE
For most development teams software
testing traditionally has consisted of only
functional system testing. The problem
was that often the test data selected exer-
cised only a limited amount of the source
code while in-the-field data was quite
different in nature. As a result, much of
the code was only exercised for the first
time when it was actually deployed.
Even in the field, its highly likely
that circumstances required to exercise
much of the code have never occurred,
and so even legacy applications have sus-
tained little more than an extension of
functional system testing through their
in-field use (see Figure 6).
Consider that problem in terms of the
data sets used to exercise that code. It is a
natural outcome that most circumstances
will generate data that exercises a particu-
lar part of the code that becomes well
provenbut its the exceptional cases that
occur rarely that cause failure. Indeed,
anyone who has been involved with the
correction of problems seen in the field
will confirm how frustrating the repro-
duction of relevant circumstances can be.
Structural coverage (see Figure 7)
addresses this problem by providing evi-
dence that all of the code base has been ex-
ercised. Such an approach has been proven
to reduce the risk of failure and conse-
quently is specified in most, if not all, in-
dustrial standards concerned with safety.
OBJECT CODE COVERAGE
Structural code coverage offers a proven
mechanism for ensuring that software is
robust and safe. But weve already estab-
lished that merely exercising all of the
source code does not prove that all of
cover feature
A dynamic flow graph showing
the assembler code exercised
through a single function call.
Figure 4
S
c
r
e
e
n
s
h
o
t

c
o
u
r
t
e
s
y

o
f

L
D
R
A
.
A dynamic flowgraph showing
100% assembler code exercised
through additional function calls
Figure 5
S
c
r
e
e
n
s
h
o
t

c
o
u
r
t
e
s
y

o
f

L
D
R
A
.
A dynamic flowgraph showing
the source code exercised
through a single function call.
Figure 3
S
c
r
e
e
n
s
h
o
t

c
o
u
r
t
e
s
y

o
f

L
D
R
A
.
the object code has been similarly exer-
cised and proven. True, its less likely
that an unexercised route through the
object code will lead to system failure.
But even lesser risks can be unacceptable
if a system is sufficiently safety-, com-
mercially-, or mission-critical.
In short, how big are your risks?
Consider the fact that our example
mismatch between source- and object-
code flow charts was generated in a com-
piler with optimization disabled. Many
more differences are likely as the result of
compiler interpretation and optimization.
While traditional structural coverage tech-
niques are applied at the source-code lev-
el, the object code executes on the proces-
sorand thats what really matters.
Any differences in control flow struc-
ture between the two can make for signif-
icant and unacceptable gaps in the testing
process. In some industries, these gaps are
acknowledged and accounted for. For ex-
ample, in aerospace, the DO-178B stan-
dard requires developers to implement
OCV facilities for those elements of the
application that have a Level-A (safety-
critical) classification. While this is often a
subset of the application as a whole, it has
traditionally represented a significant
amount of testing effort and hence has al-
ways required considerable resources.
Opportunities to implement auto-
mated, compiler-independent processes
can help to reduce overall development
costs by considerable margins, and con-
versely make OCV commercially justifi-
able in other fields.
AUTOMATED OCV
Automated OCV solutions can provide a
complete structural coverage analysis so-
lution for both source and object code
from unit to system and integration lev-
els. Typical solutions combine both
high- and object-level (assembler) code
analysis tools, with the object-level tool
variant being determined by the target
processor that the application is re-
quired to run on. A typical example
might see C/C++ and TMS320C25x As-
sembler analysis tools teamed together
to provide the required coverage met-
rics, as shown in Figure 8.
OCV AT THE UNIT LEVEL
Some automated tools enable users to
create test cases for structural coverage
of high-level source and apply the same
test cases to the structural coverage of
the corresponding object code. A driver
program is generated by such a unit-test
tool that encapsulates the entire test en-
vironment, defining, running, and mon-
itoring the test cases through initial test
verification and then subsequent regres-
sion analysis. When used for OCV, this
driver may linked with either the high-
level source unit or the associated object
code. In so doing, users can apply a uni-
form test process and compare code in
order to determine any discrepancies or
deficiencies, as Figure 9 demonstrates.
If structural coverage discrepancies
or deficiencies are identified at the object
level, users are presented an opportunity
to define additional test cases to close any
gaps in the test process. The obvious ad-
vantage of identifying and applying cor-
rective action at such an early develop-
ment stage is that its much easier and
cheaper. It also significantly increases the
quality of the code and the overall test
process with the latter reaping benefits at
Code exercised both on site and by functional
testing is likely to include many unproven
execution paths.
Figure 6
Application
code base
Code
exercised
during
functional test
Code
exercised
in service
initial application
Code exercised
in service
enhanced application
Ensuring all code is exercised using structural
coverage.
Figure 7
Code base exercised
D
a
t
a
Functional test
In serviceinitial application
In serviceenhanced application
Structural coverage
cover feature
the later stages of integration
and system testing and on-
ward in the form of reduced
failure rates and maintenance
costs when the application is
in the field.
While the code is still
under development, devel-
opers can also benefit from
the considerable additional
test feedback together with
satisfying the necessary OCV
requirements in a highly au-
tomated and cost-effective
manner. The results of these
analysis facilities can be fed
back to the development
team with the possibility that
further code and design defi-
ciencies may be identified
and rectified, further enhancing the
quality of the application as a whole.
MAKING OCV THE NORM
Its clear that OCV has always involved
significant overhead and even in the
aerospace sector, its only enforced as a
requirement for the most demanding
safety integrity levels. Even then, the el-
ements nominated for OCV in these
applications are usually a subset of the
application as a wholea specialist
niche indeed.
Until quite recently, unit test has
been considered a text-book nicety
and yet the ever-increasing capabilities
and ease of use of automated unit-test
tools has introduced a commercial jus-
tification of such techniques even
when risks are lower.
Most applications include key ele-
ments in the software; a subset of code
thats particularly critical to the success
of the application and can be identified
in the application requirements. The
software requiring OCV can be identi-
fied and traced through
an extension to the
RTM.
The advent of tools to automate the
whole of that process from require-
ments traceability right through to
OCV challenges the notion that the
overhead involved can only justify the
technique in rare circumstances. Just as
for unit test before it, the time has come
for OCV to be commercially justifiable
in a much broader range of circum-
stances.
Mark Pitchford is a field applications en-
gineer with LDRA, where he specializes in
software test.
PASSED
The automation of object code verification can reduce the necessary amount
of testing effort by a considerable margin.
Figure 8
User-configurable
for different
target environments
LDRA
test
manager
Source
code
Assembler
source
code
Test
case
generation
Test
harness
generation
Test
execution
Test result
analysis and
reporting
Instrumented
Assembler
source
LDRA
design
review
LDRA
test
verification
LDRA
Testbeta
TBrun
Object code and source flow
graphs illustrate the structure
and coverage of the high- and
low-level code, and hence any
discrepancies between them.
Object code Source code
S
c
r
e
e
n
s
h
o
t
s

c
o
u
r
t
e
s
y

o
f

L
D
R
A
.
Figure 9
BY DAVID B. STEWART, PHD, INHAND ELECTRONICS, INC.
W
breakpoints to monitor the interrupt will likely break
functionality.
Another example is synchronization and timing errors
in real-time systems. Developers regularly add mutexes,
semaphores, condition variables, or other mechanisms to
guard shared resources. But how do you test and debug an
issue with these mechanisms? Can you tell whether or not a
race condition or priority inversion is actually occurring?
How do you track down a glitch that only happens random-
ly? Can you identify the root cause of a particular real-time
constraint not being met?
To troubleshoot these types of real-time issues, the logic
analyzer, which traditionally is used by hardware engineers
to debug their digital circuits, can be the software engineers
best aide. It provides a new power-tool for your software de-
bugging toolbox. It enables tracing through a program with
microsecond resolution and can actively be used to monitor
hile many embedded software issues can be debugged us-
ing either print statements or symbolic debuggers (such as
JTAG tools), there are many instances where neither of
those methods can help. For example, suppose the prob-
lem is in an interrupt handler that is executing ten thou-
sand times per second. Its not practical to put print state-
ments as that will ruin the real-time execution. Adding
Dave Stewart is one of the nations leading
experts in architectures and implementation
for embedded real-time systems. In his many
years of experience, previously as a consultant
and now as director of systems integration
at InHand Electronics, Dave has regularly been
involved in the final stages of system delivery.
He credits the techniques described in this
article as the primary difference between
being an average engineer who has difficulty
finding closure because there is always a
handful of nasty lingering bugs to fix, and the
master troubleshooter who finds the root cause
of the final issues and resolves them to be able
to say Done. This article is based on a class
he taught at ESC Boston 2011.
Embedded Systems
Design magazine
begins a series of
articles based on
ESC classes, which
ESC/DESIGN West
instructors have adapted for our readers.
ESC classroom
This logic analyzer technique is a power-tool for the
embedded software engineers toolbox.
Troubleshooting
real-time software
issues using a
logic analyzer
drivers, interrupt handlers, operating
system, or real-time application code
that has critical time constraints.
The logic analyzer is not the holy
grail of debug tools by a long shot. In
fact, this method is significantly more
challenging than using either print state-
ments or symbolic debugging. Im still
waiting to have a system with a button
that says Debug Meclick it, and
your problem is found and fixed. But
until that tool exists, you may need to go
deep into the trenches, namely the low-
est levels of code where print statements
and symbolic debuggers cannot do a
good job, to find the root cause of a
problem. The logic analyzer allows the
software engineer to do that. The meth-
ods I describe in this article are not the
easiest to learn and are extremely diffi-
cult to master. However, if you do learn
them and effectively use them, it could
make the difference between you forever
being an average embedded systems en-
gineer and becoming an expert.
The techniques I present here
should supplement your current debug-
ging tool box. If you spend an unsuc-
cessful day or more trying to track down
a problem with other tools, dont spend
more time using the same methods. In-
stead, try the techniques in this article.
The methods can be used on almost
any embedded architecture. I have used
these techniques on small 8-bit and 16-
bit microcontrollers with single-thread
execution as slow as 8MHz and using
only 2K RAM. The same techniques
have been used equally effectively on
multi-threaded complex ARM architec-
tures such as the XScale, OMAP, and
DaVinci processors with 512MB RAM
and 1GHz clock speed. Although the set-
up is different in each case, the funda-
mentals of the logic analyzer methods
remain the same.
The key to understanding the bene-
fit of this logic-analyzer approach is to
recognize that a software troubleshoot-
er is a detective. A debug tool only pro-
vides clues. The better the clues, the
faster the problem can be found, and
thus the quicker it can be fixed. The
logic analyzer takes more setup time
than print statements or a symbolic de-
bugger, but the quality and quantity of
the clues can be significantly better.
DEBUG MACROS FOR PRINTING
The use of macros to standardize print
statement debugging is both useful to
know and represents the basis for logic
analyzer debugging macros.
Consider the procedure when using
print statements to debug code. A
make-shift code segment is shown in
Listing 1, with print statements added
to trace the flow of the code. This
would produce the following output
(with assumed values for x and y):
Start of myfunc
x = 10
f(x) = 24
End of myfunc
While such code will help trace the
internals of myfunc(), its rather ineffi-
cient to type in all those print statements,
and the amount of information provided
in each statement is minimal. What if
these lines of code were just a handful
out of thousands of debug statements?
Tracing back to the original source code
could also be time consuming.
A simple solution is to abstract print
statement debugging into macros. Listing
2 shows two macros that we can use. With
these macros, the debug code can be
changed to that shown in Listing 3. The
resulting output would be:
[file.c/3] myfunc()
[file.c/5] x = 10
[file.c/7] y = 24
[file.c/9] myfunc()
When such code is intermixed with
thousands of debug statements, its still
possible to easily follow the code, as file-
names, function names, line numbers,
and values of variables are each clearly
marked. Because macros are used, its also
easier to use shortcuts or cut-and-paste to
add the debug statements to your code,
thus also making it more efficient.
Suppose we want to print the vari-
ables in hex instead of decimal. We can
create alternate macros, as shown in
Listing 4. If we replace lines 5 and 7 with
ESC classroom
Listing 1 Typical print statement
debugging.
void myfunc(void) {
int x,y;
printf(Start of myfunc\n);
x = read();
printf(x = %d\n,x);
y = f(x);
printf(f(x) = %d\n,y);
etc.
printf(End of myfunc\n);
}
Im still waiting to have a
system with a button
that says Debug Me,
but until then . . .
!
!
Listing 2 Macros to standardize print statement debugging
#dene DEBUG_WHERE() printf([%s/%u] %s()\n,__FILE__,__LINE__,__FUNCTION__)
#dene DEBUG_INT(_var) printf([%s/%u] %s = %d\n,__FILE__,__LINE__,#_var,_var)
Listing 3 Using
debug macros.
void myfunc(void) {
int x,y;
DEBUG_WHERE();
x = read();
DEBUG_INT(x);
y = f(x);
DEBUG_INT(y);
etc.
DEBUG_WHERE();
}
Listing 4 Dening additional print statement debug macros
#dene DEBUG_HEX8(_var) printf([%s/%u] %s = 0x%02X\n,__FILE__,__LINE__,#_var,_var)
#dene DEBUG_HEX16(_var) printf([%s/%u] %s = 0x%04X\n,__FILE__,__LINE__,#_var,_var)
DEBUG_HEX8() and DEBUG_HEX16()
macros respectively, it results in this
change to the outputs:
[file.c/5] x = 0x0A
[file.c/7] y = 0x0018
There are many different ways that
macros can be used to standardize de-
bug print statements, but I wont cover
them here, since our focus is on debug-
ging with the logic analyzer.
The constraint with the print-state-
ment method is that you might be able
to add maybe 50 to 100 debug state-
ments per second to your code before it
breaks functionality, or maybe just a
handful per second before it affects
real-time performance. Using the logic
analyzer, its possible to get thousands
of debug statements per second with
negligible impact on the systems real-
time performance. Furthermore, the
data is time-stamped and can be visual-
ized as timing diagrams, enabling rap-
idly identifying anomalies in the code.
The concept of logic-analyzer de-
bugging is similar to using these DEBUG
macros, except that the macros will be
defined to send codes to a logic analyzer
instead of print statements to a console.
Before going into detail on logic-
analyzer macros, Ill describe the logic
analyzer and hardware setup needed to
support this type of debugging.
LOGIC ANALYZER
A logic analyzer is a hardware test in-
strument that is used to monitor digital
signals. Typical logic analyzers have
anywhere from 32 to hundreds of digi-
tal channels. For software debugging,
we generally only need 16 to 24 chan-
nels, and speeds under 100 MHz. So
there is no need to get high speed or
maximum number of channels.
The lower-cost analyzers can be ob-
tained for under $500; theyre simply a
pod that plugs into the USB port of a
PC, and software on the PC is used to
visualize the captures. At the other ex-
treme are some very powerful analyzers
that can cost $20,000 or more. While
the high-end analyzers have many at-
tractive features that can speed up trou-
bleshooting, a low-cost one is sufficient,
at least for starters.
The one so-called luxury of a logic
analyzer that is highly desirable is the
memory depth. Memory depth repre-
sents how many samples can be stored
in the logic analyzer before its memory
fills up. For example, if sampling at 1
million samples per second, an analyzer
with 32-K depth will fill up in just
32 ms, while an analyzer with 4-M
depth can run for four seconds. The lat-
ter is extremely beneficial, because it al-
lows you to watch the system, have a
couple of seconds to manually trigger
after you observe the failure, and know
that the signals have been captured
when the problem occurred. If you only
have 32 ms, its not possible to manual-
ly observe a failure, and thus its more
difficult to get the problem captured.
Other features that can be helpful
but arent necessary are good search fil-
ters, state machine triggers, and ability
to compress captured data so that sam-
ples are only stored when the signals ac-
tually change, and thus longer traces
can be obtained.
Every logic analyzer has at least two
views for captured data, a timing view
and a state view, as Figure 1 illustrates.
The timing view is used to quickly visu-
alize patterns, identify anomalies, and
zoom in to points of interest in a data
capture. The state view is primarily use-
ful with more advanced troubleshoot-
ing, in which the data is downloaded to
a PC and software is written to auto-
matically parse the data and extra infor-
mation such as execution time, check-
ing for real-time deadline errors, and
validating that no race conditions oc-
curred. How to automatically parse a
logic analyzers data is a more advanced
Examples of logic analyzer views. Toptiming view; bottomstate view.
Figure 1
ESC classroom
ESC 2012 CLASSES
DAVE STEWART
Dave Stewart will teach four
classes at ESC/DESIGN West in
March, 2012.
ESC-210: Solving Real Problems that
Required Hiring a Consultant
2:00 PM3:00 PM March 27
ESC-223: Costly Mistakes of Real-
Time Software Development
3:15 PM4:15 PM, March 27
ESC-313: Remotely Troubleshooting
Embedded Systems using High Qual-
ity Log Files
2:00 PM3:00 PM, March 28
ESC-316: Achieving Real-Time Per-
formance with Linux/Android or
Windows CE
3:15 PM4:15 PM March 28
Use promo code UBMDESIGN
for 20% off upcoming ESC class-
es. For more information about
these and other sessions, go to
www.ubmdesign.com/sessions/esc
topic that I wont cover in this article.
HARDWARE SETUP
To use a logic analyzer to troubleshoot
software, you must connect it to the em-
bedded system under test. Unfortunately,
at least for existing hardware platforms,
this is sometimes the biggest challenge.
The goal is to identify eight unused
digital outputs from the embedded sys-
tem that can be used to send codes from
software to the logic analyzer. Some-
times this is easy. There might be an un-
used 8-bit digital I/O port that can be
used for this function. In other cases,
there might be eight spare pins, but be-
cause theyre scattered on various I/O
ports, theyre not as easy to write to.
Nevertheless, as long as theyre free, that
is good enough.
If there arent at least eight available
pins, you may need to scrounge for
them. For example, suppose a system has
an SD card, but the SD card is not used
when the failure to be debugged hap-
pens. The command, clock, four data
lines, card detect, and write protect lines
can potentially all be used to provide 8
bits; they just need to be reconfigured in
software.
If the target system has an FPGA (or
CPLD), it may be possible to use eight
pins from that device and send a com-
mand to the FPGA using whatever com-
munication means already exists be-
tween those two devices, then allow the
FGPA to output the digital signals.
The next challenge is to hook up
these eight outputs to one of the ports
on the logic analyzer. Most logic analyzer
probes can connect directly to 0.1-inch
pins and include clips that allow attach-
ing onto smaller pins. If necessary, a
hardware technician can add wires to the
embedded system under test to bring
out these eight lines in such a way that
the logic analyzer can more easily be
connected to it.
If the problem that needs to be de-
bugged includes some kind of I/O, such
as push-button keys, a controlled digital
output, or a serial link, each of these sig-
nals should also be connected to other
channels on the logic analyzer.
Figure 2 shows a block diagram of
the setup. The I/O connections on chan-
nel 2 are optional.
When designing hardware for a new
real-time embedded system, a design-
for-test requirement should be to have
eight dedicated digital output pins avail-
able specifically for softwares use, and to
have these brought out to a connector
for easy connection to a logic analyzer.
At InHand Electronics, we typically
place a high-density connector on the
board with all the signals that we may
want to hook up to the logic analyzer for
software debugging, so that board real
estate used for software debugging is
minimized. We have a separate break-
out board populated with 0.1-inch pins
for each signal that makes it easy to con-
nect a logic analyzer. An example is
shown in Figure 3; a cable is used to
make the connection from the system
under test to the breakout board.
Once the hardware is setup, the next
step is to define macros to output codes
to the logic analyzer.
DEFINING LDEBUG MACROS
The first step is to create the
LDEBUG_HEX8() macro (or alternately,
an inline function) to send an 8-bit code
to the logic analyzer via the digital out-
puts identified above. The actual defini-
tion of the macro depends on the
processor, hardware setup, and which
outputs were selected. An additional
macro or function, LDEBUG_INIT(),
might need to be defined to initialize the
selected pins as digital outputs.
Listing 5 shows four examples of
defining the LDEBUG macros, extracted
from real target platforms that Ive used
in the past. In Listing 5a, a TI MSP430
had Port 4 reserved for this LDEBUG
function. The port is initialized to out-
put, and writing to the output register
sends the 8-bit value to the processors
port four pins.
A slightly more complex macro is
shown in Listing 5b. This example
shows the macros for a Marvell PXA270,
which has separate set and clear regis-
ters. In this example, GPIOs 64 thru 71,
ESC classroom
Hardware setup for troubleshooting with a logic
analyzer.
Figure 2
Logic
analyzer
(Assuming
8-bit
channels)
Embedded
system
under test
RX/TX
I
2
C
SPI
Keys
D0-D7
Ch.1
Ch.2
Example of a design-for-test platform. The embedded system under test (InHands DM3730 Fury
SBC, in green) has a high-density connector to interface to a breakout board (in red), where all
the logic analyzer connections can easily be made.
Figure 3
Photo courtesy
InHand Electronics Inc.
www.inhand.com
The goal is to identify
eight unused digital out-
puts from the embedded
system that can be used
to send codes from soft-
ware to the logic analyzer.
!
!
!
which are bits 0 through 7 on GPIO Port
2 of the processor, are used.
A third, much more complex scenario
happens when scrounging bits, as shown
in Listing 5c. This example is also for a
PXA270, but in this case, the specific
GPIOs that were available are GPIOs 84,
85, 93, 94 on GPIO Port 2, and GPIOs
116, 106, 107, and 108 on GPIO Port 3.
The fourth example (which is what
is used on Fury in Figure 3) is shown in
Listing 5d. This definition is clearly the
simplest but requires that hardware was
designed specifically to accommodate
this feature. An FPGA is connected to
the processors memory bus, and the
FGPAs application programming inter-
face is used to abstract writes to the reg-
ister. This example assumes the FPGA is
configured to output any value written
to register 3 to the 8-bit digital output.
Regardless of the complexity of the
macro, once the macro is defined, all re-
maining usage is simple by calling LDE-
BUG_HEX8(), and the code passed as an
argument can be captured by the logic
analyzer.
VERIFYING WITH THE SETUP
Before troubleshooting a real issue, test
the macros and verify the setup using
the test function provided in Listing 6.
This is the equivalent of getting Hello
World program working as a first step
on a new platform.
Execute the function on the target
platform. It doesnt matter if this func-
tion is executed as a standalone applica-
tion, or is integrated into the initializa-
tion code of the full system. As long as
it gets executed and the test pattern it
generates can be captured on the logic
analyzer, its good enough.
Setup the logic analyzer to trigger on
Bit 7 (of the 8-bit digital output port)
transitioning from a 1 to a 0. Run the
logic analyzer and wait for trigger. Then
execute the code. Consult your logic an-
alyzers technical documentation for
help in setting up such a trigger.
If all goes well, the logic analyzer will
get triggered when the code is executed,
and the timing view on the logic analyzer
screen will be the step pattern as shown
in Figure 4. If this doesnt happen, re-
view all steps above and troubleshoot the
macros or hardware setup. If you dont
capture the pattern at all, it could be an
Listing 5 Examples of dening macros for logic analyzer debugging.
(a) LDEBUG macros for TI MSP430 Port 4
uint8_t *LDEBUG_dout8 = (uint8_t *) 0x001D; // reg addr
uint8_t *LDEBUG_dir8 = (uint8_t *) 0x001E; // reg addr
#define LDEBUG_INIT() *LDEBUG_dir8 = 0xFF // output
#define LDEBUG_HEX8(_h8) *LDEBUG_out = (_h8)
(b) LDEBUG macros for PXA270 using GPIOs 64 thru 71.
uint32_t *LDEBUG_set8 = (uint32_t *) 0x40E00020; // GPIO2 set
uint32_t *LDEBUG_clr8 = (uint32_t *) 0x40E0002C; // GPIO2 clr
uint32_t *LDEBUG_dir8 = (uint32_t *) 0x40E00014; // GPIO2 dir
#define LDEBUG_INIT() *LDEBUG_dir8 |= 0x000000FF
#define LDEBUG_HEX8(_h8) { \
uint32_t h32 = (uint32_t) hex8; \
uint32_t sg2,cg2; \
sg2= ( h32 & 0x000000FF); \
cg2= ((~h32) & 0x000000FF); \
*_gpsr2 = sg2; \
*_gpcr2 = cg2; }
(c) LDEBUG macros for PXA270 using 84, 85, 93, 94, 116, 106, 107, and 108 as D0 thru D7 respectively.
static volatile uint32_t *_gpdr2 = (uint32_t *)0x40E00014;// GPIO2 dir
static volatile uint32_t *_gpsr2 = (uint32_t *)0x40E00020;// GPIO2 set
static volatile uint32_t *_gpcr2 = (uint32_t *)0x40E0002C;// GPIO2 clr
static volatile uint32_t *_gpdr3 = (uint32_t *)0x40E0010C;// GPIO3 dir
static volatile uint32_t *_gpsr3 = (uint32_t *)0x40E00118;// GPIO3 set
static volatile uint32_t *_gpcr3 = (uint32_t *)0x40E00124;// GPIO3 clr
// set directions
#define _MASK2 0x60300000
#define _MASK3 0x00101C00
#define LDEBUG_INIT() {*_gpdr2 |= _MASK2; *_gpdr3 |= _MASK3;}
#define LDEBUG_HEX8(_h8) LDEBUG_Hex8(_h8)
void LDEBUG_Hex8(uint8_t h8) {
uint32_t h32 = (uint32_t) hex8;
uint32_t gr2,gr3,ngr2,ngr3;
// don't write to registers yet; we want to write to registers
// as quickly as possible, to minimize race conditions.
gr2=(((h32&0x0C)<<(29-2)|((h32&0x03)<<(20-0)))); // D3.D2|D1.D0
gr3=(((h32&0xE0)<<(10-5)|((h32&0x10)<<(20-4)))); // D7.D6.D5|D4
h32 = ~h32;
ngr2=(((h32&0x0C)<<(29-2)|((h32&0x03)<<(20-0)))); // D3.D2|D1.D0
ngr3=(((h32&0xE0)<<(10-5)|((h32&0x10)<<(20-4)))); // D7.D6.D5|D4
*_gpcr2 = ngr2;
*_gpsr2 = gr2;
*_gpcr3 = ngr3;
*_gpsr3 = gr3;
}
(d) LDEBUG macros on a system with an adequately-programmed FPGA connected to memory bus.
#define LDEBUG_HEX8(_h8) fpga_Write(3,_h8) Listing 6 Function to test logic
analyzer debug macros
#include LDEBUG.h
void LDEBUG_TEST(void) {
LDEBUG_HEX8(0xFF);
LDEBUG_HEX8(0x01);
LDEBUG_HEX8(0x02);
LDEBUG_HEX8(0x04);
LDEBUG_HEX8(0x08);
LDEBUG_HEX8(0x10);
LDEBUG_HEX8(0x20);
LDEBUG_HEX8(0x40);
LDEBUG_HEX8(0x80);
LDEBUG_HEX8(0x55);
LDEBUG_HEX8(0xAA);
};
Logic analyzer output for test pattern.
Figure 4
issue with initialization of the debug I/O
ports as output, a problem with writing
to these I/O ports, or a channel or trigger
setup issue on the logic analyzer. If you
get some kind of pattern but it doesnt
match what is shown, review each indi-
vidual signal connection.
Once youre able to capture this test
pattern, youre ready to use this tech-
nique for debugging.
DEBUGGING BASICS
What makes logic analyzer debugging
more difficult than print statements or
symbolic debugging is that the data cap-
tured is very cryptic.
Listing 7 shows a code segment us-
ing the print DEBUG macros. Output
from executing this code would be:
[file.c/9] pos = 0x0063
[file.c/10] vel = 0x1D18
[file.c/11] acc = 0xFD4E
[file.c/12] tim = 0x0DE5
Listing 8 shows the same code seg-
ment instead using the LDEBUG_HEX16()
macro, which is built upon the
LDEBUG_HEX8() macro created previously.
The logic analyzer capture for the
first LDEBUG operation is shown in Fig-
ure 5. The first code seen is the 0x40, fol-
lowed by the 16-bit data, which was split
as two separate 8-bit values, first the
MSB, then the LSB.
Zooming out on the logic analyzer,
as shown in Figure 6, we see all four of
the LDEBUG_HEX16 commands. The
codes (i.e. 0x40 through 0x43) are used
to produce an easily recognizable pattern
on the logic analyzer. Once this pattern
is identified, the numbers in between
represent the data variables. By correlat-
ing the codes and data values back with
the source code, its possible to deter-
mine the value of each variable.
Suppose this code was executing a
thousand times per second, and the logic
analyzer captured one second of data.
This particular sequence would then be
repeated a thousand times during the
one capture. Its obviously not possible
to look at all thousand items manually.
You can use two approaches to wade
through thousands of data elements.
One approach is to switch to state view
and save the data to a file. You can then
write a program or script that parses
through the file and looks for specific is-
sues. This technique is more advanced; I
dont describe it here. The other method
is much less formal and often just as ef-
fective, and thus will likely be used much
more often. I call this technique visual-
izing performance, as described below.
TRACING EXECUTION
You can use the logic analyzer to view
precisely what portion of code was exe-
cuted during any interaction of a
thread or driver or during any execu-
tion of an interrupt handler. At the
same time, the logic analyzer captures
timing measurements of each code seg-
ment within that function.
Consider the make-shift function
shown in Listing 9 and assume that its
part of an interrupt handler in which
print statements are not viable and in-
serting breakpoints would break the
functionality. How do you know which
branches are taken when?
By instrumenting the code with
LDEBUG_HEX8 statements scattered, its
possible to determine both the precise
execution trace and execution time
measurement, as illustrated by the corre-
ESC classroom
Listing 7 Example of using print
debug macros
void get_vector() {
pos = get_position();
vel = get_velocity();
acc = get_acceleration();
tim = get_timestamp();
DEBUG_HEX16(pos);
DEBUG_HEX16(vel);
DEBUG_HEX16(acc);
DEBUG_HEX16(tim);
};
Listing 8 Example of using logic
#dene LDEBUG_HEX16(code,value) {\
LDEBUG_HEX8(code); \
LDEBUG_HEX8(value >> 8); \
LDEBUG_HEX8(value & 0xFF); }
uint16_t pos, vel, acc, tim;
void get_vector(vector_t &data) {
pos = get_position();
vel = get_velocity();
acc = get_acceleration();
tim = get_timestamp();
LDEBUG_HEX16(0x40,pos);
LDEBUG_HEX16(0x41,vel);
LDEBUG_HEX16(0x42,acc);
LDEBUG_HEX16(0x43,tim);
};
Logic analyzer capture of each item in function get_data() of Listing 8.
Figure 6
Scale: 1 microsecond
per division
LDEBUG_HEX16(0x40,pos);
LDEBUG_HEX16(0x41,vel);
LDEBUG_HEX16(0x42,acc);
LDEBUG_HEX16(0x43,tim);
pos vel tim acc
A logic-analyzer capture of one data item.
Lines in yellow are the per-bit timing diagrams.
Well see later the value of these.
Figure 5
LDEBUG_HEX16(0x40,pos)
sponding logic analyzer capture shown
in Figure 7. For example, during this
specific iteration, we know that y was
not less than zero, because the code 0xB3
showed up, not the code 0xB2. The error
of z > 0 also did not occur, because the
code 0xBE was not in the capture.
From the log, we could also tell that
the function do_calc(x,y,z) took ap-
proximately 23 s to execute, based on
the difference between 0xBB and 0xBF.
A more precise measurement would be
possible by either zooming into the
time view, or switching to the state view
and looking at the relative time stamp.
As a personal convention, I find it
helpful to separate the 2-digit hex codes
as 0xYZ, where Y=unique number
for the function, and Z is a location
within the function. In Figure 7, Y=B. Z
is 1 for entry, F for a normal exit, E for
an error exit, and 2 thru D for 12 other
trace points within the function. Thus
0xB1 represents entry into the function,
and 0xBF represents normal exit. Z=0 is
reserved to use as a specific trigger
point when necessary. As you gain ex-
perience, however, you can choose any
personal conventions that you find
helpful. Having conventions makes it
easier to parse the rather cryptic output
of the logic analyzer.
VISUALIZING PERFORMANCE
A very hardyet rather common
real-time issue that needs to be solved is
when one or more threads arent meet-
ing their timing requirements. Quite
often, the thread that is failing is not the
culprit. Rather, it may be some other
thread that has higher priority or using
resources needed by the failing thread
that is at the root of the problem, but
knowing which thread to troubleshoot
can be difficult to find.
The logic analyzer can be used to
visually spot performance anomalies.
Very often, real-time issues show them-
selves first at the very low level of exe-
cution. By instrumenting code with
LDEBUG tracing statements and simply
monitoring execution from a birds eye
view, you can acquire a trained eye to
zero in on parts of the code where there
is a potential anomaly. Then, look at the
logic analyzer captures more closely to
determine whether or not any of those
anomalies are real problems.
An example is provided in Figure 8a.
The top diagram is the birds eye view.
This is a 2-second logic analyzer capture
of a system thats been instrumented
with LDEBUG macros in various key parts
of the code.
In this sequence of diagrams, the
green is I
2
C communication, the white
is the 8-bit debug codes, while the yel-
low are the per-bit timing diagrams.
While the per-bit diagrams are not nec-
essary when looking closely at the 8-bit
codes, theyre helpful in these birds-eye
views to show patterns. (Note that to
conserve space in this article, only four
of the bits are shown; that is generally
sufficient to see the patterns.)
Quite simply, most real-time errors
show up as pattern anomalies when
looking at a logic analyzer capture. So
lets focus on some of the anomalies we
can see.
To the left of the top image, the red
ellipse is circled around an anomaly.
Note how much more space there is be-
tween adjacent pulses. There is a per-
formance issue here that should be in-
vestigated. By zooming in on this area,
we can look at the individual hex codes
to see what part of the code was execut-
ing, and how long each code segment
was taking. However, for this example,
lets instead focus on a different part.
The green represents I
2
C communi-
cation, which seems to come in bursts of
five messages at a time. However, near
the middle, they stop. Is this normal? Or
is this indicative of the problem?
To better understand this problem,
we can zoom in to the rectangular por-
tion, which is the last burst of communi-
cation before they stop.
At the new zoom level (Figure 8b),
we see more granularity, both with the
I
2
C communication as well as with the
patterns generated by the LDEBUG state-
ments. For the I
2
C, we could see now
that in the burst of five I
2
C messages, the
fifth one takes longer than the others.
This is probably normal, if there are
more bytes transferred. Nevertheless,
when trying to find a glitch or perform-
ance anomaly, its always worthwhile to
double check that your observations
match expectations.
At this level, we begin to see details
of a potential performance anomaly. Re-
Example of code tracing. This is a trace of the function shown in Listing 9. In addition to knowing
which branches were taken, the time stamps and scale provide execution time measurements for
every code segment, which is shown visually in the timing view.
Figure 7
Scale
10 sec/div
Listing 9 Tracing code using logic
void myfunc(int x) {
int y,z;
LDEBUG_HEX8(0xB1);
y = f(x);
if (y < 0) {
LDEBUG_HEX8(0xB2);
Do stuff;
} else {
LDEBUG_HEX8(0xB3);
}
z = g(y);
if (z > y) {
LDEBUG_HEX8(0xB4);
Do stuff
LDEBUG_HEX8(0xB5);
Do more stuff
LDEBUG_HEX8(0xB6);
} else {
LDEBUG_HEX8(0xB7);
if (z > 0) {
// ERROR!
LDEBUG_HEX8(0xBE);
}
LDEBUG_HEX8(0xB9);
do stuff
LDEBUG_HEX8(0xBA);
Do stuff
LDEBUG_HEX8(0xBB);
}
do_calc(x,y,z);
LDEBUG_HEX8(0xBF);
}
ESC classroom
member it is always important to realize
that any anomaly may in fact be normal;
calling it an anomaly simply means it
merits a closer look.
The specific anomaly to note is that
the code 0x46 is always captured before
an extended break. Is this normal? If the
convention is followed that the second
digit is an F at the end of any function,
this means we have something blocking
or taking really long right after code
0x46 is printed. This might not be a
problem; for example, it might be a call
to a function in another module which
is not instrumented with LDEBUG state-
ments. Or it might point to a real issue;
perhaps the code is calling a function
taking much longer than expected, or
unexpectedly blocking when trying to
acquire a resource.
Suppose the performance anomaly
with the 0x46 is normal. We can zoom in
again. In this case, we select the part of
view in which the bit-patterns is differ-
ent from everywhere else. It is surprising
how often using that simple heuristica
difference in the bit patternis enough
to zero in quickly on real problems.
In the zoom of that area (Figure
8(c)) we see two more potential anom-
alies, namely extended periods following
each of codes 0xAF and 0x9F. The ques-
tion then, is what happens immediately
after those codes are sent to the logic an-
alyzer? Repeating this approach, taking
a few minutes per anomaly, most per-
formance issues in the system can be
identified within a few hours.
Figure 8(d) shows on additional
zoom, which is the I2C communication.
Some logic analyzers will also show the
hex values as well as protocol start and
stop bits for serial communication, as
shown in Figure 9.
SIMPLY LOGICAL
The logic analyzer techniques described
in this article provide you one addition-
al, powerful tool to use to debug real-
time software issues.
Consider this metaphor: if you need-
ed to cut a branch from a tree, you would
use a branch cutter that takes a second to
pull out of the shed, snip, and it is
done. You would not go get a chainsaw
for such a simple job. However, if you
needed to cut down a large tree, the
branch cutter is useless, and a chainsaw is
much more powerful than an axe or saw.
The logic analyzer is like that chain saw.
Its powerful, but more difficult to set up
and more awkward to use. Use it when
necessary, but still hang on to all your
other tools and use those when they can
get the job done more efficiently.
Dave Stewart is the director of Research
and Systems Integration at InHand Electron-
ics, a developer of small, low-power elec-
tronics solutions for handheld and wireless
device designers. He has significant experi-
ence in numerous market segments, includ-
ing mobile computing, wireless sensor net-
works, aerospace, industrial control,
consumer electronics, transportation, physi-
ological monitoring, and environmental
monitoring.
ESC classroom
Logic analyzer capture of performance anomalies. (a) A high level birds eye view of performance.
Green shows communication that stops for an extended period of time. (b) Zoom of (a), we could
see the patterns resulting from the per-bit timings. (c) Zoom of (b). When we look closely we see
several large gaps with the codes 0xAF, 0x9F, and 0x46. (d) Zoom of I
2
C communication.
Figure 8
A
B
C
D
Logic analyzer with built-in I
2
C protocol analysis.
Figure 9
How should processes running on different RTOSes
communicate in systems with more than one operating
system? The author suggests you can manage inter-
process communications with global-object networking.
Manage multiple
processes & processors
in a deterministic
multicore design
BY CHRIS MAIN, TENASYS CORPORATION
been implemented as separate compute platforms interconnected via
a communication network.
As the computing capabilities of off-the-shelf PCs have multiplied,
original equipment manufacturers (OEMs) now can consolidate multiple
functions onto a single platform to improve the reliability and efficiency
of their systems, at the same time driving out dedicated hardware
in favor of software-based implementations.
However, there are potential problems with consolidating
the functions that were previously performed by separate
feature
T
he typical embedded control system consists of a number of in-
dependent dedicated functions that interact with each other to
perform a task. Functions may include control elements, data
acquisition elements, and sometimes a human/machine inter-
face, all working together. In many cases, these functions have
7
computing platforms, and these prob-
lems can cause the system to fail if not
dealt with successfully. Integrated sys-
tems mzust not remove the advantages
that multiplatform systems accom-
plished by separating the functions.
One advantage of keeping system
elements separate is determinism. Em-
bedded systems need to respond to ex-
ternal stimulus in a reliable and pre-
dictable manner. Therefore, the means
of communication between the appli-
cation elements must be efficient, and
the receiving elements must be able to
rely on the data being timely and accu-
rate.
Implementing each function as a
process running under one real-time
operating system (RTOS) might not be
the best method. Scheduler interference
between the functions results in lack of
independence, which can cause
processes that were previously executed
with highest priority in a separate com-
puting platform system to fail in a con-
solidated environment.
Virtualized operating systems have
been used to achieve system consolida-
tion, but when applied as an after-
thought these methods have had limit-
ed success in supporting real-time
determinism and scalability of the
available processing power. Although
some solutions yield successful results,
they generally require customers to
make compromises that limit the capa-
bilities of their systems. Ultimately, de-
terminism and scalability must be de-
signed into the core of the software
from its inception.
ESTABLISHING REQUIREMENTS
An idealized control system may be de-
scribed by a series of independent func-
tional blocks (FBs), each of which per-
form a specific task at a specific regular
interval (Figure 1). FBs are made up of
application-specific hardware and soft-
ware components and a processor or
controller to implement the function.
Each FB may have a dedicated connec-
tion to external hardware such as mo-
tors, cameras, or other I/O points. Each
FB may also be connected to one or
more of the other FBs to implement a
whole control system, but otherwise,
each FB operates independently of oth-
er FBs.
An example of such a system (see
Figure 1) could be where FB2 is a PLC
(programmable logic controller) and
FB3 an intelligent self-contained optical
analyzer that captures the image of an
object its inspecting, analyzes it, and
informs the PLC of the result with a
GO/NO-GO output signal. FB1 could
be a motor drive that feeds the next ob-
ject that needs to be inspected.
With the availability of increased
computing performance, its possible to
move some or all of the functions onto
a single hardware platform. The advan-
tage of this is a more efficient intercon-
nect between the functions, which leads
to better overall system performance
and reliability and possibly reduced
cost. But consolidating the functions
means the development team needs to
add system management, because the
system is now apportioning common
resources such as memory and access to
I/O between the FBs.
SINGLE PROCESSOR SOLUTIONS
A typical way to combine functions on
a single platform such as a PC is to im-
plement the function blocks as separate
processes running under an RTOS.
RTOSes have built-in functionssuch
as preemptive task schedulingto en-
sure that each FBs task is executed at a
prescribed time and that a task from
one FB can preempt the processing of
another FBs task if it has a higher pri-
ority. A drawback of this implementa-
tion is that the platform resources are
not separated. Therefore, events such as
unusual I/O activity needing to be han-
dled by one of the FBs could affect the
other FBs ability to perform their tasks.
The result is that setting up a sys-
tem in this environment takes some
tuning to ensure that tasks of the vari-
ous FBs have the appropriate level of
priority and resources. This typically
makes the system somewhat custom-fit
to the platform and thus making it dif-
feature
An idealized system as a series of independent
functional blocks (FBs), each performing a
specific task at a specific regular interval and
each connected by a communication link.
Figure 1
Drive controller
Video capture
and analysis
PLC
Inter-process communications (IPC) in single
processor systems is straightforward.
Figure 2
The system manager determines how FBs are
distributed among the CPUs in a multicore
processor system.
Figure 3
Its possible to move
functions onto a single
hardware platform, but
consolidating means the
dev team needs to add
system management.
!
!
!
ficult to move from one platform to an-
other. Its also difficult to entertain any
subsequent changes to the system, such
as the addition of another FB or a per-
formance improvement in one of the
FBs, without extensive planning. Final-
ly, the finite processing capabilities of a
single processor generally limit the in-
crease in system performance that can
be obtained.
On the plus side, single processor
implementations are relatively simple.
Theyre typically run by one RTOS that
has built-in IPC (inter-process commu-
nication) facilities, making it easy for
the FBs to communicate with each oth-
er with minimal overhead (Figure 2).
MULTICORE SOLUTIONS
Single system manager: The introduc-
tion of multicore processors made a big
impact in the computing industry as a
whole. However, the adoption of multi-
cores in control-system applications has
been a little slow for two reasons. The
first and main reason is that OEMs
have not been sure how to migrate ap-
plications that were optimized to run
on a single processor onto a multicore
processor platform without breaking
them. And second, the industry has not
produced a clear path to follow for mi-
grating applications from single proces-
sor systems to multicores that enables
OEMs to get the most out of multicore
processors without requiring significant
changes to the software.
In an effort to provide the easiest
solution, multicore system managers
were introduced (Figure 3). These are
essentially operating systems with load
schedulers that make decisions on how
to load the FBs (applications) on the
processor cores. Generally, the method
used is SMP (symmetrical multipro-
cessing). Although this processor load-
ing method has proved acceptable for
non-real-time applications, it falls short
of the requirements for real-time con-
trol systems. FBs scheduled under SMP
arent guaranteed to be totally unaffect-
ed by the operation of other FBs, and
the systems I/Os are not partitioned
and dedicated to the associated FBs.
Multi-system manager: A better ap-
proach is to go back to the fundamen-
tals and use embedded virtualization
techniques to run each FB on a separate
core of a multicore platform, with allo-
cated/ dedicated I/Os and memory
management (Figure 4). With each core
under the control of an individual sys-
tem manager (RTOS), the system is es-
sentially an AMP (asynchronous multi-
processing) system.
The missing bit in this implementa-
tion is ability for the FBs to communi-
cate with each other. This can be added
to the application layer or embedded
within each system manager (RTOS).
The former is easier to implement but
difficult to make transparent to the de-
veloper. Its even harder to integrate
with the applications priority level so
that any inter-FB communication is
managed as part of the prioritization of
other tasks that are running.
A better method is to integrate the
IPC mechanism into the RTOS (Figure
5) where it may be automatically han-
dled by the RTOS priority scheduler.
This enables programmers to refer to
standard exchange objectssuch as
mailboxes, semaphores, and shared
memory blockswithin their code to
perform IPC between processor cores
and across platforms. This embedded
IPC methodology is so transparent that
it allows FBs to be separated and dis-
tributed among available processors
with minimal code changes.
For this system to work reliably
there must be a means for the FBs to
know the state of other FBs on which
they depend. This is done by adding a
system-manager layer to the environ-
ment. This layer provides a means of
signaling system events, such as the cre-
ation and deletion of interdependent
processes. Both the IPC and the man-
agement layers are designed to be ex-
tended across multiple instances of the
RTOS, thus making it easy to scale a
system from one to many processors, be
they on the same platform or even mul-
tiple platforms.
IMPLEMENTING GLOBAL OBJECTS
Global objects provide a means for im-
plementing the above and have the fol-
lowing characteristics:
Each instance of the RTOS is

launched on each core of a multi-
core processor. In this particular
RTOS, system functions are imple-
mented as objects, each referred to
by a handle. Each instance of the
RTOS operates independently of
the others, with its own separate
memory, scheduler, I/O devices,
Figure 4
A good way to ensure that real-time tasks dont
affect one another is to run them on separate
cores, each controlled by its own RTOS.
Interprocess communications capability is integrated
into each RTOS, allowing multi-FB applications to be
hosted on multicore processors with minimal code
changes.
Figure 5
feature
A better method is to
integrate the IPC
mechanism into the RTOS
where it may be automat-
ically handled by the
RTOS priority scheduler.
!
!
!
and associated interrupt management. Processes
that run on one instance of the RTOS have no
impact on processes that run on another instance
of the RTOS.
An efficient, asynchronous message-passing sys-

tem provides the common transport to support
the IPC and management layers across multiple
instances of the RTOS.
The system APIs are extended transparently to

allow a process on one instance of the RTOS to
access objects on another instance of the RTOS.
This is the same method by which processes com-
municate within a single instance of the RTOS,
but the scope of the object handles has been
extended by means of the IPC layer so that a han-
dle may refer to an object elsewhere. Each
instance of the RTOS has a global object manager
process to manage this. This management process
acts as an agent for remote processes interacting
with local objects.
The system-management layer (called DSM, or

Distributed System Manager, in the example
shown in Figure 6) allows processes to register
their dependence on other processes in order that
theyre notified if another process in the relation-
ship is terminated or compromised. The DSM
layer also monitors nodes (instances of the
RTOS), so that if one is shutdown or fails,
processes on other nodes are notified.
In this example, which implements the example

system described earlier, an instance of the
Windows OS has been added and the functionali-
ty is also extended to that operating system.
Referring to the application in Figure 1, we can
now have the video camera application (which well
call FB3) run by Process C on Core 3 and the PLC
(FB2) run by Process B on Core 2 of a multicore plat-
form. As before, the video application needs to inform
the PLC when it has completed its video capture and
The dual RTOS scenario.
Ellc|erl pallerr recogr|l|or ard dala r|r|rg derards a deparlure lror lrad|l|ora|
corpul|rg lec|ro|ogy ard prograrr|rg. w|al l|e W|ee| d|d lo revo|ul|or|ze
lrarsporlal|or, Cogr|Ver does lor pallerr recogr|l|or.
Native Parallelism for High-Performance Reduced-Energy Computing
Valc| a pallerr arorg ary ruroer |r a lxed arourl ol l|re. Forgel aooul l|e
rerory s|ze ard access-l|re ooll|erec|s. Ta|e advarlage ol l|e ral|ve|y para||e|
arc||leclure ol our cogr|l|ve reror|es lor rass|ve|y para||e| dala r|r|rg. 3ear|ess|y
slac| Cogr|8|ox
TV
lor sca|ao|e ||g|-perlorrarce recogr|l|or W|l| reduced erergy,
|alercy, s|ze ard cosl.
Nat|ve Hode| Cenerator and Rea|-T|me 6|ass|er for |nte|||gent 8ens|ng
Turr d|g|la| |rpul slrears |rlo va|uao|e |rlorral|or al l|e sersor |eve| W|el|er |l
|s lo acluale a dev|ce, Warr lor arora||es or serd or|y re|evarl |rlorral|or lo l|e
c|oud. 0ur cogr|l|ve reror|es |earr |r rea|-l|re lror exarp|es W||c| e||r|rales
prograrr|rg ard |rproves accuracy.
It all Rides On the
Right Technology
(916} 358-9483 www.cogn|mem.com
TM
Get Pattern Recognition
Right with CogniMem!
Eva| K|t|80K
CV1K v|s|or sersor
Freesca|e |.VX53 0u|c| 3larl 8oard
S1,891 $995 W|||e supp|y |asls
Technical Training
Learr aooul pallerr recogr|l|or
lror l|e |rduslry p|oreers |r or-||re
ard c|assroor lra|r|rg.
Cet Your Pattern Recogn|t|on Ro|||ng w|th 6ogn|Hem
Sensor Input
Classifcation
Identifcation
Anomaly Detection
Nothing to Declare
The
Cloud
!
Data Mining/Analytics
1,024
cognitive
memories
CogniBlox
TM

4 - CM1K chips/board
(4,096 cognitive memories)
Stack for unlimited performance
ADC
Act
The system-management layer
allows processes to register their
dependence on other processes
in order that theyre notied if
another process in the relationship
is terminated or compromised.
!
!
!
analysis and tell the PLC whether the
results are successful or not. If both ap-
plications were run on a single proces-
sor, passing such information would be
easy to do using a mailbox transport
object.
With global objects and the associ-
ated global object network, the same
mechanism can be used with the addi-
tion of three program steps. First, the
PLC (Process B) needs to make the
Mailbox global so that processes run-
ning on other nodes/processors can dis-
cover it. Then two additional instruc-
tions must be executed to allow a
remote process, such as Process C, to
find a global object, in this case the
Mailbox, so that it can write to it.
Table 1 shows a listing of the com-
mands that would be executed by both
processes, with the additional instruc-
tion shown in bold and underlined.
Note also that the DSM registers
the connection between the processes
when the Mailbox is established. So if
the Process B that is the PLC applica-
tion faulted, the video app, Process C,
would be notified and would take ap-
propriate action.
The concept of passing information
from one independent functional block
to another is extendable with memory
objects. The steps to setup a memory
object are similar to those of setting up
a Mailbox. Global memory objects are
better suited for the transfer large
blocks of information. An example
would be passing position-correcting
information directly from the video ap-
plication to the motor drive upon par-
tial failure of results from the video
capture and analysis.
Because memory objects are often
subscribed to by more than two
processes, its necessary to allow a
memory object to remain present even
though the process that created it might
have terminated and has no longer any
need for it to be present. Global objects
provide such a mechanism with the in-
clusion of an Index. For example, if a
memory object is expected to be sub-
scribed to by four processes, the process
that creates the memory object assigns
it an initial Index =4. Every time an ob-
ject unsubscribes from the memory ob-
ject the index is decremented. Only
when the last process unsubscribes does
the memory object get removed.
Global objects extend to a Windows
environment as well. They can be used
to allow applications that require an ad-
vanced Windows-based human inter-
face to communicate information with
RTOS-based functional blocks. In our
example system (Figure 1), a Windows
application could read video informa-
tion directly from the memory object
that is put there by the video applica-
tion and display it for visual inspection
by an operator.
The above example shows how
global objects can be used by independ-
ent FBs to communicate information
and how the ability to pass large blocks
of information can even extend the sys-
tem capabilities. Moreover, because
they provide a mechanism for enabling
distributing FBs to communicate, the
use of global-objects-based communi-
The sequence of operations that allows processes on different processors
to communicate involves adding just two additional instructions to the flow
that would have been used with a single-processor implementation.
Process B Process C
PLC Video app. Comment
CreateRtMailbox Create Mailbox A
CatalogRTHandle Catalog Mailbox in root process
GetRtNodeLocationByName Get location of remote mailbox
GetRemoteRootRtProcess Get remote root process handle
ReceiveRtData Wait for message indenitely
LookupRtHandle Get handle of Mailbox A
SendRtData Send data to Mailbox A
Wake up on receipt of data and read data
DeleteRtMailbox Delete mailbox
DeleteRtReferenceObject Delete reference object
Table 1
feature
The concept of passing
information from one
independent functional
block to another is
extendable with memory
objects.
!
!
!
An example of a global object implementation, TenAsys GOBSnet facilitates communication
between processes on different platforms.
Figure 6
cations can also be used to break-up
an FB like a motor-drive across two
processors if needed.
IMPLEMENTATION ISSUES
When a process on one RTOS is inter-
acting with an object on another RTOS,
the behavior of both instances of the
RTOS must continue to be predictable,
and the overhead of performing the op-
eration must be negligible. More im-
portantly, functional integrity of the
system must be preserved. Task priori-
ties must remain intact, and the imple-
mentation must ensure that false prior-
ity and priority inversion problems,
such as a low-priority thread on one
node blocking a higher-priority thread
on another node, are avoided.
Overheads of the implementation
are kept to a minimum and predictabil-
ity is maximized with the implementa-
tion of a light-weight message-passing
layer based on a simple shared memory
plus interprocessor interrupt for the
transport. Operations are handled by a
local agent on the receiving node on be-
half of the sending thread, and are di-
vided into two classes. The first class in-
cludes creation, deletion, and signaling
of objects, which are performed by the
agent directly. The second class of oper-
ations are those that wait on an object.
The latter operations are handled by
proxy threads that execute at the priori-
ty of the original caller, so that the call-
ing thread is effectively woken up ac-
cording to the scheduling policy of the
RTOS where the object is resident.
As an example, consider two
processes, each of which is implement-
ing one of the FBs running on a single
instance of the RTOS. Process A con-
tains an object thats being waited on
by a thread in Process B (Figure 7).
When the object is signaled, the thread
in Process B becomes ready to run
when its the highest-priority thread on
the schedulers ready list.
In Figure 8, Process A and Process
B are on separate instances of the
RTOS. When the object is signaled, the
proxy thread waiting on it is made
ready. When its the highest-priority
ready thread on the RTOS instance, it
runs and completes the transaction on
behalf of the thread in Process B, which
is now made ready.
The effect of this is that the thread
in Process B is subject to the scheduler
state of RTOS 1 when its waiting on
objects that reside on that instance of
the RTOS. This ensures that there arent
any arbitrary priority issues when the
processes are interacting across separate
instances of the RTOS.
PERFORMANCE CONSIDERATIONS
For processes that have tight loops, its
necessary for operations to carry negli-
gible to no overhead. One way of
achieving that is to use a memory ob-
ject. A memory object may be mapped
into many processes on different nodes,
just as it may be mapped into many
processes on the same node. Access to
the memory carries no additional over-
head once the mapping is complete,
and controlling the access to the mem-
ory can be managed, for example, by
some synchronization object such as a
semaphore accessed by all processes, if
the specific application requires it. This
ensures that processes across the nodes
access data at a specific time to avoid
any contention issues and provide data
synchronicity across the nodes/func-
tional blocks.
Chris Main is CTO and cofounder of
TenAsys Corporation, where he has led
development of the company's virtualiza-
tion technologies. He has worked in real-
time systems starting with minicomputers
and was involved in the iRMS group at
Intel. He was on the original develop-
ment team for INtime. He earned a grad-
uate degree in physics from York Univer-
sity and postgraduate degree in
education from Bath University.
feature
The dual RTOS scenario.
Figure 8
Two processes, each under the control of a separate instance of the RTOS. Thread in Process B waits on an object in
Process A. In the dual RTOS scenario, Thread A runs as a Proxy in the local agent in RTOS 1. When the object is signaled,
and the Proxy thread is the highest-priority thread on RTOS 1 then Thread A runs under Process B. In the TenAsys
implementation, the Local Agent is known as the GOBS Manager and the IPC is called GOBSnet. Implementation and
management of GOBSnet is embedded in the individual GOBS Managers.
Two processes under the control of a single
instance of the RTOS. A thread in Process B
waits on an object in Process A.
Figure 7
S
tay up on new products. For the
latest new products and
datasheets, go to Embedded.com,
www.eetimes.com/electronics-products,
and Datasheets.com.
Kontron announces deployable
industrial temp-rated platform for
smart M2M applications
Toni McConnel, Embedded.com
Kontrons new
ready-to-deploy Ma-
chine-to-Machine
(M2M) hardware
platform, the Kon-
tronKM2M806XT, is
targeted for applica-
tions that must op-
erate in extended temperatures and in-
dustrial environments.
The KM2M806XTcomes complete
with application-ready middleware and
supports M2M digital device connec-
tivity out of the box. An optimal plat-
form specically for factory and smart
building automation applications,
Kontrons new M2M system is indus-
trial temp rated (-40 to +85 C) and in-
cludes a cast aluminium case with ther-
mal management capabilities needed
for operation under extended tempera-
ture conditions.
The KM2M806XT is based on the
Intel Atom processor architecture. The
device is designed with a modular ap-
proach, which includes a carrier board,
audio/video board, a Kontron COM
Express mini Computer-on-Module
(Kontron COMe-mTT10), an optional
expansion board along with a M2M
software development kit from Wind
River. The modular approach enables a
simple and cost-efcient tailoring to
specic application needs. Specic in-
terface demands or processor require-
ments can be integrated. See full story
at www.eetimes.com/4236332.
Kontron
http://us.kontron.com/products/systems+a
nd+platforms/m2m/km2m806xt.html
Elliptic unveils tVault security ar-
chitecture for trusted execution
environments
tVault Security Architecture from Ellip-
tic Technologies enables end-to-end se-
curity in connected devices, helping
SoC vendors, OEMs, ODMs, and net-
work operators create products with
standards-compliant security. tVault
provides security inside Trusted Execu-
tion Environments (TEEs) and enforces
the protection of sensitive information
to ensure that it is stored, processed,
and accessed only by authorized appli-
cations.
tVault enables highly secure envi-
ronments that allow for a wide range of
applications including Digital Rights
Management (DRM) and content pro-
tection, Over-The-Top (OTT) TV, mo-
bile TV, and electronic nancial trans-
actions to be deployed in high
performance computing platforms.
tVault consists of rmware, standard
APIs, hardware support, and accelera-
tion that runs efciently in limited re-
source environments. tVault integrates
within frameworks such as ARM Trust-
Zone, where the critical security com-
ponents are embedded in a trusted and
secure OS environment. The non-criti-
cal components are executed by the rich
OS, such as Android.
See the full story online at
www.eetimes.com/4236145.
Elliptic Technologies
www.elliptictech.com
Telits M2M modules support AIA
Pioneer and GoFer remote
monitoring
Telit Wireless Solutions M2M modules
will enable connectivity for remote mon-
itoring applications from Alta Industrial
Automation Ltd. (AIA). Leveraging
Telits G24 and H24 modules for its Pio-
neer and GoFer product lines, AIA en-
ables real-time monitoring of a wide
range of mobile and xed industrial as-
sets, such as gas lines, irrigation systems,
chemical tanks and automotive eets.
Equipped with Telits G24 and H24
modules, variations of AIAs Pioneer and
GoFer devices feature low-power con-
sumption to extend the life of remote
M2M deployments, maximizing cus-
tomers return on investment. See full
story at www.eetimes.com/4236134.
Telit Wireless Solutions
www.telit.com
LED driver controller handles de-
manding lighting applications
Ismini Scouras, EE Times
By extending input voltage operation
from 60 V down to as low as 5.0 V, the
ZXLD1371 LED driver controller from
Diodes Inc. has been designed to handle
as broad a range of applications as pos-
sible, including those subject to the
greatest variance in input voltage, such
as automotive lighting and 12-VAC
powered systems.
Its ability to control an external
driver FET in buck, boost and buck-
boost driver topologies makes it an all-
in-one solution, capable of driving as
many as 20 high current LEDs in boost
mode with a high level of accuracy. See
full story at www.eetimes.com/4236083.
Diodes Inc.
www.diodes.com
Smart M2M and secure architecture
new products
By Jack G. Ganssle
break points
B
ack when the Earth was starting
to cool and the first creatures
were crawling from the slime, we
were building a very fast system using
plenty of discrete logic because the
processors of those Paleozoic years
couldnt keep up with our data rates. I
was probing a pair of signals on a fabu-
lously-expensive oscilloscope, but their
relationship made no sense. Eventually
I realized that one of the scope probe
leads was a full meter longer than the
other. This was the first, but certainly
not the last, time I cursed lights snail-
like pace. And it was the first time I
was forced to think about scope
probes, other than the routine of com-
pensating them.
Eons later I still see engineers root-
ing around in a bin and untangling a
random, often abused, probe, carelessly
connecting it to the scope that they
spent a week evaluating and compar-
ing to a host of other products. But
that $10k or $20k instrument (or
more; I read a press release for a nifty
$400k model this week) can be com-
pletely hobbled by a lousy or poorly-
selected probe.
A scope probe is not a wire. Sure,
its an electrical connection between a
node on a board and the oscilloscope.
But its resistance, capacitance, and in-
ductance have serious consequences as
speeds increase.
Plenty of white papers talk about
proper probe selection, but to my
knowledge none show how the wrong
probe can either cause your circuit to
fail or even physically destroy compo-
nents. Lets look at some of the issues.
For readers without an EE, heres a
bit of background. There will be a little
math, but fear not! Mostly this is as
simple as Ohms Law, which is:
E=IR
E is voltage, I current, and R resistance.
But theres really no such thing as a
perfect resistor. Every component, be it
a wire, resistor, or anything else has
some amount of capacitance and in-
ductance associated with it. So, while
Ohms Law holds true, as frequencies
increase we need to include these ef-
fects in our thinking about resistance.
A capacitor passes AC but not DC,
and the higher the frequency, or the
larger the capacitance, the more easily
it passes current. This is known as ca-
pacitive reactance, which is a form of
resistance to alternating current. Its
expressed as:
C is the capacitance in farads and f
is the frequency in Hz. If f is zero
DCthe reactance is infinity and a
perfect capacitor completely blocks
current flow. As the signal gets faster
its reactance drops.
Inductors are similar:
In this case L is the inductance. So
an inductor, too, has a resistive-like ef-
fect, although it is inverse of that of the
capacitor.
If a circuit has inductance and ca-
pacitance, the total reactance is, well,
its thankfully not important to this
discussion, but suffice to say that one
can compute a net reactance. Toss in
pure resistance and the total imped-
ancewhich is merely resistance to
waveformsin a parallel circuit is:
1
2
= X
fC
c
X fL
l
2 =
Probing pointers
The wrong probe can
cause your circuit to fail
or even physically
destroy components.
Here are some of the
issues.
!
!
!
Jack G. Ganssle is a lecturer and consultant on embedded
development issues. He conducts seminars on embedded systems
and helps companies with their embedded challenges.
Contact him at jack@ganssle.com.
Ohms Law still holds, except we
now replace R with Z. So its possible to
compute current flow in a complicated
circuit at any given frequency if one
knows the voltage and impedance.
I said theres no such thing as a
perfect resistor. A typical watt resis-
tor has 0.5 pF of shunt capacitance. A
wire-wound resistor is a coil and has
inductance (although some have re-
verse windings to limit this). A normal
film or carbon resistor has very little
inductance.
A scope probe has capacitance, re-
sistance and some inductance (mostly
in that black ground wire), and looks
something like Figure 1.
A scope probe, because of its im-
pedance, is rather like a resistor that
gets placed in parallel with the node
youre testing. The net impedance of
two in parallel is:
Thus, placing a probe on a node re-
duces the impedance of that point.
Whatever drives the node must, in effect,
push harder or the signal will degrade.
But is this really a big deal? Scope
probes are typically specified at 10 mil-
lion ohms, which is an enormous value.
Put that in parallel with a digital device,
whose resistance is orders of magni-
tudes lower, and there will be no meas-
urable effect.
But whats important is impedance,
not resistance, and as noted earlier, im-
pedance depends on frequency. If
youre probing a digital circuit odds are
that things are switching pretty quickly.
The frequency may be quite high.
Thats where the second part of a
probes spec, the tip capacitance, comes
in. This ranges from under a pF to
100 pF or more. And that has a huge ef-
fect on the probes impedance. Tektron-
ix is one of the few vendors that gives
graphs of probe impedance. Their
TPP1000, a 1-GHz passive probe, has
the impedance vs. frequency curve in
Figure 2.
At 100 MHz the impedance appears
to be around 500 ohms. The probes ca-
pacitance is 4 pF; running the reactance
numbers we get 400 ohms at that fre-
quency, pretty darn close. At low fre-
quencies the reactance gets very large so
the 10-Mresistor dominates.
This is a $900 probe. Cheap probes
may be considerably worse. The capaci-
tance of Pomonas $117 5812A, rated
for 300 MHz, is listed as <17 pF. Lets
assume 17. Thats 93 ohms at 100 MHz.
In a 5-volt circuit, the probe will add a
54-ma load.
Surfing the net one finds lots of
cheapies at 100 pF or worse, which nets
a terrifying 20 ohms at 100 MHz. To
put that into perspective, in a 2-volt cir-
cuit it would take 100 ma to drive the
probe alone, and few gates can do that.
Even at 10 MHz were talking 10 ma.
74HCT gates, for instance, are generally
rated at 4 ma. Other parts, notably
processors, may be capable of driving
less current. TIs OMAP35xx parts are
specd at 2 ma on most pins.
In other words, connect one of
these puppies to your board and the
circuit may very well stop working. I
think some of those homeless people I
see in Baltimore are engineers who
cracked when they found their trou-
bleshooting tools made troubleshoot-
ing impossible.
The important take-away is this:
when buying a probe dont be seduced
by the 10-Mrating. Think imped-
ance, which is related to tip capaci-
tance.
(A side note for those working with
analog. Generally analog signals arent
as fast as digital so the probe-loading is-
sues may be less severe. On the other
hand, many analog nodes have a much
higher impedance than digital. Even at
DC putting a 10-Mprobe across a
10-Mnode will zap half the signal).
Better probes exist. Teks 4 GHz
P7240 has a tip capacitance of only
0.85 pF. Running the numbers we get
2 Kat 100 MHz, which exactly match-
es the chart in the devices manual. But
this is an active probe, one loaded with
electronics, and itll set you back $5,000.
Which explains the sign held aloft by
1 2
1 2
=
+
Z
Z xZ
Z Z
net
TPP1000 probe impedance.
Figure 2 Graphic courtesy of Tektronix, Inc. Reproduced with permission.
Equivalent circuit of a scope probe.
Figure 1
Probe tip
Ground
When buying a probe
dont be seduced by the
10-M rating. Think
impedance, which is
related to tip capaci-
tance.
!
!
!
break points
one gaunt street person last week: Please
help. Will work for a pair of P7240s.
Logic analyzer probes also exhibit ca-
pacitive characteristics. Agilent, for in-
stance, sells sets that range from 0.7 pF to
3 pF per tip. The probe sets for their
MSOs run 8 to 12 pF. Cheapies advertised
on the Internet have higher capacitances,
and an astonishing number dont have a
rating at all. Never connect a logic analyz-
er to a circuit unless youve thought
through the probe impedance issues.
FOURIER FITS
But it gets worse.
In 1822, Joseph Fourier released his
Thorie analytique de la chaleur (The Ana-
lytic Theory of heat). That seminal work
has tormented generations of electrical
engineering students (and no doubt oth-
ers). Discontinuous functionslike
square wavesare very resistant to mathematical analysis
with calculus unless one does horrible things like use unit
step functions. But Fourier showed that one can represent
many of these periodic functions as the sum of sine waves of
different amplitudes and frequencies. The Fourier Series for a
square wave is:
The series goes on forever, so all square waves have fre-
quency components going to infinity. However, the ampli-
tude of these decrease rapidly due to the division by an ever-
larger odd number. The point, though, is that the
frequency of a square wave is composed of many frequen-
cies higher than that of the baseband.
Pulses, like the ones that race around every digital board,
the ones we probe with our scopes and logic analyzers, are
square-wave-ish. The good news is that theyre not perfect
square waves: obviously, with the exception of clocks, they
rarely have a 50% duty cycle. Pulses are also, happily, imper-
fect. Fouriers analysis assumed that the signal transitions be-
tween zero and one instantaneously. In the real world every
pulse has a finite rise and fall time. If T
r
is the rise time, then
the frequency components above F in the following formula
will be so far down theyre not important:
This does mean that, assuming a 1-nsec rise time, even if
your clock is ticking along at a leisurely rate about the same
as a Florida old-timers speedome-
ter, the signals have significant fre-
quencies up to 500 MHz.
Those unseen but very real fre-
quency components will interact
with the scope probe.
AD HOC FORMULAS
Long troubleshooting sessions often
see a board covered with connec-
tions to test equipment, data loggers,
etc. Long lengths of wire-wrap wire
get soldered between a node and an
instrument. These connections all
change the AC properties of the
nodes by adding inductance and ca-
pacitance. Here are some useful for-
mulas with which one can estimate
the effects. These are derived from
book High-Speed Digital Design
(Howard Johnson and Martin Gra-
ham, 1993 PTR Prentice-Hall Inc, Englewood Cliffs, NJ), and
theres much more useful data in that book.
Most of us use multilayer PCBs that have one or more
ground and power planes. Solder a wire to a node and drape
it across the board as it runs to a scope or other instrument,
and youll add capacitance. If d is the diameter of the wire in
inches, h is the height above the PCB, and l is the length of
the wire, then the capacitance in pF is:
(A better solution is to run the wire straight up from the
node, perpendicular to the PCB.)
AWG 30 wire-wrap wire is 0.0124 inches in diameter.
Typical hook-up wires are AWG 20 (0.036 inches), AWG 22
(0.028 inches), and AWG 24 (0.022 inches).
The inductance of the same wire in nanohenries is:
The inductance of a round loop of wire (for example a
scope probes ground lead) in nH is, if d is the diameter of
the wire and x is the diameter of the loop:
Next month well look at some real-world data.
( )
4
(sin(2 )
1
3
sin(6 )
1
5
sin(10 ) ...
= + + + f t ft ft ft
0.5
= F
T
r
1.4
ln(
4
)
= C
l
h
d
5.08ln(
4
) = L
h
d
15.6 (ln(
8
) 2) = H x
x
d
Never connect a logic
analyzer to a circuit
unless youve thought
through the probe imped-
ance issues.
But it gets worse . . .
!
!
!
Get current,
without the hassle.
Design News is a registered trademark of UBM plc 2012
REGISTER AT
DesignNews.com/dkcec
With Digi-Keys Continuing Education Center, catch up to 180 days of free,
interactive courses engineered by Design News, starting January 2012.
Build your engineering know how. Take one or all. Its your choice.
Tracks include: Microcontrollers Basic, Microcontrollers Advanced, MEMS Sensor
Technology, Lighting, Embedded Internet and Cloud, Wirelesss, and Power.
@DigiKeyCEC
Digi-Key Continuing Education Center
FOLLOW US
A full featured development solution
for all ARM Powered
platforms.
1-800-348-8051
www.arm.com/ds5
Leading Embedded
Development Tools

CMP Esd0312

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CMP Esd0312

Diunggah oleh

Hak Cipta:

Format Tersedia

E MB E D D E D S Y S T E MS D E S I G N

Dual IPv4/IPv6 TCP/IP stack, USBX

New test 1. Line 62. End of block 3.

New test 2. Line 47. End of block 1.

New test 3. Line 52. End of block 2.

Soto achieve 100% coverage of the

Each instance of the RTOS is

An efficient, asynchronous message-passing sys-

The system APIs are extended transparently to

The system-management layer (called DSM, or

In this example, which implements the example

Anda mungkin juga menyukai