Embedded.systems.design..April.2012

E M B E D D E D S Y S T E M S D E S I G N

APRIL 2012

VOLUME 25,NUMBER 3

SHIELDINGSYSTEMSFROMATTACK 12

Win with secureand reliable

8

Data-at-rest protection

19

Efficient tests formagnetic cards and

readers 24

Probing pointers32

The Official Publication of The Embedded Systems Conferences and Embedded.com

Get current, without the hassle.

Design News is a registered trademark of UBM plc © 2012

REGISTER AT

DesignNews.com/dkcec

With Digi-Key’s 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. It’s 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

For nearly 30 years the world’s leading defense companies have trusted Green Hills Software’s secure and reliable high performance software for mission-critical and safety-critical applications.

From the Joint Tactical Radio System, through naval anti-surface missiles, to the F-35 Lightning II and Eurofighter Typhoon, Green Hills Software has been delivering proven and secure underpinning technology.

To find out how the world’s most secure and reliable operating system and software can take the risk out of your defense project, visit www.ghs.com/s4d

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. U.S. Navy photo by Mass Communication Specialist 2nd Class James R. Evans/Released.

TRUSTED SOFTWARE FOR DEFENSE

SEcURE REliAblE

SAFE

mouser.com/ti

Mouser and Mouser Electronics are registered trademarks of Mouser Electronics, Inc. Other products, logos, and company names mentioned herein, may be trademarks of their respective owners.

The Newest Products for Your Newest Designs®

*bigger TM

*bigger TM

mouser.com Semiconductors and electronic components for design engineers.

Authorized Distributor

Scan hereto Find TI.

Over 80,000 Searchable Part Numbers. More than 100 TI Product Knowledge Centers.

Find TI here. Faster at mouser.com.

Your Complete Source for Everything TI.


THE OFF IC IAL PUBLICATION OF THE EMBEDDED SYSTEMS CONFERENCES AND EMBEDDED.COM

VOLUME 25, NUMBER 3APRIL 2012

COLUMNSbarrcode 8Building reliable and secureembedded systemsBY MICHAEL BARR

Take it from an expert witness: If youdon’t learn to create reliable and secureproducts, your source code and designdocuments might be the ones thelawyers pore over.

break points 32Probing pointers, take 2BY JACK G. GANSSLE

Jack tests several probes to see how

different probes change the results.

DEPARTMENTS#include 7A tale of two design sitesBY COLIN HOLLAND

If not attending ESC/DESIGNWest, spend time at www.ubmdesign.com and embedded.com.

parity bit 10Probes and analyzers

analyst’s corner 11Not in Kansas anymore: Securing SCADABY ERIC MARKS

IN PERSONDESIGN West/ESC Silicon Valley March 16–29, 2012http://esc.eetimes.com/siliconvalley/

DESIGN East/ESC Boston September 17–20, 2012http://esc.eetimes.com/boston/

ONLINEwww.embedded.com

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, 303 Second Street, Ste 900, San Francisco, CA 94107, (415) 947-6000. Please direct advertising and editorial inquiriesto 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 additionalpostage 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, [email protected]. 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 additionalmailing offices. EMBEDDED SYSTEMS DESIGN is a registered trademark owned by the parent company, UBM Electronics. All material published in EMBEDDED SYSTEMSDESIGN is copyright © 2012 by UBM Electronics. All rights reserved. Reproduction of material appearing in EMBEDDED SYSTEMS DESIGN is forbidden without permission.

Cover Feature:Security fundamentalsfor embedded softwareBY DAVID KALINSKYEven if your device is not connected tothe Internet, you need to protect it frommalicious attacks. Here are some simpleprotections you can institute to makeyour system more impenetrable.

19 Enhance system security with betterdata-at-rest encryptionBY DAVID KLEIDERMACHER, GREEN HILLS SOFTWAREEmbedded systems designers can protect sensitive dataon a device’s hard drive (data-at-rest) by using encryp-tion techniques.

24 Make magnetic card readers more reliablein noisy environmentsBY IRFAN CHAUDHRY, MAXIM INTEGRATED PRODUCTSHere’s a less time-consuming way to maintain the reliability ofmagnetic card readers and cards in a variety of noisy electronicenvironments.

12

INDUSTRIAL

MEDICAL

AEROSPACE

AVIATION

SYSTEM ON A CHIP

CONSUMER

Express Logic has completed 14 years of successful business operation, and our fl 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 fi eld-proven, and represents not only the safe choice, but the most cost-effective choice when your company’s product

ThreadX, FileX, and TraceX are registered trademarks, and NetX, USBX, PEGX, StackX, and Certifi cation Pack are trademarks of Express Logic, Inc. All other trademarks are the property of their respective owners.

Copyright © 2010, Express Logic, Inc.

Express Logic has completed 14 years

When Your Company’s Success, And Your Job, Are On The Line - You Can Count On Express Logic’s ThreadX® RTOS

REALLY COUNTSTHREADX: 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 fi nd out more about our ThreadX RTOS, FileX® fi 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 overfl ows a thing of the past. And if you’re developing safety-critical products for aviation, industrial or medical applications, ask about our new Certifi cation Pack™ for ThreadX.

For a free evaluation copy, visit www.rtos.com • 1-888-THREADX

ThreadX, FileX, and TraceX are registered trademarks, and NetX, USBX, PEGX, StackX, and Certifi cation Pack are trademarks of Express Logic, Inc.

, our patent-pending stack size analysis tool that makes stack overfl ows a

Edward L. Lamie

With ThreadX

Second Edition

Now with appendices for ARM, Coldfi re,

MIPS and PowerPC architectures

Newnes

INCLUDEDINCLUDEDINCLUDEDCD-ROM

REAL-TIME

EMBEDDED

MULTITHREADING

Express Logic has completed 14 years of successful business operation, and our fl agship product, ThreadX, has been used in over 800 million electronic devices and systems,

Express Logic has completed 14 years simply simply 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

T H R E A D

BY Colin Holland #includeE M B E D D E D S Y S T E M S D E S I G NE M B E D D E D S Y S T E M S D E S I G N BY Colin Holland #includeE M B E D D E D S Y S T E M S D E S I G N

Director of ContentColin [email protected]

Managing EditorSusan Rambo(415) [email protected]

Acquisitions/Newsletter Editor, ESD and Embedded.comBernard Cole(928) [email protected]

Contributing EditorsMichael BarrJack W. CrenshawJack G. GanssleDan Saks

Art DirectorDebee [email protected]

Production DirectorDonna [email protected]

Article submissionsAfter reading our writer’s guidelines, sendarticle submissions to Bernard Cole [email protected]

Subscriptions/RSS Feeds/Newsletterswww.eetimes.com/electronics-subscriptions

Subscriptions Customer Service (Print)Embedded Systems DesignPO Box # 3609Northbrook, IL 60065- [email protected](847) 559-7597

Article Reprints, E-prints, andPermissionsMike LanderWright’s Reprints(877) 652-5295 (toll free)(281) 419-5725 ext.105Fax: (281) 419-5712www.wrightsreprints.com/reprints/index.cfm?magid=2210

PublisherDavid Blaza(415) [email protected]

Associate Publisher, ESD and EE TimesBob Dumas(516) [email protected]

Corporate—UBM ElectronicsPaul Miller Chief Executive OfficerDavid Blaza Vice PresidentKaren Field Senior Vice President, ContentFelicia Hamerman Vice President, MarketingBrent Pearson Chief Information OfficerJean-Marie Enjuto Vice President, Finance Amandeep Sandhu Director of Audience Engagement &

AnalyticsBarbara Couchois Vice President, Partner Services &

Operations

Corporate—UBM LLCMarie Myers Senior Vice President,

ManufacturingPat Nohilly Senior Vice President, Strategic

Development and BusinessAdministration


A tale of two design sites

www.embedded.com | embedded systems design | APRIL 2012 7

Some of you will undoubtedly bereading this while attending theESC/DESIGN West event or in

the lead up to it. For those not fortunateto be joining us in San Jose in the lastweek of March, I would like to highlightwhat we’ll be providing through theevent website www.ubmdesign.com.

As well as all the information re-quired for people to plan a conferencevisit, we’ll be updating news from theshow via the Breaking News tab onwww.ubmdesign.com (or directly here:www.ubmdesign.com/breaking-news).What’s more exciting is that you’ll beable to access several areas on the siteaimed at extending the life of contentfrom the shows and well as providingtwo-way interaction. One such sectionis the forum-like Answerstream(www.ubmdesign.com/answerstream),which will provide discussion areas on:

Analog/mixed signalAndroidDevelopment toolsFPGALEDsLow powerMemoryMedicalMicroprocessors/microcontrollers RTOSSecuritySensorsTest and measurement

This is part of our goal to providea continuing educational experienceand community resource year-round.The web site will provide intelligent,personalized content in real-time in-

cluding white papers, webinars, videos,special offers, and collateral. The intel-ligent content functionality not onlydelivers targeted subject matter con-tent but also dynamically monitorsyour reactions and engagement pat-terns in able to recommend additional,meaningful content. The application isplatform agnostic and available towork on tablet and desktop devices.

In parallel over the comingmonths, we’ll be looking to upgradeand enhance our sister website, Em-bedded.com. This site has long beenregarded as the must-visit location formany people involved in the embed-ded sector worldwide. I’m extremelykeen to receive feedback from existingand potential readers on what youwould like to see from Embedded.com—let me know what we do well, thecontent you like and would like to seeexpanded, but more importantlywhere we could improve our service toyou.

The design of embedded systems iscontinually evolving and we want Em-bedded.com to reflect that while mak-ing sure we don’t “throw the baby outwith the bathwater” and discard any-thing you find useful and rely on tohelp you to implement your designs.What else would be useful to you—more code for download, detailed de-scriptions of development kits? Whatelse should we add that could makeyou more efficient?

I look forward to receiving com-ments from as many of you as possible.

In the meantime, live at ESC andlater in April we’ll be doing a webinaron the results of our annual EmbeddedMarket Survey—keep an eye on Em-bedded.com and its newsletter for anupdate on the date.

Colin [email protected]

Colin Holland is the directorof content for EmbeddedSystems Design magazine,Embedded.com, and theDesignWest and East (whichincludes the EmbeddedSystems Conferences). You may reach him at [email protected].

the field—so that the number andimpact of failures are minimized.One key strategy for building reli-able systems is to eliminate singlepoints of failure. For example, re-dundancy could be added aroundthat critical input sensor—perhapsby adding a second sensor in parallelwith the first.

Another aspect of reliability thatis under the complete control of de-signers (at least when they considerit from the start) are the “fail-safe”mechanisms. Perhaps a suitable butlower-cost alternative to a redun-dant sensor is detection of the failedsensor with a fall back to mechanicalbraking.

Failure Mode and Effect Analysis(FMEA) is one of the most effectiveand important design processes usedby engineers serious about designingreliability into their systems. Follow-ing this process, each possible failurepoint is traced from the root failureoutward to its effects. In an FMEA,numerical weights can be applied tothe likelihoods of each failure as wellas the seriousness of consequences.An FMEA can thus help guide you toa cost effective but higher reliability

design by highlighting the most valuable places to insertthe redundancy, fail-safes, or other elements that rein-force the system’s overall reliability.

In certain industries, reliability is a key driver ofproduct safety. And that is why you see these techniques,

In this era of 140 characters orless, it has been well and con-cisely stated that, “reliability

concerns accidental errors causingfailures, whereas security concernsintentional errors causing failures.”In this column, I expand on thisstatement, especially as regards thedesign of embedded systems andtheir place in our network-con-nected and safety-concious mod-ern world.

As the designers of embeddedsystems, the first thing we must ac-complish on any project is to makethe hardware and software work.That is to say, we need to make thesystem behave as it was designedto. The first iteration of this is of-ten flaky; certain uses or perturba-tions of the system by testers caneasily dislodge the system into anon-working state. In commonparlance, “expect bugs.”

Given time, tightening cycles ofdebug and test can get us past thebugs and through to a shippableproduct. But is a debugged systemgood enough? Neither reliabilitynor security can be tested into aproduct. Each must be designed infrom the start. So let’s take a closer look at these two im-portant design aspects for modern embedded systems andthen I’ll bring them back together at the end.

RELIABLE EMBEDDED SYSTEMSA product can be stable yet lack reliability. Consider, forexample, an anti-lock braking computer installed in acar. The software in the anti-lock brakes may be bug-free, but how does it function if a critical input sensorfails?

Reliable systems are robust in the face of adverserun-time environments. Reliable systems are able to workaround errors encountered as they occur to the system in

Building reliable and secure embeddedsystems

By Michael Barrbarr code

Michael Barr is CTO of Barr Group and a leading expert inthe architecture of embedded software for secure and reli-able real-time computing. Barr is also a former lecturer atthe University of Maryland and Johns Hopkins University andauthor of three books and more than sixty five articles andpapers on embedded systems design. Contact him [email protected].

Neither reliability norsecurity can be tested,debugged, or patched intoa product. They must bedesigned into embeddedsystems from day one.

!!!

8 APRIL 2012 | embedded systems design | www.embedded.com


FMEA, and other design-for-reliability processes being ap-plied by the designers of safety-critical automotive, medical,avionics, nuclear, and industrial systems. The same tech-niques can, of course, be used to make any type of embed-ded system more reliable.

Regardless of your industry, it is typically difficult orimpossible to make your product as reliable via patches.There’s no way to add hardware like that redundant sensor,so your options may reduce to a fail-safe that is helpful butless reliable overall. Reliability cannot be patched or testedor debugged into your system. Rather, reliability must bedesigned in from the start.

SECURE EMBEDDED SYSTEMSA product can also be stable yet lack secu-rity. For example, an office printer is thekind of product most of us purchase anduse without giving a minute of thought tosecurity. The software in the printer maybe bug-free, but is it able to prevent awould-be eavesdropper from capturing aremote electronic copy of everything youprint, including your sensitive financialdocuments?

Secure systems are robust in the face ofpersistent attack. Secure systems are ableto keep hackers out by design. One keystrategy for building secure systems is tovalidate all inputs, especially those arriv-ing over an open network connection. Forexample, security could be added to aprinter by ensuring against buffer over-flows and encrypting and digitally signingfirmware updates.

One of the unfortunate facts of designing secure em-bedded systems is that the hackers who want to get in onlyneed to find and exploit a single weakness. Adding layers ofsecurity is good, but if even any one of those layers remainsfundamentally weak, a sufficiently motivated attacker willeventually find and breach that defense. But that’s not anexcuse for not trying.

For years, the largest printer maker in the world appar-ently gave little thought to the security of the firmware inits home/office printers, even as it was putting tens of mil-lions of tempting targets out into the world. Now the secu-rity of those printers has been breached by security re-searchers with a reasonable awareness of embedded systemsdesign. Said one of the lead researchers, “We can actuallymodify the firmware of the printer as part of a legitimatedocument. It renders correctly, and at the end of the jobthere’s a firmware update. ... In a super-secure environmentwhere there’s a firewall and no access—the government,Wall Street—you could send a résumé to print out.”

Security is a brave new world for many embedded sys-

tems designers. For decades we have relied on the fact thatthe microcontrollers and flash memory and real-time oper-ating systems and other less mainstream technologies weuse will protect our products from attack. Or that we cangain enough “security by obscurity” by keeping our com-munications protocols and firmware upgrade processes se-cret. But we no longer live in that world. You must adapt.

Consider the implications of an insecure design of anautomotive safety system that is connected to another Inter-net-connected computer in the car via CAN; or the inse-cure design of an implanted medical device; or the insecuredesign of your product.

Too often, the ability to upgrade a product’s firmware inthe field is the very vector that’s used to attack. This can

happen even when a primary pur-pose for including remotefirmware updates is motivated bysecurity. For example, as I’velearned in my work as an expertwitness in numerous cases involv-ing reverse engineering of thetechniques and technology ofsatellite television piracy, much ofthat piracy has been empoweredby the same software patchingmechanism that allowed thebroadcasters to perform securityupgrades and electronic counter-measures. Ironically, had the secu-rity smart cards in those set-topboxes had only masked ROM im-ages the overall system securitymay have been higher. This was

certainly not what the designers of the system had in mind.But security is also an arms race.

Like reliability, security must be designed in from thestart. Security can’t be patched or tested or debugged in.You simply can’t add security as effectively once the prod-uct ships. For example, an attacker who wished to exploit acurrent weakness in your office printer or smart card mightdownload his hack software into your device and write-pro-tect his sectors of the flash today so that his code could re-main resident even as you applied security patches.

RELIABLE AND SECURE EMBEDDED SYSTEMSIt is important to note at this point that reliable systems areinherently more secure. And that, vice versa, secure systemsare inherently more reliable. So, although, design for relia-bility and design for security will often individually yielddifferent results—there is also an overlap between them.

An investment in reliability, for example, generally paysoff in security. Why? Well, because a more reliable system ismore robust in its handling of all errors, whether they areaccidental or intentional. An anti-lock braking system with

Security is a brave newworld for many embeddedsystems designers. Fordecades, we relied on thetechnologies we use toprotect our products orthat we can gain enough“security by obscurity.”But we no longer live inthat world.

!!!!!

a fall back to mechanical braking for increased reliability isalso more secure against an attack against that critical hard-ware input sensor. Similarly, those printers wouldn’t be atrisk of fuser-induced fire in the case of a security breach ifthey were never at risk of fire in the case of any misbehaviorof the software.

Consider, importantly, that one of the first things ahacker intent on breaching the security of your embeddeddevice might do is to perform a (mental at least) fault-treeanalysis of your system. This attacker would then target histime, talents, and other resources at one or more singlepoints of failure he considers most likely to fail in a usefulway.

Because a fault-tree analysis starts from the general goaland works inward deductively toward the identification ofone or more choke points that might produce the desirederroneous outcome, attention paid to increasing reliabilitysuch as via FMEA usually reduces choke points and makesthe attackers job considerably more difficult. Where securi-ty can break down even in a reliable system is where thepossibility of an attacker’s intentionally-induced failure isignored in the FMEA weighting and thus possible layers ofprotection are omitted.

Similarly, an investment in security may pay off ingreater reliability—even without a directed focus on relia-bility. For example, if you secure your firmware upgradeprocess to accept only encrypted and digitally-signed bina-ry images you’ll be adding a layer of protection against a in-advertently corrupted binary causing an accidental errorand product failure. Anything you do to improve the relia-bility of communications (through checksums, preventionof buffer overflows, and so forth) can have a similar effecton reliability.

THE ONLY WAY FORWARDEach year it becomes increasingly important for all of us inthe embedded systems design community to learn to designreliable and secure products. If you don’t, it might be yourproduct making the wrong kind of headlines and yoursource code and design documents being pored over bylawyers. It is no longer acceptable to stick your head in thesand on these issues. ■

barr code


Reliable systems are inherently moresecure. And vice versa, secure systems areinherently more reliable. So, although,design for reliability and design for securi-ty will often individually yield differentresults—there is overlap between them.

!!!

Excellent article (“Troubleshooting real-time soft-ware issues using a logic analyzer,” David B.Stewart, March 2012, p. 19, www.eetimes.com/

4236800). With a bit of extra programming, you canalso sometimes use a “companion” microcontrollerinstead of a dedicated logic analyzer.

—vapats

I’m wanting to trythis out for the fun ofit with a pinball ma-chine’s logic board.

—K1200LT Rider

Probe pointersVery informative(“Probing pointers,”Jack Ganssle, March2012, p. 34, www.eetimes.com/4236927). Ihave had $15 “allpurpose” probes

come back and bite me.I’m assuming that for emergency run repairs on

printed-circuit boards it would be better to arch thepatch wire off the PCB than have it lay on top ofthe board.

—Saluki_456

Discriminated unionsWith virtual functions and proper instantiation, youdo not need any isKindOf() operator to discriminatewhich parameters or functions to use (“Discriminat-ed unions,” Dan Saks, March 2012, p. 9, www.eetimes.com/4237055). This is one of the most power-ful underpinnings of the C++ language.

— krwada

Probes and analyzers

parity bit


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 multipleprocesses in multicore

27

Probing pointers34

VERIFYINGREQUIREMENTSAND OBJECTCODE 12

We welcome your feedback. Letters to the editor may be edited.Send your comments to Colin Holland at [email protected] post your feedback directly online, under the article you wishto discuss.

CONTENTS

New Supported Processors 4

Nexus-Trace for Small Package Format Cores 5

Checking JTAG Signals 6

Enhancements to Target OS-Awareness 6

Code-Coverage – Simplified 7

CoreSight Trace Memory Controller 10

Trace Analyses for Cortex-M3/M4 12

Simulink® Integration 14

UEFI BIOS Debugging with TRACE32 16

www.lauterbach.com

DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER

NEWS 2012

Embedded designs are becoming ever more com-plex and time to market is getting shorter. To meet these challenges many project managers now rely on debug and trace tools that can accompany developers through all phases of the project.

TRACE32, the debug and trace tool family from Lauter-bach provides a consistent concept and environment which can be further extended with user customizable scripts. This helps to shorten the familiarization pro-cess and makes time for the actual development work. Developers with practical knowledge gained from more than 10 years experience with TRACE32 are quite common. So, what makes TRACE32 different?

• Hardware-andsoftware-basedtools• Earlysupportfornewprocessors• Largeportfolioofsupportedprocessors• Extensivetestandanalysisfunctions• Seamlessintegrationintotheembeddedtoolchain

Hardware and Software Tools

The core business of Lauterbach is the design and manufacture of hardware-based debug and trace tools. In addition Lauterbach has also offered logic analyzers

for over 20 years. The key feature of TRACE32 logic analyzers is seamless integration within the hardware-based debug and trace tools. For a typical application using the logic analyzer integrated in PowerTrace II read the article “Checking JTAG Signals” on page 6.

Fast, efficient computers mean that more simulation and validation is being undertaken on PC and worksta-tions. In the embedded world the pre-silicon software development on virtual targets has become the norm. For this phase of the project Lauterbach can provide pure software solutions.

A Debugger for all Phases of the Project

DEBUGGER, REAL-TIME TRACE, LOGIC ANALYZER

NEWS 2012

http://www.lauterbach.com

NEWS 2012 www.lauterbach.com2

Virtual Targets

Today virtual targets are increasingly being used to start software development long before the first hard-ware prototypes become available. As soon as a virtual target is available, debugging of the driver, the operating system, and the application can begin.

For debugging and tracing, most virtual targets have their own API. If this is not the case, the standardized MCD-API (http://www.lauterbach.com/mcd_api.html) can be used. Many new projects today use multicore chips. Consequently, Lauterbach has expanded its mul-ticore debugging support for virtual targets since 2011.

Pre-Silicon Validation

For semiconductor manufacturers, it is important to validate the design of their processors or SoCs before actual production. Individual sections are intensely tested, for example: the JTAG interface, the entire core, or the interaction between core and peripherals.

For this testing, you traditionally used an emulator for the silicon (e.g. Palladium) or FPGA prototypes, con-nected to the hardware-based TRACE32 debug tools. This would run much slower than the real processors.

Today, you can perform first validations of Verilog or SystemC models directly on a PC or a workstation. With pure software validation you cannot use debug hardware. Therefore, Lauterbach added a Verilog Back-End to its software in 2011. This simulates a JTAG interface at the signal level (see figure 1).

The integration of TRACE32 tools into the pre-silicon validation forms an important part of the early support for the latest processors and SoCs:

• Testedtoolsarereadybeforethefirstsiliconleavesthe factory.

• Expert knowledge of the new processor/SoC isavailable and can be accessed by the customer.

• Start-up scripts for the TRACE32 debugger areavailable.

60+ Supported Processor Architectures

Lauterbach has tools available for all the common processors or SoCs on the embedded market. In fact Lauterbach is the only provider of tools for many cores. Standard controllers, DSPs, FPGA softcores, configu-rable cores - everything can be combined into a multi-core chip and debugged with a TRACE32 tool.

In 2011, Lauterbach also added support for numerous new processors and multicore chips. For an overview, see the table on page 4.

Test and Analysis Functions

Each phase of a project requires its own test and analysis functions. To provide this, the TRACE32 PowerView GUI includes an extensive selection of commands and menus. Boundary scan commands (see figure 2), core detection commands and com-mands for manipulating the JTAG pins are some examples of low-level commands.

Fig. 1: For each user entry in TRACE32 Front-End, Verilog Back-End produces JTAG signals for validation of the model.

Verilog model

TRACE32Actuator

(shared library).DLL /.SO

TRACE32 Front-End for ARM

TRACE32 Verilog Back-Endfor Cortex-A/-R

.V

JTAG TAP.V

Cortex-A.V

.V

Trigger

Verilog Simulator for Cortex-A

Run-timecounter

JTAG

Reset

TRACE32Actuator

.V

Verilog ProceduralInterfaceNamed

pipe

3

During the quality and test phase the high-level com-mands provide support for the developer and these typically deal with analysis of trace data. Examples are: measuring function runtime, energy profiling, or details of code-coverage.

Since the beginning of 2011, Lauterbach has enabled most major processor architectures to stream the trace information to the host computer in real-time. This allows significantly more diagnostic data to be col-lected and quality assurance becomes much easier. For more information, see the article “Code-Coverage – Simplified” on page 7.

Integration into Embedded Tool Chain

The TRACE32 software is an open design so that it works smoothly with all of the common basic compo-nents of an embedded design. This includes:

• Hostoperatingsystems• Programminglanguagesandcompilers• Targetoperatingsystems• Virtualmachines,suchasAndroidVMDalvik

The open TRACE32 API allows seamless interaction with numerous third-party tools. Examples include special IDEs such as Eclipse, graphical programming tools and external profiling tools. Several new develop-ments in this area were added in 2011.

Prism, the parallelization tool from the Scottish com-pany CriticalBlue, supports developers when migrat-ing single-core code to run on multicore chips. The tool enables you to try different parallelization strategies without making changes to the function code. When the optimal strategy is determined, the paralleliza-tion can be performed step by step, also supported by Prism.

Since July 2011, Lauterbach has included the option of exporting trace information in Prism format, enabling the CriticalBlue tools to work with the trace recorded by the actual operation of the code.

The article “Simulation and Reality Come Closer Together” on page 14 thoroughly describes another innovation – the integration between MATLAB Simu-link® and TRACE32.

Extended Lifetime

When migrating to a new technology Lauterbach has a philosophy of ensuring there is a long transition phase. They will not force a customer to accept a technology change while in the middle of a key project.

For example: Starting in May 2012, Lauterbach will introduce a QT version of its graphical user interface TRACE32 PowerView (see figure 3). With QT, an up-to-date GUI will be available for Linux, Mac OS X, and other host operating systems.

Lauterbach will continue to support the Motif version of TRACE32 PowerView so that customers can deter-mine their own best transition time.

Within these pages of our NEWS 2012, you will find further information which might be useful for your cur-rentorfutureprojects.Hopefullyyouwillfindafeaturethat contributes to your project’s success. We will be demonstrating several of them live at the upcoming ESC Silicon Valley, March 26-29th, in San Jose, and at many other shows in the US throughout the year.

Scan chain configuration

Fig. 2: Boundary-Scan commands are available for commissioning the hardware.

QT-based PowerView

Fig. 3: The new QT-based GUI for Linux, Mac OS X and other operating systems.


New Supported Processors

New Derivatives

Altera Cortex-A / -R•FPGAwithCortex-A9MPCoreasHardcoreMIPS32•MP32

AppliedMicro PPC44x •86290/491/791Q2/2012

ARM Cortex-A / -R•Cortex-A7/Cortex-A7MPCore•Cortex-A15•Cortex-A15MPCore•Cortex-R5/Cortex-R5MPCore•Cortex-R7/Cortex-R7MPCore

Beyond Semiconductor

Beyond•BA22

Broadcom MIPS32•BCM35230•BCM63168,BCM63268•BCM7231,BCM7358

Cavium MIPS64•CN61XX/CN62XX/CN66XX•CN67XX/CN68XX

Ceva CEVA-X•CEVA-XC

CSR ARM11•QUATRO4500

Cypress ARM9•EZ-USBFX3

Energy Micro Cortex-M•GiantGecko

Freescale MCS12X•MC9S12VR,MC9S12XS •MM912F634Cortex-A / -R•i.MX6SeriesMPC55xx/56xx•MPC5604E,MPC5675K, •MPC5676RPower QUICC III•P1010,P1020•P2040,P2041•P3041,P4040,P4080•PSC9131QorIQ 64-Bit•P5010,P5020

Fujitsu Cortex-A / -R•MB9DF126,MB9EF126

IBM PPC44x•476FPQ2/2012

Ikanos MIPS32•FusivVx185

Infineon TriCore•TriCoreMulti-Core Architecture

Intel® Atom™/x86•AtomD2500,AtomN550•Corei3/i5/i72ndGeneration

Lantiq MIPS32•XWAYxRX100•XWAYxRX200

LSI PPC44x•ACP344xQ2/2012

Marvell ARM9 Debug-Cabel•88E7251ARM11 Debug-Cabel•88AP610-V6,MV78460-V6Cortex-A / -R Debug-Cabel•88AP610-V7,MV78460-V7

Nuvoton Cortex-M•NuMicro

NXP Cortex-M•LPC12xxBeyond•JN5148

Qualcomm MIPS32•AR7242Cortex-A / -R•Krait

Renesas V850•V850E2/Fx4: 70F3548..66 70F4000..70F4011•V850E2/Fx4-L:70F3570..89•V850E2/Px4:70F3503/0570F3507/08/0978K0R / RL78•78K0R/Kx3-C/L•RL78/G14,RL78/G1A•RL78/F12,RL78/I1ASH•SH708xwith AUD/Onchip-Trace•SH7147

5

The Nexus cell, which is integrated into the control-lersoftheMPC560xB/CfamilyfromFreescaleortheSPC560B/CcontrollersofST,cangeneratetracedatafor the instructions executed by the core. If an operat-ing system is used, information on task switching are produced as well.

A microcontroller must have a trace interface, so that an external trace tool, such as TRACE32, can record this tracedata.However, themembersof theMPC560xB/Cfamilydonothavethisinterfaceintheirstandard packaging. To provide access to this valu-able data about the program run during the develop-ment phase, silicon-compatible microcontrollers in a 208-pinBGAdevelopmentpackageareoffered,whichhave a Nexus interface with 4 MDO (Message Data Out) pins.

Since mid-2011, Lauterbach has provided MPC560xB/C adapters that can replace the originalcontrolleron the targethardwarewitha208-pincon-troller with Nexus interface.

The MPC560xB/C adapter consists of a suitable MPC560xB/Ccontrollerin208-pinBGAdevelopmentpackage and Mictor plug with Nexus interface for con-necting TRACE32 trace tools (shown in figure 4 in blue). In addition, a socket adapter from the Tokyo Eletech company is required.

Nexus-Trace Also for Small Package Format Cores

New Derivatives

Samsung ARM7•S3F4Cortex-A / -R•S5PV310Cortex-M•S3FM,S3FN

ST-Ericsson Cortex-A / -R•A9500,A9540,M7400MMDSP•A9500,A9540

STMicro- electronics

MPC55xx/56xx•SPC56A80,SPC56HKCortex-M•STM32F2xx,STM32F4xx

Synopsys ARC•ARCEM4,ARCEM6

Tensilica Xtensa•BSP3,LX4,SSP16

Texas Instruments MSP430•CC430Fxxx,MSP430FR5xxx •MSP430x1xx..MSP430x6xx

Texas Instruments (Cont.)

ARM9•AM38xx•OMAP4460/4470•TMS320C6A81xx•TMS320DM81xxCortex-A / -R•AM335x,AM38xx•OMAP4460/4470/543x•RM48L950•TMS320C6A81xx•TMS320DM81xx•TMS570LS3xxxCortex-M•AM335x•OMAP4460/4470/543x•TMS470MFxxxTMS320C28X•TMS320C28346/F28069TMS320C6x00•OMAP4460/4470/543x•TMS320C6A81xx•TMS320DM81xx•TMS320TCI6616/18

Xilinx Cortex-A / -R•Zynq7000

Tokyo Eletech adapter

Tokyo Eletech socket

Nexus connectorMPC560xB/C in 208-pin package

Fig.4: The MPC560xB/C adapter allows a development package withNexus interface to be used instead of the original controller.


The following version adaptations have been made:

• eCos3.0 • embOS3.80 • FreeRTOSv7• Linuxv3.0 • MQX3.6 • RTEMS4.10• SMXv4

• The content of the QNX tracelogger can be dis-

played using TRACE32 QNX OS-Awareness. A graphical representation of the task switch is also possible using the TRACE32 command group LOGGER.Chart.

• TRACE32 QNX OS-Awareness has been adaptedfor the use of position-independent executables.

Checking JTAG Signals

Fig.5: MeasuringarrangementforrecordingtheJTAGsignals.

JTAG signals

Fig. 6: The recorded JTAG signals.

JTAG protocol

Fig. 7: The protocol representation of the JTAG signals.

New Supported Target-OS

µC/OS-II for Andes available

Elektrobittresos(OSEK/ORTI) available

Erika(OSEK/ORTI) available

FreeRTOS für AVR32 available

Linux for Beyond planned

MQX for ARC available

OSEK/ORTISMP planned

PikeOS available

PXROS-HRRunModeDebugging available

RTEMS for Nios II available

Sciopta 2.x available

SYS/BIOSforARM available

VxWorks SMP available

Lauterbach’s PowerTrace II is equipped with an inte-grated logic analyzer and supplied with a standard digital probe. This enables 17 digital channels to be recordedwithasamplingrateofupto200MHz.This

logicanalyzerhasasavedepthofupto1024Ksam-ples and an example of its use would be the test of the JTAG signals during pre-silicon validation (see fig-ures 6 and 7).

Enhancements to Target OS-Awareness

7

As of March 2011, TRACE32 trace information can be streamed to a host hard-disk from the running target. The large amount of program flow data which can result from this method, leads to a sig-nificant simplification of the code-coverage.

Trace-based Code-Coverage

Proof of statement coverage and condition coverage is often required to meet system quality specifications in industries such as medical and automotive.

•Statement coverage proves that each line of code was executed during the system test.

• Condition coverage proves that for each condi-tional instruction both pass and fail branches were executed at least once.

For many embedded systems highly optimized code must be tested in real-time. The alternatives of code instrumentation and non-real-time operation cannot be used in these cases.

To be able to meet these requirements, the target pro-cessor/SoC must fulfill the following prerequisites:

1. The cores which are implemented must have a core tracelogic(seefigure8).Thislogicgeneratesinfor-mation about the instructions executed by the core. Depending on the operation of the trace logic, infor-mation about the task switches and the read/write operations can also appear.

2. The processor/SoC must have a trace port with suf-ficient bandwidth so that the trace information can be recorded by an external tool without any informa-tion loss.

The Classic Measurement Process

Until now, code-coverage analysis was performed with TRACE32 using the following steps:

1. Start program execution and automatically stop when the trace memory is full.

2. Transfer the trace memory content to the code- coverage database.

3. Continue program execution.

For each measurement step, the amount of data col-lected was limited by the size of the memory available within the trace tool. The results of the code-coverage-analysis could be checked after the total measurement was completed or, if needed, after each intermediate step.

New: Streaming

If the trace data is transferred to a drive on the host computer at the time of recording, the complete soft-ware routine can be recorded in one measurement step. The streamed data is stored within a file on the hard-disk. To avoid completely filling the hard-disk with trace data, TRACE32 stops streaming as soon as less than 1 GByte of free memory remains.

To be able to stream, the following technical prerequi-sites must be fulfilled:

• 64-bit host computer and 64-bitTRACE32 execut-able

• Interface between trace tool and host computermust be as fast as possible.

• Optimal configuration of the trace source and thetrace tool

TRACE32 PowerView64-bit host

SoC

Trac

e p

ort

JTA

G

Tracecontrollogic

Trace memoryas FIFO

File onhard-disk

Coretracelogic

Core

Fig.8: Forthecode-coverageanalysis,upto1TByteoftracedatacanbestreamedtothehostcomputer.

Code-Coverage – Simplified


Fast Host Interface

The amount of trace data that is exported via the trace port depends on the target system hardware. The number of cores, the number of trace port pins, and the trace clock speed are all important parameters. The protocol used by the core trace logic plays also an important role. For example, the ARM PTM protocol is more compact than the ARM ETMv3 protocol (see figure9).

The embedded software is another major variable. A software program that performs many jumps and retrieves data/instructions mainly from the cache pro-duces more trace data per second than a software program that processes many sequential instructions and must frequently wait for the availability of data/ instructions.

The amount of data varies but it is always large. Stream-ing only works properly, if the transfer rate between the tool and the host computer is fast enough to transfer all of the data from the trace port to the host computer without any data loss. The 1 GBit Ethernet interface is the only recommended interface for the PowerTrace II.

The programming of the trace logic on the chip can be used to directly influence the amount of trace data being generated. The logic should be programmed so that only trace information which is relevant to the code-coverage analysis is being generated. To illustrate this point, the following two examples are provided.

ETM/PTM: Optimal Configuration

ETM and PTM are different implementations of the core trace logic on the ARM/Cortex architectures.

The ETM can be configured so that trace information is produced only for the instructions executed by the program. Information about the read/write operations is not needed for code-coverage. By default the PTM only generates information about the program flow. Therefore the PTM does not need to be configured.

Both trace sources encode the virtual address instruc-tions. If an embedded design uses an operating sys-tem, such as Linux or Embedded Windows, virtual ad-dresses cannot be mapped unambiguously to physical

TRACE32 trace tools are available in two designs, which differ especially in relation to their features.

• 256or512MBytetracememory• USB2.xand100MBitEthernet• 80MBit/sasmaximumtransferratetohost computer• Softwarecompressionoftracedata(factor3)• Memoryinterfacewith100MHz

• 1/2/4GBytetracememory• USB2.xand1GBitEthernet• 500MBit/sasmaximumtransferrateto host computer• HardwarecompressionoftracedataforETMv3 and PTM (factor 6)• Memoryinterfacewith233MHz

PowerTrace vs. PowerTrace II

PowerTrace

PowerTrace II

Average load

Maximum load

20 4 6 8 10 GBit/s

3.2 GBit/s max. transmission rate

Cortex-R4@ 500MHz

ETMv3

Cortex-A9@ 1GHz

PTM

4 x Cortex-A9@ 1GHz

PTM

Fig.9: Atransmissionrateof3.2GB/sisgenerallyadequateforstreamingprogramsequenceinformationonthehost.

9

Statement & condition coverage

Function coverage

Detailed coverage

addresses. The trace source must also be configured, so that information is generated defining the virtual address space in which an instruction was located.

For the ARM ETM/PTM, the amount of trace data can be further reduced:

• The code-coverage analysis does not analyze orneed time information. We therefore recommend configuring the TRACE32 trace tool so that the trace data is transferred to the host without time stamps. This reduces the amount of data by a third.

• PowerTraceIIalsoprovidesFPGA-basedhardwarecompression of the trace data. This enables up to 3.2 GBit/s trace data to be transferred to the host computer.Figure9shows that this transfer rate isgenerally sufficient for streaming ETM/PTM data without any data loss.

Nexus: Optimal Configuration

Onprocessorsof theMPC5xxx/SPC5xx families thecore trace logic is implemented to the Nexus standard. To undertake code-coverage analysis, a Nexus class 2 trace cell is adequate as all you need is detail of the

program sequence on the individual core(s). If Branch History Messaging is used this can make the tracedata very compact. Compared to standard trace data a reduction by a factor of 10 is realistic. Only Power-Trace II supports streaming from the Nexus trace port.

Streaming also works for all other processors/SoCs that are supported by TRACE32 and have a trace port.

Code-Coverage for SMP-Systems

TRACE32 also supports code-coverage analysis on SMP (symmetric multiprocessing) systems. For code-coverage it must be proven that an instruction was executed, which core was responsible for running the code is irrelevant. Figure 10 shows the results of code-coveragefortwoCortex-A9MPCores.

For statement and condition coverage, if only the fail-branch of a conditional statement was run the state-ment is highlighted in yellow and marked with “not exec”. The detailed coverage lists the specifics of how often each statement or each branch of the statement was run.

Fig. 10: Code-coverage analysis for an SMP system.


The new CoreSight Trace Memory Controller pro-vides SoC designers with more design options for the trace infrastructure. TRACE32 already has sup-port for the first designs which use the TMC.

Through CoreSight, the diagnosis data needed for the analysis of SoC-internal processes is produced by ‘trace macrocells’. There are three types of trace macrocells:

• Core trace macrocells are assigned to a core and generate trace information about the instructions processed by that core. Information about process switches and load/store operations is generated depending on the design of the trace cell.

• Bus trace macrocells are firmly assigned to a bus and generate trace information on data transfers that occur on the bus.

• System trace macrocells generate trace informa-tion for hardware trigger (system event tracing) or provide diagnostic information produced by code instrumentation of the application software.

The CoreSight Funnel combines all of the trace data into a single data stream (see figure 11). This trace data stream is then either stored in an on-chip mem-ory buffer (ETB) or exported to an external tool using a trace port (TPIU). The IP for CoreSight trace being implemented today is sometimes pushed to the limit when dealing with complex multicore SoCs that con-tain many trace macrocells.

• ETB: The on-chip trace memory is often too small to record enough trace data for any meaningful future analysis. The typical size for the ETB is still between 4and16KByte.

• TPIU: System states may occur where more trace data is being generated than the trace port can output. The CoreSight design is such that trace data from the trace macrocells is only taken over if the trace data can be exported by the TPIU. If the trace data gener-ated remains in the trace macrocells for too long, the FIFOs there can overflow and important data may be lost.

The new CoreSight Trace Memory Controller should provide a solution for both of the above scenarios.

TMC as Embedded Trace Buffer

To be able to store more trace data on-chip for later analysis, the chip manufacturer can theoretically con-nect up to 4 GByte of SRAM to the Trace Memory Con-troller (see figure 12).

CoreSight Trace Memory Controller

ARM CoreSight

With CoreSight, ARM makes available an exten-sive set of IP blocks, which enables SoC designers to build a custom debug and trace infrastructure.

A single debug interface is enough to control and coordinate all cores of the SoC, as well as access all memory.

One trace interface is sufficient for providing diag-nostic data about the processes occurring within the SoCs without any impact on real-time performance.

Coretrace

Systemtrace

Bustrace

TPIU ETB

Funnel

Funnel

Trace bus (ATB)

Fig. 11: CoreSight Funnel combines all trace data produced by trace macrocells into a single data stream.

Trace Memory Controllerin ETB mode

SRAM

Trace bus (ATB)

Fig. 12: In ETB mode, the Trace Memory Controller can make up to 4 GByte of on-chip trace memory available.

11

TMC as Embedded Trace FIFO

Inspections of the trace data streams being exported by the TPIU have shown that the bandwidth of most trace ports is large enough for normal operation. Over-load, and therefore loss of trace data, only happens when peaks occur.

The Trace Memory Controller can be integrated into the trace infrastructure of the SoCs, so that the Trace Memory Controller acts as an Embedded Trace FIFO and cushions peaks in the load on the TPIU (see fig-ure 13). This ETF is designed so that no trace data loss can occur. The size of the ETF can be freely de-finedfrom512Bytesto4GBytes.

Both integrations of the Trace Memory Controller in the trace infrastructure depicted are simple examples. Of course, you can build the TMC IP block into the CoreSight system in much more complex and flexible ways.

Modifications in TRACE32

As you would expect, Lauterbach has to modify the TRACE32 software for the configuration and handling of the Trace Memory Controller. This applies especially when the Trace Memory Controller is integrated in the SoC using new, previously unsupported ways. The TRACE32 user only needs to configure the basic ad-dress for the TMC. Then all the proven trace display and analysis features can be used as usual.

TMC as Router to High-Speed Link

The idea of moving away from dedicated trace ports has long been discussed within the embedded com-munity. There are certainly several good arguments for this move.

For the first time CoreSight traces can now connect to a high-speed standard interface by using the Trace Memory Controller. USB or Ethernet interfaces are common favorites, especially as they are available in many end products. Ideally, the external trace tool will share the interface with the other connected devices.

Within the SoC, the TMC operates as Embedded Trace Router and has the task of passing on the trace data through the AXI bus for the export to the IP of the high-speed interface (see figure 14).

This new method of trace export will need completely new trace tools. Lauterbach is currently in close contact with leading semiconductor manufacturers to develop the appropriate tools for this switch in technology.

• Openforusewithallcoreswhichcanbeintegratedinto CoreSight; Lauterbach offers debug solutions for all ARM/Cortex cores and for numerous DSPs, as well as for configurable cores.

• Supportforasymmetricmultiprocessing(AMP)andsymmetric multiprocessing (SMP)

• Debugging via JTAG interface and 2-pin Serial Wire Debug

• Synchronizeddebuggingofallcores

• SupportfortheCoreSightCrossTriggerMatrix

• Supportforalltypesoftracemacrocells (ETM,PTM,HTM,ITM,STM,andmore)

• Toolsforparallelandserialtraceports

• Multicoretracing

TRACE32 CoreSight Features

Trace bus (ATB)

Trace Memory Controllerin FIFO mode

SRAM

TPIU

Fig. 13: In FIFO mode, the Trace Memory Controller can cushion load peaks on the TPIU. By doing this, trace data loss can be avoided.

Trace Memory Controllerin Router mode

SRAM

AXI

High-speed link(USB, Ethernet, ...)

Trace bus (ATB)

Fig. 14: In Router mode, the Trace Memory Controller forwards the trace data for the export to a high-speed standard interface.


Troubleshooting, performance tuning and code-coverage - all of these can be performed quickly and precisely on an embedded system if the ad-equate trace analysis is provided. In 2011, Lauter-bach explored new paths to enable optimized trace analyses for the Cortex-M3/M4 processors.

Combining ETM and ITM

For Cortex-M3/M4 processors, trace information can be generated from two different sources (see fig-ure 17). The ETMv3 generates information about the executed instructions. The ITM generates information about the performed read/write accesses assisted by the Data Watchpoint and Trace Unit (DWT).

The ITM trace packages for read/write accesses con-tain the following information: data address, data value, program counter.

Through analysis of the program counter, the data accesses which are separately generated can be seamlessly integrated into the program sequence (see

figure15),whichinturnleadstosignificantlysimplererror location. The cause of an error such as an incor-rect data value being written into an address can be easily found if the write accesses are embedded into the overall program trace.

OS-Aware Tracing

If an operating system is running on the Cortex-M3/ M4, task switch information becomes essential for the trace analysis.

Intelligent Trace Analyses for Cortex-M3/M4

Instruction flow with task switches (ETM&ITM)

Timing diagram for task switches (ITM) Timing diagram for task MIPS (ETM&ITM)

Call tree for task "sens1" (ETM&ITM)

Fig. 16: Through the combination of ETM and ITM trace data, extensive trace analysis can be provided for the eCos operating system.

Instruction flow with data accesses (ETM&ITM)

Fig.15: BycombiningETMandITMtracedata,read/writeaccessescanbeintegrated seamlessly into the program sequence.

13

In order to receive information about task switches the following method can be used: Trace information on the write cycle in which the kernel writes the identifier for the current task on the corresponding OS variable can be generated using the ITM. As described above the write access information can be integrated seam-lessly into the program flow trace. This improves the readability of the trace listing (see figure 16). The inte-gration of the task switch into the program sequence also forms the basis for the runtime analyses shown in the figure 16.

Three Recording Modes

To record the trace information generated by the Cortex-M3/M4 processors, Lauterbach supports three modes:

• FIFO mode:Storingtheinformationinthe128MBytememory of the TRACE32 CombiProbe.

• STREAM mode: Streaming the information to a hard-disk on the host computer.

• Real-time Profiling: The trace information is streamed to the host computer and analyzed during runtime.

For the first two recording modes, the trace informa-tion is collected and the trace analysis is undertaken after recording is completed.

Each recording mode has its own features. FIFO is the most commonly used mode. It is quick and usually all that is needed for error location and the runtime analy-ses.

The ETMv3 implemented on Cortex-M3/M4 proces-sors has neither a trigger nor a trace filter. It is not possible to select for recording only those program segments that are needed for troubleshooting. This can mean trace data might have to be collected for a relatively long period in order to cover the area needed for analysis. In this case the STREAM mode can be the best option. The STREAM mode, however, places high demands on the debug environment:

• Thelargeamountofdatathatresultsfromstream-ing requires a 64-bit TRACE32 executable. This is needed to allow the address range for the large number of trace entries that will be collected.

• The transfer rate between CombiProbe and hostcomputer must be fast enough to stream all trace datawithoutadataloss.The128MBytememoryofthe CombiProbe is used to cushion load peaks from the trace port (TPIU).

Real-time Profiling is particularly suitable for perform-ing statement and condition coverage. The coverage analysis can be followed live on the screen and the test results are visible immediately (see figure17). “ok”marked lines are already covered.

Cortex-M3/M4 Core

Formatter

DWT4 hardware watchpointson load/store operations

ITMInstrumentation Trace

Macrocell

ETMv3Instruction flow

only

TPIUTrace Port Interface

Unit

Statement coverage on running system

Function coverage on running system

TRACE32CombiProbe

Fig. 17: Real-time profiling enables code-coverage analysis to be followed live on the screen

TPIUTrace Port Interface

Unit

TRACE32CombiProbe


It is now common to perform simulation and verifica-tion of designs before committing to hardware. This is why tools such as MATLAB® and Simulink® have made inroads as development software into the control engineering market. It can save a lot of time and effort if the control loop can be tested for the effects of many variables before finalizing the design.

So what is the next step, after the control algorithm has beenfoundthroughsimulation?Howisthissolutionin-tegrated into the control hardware? For this, Simulink enables you to generate code automatically. But can you be sure that the program behaves the same way on the control hardware as in the simulation?

Verification Approach

The Institute of Flight System Dynamics at Technische Universität München came up with an interesting solu-tion during development of a flight control system for a Diamond DA42 (see figure 20).

After the control algorithms had been created and functionally tested with Simulink, the corresponding program code for the processor of the control hard-ware was generated from the control blocks using the Embedded Coder. Using a TRACE32 debugger, the generated code was loaded into the control hardware and functionally tested in-situ.

To determine the level of deviation between simulated control behavior (red path) and real control behavior (green path), but above all to confirm the numeric accu-racy of the control hardware, a Processor-In-the-Loop simulation (PIL)waschosen (seeFigure18).Essen-tially, the PIL simulation is based on the specially de-veloped Simulink blocks “PIL Send” and “PIL Receive”. These were designed to implement communication between Simulink and the TRACE32 Remote API.

In each run through, the flight control algorithm per-forms a single calculation step of the discrete time flight control on the target hardware. The Simulink model provides the necessary input parameters. The values calculated are returned to the Simulink model and there supply the aircraft model. In a parallel calcu-lation, the simulated flight control algorithm computes the same values. The difference is then used to com-pare the two results.

The testing in the stand resulted in an absolute de-viation of 10-13 – a high level of consistency that was elegantly and easily proven with this approach.

For more information about the project of the Institute of Flight System Dynamics at the Technische Universität München, go to www.lauterbach.com/intsimulink.html.

TRACE32 Integration for Simulink®

At the Embedded World show February 2012 in Nuremberg/Germany, Lauterbach will be presenting an even closer coupling between Simulink and Lauter-bach’s TRACE32 debuggers.

Lauterbach has used the property of the Simulink code generation that the code block always begins with a comment line which contains the name and model path for the block. These comment lines are available after the generated code has been loaded into the

Simulation and Reality Draw Closer Together

Flight control algorithm

Target

Flight testpattern

-Deviationprotocol

Aircraftmodel

Flight controlalgorithm

PILSend

PILRcv

Flight control algorithm

TRACE32 Remote API

Simulink® model

Fig.18: Therealcontrolbehavior (greenpath)and thesimulatedcontrolbehavior (red path) are compared.

15

TRACE32 PowerView Simulink®

Fig.19: TheblockbelongingtotheselectedsourcecodelineismarkedinSimulink.

Fig. 20: Diamond DA42 (Source: www.diamond-air.at)

TRACE32 debugger. These lines allow a simple cor-relation between the Simulink block and the lines in the source code.

Navigation from Simulink® to TRACE32

A global TRACE32 menu and TRACE32 menus for blocks and signals are integrated into Simulink as ‘Simulink Customization Menus’. The TRACE32 debugger can be controlled from Simulink with the help of these menus. The following functions are available:

• ShowblockcodeinTRACE32• OpenTRACE32VariableWatchWindowforsignals• LoadSimulinkbuildtotheTRACE32debugger• Setandmanageblock/signalbreakpoints• Startandstopprogramonthecontrolhardware

Navigation from TRACE32 to Simulink®

Selecting a section of source code in the TRACE32 debugger marks the corresponding block in Simulink (seeFigure19).

Future

When Simulink Release 2012a is available, fur-ther TRACE32 functions will be possible in Simulink. Lauterbach will use the improved functionality of the Simulink rtiostream API to integrate a PIL simulation, data logging, and parameter tuning.

MATLAB® and Simulink® are registered trademarks of The MathWorks, Inc.

www.lauterbach.com16

A new TRACE32 extension for the Atom™ De-bugger provides a complete debug capability of Insyde’s H2O UEFI BIOS.

UEFI is the successor to the traditional PC BIOS. It functions as an interface between firmware and oper-ating system managing the boot process. From power-on to takeover by the operating system, UEFI runs through various, clearly distinguished phases (see figure 21).

As it is a JTAG-based tool, TRACE32 allows debug-ging to start from the reset vector.

In each phase of the boot process, the PowerView user interface provides special windows which show UEFI specific information. Functions and prepared scripts enable debugging of dynamically loaded drivers starting from the first instruction. For more information about the new UEFI extension, go to www.lauterbach.com/uefi.html.

UEFI BIOS Debugging with TRACE32

Board Init

Device,Bus, orService Driver

ChipsetInit

?

OS-AbsentApp

Transient OSEnvironment

Transient OSBoot Loader

Boot ServicesRuntime Services

Final OSEnvironment

OS-PresentApp

SecurityPre-EFI

InitializationEnvironment

DriverExecution

Environment

BootDevice

Selection

TransientSystem Load Runtime Afterlife

veri

fy

security

Power on Platform initialization OS boot Shutdown

DXEDispatcher

CPUInit

PreVerifier

Final OSBoot Loader

Boot Dispatcher

Fig. 21: System boot process with UEFI.

WORLDWIDE BRANCHES

•USA•Germany

•France •UK •Italy •China •Japan

Represented by experienced partners in all other countries

16

•USA•

Represented by experiencedpartners in all other countries

KEEP US INFORMED

If your address haschanged or if youno longer want to be on our mailing list, please send us an e-mail to:

[email protected]

KEEP US INFORMED

Security researchers warn that at-tacks against supervisory controland data acquisition (SCADA) sys-

tems could cripple critical infrastructureservices. SCADA networks encompasscomputers and applications that per-form key functions in providing essen-tial services and commodities such aselectricity, natural gas, gasoline, water,waste treatment, and transportation—all part of the nation’s critical infra-structure. The first step in safeguardingour critical infrastructures is in identify-ing system vulnerabilities.

Even though SCADA systems havebeen used for a decade to monitor andcontrol critical equipment at powercompanies, manufacturing facilities, wa-ter treatment plants, and even buildingautomation, not until recently has thefocus been on security and the vulnera-bilities of such systems.

SYSTEM VULNERABILITIESDigital Bond, a consulting firm special-izing in control-system security, hasfound that the latest vulnerabilitiesmostly exist in free or low-cost Win-dows-based engineering work-stationsthat are used as graphical user interfacesto back-end control systems. SCADAsystems such as Siemens are deployedwidely in critical infrastructures.

Siemens reported last year that aStuxnet worm was released for the pur-pose of stealing industrial secrets, dis-turbing operations and infecting some14 nuclear plants. The worm leveraged apreviously unknown Windows vulnera-bility (now patched) that allowed it tospread from computer to computer,typically via USB sticks. In today’s times,it has become increasing apparent thatattacks on vulnerable SCADA systemscan wreak havoc.

Cambashi analyst Christine Easter-field agrees and advises that you “con-sider operational procedures, staff, andother factors. For example, staff need tobe trained in secure practices and madeaware of the risks to which they may ex-pose critical systems.”

Blue Pillar, a provider of energy as-sets management software, confirmedCambashi’s operational procedures andstaff concerns and believes that with theexception of the IT staff, the operationaland energy management staff does noteven have energy asset security on theirradar as a security concern. The reality isthat they either rely 100% on physicalsecurity or they have to rely on the unse-cured and open industrial automationimplementations running ModbusTCP-IP throughout their networks.

According to Kyle Zeronik, BluePillar’s VP of Information Technology,it’s critical to secure the SCADA fromtop to bottom. “We secure critical pow-er infrastructures right down to secur-ing the messaging within our architec-ture to limit the conversations to onlythe devices with appropriate creden-tials and authorizations. We managesite-site communication including In-

ternet security and encrypted messagestransmitted over secure channels. De-vice level communications is managedvia 256-bit AES (FIPS-197 certified)encryption.”

SECURITY CHECKS AND BALANCESAny facility with a connection to theSCADA system should conduct a physi-cal security survey and inventory accesspoint check. It’s imperative to identifyand assess any source of information in-cluding remote telephone, computernetwork, and fiber optic cables thatcould be tapped; radio and microwavelinks that are exploitable; computer ter-minals that could be accessed; and wire-less local area network access points.The goal is to identify and eliminate sin-gle points of failure.

The National Infrastructure Protec-tion Plan Program works with severalgovernment agencies in the area of cy-ber security to ensure the integrity andavailability of the nation’s cyber infra-structure. In addition, the National Su-pervisory Control and Data Acquisition(SCADA) Test Bed is a DOE Office ofElectricity Delivery and Energy Reliabil-ity (OE)-sponsored resource to help se-cure our nation’s energy control sys-tems. It combines state-of-the-artoperational system testing facilities withresearch, development, and training todiscover and address critical securityvulnerabilities and threats to the energysector. ■

Eric Marks is the industry practice leaderfor PricewaterhouseCoopers. He holds abachelor of mathematics in computer sci-ence from the University of Waterloo andan MBA in strategic management andmarketing from The Wharton School ofthe University of Pennsylvania.

Not in Kansas anymore: Securing SCADA

analyst’scorner

SCADA is not secure, butwhat can be done toestablish security?

!


This excerpt is from a longer article atwww.eetimes.com/4238057.


ESC classroom

David Kalinsky is a teacher ofintensive short courses on embed-ded systems and software develop-ment for professional engineers.One of his popular courses is“Introduction to Software Securityfor Embedded.” His courses arepresented regularly in open-classformat at technical trainingproviders in international locationssuch as Munich, Singapore,Stockholm, and Tel-Aviv, as well asin his “home market” of the USA.See www.kalinskyassociates.com.

Speaker

Iwas preparing for a trip to the Eastern European citywhere my parents had lived as children. I had neverbeen there. I googled the name of the city, and wasquickly led to a story that was surprising and chilling:A high school student there had modified a TV remotecontrol so that it could control the city’s tram system—thus converting the urban railways into his own

Even if your device is not connected tothe Internet, you need to protect it

from malicious attacks. Here are somesimple protections you can institute tomake your system more impenetrable.

BY DAVID KALINSKY

giant model train set. While switchingtracks using his infrared gadget, this kidcaused trams to derail. Twelve peoplewere injured in one derailment.1

Recently, new terms like Stuxnetand Duqu have entered our lexicon.Embedded systems including those thatdo supervisory control and data acqui-sition (SCADA) are under relentless se-curity attacks.

Many embedded software develop-ers feel that embedded systems securi-ty should be handled at the systems-engineering level or by the hardwarethat surrounds their software. And in-deed many things can be done at those

levels, including:

• Secure network communicationprotocols.

• Firewalls.

• Data encryption.

• Authentication of data sources.

• Hardware-assisted control-flowmonitoring.

But these traditional techniquesaren’t enough, as was frighteningly de-scribed at last year’s DesignCon East2011 talk “Strong Encryption and Cor-rect Design are Not Enough: ProtectingYour Secure System from Side Channel

Security fundamentals for embedded software


Attacks.” The speaker outlined howpower consumption measurements,electromagnetic leaks, acoustic emis-sions, and timing measurements cangive attackers information they canuse to attack your embedded device.

Clearly then, system-level andhardware defenses are not enough.Most security attacks are known to ex-ploit vulnerabilities within applicationsoftware. Vulnerabilities are intro-duced into our embedded systems dur-ing software design and development.Since system-level and hardware defens-

es against security attacks are far fromperfect, we need to build a third line ofdefense by dealing with vulnerabilities inour application software.

While our software line of defensewill surely be less than perfect, weneed to work on that line of defensewith the immediate objective of reduc-ing the size of the “attack windows”that exist in our software. The veryfirst step in doing this is to try to thinklike an attacker. Ask how an attackercould exploit your system and yoursoftware in order to penetrate it. Youmight call this a threat analysis. Usethe results to describe what your soft-ware should not do. You might callthose abuse cases. Use them to planhow to make your software better re-sist, tolerate or recover from attacks.

Don’t forget that our attackers havea big advantage when it comes to em-bedded systems: Most embedded soft-ware has severe execution time con-straints, often a mixture of hardreal-time and soft real-time tasks. Thiscoaxes us to design application softwarethat is “lean and mean,” by reducing toa minimum intensive run-time limitchecking and reasonableness checking(for example, invariant assertions) inorder to meet timing requirements.Our attackers have no such executiontime constraints: They are perfectlyhappy to spend perhaps weeks ormonths researching, preparing, andrunning their attacks—possibly tryingthe same attack millions of times in thehope that one of those times it mightsucceed, or possibly trying a differentattack each day until one hits an open“attack window.”

HOW CAN ATTACKERS ATTACK VIAOUR OWN SOFTWARE ?Quite often embedded software develop-ers dismiss the issue of embedded soft-ware security, saying: “Hey, our devicewill never connect to the Internet or toany other external communication link.So we’re immune to attack.” Unfortu-nately, this is naïve and untrue. I’d liketo present a counterexample:

Many embedded devices use analog-to-digital-converters (ADCs) for dataacquisition. These ADCs may be sam-pled on a regular timed basis, and thedata samples stored by application soft-ware in an array. Application softwarelater processes the array of data. But anattacker could view this in a totally dif-ferent way: “What if I fed the ADC withelectrical signals that, when sampled,would be exactly the hexadecimal repre-sentation of executable code of a nastyprogram I could write?” In that way, theattacker could inject some of his soft-ware into your computer. No network orInternet needed.

Seems like a lot of work to build an“ADC Code Injector” device just for thispurpose. But the attacker might not bejust a high-school kid. He might be a bigindustrial espionage lab, or a large, well-funded team working at the nationallaboratory of a foreign government.

Now, how could he get your proces-sor to execute his program that he’s in-jected? He might gamble that your soft-ware stores the ADC data array on astack (perhaps using alloca() or mal-loca() ). If his luck is good, he couldcause an array overflow, possibly bytoying with the hardware timer thatcontrols the ADC data sampling. A typ-ical normal stack layout is shown inFigure 1.

If the attacker succeeds in causing anarray overflow, the stack could becomecorrupted, as shown in Figure 2 below.Note that “return address” was stored onthe stack at a location beyond the end ofthe array.

If the attacker plans the corruptionjust right, the overflow will reach the lo-cation on the stack where the current re-


ESC classroom

Typical normal stack layout.

Figure 1

Framepointer

(FP)

Stackpointer

Memorygrowth

Stackgrowth

Previousstackframe

Arguments

Return address

Saved FP

ADCdata[256]

Stack is corrupted after array overflow.

Figure 2

Previousstackframe

Arguments

Corruptedreturn address

Attack code

If an attacker succeeds inbreaking into software run-ning at a high level of privi-lege, immediately yourattacker will be operating ata high level of privilege too.

!!!


turn address was stored. This can beused to insert into this stack location apointer to his own code. As a result,when “Return Address” is used by yourcode, control will pass to the attacker’scode. Suddenly his code is executing onyour processor, instead of your code.

This is called a stack smashing attack.Please note that it was done in this ex-ample without an Internet connection,and without a connection to any exter-nal communication line.

Of course, it could have been helpfulfor our attacker to have the source codefor your embedded software—as a dis-gruntled ex-employee might. But I thinka patient and resourceful attacker teamcould develop this kind of attack evenwithout your source code.

Can you think of an easier way foran attacker to develop an attack onyour current project ?

WHAT’S SW DEVELOPER TO DO?During embedded systems software de-sign, you can enhance software securityby keeping several fundamental ideas inmind:2

Mindframe #1: Distrustful decompositionSeparate the functionality of your soft-ware into mutually untrusting chunks, soas to shrink the attack windows intoeach chunk. (In embedded software, wesometimes call these chunks processes orsubsystems or CSCIs.)

Design each chunk under the as-sumption that other software chunkswith which it interacts have been at-tacked, and it is attacker software ratherthan normal application software that isrunning in those interacting chunks. Donot trust the results of interactingchunks. Do not expose your data to oth-er chunks via shared memory. Use or-derly inter-process communicationmechanisms instead, like operating sys-tem message queues, sockets, or TIPC(Transparent Inter-process Communica-tion). Check the content you receive.

As a result of mutually untrustingchunking, your entire system will not

be given into the hands of an attackerif any one of its chunks has been com-promised.

Mindframe #2: Privilege separationKeep to a minimum the part of yourcode that executes with special privilege.

Think about it for a moment: If anattacker succeeds in breaking into soft-ware that’s running at a high level ofprivilege, immediately your attackerwill be operating at a high level of priv-ilege too. That’ll give him an extra-wide open “attack window” into yoursystem.

So let’s avoid running applicationsoftware in kernel mode, or mastermode, or supervisor mode, or whateveryour particular CPU architecture may

call it. Leave that mode for operating sys-tem use only. Run your application soft-ware strictly in user mode. This will en-list your CPU hardware in efforts to limityour software’s attack window.

Mindframe #3: Clear sensitive informationClear every reusable resource whenfreeing it.

Think about it: After you’ve re-leased the resource, be it a RAM bufferor a software-hardware interface dataregister, the next user of the very sameresource might be an attacker. Embed-ded system attackers enjoy “phishing”these resources, just as much as Inter-net attackers enjoy phishing. Wouldn’tthey be overjoyed to read whatever datayou had been working on in the buffer,or to read the data you’ve just given tohardware for output!

Some of us would say theseare bugs. But I’d like to callthem vulnerabilities here . . .Small vulnerabilities canopen the window to hugeattacks.

!!!

Most resource release services inembedded environments simply markthe newly freed resource as “available.”They leave the old information con-tained in the resource potentially visi-ble to new users, trusting the new userto over-write the old content ratherthan reading it. This is done since it’smuch faster than explicitly nulling outthe resource.

So when an application is done witha resource, it’s up to the application toprepare for releasing the resource by firstzeroing out each and every:

• Heap buffer, memory pool buffer,memory partition segment.

• Statically-allocated memory buffer.

• Released stack area.

• Memory cache.

• File in a file system.

• Hardware interface data register,status register, control register.

WHAT CAN BE DONE DURINGCODING?During embedded systems program-ming, developers can augment softwaresecurity by avoiding a number of com-mon software security vulnerabilities.

Some of us would say these arebugs. But I’d like to call them vulnera-bilities here, to emphasize that sometiny software “defect” that might betoo minor even to be called a bug—might be just what an attacker is look-ing for in order to mount his attack onyour embedded system. Small vulnera-bilities can open the window to hugeattacks.

Vulnerability #1: Buffer overflowFar and away, the most widespread secu-rity vulnerability in C-language codingis buffer overflow. It could be as simpleas writing into element number 256 of a256-element array.

Compilers don’t always identifyout-of-bounds buffer access as a soft-ware defect. Yet buffer overflow canlead to more serious consequences,such as stack smashing that was dis-cussed earlier, code injection, or evenarc injection—by which an attackerchanges the control flow of your pro-gram by modifying the return addresson stack. In arc injection, an attackerdoesn’t even have to inject any code,and he can jump to an arbitrary func-tion in existing code, or bypass validitychecks or assertions.

Here’s an example of a buffer over-flow attack: An embedded device is re-quired to measure the temperature ofwater in a swimming pool and to displaya histogram showing the percentage oftime that the water is at various temper-atures. The software developer creates anarray of 100 positive integers, each ele-ment corresponding to one degree Cel-sius. Element 0 for 0°C. Element 1 for1°C, etc. Each time the temperature sen-sor makes a water temperature measure-ment, the corresponding element of thearray is incremented by 1.

Remember, this is a swimming poolto be used by humans. So the program-

mer feels safe and secure in designinghis temperature array with lots and lotsof room beyond the range of watertemperature values that a human bodycan tolerate.

Until one day, an attacker pulls thetemperature sensor out of the waterand heats it up using a cigarette lighter.As soon as the sensor measures a valuegreater than 100°C, the histogram up-

date software corrupts an address inmemory beyond the end of the temper-ature array. If there’s data there, the at-tacker will have corrupted the data. Ifthere’s machine code there, the attackerwill have corrupted the executable soft-ware. In either case, this is a damagingattack. Please note (once again) that itwas done without an Internet connec-tion, and without a connection to anyexternal communication line. Just a cig-arette lighter.

How can we avoid buffer overflows?This vulnerability is so widespread (andso widely sought-after by attackers),that a multipronged approach is best:prevent, detect, and recover. Preventbuffer overflows by careful input vali-dation: check that a temperature sensoris reporting a value within bounds. Inour swimming pool example, explicitlycheck that it’s not reporting a tempera-ture that corresponds to ice or to super-heated vapor (> 100°C).

Prevent buffer overflows also byavoiding dangerous library functions(like gets() ) and exercising extra carewith others (like memcpy() ).

Detect buffer overflows by using theidea of “paint”: Extend the bufferslightly at both ends. Fill the extension


ESC classroom

Please note (once again)that it was done without anInternet connection, andwithout a connection to anyexternal communicationline. Just a cigarette lighter.

!!!

ESC 2012 CLASSESDAVID KALINSKY

Dave Kalinsky will teach fourclasses at ESC/DESIGN West inMarch, 2012. Also look for class-es he will be teaching atESC/DESIGN East in Boston thisyear.

ESC-101: Software Design forMulticore Systems—2012 EDITION8:00 AM to 12:00 PM,March 26

ESC-402: Is Static CodeAnalysis Ready for Real-time?3:15 PM–4:15 PM, March 29

Speaker

areas with unusual content I call“paint”; for example, a trap instructionin your processor’s machine language.Then check the paint repeatedly at runtime. If the paint has been over-written,you’ve detected a buffer overflow.

Vulnerability #2: Pointer shenanigansIf an attacker can modify a data pointer,then the attacker can point to whereverhe likes and write whatever he likes. If anattacker can over-write a function point-er, the attacker is well on his way to exe-cuting his code on your processor.

Vulnerability #3: Dynamic memory al-location flawsIt’s so easy to write defective code fordynamic memory allocation, that theuse of dynamic memory allocation isforbidden in many embedded aero-space and safety-critical systems. Ofcourse, attackers are eager to searchout these defects, as they also representgolden opportunities for them to violate the security of an embeddedsystem.

Common flaws include double-free-ing, referencing of freed memory, writ-ing to freed memory, zero-length alloca-tions, and buffer overflows (again).

A flaw that is particularly sensitivein embedded software, is neglecting tocheck the success or failure of a mem-ory allocation request. Some memoryallocators will return a zero instead ofa pointer to a memory buffer, if theyrun out of available memory. If appli-cation software treats this zero as apointer, it will then begin writing towhat it thinks is a buffer starting atmemory address zero.

Many an attacker would be happyto have your software do this. Attackersknow that embedded systems tend tobe tightly memory constrained. Theywill try to make a system run out ofmemory by doing whatever they can toforce your memory allocator to allocatemore memory than usual—perhaps byleaking memory, possibly leaking it intosome code they’ve injected. They mayalso try to flood your data-acquisition

system with higher than normal vol-umes of data or higher rates of data—in the hope that the avalanche of datawill exhaust your memory capacity.And then … if your software asks for abuffer but neglects to check for alloca-tion failure, it will begin writing abuffer at address zero—trampling uponwhatever was there. For example, ifyour interrupt enable/disable flags hap-pen to be at that address, this could

turn off the connection between soft-ware and peripheral hardware inter-faces. Essentially, this could dis-embedyour embedded system.

Vulnerability #4: Tainted dataData entering an embedded systemfrom the outside world must not betrusted. Instead, it must be “sanitized”before use.

This is true for all kinds of datastreams as well as even the simplest ofintegers. Attackers are on the lookout forextreme values that will produce abnor-mal effects. In particular they’re lookingfor unexpected values, like situationswhere a digital microprocessor wouldgive a different result from what a hu-man would calculate using pencil andpaper. For example, an integer ‘i’ hap-pens to have the value 2,147,483,647. If Iwere to add 1 to this value in a back-of-the-envelope calculation, I’d get+2,147,483,648. But if my microproces-


ESC classroom

Free Evaluation Kits: www.smxrtos.com/evalFree Demos: www.smxrtos.com/demo

You’ve found it. Our software is built torun right out of the box—no integrationrequired—and we provide full support forpopular tools. With Micro Digital you have low-cost, no-royalty licensing, full source code, and direct programmer support. So get your project off to the right start. Visit www.smxrtos.com/processors today.

Looking for the right software foryour processor?

SMX® RTOSBSPsDevice DriversKernel AwarenessSimulator

TCP/IPFAT File SystemFlash File SystemGUIC++ Support

USB DeviceUSB HostUSB OTGWiFiFloating Point

www.smxrtos.comR T O S I N N O V A T O R S

ARM • Cortex • ColdFire • PowerPC • x86 • IAR EWARM • CrossWorks • GCC • CodeWarrior

Data entering an embeddedsystem from the outsideworld must not be trusted.It must be “sanitized”before use. This is true for even the simplest ofintegers.

!!!

sor were to execute i++, it would get -2,147,483,648 (a large negative num-ber). It wouldn’t take long for a cleverattacker to leverage this kind of quirkinto some kind of havoc in an embed-ded system.

A useful technique for data saniti-zation is called white listing. It involves

describing all possible valid values for agiven piece of data and then writingcode that only accepts those values. Allunexpected values are viewed as “taint-ed” and are not used.

MORE TO EXPLOREClearly the concepts of software securi-ty for embedded systems are not limit-ed to three design “mindframes” and

four coding “vulnerabilities.” Attackersare a creative bunch, always findingnew ways to threaten the security ofour software and systems. The story ofsoftware security is incessantly chang-ing. One way to keep up is to visit awebsite called CWE—Common Weak-ness Enumeration (http://cwe.mitre.org/) that keeps a continually updatedlist of software weaknesses forsecurity.3 Most of them are as relevantfor embedded software as for non-em-bedded software. I’d start at their “Top25 Most Dangerous Software Errors”list, which is updated each year.

We’ve seen several ways that a de-termined attacker can undermine anembedded system—even one withoutan Internet connection, and without aconnection to any external communi-cation line. We’ve also seen that embed-ded software designers and program-mers can contribute an additional layerof defense against malicious attacks, be-yond what can be done at system-leveland in hardware. The embedded soft-ware community needs to be alert tothe special “mindframes” and “vulnera-bilities” involved in this new challengeto our embedded systems. ■

David Kalinsky is director of customereducation at D. Kalinsky Associates—

Technical Training, a provider of inten-sive short courses on embedded systemsand software development for profes-sional engineers. He is a popular lectur-er and seminar leader on technologiesfor embedded software in North Ameri-ca, Europe, and Israel. In recent years,David has built high-tech training pro-grams for a number of Silicon Valleycompanies, on various real-time operat-ing systems and other aspects of soft-ware engineering for the developmentof real-time and embedded systems. Be-fore that, he was involved in the designof many embedded medical and aero-space systems. David holds a Ph.D. innuclear physics from Yale University.Contact him through www.kalinskyasso-ciates.com.

ENDNOTES1. “Daily Telegraph” newspaper London

UK, “Schoolboy hacks into city’s tramsystem.” The city: Lodz, Poland. Thedate: 11 Jan. 2008.

2. Dougherty, C., K. Sayre, R.C. Seacord, D.Svoboda, and K. Togashi. “Secure DesignPatterns,” CERT Program, Software En-gineering Institute, Carnegie MellonUniversity, Pittsburgh PA, Technical Re-port CMU/SEI-2009-TR-101, ESC-TR-2009-010.

3. CWE’s “Common Weakness Enumera-tion,” The MITRE Corporation, BedfordMA, cwe.mitre.org.


ESC classroom

TRACE32®

A determined attackercan undermine an embedded system—evenone without an Internetconnection, and without aconnection to any externalcommunication line.

!!!

Embedded systems designers can protect sensitive data that’s ona device’s hard drive (data-at-rest) by using encryption techniques.

Enhance system securitywith better data-at-rest

encryptionBY DAVID KLEIDERMACHER, GREEN HILLS SOFTWARE

I


feature

targets, architectural design plans, per-sonal identification information (name,address, Social Security number), andmedical records—including blood-testresults and a cancer diagnosis.

When asked whether this could beprevented, one copier company said thatcustomers could purchase a $500 optionthat will erase copied images from thehard drive after use. Give the guy whowrote those couple lines of code a bonus!

Another obvious solution to thisproblem is data-at-rest protection.Data-at-rest protection is a when datastored on a device and not in transit,known as data at rest, is either encrypt-ed or follows certain protocols that in-clude encryption to protect the datafrom unauthorized access. The storage

media for an embedded system may in-clude hard disk drives, flash memory,and attached USB thumb drives. As wit-nessed by the photo copier story, seem-ingly benign, mundane office equip-ment is often vulnerable and notprotected. On the other hand, manymodern embedded systems do have en-crypted storage-protection require-ments, driven by intellectual propertyprotection, digital rights management,sensitive customer information, andmore. Compliance regulations in certainindustries require that sensitive storeddata be protected with appropriate data-protection protocols that include en-cryption. See sidebar for examples.

This article discusses approaches forprotecting data-at-rest.

n 2010, the television network CBS aired a program demonstrat-ing how discarded office copiers are gold mines for private infor-mation, trivially harvested from disk drives within the machines.1

From copiers randomly selected from a used copier warehouse,investigators recovered lists of wanted sex offenders, drug-raid

CHOOSING THE STORAGE LAYER As shown in Figure 1, developers maychoose from multiple layers in the data-storage stack to apply data-at-rest pro-tection protocols.

Hardware layer: With full-disk en-cryption (FDE), the entire medium usedfor storage is encrypted. All the datathat goes on the storage medium is en-crypted, including certain hidden files,such as the operating system’s tempo-rary files and swap space. The advan-tage is such files are not exposed. How-ever, the drive itself is not encrypted,leaving the master boot record exposed.

When FDE is handled within themedium peripheral itself, it’s referred toas a self-encrypting drive (SED). SEDs arecommon in the laptop market. The ad-vantage of SEDs for the embedded sys-tems developer is that little or no new

software must be written to take advan-tage of the data-protection facilities. En-cryption is performed with specializedhardware within the storage device, of-floading the main embedded applica-tions processor. If self-encrypting stor-age media is feasible, it’s an excellentchoice due to ease of use, excellent per-formance, and the ability to hide thestorage encryption key from the mainapplications processor and memory. Un-fortunately, many embedded systemswill be unable to use the available stand-alone SED products due to form-factorlimitations.

Block manager layer: Encryptioncan be performed at the next level up,the device-management layer, typicallya block-oriented driver. Protection atthis level may cover the entire manageddevice (FDE). The performance impli-cations of this approach vary. If the em-bedded platform contains a symmetricencryption accelerator, the overhead islikely to be reasonable, while a purelysoftware cryptographic implementationmay cause a dramatic loss in perform-ance. Embedded systems developers canarchitect the encryption facilities suchthat the device driver calls out to genericmedium block encryption routines, en-suring that software is easier to main-tain across different generations of theembedded product that may use differ-ent types of storage.

File system layer: The next candi-date for data-at-rest protection is thefile system. The major advantage of im-plementing storage protection at thefile system layer is to provide finergranularity over the choice of informa-tion that requires storage confidentiali-ty. This is especially important if en-

cryption is performed in software withminimal or no hardware acceleration.Depending on the file system imple-mentation, developers may be providedoptions for encryption at the volumelevel or at the individual file level.

Applications layer: Finally, applica-tions can add their own data protec-tion, either using underlying file-systemencryption features or a custom imple-mentation. For example, an audit log-ging application can encrypt its auditrecords prior to calling the standard filesystem output functions.

For volume, file, or application-lev-el data protection, developers can em-ploy separate keys for these groups ofdata rather than a single key for the en-tire system. This is a sensible applica-tion of “least privilege” principles.

Developers resorting to custom, ap-plication-level approaches will also needto design their own key-managementsystem, whereas users of encrypting filesystems or SEDs can use the key-man-agement framework provided by theproduct supplier.

WHICH ENCRYPTION ALGORITHM?Data-at-rest presents some uniquechallenges for encryption algorithmsrelative to network security protocols.

For data-at-rest protection, an en-cryption algorithm must be performedwithout adding additional storage space:A plaintext media block is encrypted inplace, generating a ciphertext block ofthe same size. The most basic encryptionmode, electronic code book (ECB),would provide this memory conserva-tion but is not suitable for data-at-restencryption since any two same plaintextblocks will encrypt to the same cipher-


feature

Data-at-rest protection choices by layer.

Figure 1

Example: Encrypted mail folders

Example: Encrypted file system (EFS)

Encrypting device driver

Self-encrypting drive

Data-at-rest protection choic

Application

File system

Block manager

Figure 1

Hardware

Tweakable block cipher overview.

Figure 2

Block encryption algorithme.g. AES-ECB

TweakKey

Plaintext block

Ciphertext block

COMPLIANCE REGULATIONS

• Medical sector: the HealthIndustry Portability and Ac-counting Act (HIPAA) requiresthat patient data stored withinmedical devices is protected.

• Financial sector: the Pay-ment Card Industry (PCI) datasecurity standard (PCI DSS) re-quires the protection of creditcard information within finan-cial processing systems.

• Government and security-conscious enterprises:Data-at-rest protection withinsmartphones and tablets is a re-quirement if handhelds areused for the processing of sen-sitive information.

text, making it easy for an attacker tofind patterns in the data and potentiallyderive information. We must considerother modes, most of which require aninitialization vector (IV). However, toavoid space expansion, the data-protec-tion system must include a means forimplicitly deriving this IV.

Implicit IV derivation poses a sur-prisingly difficult challenge for commonencryption modes. Many modes requireuniqueness: The same IV must never bereused for a particular key. For example,with counter mode, a predictable countercan be used, but the same number cannever be repeated for a given key. For ci-pher block chaining (CBC) mode, aunique and unpredictable number mustbe used. Network security protocols havethe freedom to generate the IV and sendit along as part of the transmitted data;for the Advanced Encryption Standardwith CBC (AES-CBC), each transmissioncan generate a new random number forthe IV and transmit this IV to the receiv-er. But for data-at-rest, we have no roomto store the IV for subsequent decryption.

The obvious source for an implicitIV would be the sector number and off-set for a particular data block. Using thiscombination provides every disk blockwith a unique input value. However, asdata is read and written over time, thesame sector and offset are reused for thesame key. This implies a serious weak-ness in the applicability of common en-cryption modes for data-at-rest protec-tion. Numerous other weaknesses ofcommon modes, especially CBC, havebeen identified when applied to data-at-rest protection protocols. ClemensFruhwirth has written an excellent pa-per discussing these weaknesses.2

TWEAKABLE CIPHERSThe good news is that cryptographershave worked diligently to address thisencryption mode challenge. Liskov,Rivest, and Wagner introduced the con-cept of a tweakable block cipher in2002.3 The basic idea of a tweakable ci-pher is to apply the IV concept to thesingle-block cipher itself rather than to achaining mode built on top of the block

cipher. As shown Figure 2, the block ci-pher converts a plaintext block to a ci-phertext block, using both the tradition-al key as well as the tweak as inputs.

The practical application of tweak-able ciphers for the data-at-rest protec-tion problem is the property that the ci-pher’s security doesn’t preclude reuse ofthe IV; thus, media sector number andblock offset within the sector provide aperfect fit for tweak selection.

XTS-AESIn 2007, IEEE’s Security in StorageWorking Group (SISWG) publishedstandard P1619.4 The IEEE P1619 stan-dard defines the XTS-AES cipher modeas a result of a thorough study of nu-merous potential tweak-based algo-rithms for use in data-at-rest protection.

This choice is further bolstered byNIST in “Special Publication 800-38E”,which approves the XTS-AES ciphermode and references its definition inIEEE P1619-2007.5 NIST has alsoamended FIPS 140-2 to include XTS-AESas an approved cipher for validation.6

The tweak algorithm found in XTS-AES is based on and almost identical tothe one originally created by notedcryptographer Phillip Rogaway, calledXEX.7 In addition to strong security,XEX (and hence XTS-AES) are also de-signed for efficiency when applied tostorage of many sequential data blocks(as is common with file storage).

The XTS-AES block cipher is depict-ed in Figure 3. Oddly this cipher requirestwice the keying material; for 128-bit se-curity, 256 bits of key must be used. Thefirst half of the key is used to process theplaintext; the second half is used to en-crypt a 128-bit representation of the sec-tor number, which acts as the primarytweak, as shown in Figure 3. The resultof this encryption is fed to a functionthat performs a Galois field multiplica-tion (implemented as a sequence of shiftsand XORs) of the encryption result witha Galois constant derived from the sec-ondary tweak, the numeric index of thedata block within the sector.

The result of this Galois multiplica-tion is used twice. First it’s added (XOR)

to the plaintext block, which is then en-crypted with the first key half. The Ga-lois result is added (XOR) again to theplaintext block encryption result to cre-ate the final ciphertext block.

Decryption is similar; however,while the AES-ECB decryption algo-rithm is used to process the ciphertext,the tweak cipher remains the same, us-ing the AES-ECB encryption algorithm.

In practice, data is stored to mediain sectors. Therefore, the block encryp-tion algorithm shown earlier must beexecuted in a loop across the entire sec-tor. Note that while XTS-AES handlespartial blocks, that part of the algorithmis often unnecessary. For example, thecommon sector size of 512 bytes will re-sult in 32 block encryptions, and mostmedia-management layers will access afull sector at a time. For such a system,given a function, xts_encrypt, whichtakes the sector number and size inbytes, plaintext block, and encryptionkey as input, the simple code sequence inListing 1 handles the sector encryption.

It’s also easy to see from this code se-quence that XTS-AES is parallelizable. Ifthe embedded system contains an AEShardware accelerator (especially one thathas direct support for XTS mode), thisimplementation should be modified totake advantage of the accelerator’s abilityto process multiple AES blocks at once.Furthermore, if the media allows for sec-tor size configurability, developers maywant to vary the sector size to see if bet-


feature

The XTS-AES data-at-rest encryption cipher.

Figure 3

GFmul

AES-ECB

Ciphertext block

Plaintext block

+

Sector number (Tweak1)

GFmul

AES-ECB

Block offset (Tweak2)

AES-ECB

+

Key1

Key2

ter throughput (potentially at the ex-pense of slightly reduced space efficien-cy) can be achieved.

When selecting data-at-rest protec-tion products, avoid legacy approachesthat use weaker modes (numerous CBC-based implementations have been com-mercialized). Employ the NIST- andFIPS-approved standards instead.

MANAGING THE KEYThe primary purpose of data-at-rest pro-tection is to ensure that information re-siding on lost or stolen media cannot beaccessed by unauthorized parties whomust be assumed to have complete phys-ical access to the disk. Thus, the symmet-ric storage encryption key must never bestored in the clear on the disk. However,it’s often necessary to store an encryptedcopy of the symmetric key on the disk(or perhaps an attached Trusted PlatformModule, if available). The key is un-wrapped for active use while the systemis executing in an authorized manner.For personal computers such as laptopsand smartphones, unwrapping is trig-gered by successful authentication of theuser (such as using a password, smart-card, biometric, or multiple factors).

GENERATING THE KEYA typical method of storage encryptionkey establishment is to convert user cre-dentials into a key using a key derivationfunction (KDF). A popular KDF used toconvert passwords is the password-basedkey derivation function, version 2(PBKDF2). PBKDF2 is defined in theRSA Laboratories’ specification PKCS #5and duplicated in RFC 2898.8,9 PBKDF2applies a hash function to the passwordconcatenated with a salt (random bit-string). To make password cracking moredifficult, the standard recommends thatthe hash output be rehashed multiple

times. The recommended minimumhash iteration count is 1,000, althoughthe number is expected to increase overtime. Apple’s iOS 4.0 uses 10,000 itera-tions. In 2010, RIM BlackBerry’s en-crypted backup service was determinedto be vulnerable due to faulty applicationof PBKDF2. Instead of following thestandard, the BlackBerry software usedan iteration count of one.10

When the password is used to di-rectly generate the storage encryptionkey, a change in password changes theencryption key, thereby forcing re-en-cryption of the entire protected media.To avoid this problem, a permanent,unique encryption key is created whenthe media is initially provisioned, andthe key is wrapped (encrypted) with thepassword-derived key. With this two-level keying scheme, a periodic pass-word change only requires rewrappingof the encryption key.

The user-authentication approachmay be sufficient for limited types ofattended embedded systems that cantolerate user intervention whenever theprotected volumes must be unlocked.Nevertheless, this approach is not suffi-cient for large classes of unattendedembedded systems. If the embeddedsystem encounters a fault and automat-ically reboots, the encrypted volumesmust be able to get back online withoutmanual credential input.

REMOTE KEY PROVISIONINGWe can consider two classes of unattend-ed embedded systems: those that have aremote management network interfaceand those that do not. For the latter, theembedded system lacks any mechanismfor dynamic interaction that can unlockan encryption key. In this case, if infor-mation value demands data-at-rest pro-tection, the designer is advised to incor-

porate a cryptographic coprocessor thatprovides physical tamper-resistant keystorage and internal execution of thedata encryption algorithm. The devicedriver sends plaintext to this encryptorand receives ciphertext for storage ondisk and similarly requests decryption ofdisk blocks as needed.

For network-enabled embedded sys-tems, a remote management server holdsa database of the provisioned data-en-cryption keys. A server connection is ini-tiated by the embedded system whenevera data-encryption key must be unlocked(such as at boot time). The embeddedsystem and server mutually authenticate,and the server provides a copy of the em-bedded system’s provisioned data-en-cryption key over the secured channel.

KEY ESCROWWhen implementing a data-at-rest pro-tection system, developers must considerkey escrow to guard against the possibili-ty that the authentication informationused to unlock the storage encryptionkey will be lost.

There are situations where the sys-tem owner may need to extract the datafrom storage, such as after a system fail-ure. In most system designs, holding acopy of the data encryption key in anoff-site secure location is advisable in or-der to prevent loss of data when the dataencryption key is no longer accessible. Ifthe embedded system lacks a networkmanagement interface, the internally-stored key must be exportable onto me-dia for off-site escrow storage (such as ina secure vault). If the system supportsnetwork management and remote keyprovisioning, developers need to ensurethat remotely provisioned keys are re-tained on a secure server or copied toprotected offline media.

ADVANCED THREATSThe authentication software that runs tounlock the encrypted media must itselfbe trustworthy and tamper-protected.For example, the embedded operatingsystem may incorporate the authentica-tion function directly. The embedded op-erating system image (and any preceding


Listing 1 sector_encrypt(uint8_t *sector, uint32_t sector_num, uint32_t

sector_size, uint8_t key[]){

uint32_t i;assert((sector_size % AES_BLOCK_SIZE) == 0); /* 512 % 16 */for (i = 0; i < sector_size/AES_BLOCK_SIZE; i++) /* 32x */

xts_encrypt(sector+i*AES_BLOCK_SIZE, key, sector_num, i);}

feature

boot loaders) is not encrypted; only therest of the medium, which contains sen-sitive files, is protected. If the embeddedoperating system is not trusted (such asat risk of containing malware or vulnera-bilities that would permit the loading ofmalware), the authentication processcould be subverted. For example, a keylogger could record the user’s password,enabling recovery of the storage encryp-tion key and all of the encrypted data.

If we assume the embedded operat-ing system is trustworthy, we still mustensure that anything executing prior tolaunch of the operating system is trust-ed. This is a good example of the needfor secure boot.

In some cases, the designer maywant the embedded operating systemimage to be encrypted. When FDE is inuse and a sophisticated operating system(such as Linux) resides on the encrypteddisk, pre-boot authentication may be em-ployed: a small portion of the encrypteddisk contains a mini-operating systemthat is booted for the sole purpose ofperforming the authentication and un-locking the medium prior to booting thefull operating system. If the embeddedoperating system is a secure microker-nel, a separate pre-boot authenticationmodule is not required.

Attacks against pre-boot authentica-tors have been successfully perpetrated.For example, the system is booted to amalicious operating system (such as a al-ternative booting from an external USBdrive) that tampers with the pre-bootcode to steal the authentication creden-tials as they are input.11 Secure boot canprevent this attack as well; the signatureof the modified authenticator will fail tomatch the known good version, abortingthe boot process.

Another example of advanced threatis the cold-boot attack. Unless the embed-ded system is using a self-encryptinghard drive where the keys are storedwithin the media and never exposed tothe main processor, disk encryption re-quires that the storage encryption key bekept in memory (in the clear) while thesystem is operational, invoking the en-cryption and decryption algorithm to ac-

cess data. When the system is turned off,RAM is unavailable, and the only copy ofthe encryption key is itself encrypted. Oris it? In some systems, RAM is not imme-diately cleared. An attacker boots the sys-tem using a malicious operating systemthat grabs the plaintext key in RAM. Thisattack has been performed successfully.12

Data-at-rest protection within anembedded system equipped with secureboot and a trusted operating system im-pervious to remote attack can still be de-feated by removing the protected mediaand booting it on a different computerthat lacks this secure environment. Bind-ing the storage encryption key to its in-

tended embedded system platform canprevent this attack. In this case, the per-manent storage encryption key is de-rived (in whole or in combination withuser credentials) from a platform-specif-ic key, such as a fused one-time pro-grammable key or TPM key (if applica-ble). Even if the user’s credentials arestolen, the storage encryption key can-not be derived outside of the targetedembedded platform. The downside ofthis extra level of defense is that a hard-ware failure that prevents access to theplatform credential will render the datapermanently inaccessible (unless the de-rived storage encryption key itself is se-curely escrowed).

PROTECT YOUR CUSTOMERSEmbedded systems developers lookingto incorporate data-at-rest protectioninto their next designs are faced with aplethora of design choices and con-straints. This article provides designerswith an overview of the key issues toconsider. Special considerations fordata-at-rest protection include the useof government-approved symmetricencryption algorithms designed specifi-

cally for such applications and propermanagement of the long-term keys typ-ically used for this purpose. ■

Dave Kleidermacher is CTO of GreenHills Software. He writes a column onEmbedded.com about security issuesand he teaches at the Embedded Sys-tems Conference.

ENDNOTES1. Keteyian, Armen. “Digital Photocopiers Loaded

With Secrets” CBSnews.com, dated April 20,

2010 9:35 PM, www.cbsnews.com/2100-18563_

162-6412439.html

2. Fruhwirth, Clements. “New Methods in Hard

Disk Encryption.” Institute for Computer Lan-

guages Theory and Logic Group, Vienna Univer-

sity of Technology, July 18, 2005.

3. Liskov, M., R. Rivest, and D. Wagner. “Tweakable

Block Ciphers,” 2002. MIT and UC Berkeley.

www.cs.berkeley.edu/~daw/papers/tweak-crypto

02.pdf

4. Security in Storage Working Group of the IEEE

Computer Society Committee. IEEE P1619,

Standard for Cryptographic Protection of Data On

Block-Oriented Storage Devices, 2007.

5. National Institute of Standards and Technology

(NIST). “NIST Special Publication 800-38E, Rec-

ommendation for Block Cipher Modes of Oper-

ation: The XTS-AES Mode for Confidentiality

on Storage Devices.” January 2010. csrc.nist.gov/

publications/nistpubs/800-38E/nist-sp-800-38E.pdf

6. Information Technology Laboratory, NIST.

“FIPS Pub 140-2: Security Requirements For

Cryptographic Modules.” csrc.nist.gov/

publications/fips/fips140-2/fips1402.pdf

7. Rogaway, Phillip. “Efficient Instantiations of

Tweakable Blockciphers and Refinements to

Modes OCB and PMAC,” September 24, 2004.

www.cs.ucdavis.edu/~rogaway/papers/offsets.pdf

8. RSA Laboratories. PKCS #5 v2.0: Password-Based

Cryptography Standard. March 25, 1999.

9. PKCS #5: Password-Based Cryptography Specifi-

cation Version 2.0; Internet Engineering Task

Force, Request for Comments: 2898; September

2000.

10. NIST National Vulnerability Database, CVE-

2010-3741. http://web.nvd.nist.gov/view/vuln/

detail?vulnId=CVE-2010-3741

11. Turpe, Sven, et al. “Attacking the BitLocker Boot

Process,” Proceedings of the 2nd International

Conference on Trusted Computing (TRUST

2009), Oxford, UK, April 6-8; LNCS 5471,

Springer, 2009.

12. Halderman, J. Alex, et al. “Lest We Remember:

Cold Boot Attacks on Encryption Keys,” Pro-

ceedings of USENIX Security ’08, pp. 45-60.


We still must ensure thatanything executing priorto launch of the operatingsystem is trusted.

!!

BY IRFAN CHAUDHRY, MAXIM INTEGRATED PRODUCTS

Here’s a less time-consuming way to maintain magnetic card reader

and card reliability in a variety of noisy electronic environments.


feature

in maintaining the reliability of their MCR-basedsystems, especially in the face of various levelsand types of electronic noise.

ONE SIZE DOES NOT FIT ALLOne of the most crucial parts of any MCR systemis the magnetic read head (MRH). When a card isswiped, the MRH converts the stored data in thecard’s magnetic stripe to a voltage. Other MCRblocks process the converted voltage to extractthe stored data. Large differences in magneticfield strengths from one card to another and differences in swipe speeds from one person toanother make designing an MCR a challengingtask.

Adding to the MCR design difficulty are theMRH data sheets, which do not fully specify thefrequency-dependent components and are oftenvague when specifying other key parameters. Insome cases the data-sheet specifications of two

similar heads from two different manufacturersdiffer significantly in the list of parameters speci-fied and those omitted. These differences are es-pecially troublesome when you are trying tominimize noise issues in an MCR system andmake designing an optimum card-reading sys-tem difficult and time-consuming.

This article outlines a strategy to resolvethese specification issues, and then explains howto overcome the noise issues in an MCR using asecure microcontroller optimized for the task.One can certainly use Maxwell’s field equations,the geometry of the MRH, and the boundaryconditions to predict the MRH output-voltagebehavior. However, this approach is complicatedand provides limited insights for circuit analysis,design, and debugging. Instead, we propose char-acterizing the MRH first and then using basiccircuit theory and a simple circuit simulator toanalyze MCR behavior.

Make magnetic card readers

more reliable in noisy

environments

Plastic magnetic swipe cards are the principal means of estab-lishing personal identity, processing financial transactions,and proving security level for access to secure corporate andmilitary installations. Given the ubiquity of magnetic cardreaders (MCRs) and the harsh environments in which they’reused, embedded systems designers face daunting challenges


MAGNETIC-STRIPE CARD BASICSFigure 1 shows a magnetic stripe cardwith three tracks. Several ISO/IECstandards define important card prop-erties such as the physical size, exactlocation of the stripes, magnetic prop-erties, and magnetic track data struc-tures.1 Track 1 standards were createdby the International Air Transporta-tion Association (IATA). Track 2 stan-dards were created by the banking industry (American BankersAssociation, ABA), and Track 3 standards were created by thethrift-savings industry.

A two-frequency coherent phase (F2F) technique is usedfor encoding the data on magnetic stripe cards. As shown inFigure 2, the binary data is encoded along the track by magnet-izing stripe areas with different polarities. The polarity of thetransitions is arbitrary, since only the relative space between thetransitions implies a binary 1 or a binary 0.

A binary 0 is encoded with a two-unit bar magnet, while apair of one-unit bars represents a binary 1. Each bit occupiesthe same physical length on the stripe. A bit with an additionalflux transition in the middle of its length is a binary 1.

The spectrum of a continuous signal with F2F coding con-tains two fundamental frequencies, f0 and f1, where f0 is thefundamental of the square wave for binary 0 and f1 = 2f0 is thefundamental of the square wave for binary 1, hence the nameF2F. The average amplitude of the binary 0 waveform is twicethat of the binary 1 waveform, A0 = 2A1.

Figure 3 shows the combined spectrum of F2F encoded bi-nary 0s and 1s normalized to f0. Note that most of the signalenergy resides between f0 and 3 f0. Thus, to get a good approxi-mation of a rectangular waveform containing a series of F2Fencoded binary 1s and 0s, it is enough to recover the two fun-damentals (f0 and f1) and the 3rd harmonic of f0.

Moreover, due to varying binary patterns there will be othercomponents below f0. However, we can see from Fourier analysisthat the amplitudes of these components decrease quickly fordecreasing frequencies. Thus, a bandwidth from 0.5f0 to 3f0 is ad-equate for recovering an F2F-encoded rectangular waveform.2

To estimate the minimum and maximum bit rates for f0

and f1, we need to know the swipe speed range and the trackrecording density. From ISO/IEC standards, the recording den-sity of Tracks 1 and 3 is 210 bits/in (8.27 bits/mm), while thatof Track 2 is 75 bits/in (2.95 bits/mm).

For calculating f0,min we take the slowest swipe speed sup-ported and multiply it by the Track 2 density numbers. Forf1,max we pick the fastest swipe speed supported and multiply itby the density of Tracks 1 or 3.

For target swipe rates of 2in/s to 100 in/s (5cm/s to254cm/s), the range of f0 and f1 values is calculated as:

Tracks 1 and 3: f0,min = 0.42kbps and f1,max = 42kbpsTrack 2: f0,min = 0.15kbps and f1,max = 15kbps

The importance of knowing f0,min

and f1,max will become clear once wehave the MRH model and study itstransfer function.

FUNDAMENTALS OF MAGNETICREAD HEADS AND CARD READERSSwiping a magnetic stripe card past astationary MRH results in a changingmagnetic flux that produces a moving

electric field. Thus, a voltage is induced at the MRH’s output.Figure 2 can be used to study the reading process. Startingfrom the top, a magnetic stripe moving past an MRH results inchanging flux events that induce a voltage at the MRH’s outputterminals. The open-circuit readback voltage without any elec-trical losses is given by the well-known expression:3

Where:

• E(–x) = open-circuit voltage.

• K = a constant relating the effects of magnetic-stripe ve-locity, head width, and the number of coil turns in theMRH.

• H(x, y) = field function of the read head.

• M[(x-–x), y] = magnetic-stripe material magnetization.

• y1 = spacing from the head to the top of the magnetic-stripe.

• y2 = spacing from the head to the bottom of the magnetic-stripe.

E(x) = Kd

dtH(x, y) M x- x , y dx dy

1

2

y

y

∫ ∫ ( )⋅ ⋅ ⎡⎣ ⎤⎦−∞

+∞

A magnetic stripe card.

Figure 1

Magnetic Stripe Card

Track-1: IATA, 210 bits/inTrack-2: ABA, 75 bits/in

Track-3: THRIFT, 210 bits/in

S N N S S NS N N S N S S N N S S N

F2F encoding and decoding waveforms.

Figure 2

Writing Reading

Magnetic flux

Magnetic stripe Swipe direction

F2F Form

Binary data0 0

T T/2 T/2

f1 = 2f0f0

1 0 1 1

Figure 3

Spectrum of F2F-encoded binary 0 and 1.

Binary 0

Binary 1

0 1 2 3 4ω/ω0

S(ω

)

5 6 7

1.0

0.75

0.5

0.25

0

Native Parallelism for High-Performance Reduced-Energy Computing

It all Rides On the Right Technology

TMGet Pattern Recognition Right with CogniMem!

$995

Technical Training

Sensor Input

Classification

Identification

Anomaly Detection

Nothing to Declare

TheCloud

!

Data Mining/Analytics

1,024 cognitive

memories CogniBloxTM 4 - CM1K chips/board

(4,096 cognitive memories)Stack for unlimited performance

ADCAct

Clearly, this equation is highly complicated andnot intuitive for circuit analysis and design, but wecan use the basic principles to determine a model asfollows:

The MRH transfers magnetic energy to electricenergy. Since the MRH’s input is a changing magneticfield and its output is a changing electric field, themodel should contain at least one inductive element,Lh, and one capacitive element, Ch. In real systemssome energy is always spent during the transforma-tion. Thus, the model must also contain a resistive ele-ment, Rh. In practice, an MRH will not only have Ch

across its two terminals, but it will also have an exter-nal impedance, Zo. from, for example, connectingwires, PCB traces, IC pins, probes, etc.

A model corresponding to the nth harmonic fre-quency, fn, is shown in Figure 4a, which then is simpli-fied as Figure 4b.3,4,5 The transfer function of the 2nd-order circuit in Figure 4b is easily calculated as:

Note that the above transfer function does notcontain any mechanical or magnetic terms, e.g., theswipe speed, head geometry, head and stripe separa-tion, or the stripe magnetic properties. Thus, thetransfer function is more intuitive for circuit design.

To further simplify things, we propose using alumped model characterized at the highest system fre-quency instead of limiting the model to the swipespeeds.

Next we compare the electrical specifications ofMRHs from some leading manufacturers. Table 1 liststhe key specifications that are needed for the model ofFigure 4b. Notice the different amount of detail. Whileboth Manufacturers A and C specify several electricalparameters, Manufacturer B specifies only one: peak-to-peak head readout level.

The following questions may arise about the miss-ing information.

• Head inductance (Lh). How does Lh behave over alarger frequency range? How does Lh behave whencarrying currents other than what is specified?

• Head DC resistance (Rh). What voltage level is ap-plied across the head terminals?

• Head read output level (VO(P-P)). What type of testcard is used? What is the card swipe speed? What isthe load across the head?

• Head capacitance (Ch). What is the capacitance be-tween the two head terminals? Does it change withfrequency?

⎡

⎣⎢

⎤

⎦⎥

⎡

⎣⎢

⎤

⎦⎥

Tn(s) =V (s)

E (s)=

1

C L (f )

s + sR (f )

L (f )+

1

R C+

1

L (f )C

R (f )

R+1

n

n

o h n

2 h n

h n o o h n o

h n

o

To appreciate the importance of the above parame-ters, we examine the transfer function’s denominatorand find its roots by setting it to zero:

To keep expressions simple and better understand thesecond-order behavior, several network analysis booksuse standard forms to write equations.6,7 One standarduses the form:

whose roots are:

Where α is the damping attenuation:

ωo is the resonance frequency:

Therefore, depending on the values of α and ωo, theroots of the natural response can be real, complex, orimaginary. For readers who are familiar with other stan-dard forms, we now define the damping factor as ζ=α/ωo (note: quality factor Q = 1/2ζ) and use the otherstandard form:

whose roots are:

When a nonzero forcing function (such as a step, aramp, or an impulse) is applied to the system, the loca-tion of the roots in the s-plane directly affects the set-tling behavior. Figure 5 shows the settling behavior forvarious ζ values when a step is applied at t = 0. Specifi-cally, the settling behavior is categorized as:

ζ > 1 → overdampedζ < 1 → underdampedζ = 1 → critically dampedζ = 0 → undamped or oscillatory

From Figure 5 we observe that in an underdamped sys-tem, ringing occurs that can cause reading errors due tofalse peaks and false zero crossings. However, if the systemis drastically overdamped, timing errors can occur fromslow settling and reading errors can occur from shifts inthe peaks. After analyzing an MRH’s time-domain behav-ior, we next look at its frequency-domain behavior.

s + sR (f )

L (f )+

1

R C+

1

L (f )C

R (f )

R+1 02 h n

h n o o h n o

h n

o

⎡

⎣⎢

⎤

⎦⎥

⎡

⎣⎢

⎤

⎦⎥ =

+ 2 02 2s s oα ω⋅ + =

,1 22 2s s oα α ω= − ± −

2

1

2

R

L R Ch

h oα = +

⋅

⎛

⎝⎜⎞

⎠⎟

11

L C

R

Roh

h

oω =

⋅+

⎛

⎝⎜⎞

⎠⎟

2 02 2s so oζω ω+ ⋅ + =

ζω ω ζ= − ± −s s o o, 11 22


Equivalent MRH model.

Figure 4

Equivalent magnetic record head circuitfor the nth harmonic

(a)

Rh(fn)

Ch(fn)

Lh(fn)

En CL RL Vn

External load

(b)

Rh(fn)

Co = Ch+CL

Lh(fn)

En Co Ro Vn

MRH output voltage for various ζ values.

Figure 5

0 2 4 6 8 10 12

Time (s)

14 16 18 20 22 24

Out

put

1.75

1.5

1.25

1

0.75

0.5

0.25

0

-0.25

ζ = 0.125ζ = 0.25ζ = 0.5ζ = 1ζ = 2ζ = 4ζ = 8

Manufacturer specifications for a magnetic head.Parameter Manufacturer A B CVO,P-P (mV) 20 19 35Lh (mH) 25 – 110Ch (pF) – – –Rh (Ω) 110 – 280

Table 1

Transfer function’s frequency response.

Figure 6

0.01 0.1 1 10ω/ωo

T(s)

T(s)

[V/

V]

1x103

100

10

1

0.1

0.01

Figure 6 shows the frequency response of the transferfunction, Tn(s), which is normalized to its resonance frequen-cy, ωo. We observe peaking as we approach the system reso-nance frequency. This is due to the intrinsic nature of the cir-cuit shown in Figure 4b, in other words, a parallel RLC.Depending on the swipe speed, this peaking can also causereading errors.

Recall that when trying to recover F2F-encoded binarydata, we need the two fundamental frequencies, f0 and f1, andat least the 3rd harmonic of f0. From Figure 3 we see that mostof the signal energy is in the vicinity of 0.5f0 to 3.5f0, while asmall portion is around 6f0.

What will happen to the recovered F2F waveform if higher

harmonics were gained up? From Fourier analysis we knowthat the recovered waveform shape will change as the magni-tudes of the higher harmonic coefficients change. Thus, forsome cases the gain peaking shown in Figure 5 can reach apoint where the 3rd and the 6th harmonics are amplified tosuch a level that the recovered signal is severely distorted. Anydistortion that results in false peaks and zero crossings will leadto reading errors.

The above point is emphasized in Figure 7, which mathe-matically shows MRH output voltage for two different gains athigher harmonics: solid blue for the unity gain and orange fora gain of two. The dotted black lines are the zero crossing de-tector hysteresis limits. Clearly, as the gain doubles, the MRHoutput signal in red shows more distortion, false peaks, andzero crossings.

Furthermore, the MRH will not only experience distur-bances due to varying card-swipe speeds, it will also see dis-turbances at much higher frequencies that might be presentin the overall system, for example, a high-frequency systemclock. Because of gain peaking, this too can result in signaldistortion and possible reading errors. Thus, for designing anoptimum card-reading system, it is crucial to know the fre-quency behavior of the MRH beyond the swipe rates. Onemust characterize the MRH frequency behavior at least to thehighest system frequency.

CHARACTERIZING VARIOUS READ HEADSWe used a commercially available impedance/gain-phase ana-lyzer to find the equivalent circuits of several MRHs from dif-ferent manufacturers. The characterization included single-,double-, and triple-track MRHs that were used in the MCRbased on a MAXQ1740 secure microcontroller. As 12MHz isthe maximum system clock frequency for the MAXQ1740,each MRH was characterized from 100Hz to 12MHz (100Hz isanalyzer’s limit). Table 2 shows parameter averages for triple-track MRHs.


feature

Distortion in MRH output voltage due to gain peaking.

Figure 7

0 0.01-0.01-0.02 0.02Time (s)

MRH

Out

put (

V)

1.6

2

0.8

1.2

0

-0.4

-0.8

-1.2

-1.6

-2

0.4

A = 1 @ 3foA = 2 @ 3fo+ ZX Hyst- ZX Hyst

MRH transfer function vs. frequency with a 1GΩ external load (ζ = 0.03).

Figure 8

MRH-1 (ζ=0.03)MRH-2 (ζ=0.03)MRH-3 (ζ=0.03)MRH-4 (ζ=0.03)

10 10010.1 1x103

(kHz)

|T(s

)|

1x103

10

100

1

0.1

0.01

1x104 1x105

MRH transfer function vs. 3rd and 6th harmonic frequency range .

Figure 9

100(kHz)

|T(s

)|

1x103

10

100

1

0.1

0.01

1x103

MRH-1 (ζ=0.03)MRH-2 (ζ=0.03)MRH-3 (ζ=0.03)MRH-4 (ζ=0.03)

CKT-B parameters for triple-track MRHs.Parameter MRH-1 MRH-2 MRH-3 MRH-4Lh (mH) 13.67 58.09 13.20 57.43

Ch (pF) 22.15 31.11 20.60 16.97

Rh (Ω) 146.78 234.57 145.72 214.51

Table 2

ANALYZING THE MEASURED PARAMETERS Comparing the parameters in Table 2, we see that MRH 1and MRH 3 are similar. The relative differences betweentheir parameters are ΔLh ~ 3.6%, ΔRh ~ 0.7%, and ΔCh ~7.5%. For MRH 2 and MRH 4, the relative differences intheir parameters are ΔLh ~ 1.2%, ΔRh ~ 9.4%, and ΔCh ~83%.

Since Ch affects both α and ωo, for similar conditions wecan expect the behavior of MRHs 1 and 3 to be similar. Wecan expect the behavior of MRHs 2 and 4 to track belowtheir resonance frequencies, but then change as the frequen-cies reach close to, and beyond, their respective resonancepoints.

The last two points become obvious when we plot thetransfer function’s frequency response for the characterizedMRHs as shown in Figure 8. The load in Figure 8 is 1G,which results in a damping ratio of 0.03. The plots forMRHs 1 and 3 are virtually the same, while the plots forMRHs 2 and 4 show increasing differences around the reso-nance frequencies. The increase in magnitude could result inreading errors, as described earlier.

Figure 9 shows MRH transfer functions for the frequen-cy range of 150kHz to 300kHz, i.e., 3rd and 6th harmonicscorresponding to the maximum card-swipe rate of 100in/s(254cm/s). We can see that as the swipe rates increase, so dothe MRH transfer-function magnitude values. The mainconcern here is that if higher harmonics are gained up be-yond a point, false zero crossings and peaks can occur, asshown in Figure 7. Also, if signals larger than the maximumallowed appear at the interface between the head and thecard reader’s inputs, then reading errors can occur.

Two factors cause a larger signal. First, a faster swipe in-creases the rate of magnetic flux change. This, according toFaraday’s law, induces a larger inductor voltage, resulting ina larger inductor current. Second, a larger current flowingthrough a larger impedance results in a larger output volt-age, in accordance with Ohm’s law.

Within the card swipe-rate range we need to limit thepeaking to less than or equal to 20, which is the ratio be-tween the maximum and minimum gains of theMAXQ1740 magnetic card reader. Figure 9 shows that theimpedance change for MRHs 1 and 3 is less than 20, but thechange for MRH 2 and MRH 4 is nearly 30 and exceeds thelimit of 20.

What will happen if a damping resistor is added at theoutput of the MRH? Figure 10 shows the transfer functionplots for three arbitrarily different external loads values:100kΩ, 10kΩ, and 1kΩ. We see in Figure 10 that for lower-value external resistors, the peaking is reduced comparedto that shown in Figure 9. Note that for 1kΩ loads the gainat the 3rd harmonic is severely reduced for all four MRHs.This can be a problem. With 100k loads, for MRHs 2 and 3,the gains peaks at the 3rd harmonic, while for MRHs 2 and3, the gain peaks at the 6th harmonic. The main point is


MRH transfer function for different external load values.

Figure 10100

(kHz)

|T(s

)|

10

1

0.1

0.011,000

MRH-1 (100Ω)MRH-1 (10Ω)MRH-1 (1Ω)MRH-2 (100Ω)MRH-2 (10Ω)MRH-2 (1Ω)MRH-3 (100Ω)MRH-3 (10Ω)MRH-3 (1Ω)MRH-4 (100Ω)MRH-4 (10Ω)MRH-4 (1Ω)

MRH damping factors(ζ) vs. external resistor(Ro).

Figure 11

101

Ro (kΩ)

Dam

ping

fact

or ζ

10

100

1

100x10-3

100

ζ MRH-1ζ MRH-2ζ MRH-3ζ MRH-4

MRH transfer functions for optimal external loads.

Figure 12

100(kHz)

|T(s

)|

1

0.1

1,000

MRH-1 (13kΩ)MRH-2 (22kΩ)MRH-3 (13kΩ)MRH-4 (28kΩ)

that we cannot arbitrarily pick the Ro

values. When using external resistor Ro

across the MRH terminals, it’s impor-tant to ensure that the damping ratio, ζ,stays as close to the unity as possible.Figure 11 plots ζ vs. Ro for the four char-acterized MRHs. For ζ =1, we need Ro ≈12kΩ for both MRHs 1 and 3; Ro ≈22kΩ for MRH 2; and Ro ≈ 28kΩ forMRH 4. Figure 12 shows that transferfunction with optimum load values.Comparing Figure 12 to Figure 10, wenote that the gain does not peak at the3rd harmonic and stays close to unity.

While the maximum Ro is set byζ=1, the minimum Ro value depends onthe minimum signal supported and thehead DC resistance, Rh. As a general rule,keep Ro ≥ 5Rh so that Ro in parallel withRh will not attenuate the head outputsignal by more than 20%.

There are several key points to re-member. First, due to parallel RLC, thetransfer function peaks around the reso-nance frequency, ωo. Therefore, limit thispeaking for the range corresponding tothe 3rd and the 6th harmonics of cardswipe rate, e.g., 150kH to 300kHz for thecard swipe-rate range of 42kH to 50kHz.Second, the system behavior can be ad-justed by placing Ro across the headreader’s terminals. Changing Ro changesthe damping ratio, ζ. Finally, select Ro

value to make the system criticallydamped and let the lead wiring and PCBrouting set the Co value.

OPTIMIZING CARD READINGWith a method now to resolve the dis-crepancies in MRH specifications, wecan improve card reading perform-ance. Our focus will be on reducingthe effects of noise, which mostly af-fect the zero crossings (ZX). Aftercharacterizing the MRH model for theentire frequency range (note: the char-

acterization must include lead wiresand the PCB routing), we follow thesesteps:

Step 1. Choose an Ro value to get an ap-propriate damping ratio and limit thegain peaking.

• In general, the target should be criti-cally damped to slightly over-damped. As an exception, if forsome cases the gain at the 3rd har-monic drops below half, we canequalize the gain by a slightly under-damped system.

• An underdamped system can intro-duce noise from ringing of the input

signal. Ringing noise adversely af-fects the zero crossing detector, butmay also result in false peaks due togain peaking.

• Keep Ro ≥ 5Rh with the maximumRo set by ζ =1.

Step 2. On noisier printed circuit boards(PCBs) it helps to make the system over-damped, especially Track 2 (T2).

• T2 has 40 numeric digits, as op-posed to 79 alphanumeric charactersfor T1/T3.

• On T2 longer gaps exist between thepeaks where noise can affect ZX.

• Overdamping integrates the T2 sig-nal. The signal approaches a saw-tooth waveform, as shown in Figure13. Overdampening helps the ZX byfiltering out high-frequency glitches.

• Keep Ro ≥ 5Rh so that the head at-tenuation stays under 20%.

• A note of caution: an excessivelyoverdamped system can lead to er-rors due to slow settling and peakshifts.

Step 3. If using less expensive but noisierread heads, overcome the noise by re-ducing the input signal without affectingthe damping ratio.

• Choose an appropriate Ro.

• Divide Ro into smaller segments sothat the total Ro remains the same asin Step 1.

• Use the appropriate tap to get the re-quired signal division.


feature

Overdamped response. T2 for a manual swipe with 40% card and Ro =1.5kΩ.

Figure 13

Critically damped behavior. T2 for a manual swipe with 40% card and Ro =13.5kΩ.

Figure 14

If using less expensivebut noisier read heads,overcome the noise byreducing the input signalwithout affecting thedamping ratio.

!!!

• Several ways to do this are describedunder Practical Examples below.

Step 4. When the read head output onthe MAXQ1740 exceeds 300mVP-P, in-ternal clipping of the signal occurs. Thisclipping can also cause reading errors.

• Use the method described in Step 3to reduce the signal.

PRACTICAL EXAMPLESInput signal and noise reductionSuppose the optimized output resistorvalue is Ro.

Goal: achieve a 25% reduction in thesignal.

• Use one 0.25 Ro and one 0.75 Ro inseries across the head. Then 0.75 Ro

is tied to the head common-pinside. Tie the midpoint to the input.

• Use four 0.25 Ro in series across thehead. Tie the midpoint to the input.

Goal: achieve a 75% reduction in thesignal.

• Use one 0.25 Ro and one 0.75 Ro inseries across the head. Then 0.25 Ro

is tied to the head common-pin side.Tie the midpoint to the input.

• Use four 0.25 Ro in series across thehead. Tie one tap above midpoint tothe input.

EFFECTS OF DAMPING FACTORSWe next consider various damping fac-tors and their effects on the actual sig-nal behavior when test magnetic cardsare swiped using an MCR based on theMAXQ1740. MRH 2 was used in thetests. There are two important things tonote about the test cards used. First,cards are commercially available fromQ-Card and follow ISO/IEC 7811through 7816 standards. Second, thecard signal amplitudes are specified as apercentage of the nominal level. Thus, a40% card implies a maximum outputlevel that is 40% of the nominal ISOlevel.

Before we had the MRH modelavailable, it took time-consuming andfrustrating guesswork to determine the

right value of external resistors. With themodel available here, we solved the noiseissues by using a 13.5kΩ external resistorthat matched our model prediction. Fig-ure 13 shows the overdamped behavior,while Figure 14 shows the criticallydamped behavior. Comparing Figures11 and 12, we note the slow settling andpeak shifts for the overdamped case

compared to the critically damped be-havior. Both slow settling and peak shiftscan cause timing errors resulting inreading errors as described earlier.

TAKE OUT DA NOISEUsing methods presented in this article,one can predict and prevent potentialproblems early in the design phase orwhen deciding which MRH to pick. Forexample, designers can now anticipatethat in an underdamped system, readingerrors can occur due to false peaks andfalse zero crossings. Both ringing and ex-cessive gain peaking (around the 3rd and5th harmonics of the swipe speed) canproduce false peaks and zero crossing.Conversely, if the system is drasticallyoverdamped, timing errors can occurbecause of peak shifts.

The methods presented here are alsouseful for improving the performance ofan existing card-reader system that usesa specific read head. For example, in anoisy system one can first use several se-ries external resistors to make the systemcritically damped and then tap the MRHoutput from an appropriate node to di-vide down the MRH output level. Final-ly, the methods were verified in an actualcard-reader system based on theMAXQ1740 microcontroller. ■

Irfan A. Chaudhry was a principal mem-ber of the technical staff for IC design atMaxim Integrated Products at the time thisarticle was written but is no longer withthe company. He joined Maxim in 2009with over 16 years of mixed-mode IC de-sign experience in data converters, harddisk drive controllers, nuclear weapontesters, and power management. He hasmore than two dozen designs in produc-tion and holds four U.S. patents. He at-tended the University of Idaho and Wash-ington State University for hisundergraduate and graduate studies, re-spectively.

ACKNOWLEDGEMENTSOur methods are the result of rediscovering

the elegant methods developed by A. S.

Hoagland in the late 1950s and published in

his 1963 book.3

Many thanks are due to Maxim engi-

neers: Steve Grider who provided the most

help; Bryan Taylor, Stephen Umfleet, and

Lonnie Hornsby for their help in the lab;

Kevin Kwak, Don Pearce, Mark Weldele, Gary

Zanders, Brandon Priddy, Nadeem Mirza,

Mark Lovell, Kathy Vehorn, Aaron Minor,

and Jeff Owens for their design, test, and sys-

tem-level contributions and suggestions.

ENDNOTES1. ISO/IEC 7810, ISO/IEC 7811, ISO/IEC

7812, ISO/IEC 7813. www.iso.org/iso/search.htm?qt=identification+cards&search-Submit=Search&sort=rel&type=simple&published=on.

2. Cuccia, C. L. Harmonics, Sidebands andTransients in Communication Engineering.McGraw-Hill, New York, 1952.

3. Hoagland, Albert. Digital Magnetic Record-ing, Wiley, New York, 1963.

4. Chu, W. W. “Computer Simulations ofWaveform Distortions in Digital MagneticRecordings,” IEEE Transactions on Elec-tronic Computers, Vol. 15, pp. 328–336, Jun.1966.

5. Chu, W. W. “A Computer Simulation ofElectrical Loss and Loading Effect in Mag-netic Recording,” IEEE Transactions onElectronic Computers, Vol. EC-16, No. 4, pp.430–434, Aug. 1967.

6. Nilsson, J.W. Electric Circuits, 3rd ed.,(Reading, MA, Addison-Wesley PublishingCo.), 1990.

7. VanValkenger, M.E. Network Analysis, 3rded., (Englewood Cliffs, NJ Prentice-Hall),1974.

feature


With the model availablehere, we solved the noiseissues by using a 13.5kΩexternal resistor thatmatched our model prediction.

!!!

L ast month I gave a mostly theoret-ical overview of the effectprobes—like scope and logic ana-

lyzer probes—have on the nodes beingtested. The most important effects stemfrom the capacitance of the probe tip.To reiterate, the reactance, or resistanceto AC, at the tip is:

This reactance loads the node andcan alter a device’s operation—orworse.

To explore this, I built a circuit on aprinted circuit board with ground andpower planes, keeping all wires veryshort. A 50-MHz oscillator drives twoAND gates. The 74AUC08 is spec’dwith a propagation delay between 0.2and 1.6 nsec at the 2.5 volts I used forthe experiment. The second gate is aslower 74LVC08 whose propagation de-lay is 0.7 to 4.4 nsec. Still speedy, butslower than the first gate. I was not ableto find rise-time specifications but as-sumed the faster AUC would switchwith more alacrity and thought it wouldbe interesting to compare effects withdiffering rise times. Alas, it was not tobe; the LVC wasn’t much slower thanthe AUC. So I’ll generally report on theslower gate’s results

These parts are in miniscule SOT-23 packages, which keeps inductancesvery low but means one solders under amicroscope, sans coffee.

I wanted to see the effect thatprobes have on nodes, but that posed ameta-problem: if probing causes distor-tion, how can one see the undistortedsignal? Thankfully there’s a simple solu-tion. I made a pair of meter-long probesfrom RG-58/U coax cable. A BNC con-

nector on one end goes to the scope. Ashort bit of braid is exposed and sol-dered to the ground plane very close tothe node being probed, and a ¼-watt1K resistor goes from the inner conduc-tor to the node. I used an Agilent MSO-X-3054A scope with selectable inputimpedance, set to 50 ohms. This is criti-cal for the shop-made probe; the nor-mal 1 MΩ simply will not work. If yourscope doesn’t have a 50-Ω mode, use aseries attenuator such as the 120082from Test Products International (thispart doesn’t seem to be on their webpage, but Digikey resells them). Agi-

lent’s N5442A is a more expensive butbetter-quality alternative.

RG/58U is 50-Ω cable; add the re-sistor and the total is 1,050 ohms. Thescope’s 50-Ω input forms a 21:1 di-vider, but the resistor’s very low capaci-tance (remember, a ¼-watt resistorruns only 0.5 pf) means the probe’s tiplooks extremely resistive, with little re-actance. The scope thinks a 1X probe isinstalled, so to accommodate the odd-ball 21:1 ratio one multiplies the dis-played readings by 21.

The first experiment showed Fouri-er at work. The blue trace in Figure 1shows the output of the fastest gate us-ing a 21X probe. Note that it’s far fromperfect since the circuit had its own re-active properties. The rise time (mea-sured with a faster sweep rate thanshown) is about 690 psec (picosec-onds). “About” is the operative word, asthe scope has a 500-MHz bandwidth(though samples at 4 GS/sec). I foundthat having the instrument averagereadings over 128 samples gave veryconsistent results.

The pink trace is the Fourier Trans-form of the gate’s output. Unlike theblue trace, this one is not in the timedomain (e.g., time across the horizontalaxis) but is in the frequency domain.From left to right spans 2 GHz, with500 MHz at the center. The vertical axisis dBm, so is a log scale. Each peak cor-responds to a term in the Fourier series.Point “A” is exactly 50 MHz, the fre-quency of the oscillator. Most of the en-

π=X

fCc1

2


By Jack G. Gansslebreak points

Jack G. Ganssle is a lecturer and consultant on embeddeddevelopment issues. He conducts seminars on embedded systemsand helps companies with their embedded challenges.Contact him at [email protected].

Probing pointers, take 2

Jack tests severalprobes to see how different probes changethe results.

!!

ergy is concentrated there. Peak “B” is48 dBm down from “A.” That’s on theorder of 100,000 times lower than “A.”

“B” is at 900 MHz. Rememberingthat little energy remains in frequenciesabove

with F=900 MHz the rise time is555 psec, close enough to the 690measured. The same experiment usingthe slower 74LVC08 gate yielded48 dBm down at 450 MHz, or a risetime of 1.1 nsec. That’s close to the0.95 nsec reported by the scope.

Next, I connected a decent-quality$200 Agilent N2890A 500-MHz probe(11-pf tip capacitance) on the 74LVC08’soutput. The 21X probe saw an addition-al third of a nanosecond in rise time dueto the N2890A’s capacitance. In otherwords, connect a probe and the circuit’sbehavior changes.

In Figure 2 the orange trace is thegate’s output measured, as usual, withthe 21X probe, although now there’s

10 inches of wire dangling from it. Thattrace is stored as a reference, and thegreen one is the same point, with thesame probe, but the N2890A is con-nected to the end of that 10 inches ofwire. Note that the waveform haschanged—even though that otherprobe is almost a foot away—and thesignal is slightly delayed. This is proba-bly not going to cause much trouble.

Gates typically have a very low out-put impedance, so it’s unsurprisingthere’s so little effect. Often, though,we’re sensing signals that go to morethan one place. For instance, the “read”

control line probably goes from theCPU to quite a few spots on the board.To explore this situation, I put the 21Xprobe five inches down that wire, cap-tured the waveform into the reference(orange in Figure 3), and then connect-ed the same N2890A at the end of the10 inches of wire. The signal (green) atthe 5-inch point shifted right and wasdistorted.

Consider the clock signal: On a typi-cal board, it runs all over the place. Theimpedance at the driver is very low, butthe long PCB track will have a varyingreactance. Probe it and the distortioncan be enough to cause the system tofail.

The ringing is caused by an imped-ance mismatch. The N2890A haschanged the node’s impedance, so it nolonger matches that of the driver. Part ofthe signal is reflected back to the driver,and this reflection is the bounciness onthe top and bottom of the pulses.

I didn’t have any X1 probes around,so put a 100-pf capacitor on the node to

=FTr

0.5

Rise time spiked to 5.5nsec, more than a fivetimes increase; I suggestimmediately combing yourlab for X1 probes anddonating them to Goodwill.

!!!


A node’s signal changes when a probe is attached 10 inches away.

Figure 2

Distortion 5 inches down the wire due to a probe at the 10-inch point.

Figure 3

Distortion at the output of the gate with a 30-pf simulated probe.

Figure 4

Fourier Transform of fast edges.

Figure 1

simulate a really crappy probe. Rise timespiked to 5.5 nsec, more than a five timesincrease, and the signal was delayed byalmost a nsec. I suggest immediatelycombing your lab for X1 probes and do-nating them to Goodwill. And be verywary of ad hoc connections—like clipleads and soldered-in wires—whoseproperties you haven’t profiled.

But 100 pf is a really crummy probe.I soldered a 30 pf cap on the node tosimulate one that’s somewhat like an adhoc connection or a moderately-cheapprobe. In Figure 4, the orange trace isthe gate’s output with no load—just the21X probe. The green is with the addi-tional 30 pf. The distortion is significant.

So a 30-pf probe grossly reshapesthe node’s signal. What effects could thatcause?

First, everything this signal goes towill see a corrupt input. If it goes to aflip flop’s clock input the altered risetime could cause data to be incorrectlylatched. Or, if the flop’s data input(s) arechanging at roughly the same time, theflop’s output could become metastable—it’ll oscillate for a short time and thensettle to a random value.

If it goes to a processor’s non-mask-able interrupt input the leading-edgebounce could cause the CPU to executetwo or more interrupts rather than one.(Generally this is not a problem for nor-mal maskable interrupts since the firstone disables any others).

But wait, there’s more. Note that thesignal extends from well below ground

(about -600 mV) to 3.7 volts (be sure tofactor in the attenuation of the 21Xprobe), which is much higher than the2.5-volt Vcc. Depending on the logicfamily this signal goes to, those valuescould exceed the absolute maximum rat-ings. It’s possible the driven device willgo into SCR latchup, where it internallytries to connect power to ground, de-

stroying the device. I have seen this hap-pen: the chips explode. Really. It’s cool.

So far I haven’t shown any signalsacquired by the N2890A. The yellowtrace in Figure 5, is the gate’s output us-ing that probe. It’s pretty ugly! The dis-tortion is entirely in the probe, and noton the board, so does not represent thesignal’s true shape. In this case the probeis grounded using the normal 3-inch cliplead. Using the formula from last month,that loop has 61 nH of inductance.

In orange the same signal is dis-played, but in this case I removed theprobe’s grabber and connected a veryshort, about 5 mm, ground wire to themetal band that encircles the tip. The

signal is still notdisplayed correct-ly—it extends be-low ground andhas a total magni-tude of aboutfour volts, muchmore than the 2.5Vcc. But the bet-ter grounding didclean up theshape. The pointis that poorgrounding cancause the scope todisplay wave-

forms that don’t reflect the node’s realstate.

ELECTRONICS MATTERSMany in the digital world find them-selves divorced from electronics. Wethink in ones and zeroes, simple ideasthat brook little subtlety. A one is a one,a zero a zero, and in between is a no-man’s land as imponderable as the“space” that separates universes in themultiverse.

But electronics remains hugely im-portant to digital people. Ignore it atyour peril. Power supplies have crawledbelow a volt so the margin between aone and a zero is ever-tighter. On someparts the power supply must be held±0.06 volts or the vendor makes nopromises about correct operation. On a74AUC08, typical fast logic, at 0.8 Vccthere’s only a quarter volt between ahigh and a low. Improper probing caneasily skew the node’s behavior by thatmuch. And, as we’ve seen, capacitanceand inductance are so vital to digital en-gineering that we dare not ignore theireffects when troubleshooting.

Reactance, impedance, and electro-magnetics are big subjects that I’ve onlylightly touched on. They’re pretty inter-esting, too! I highly recommend thebook High-Speed Digital Design for adeep and dirty look at working withhigh-speed systems.1 The ARRL Hand-book from the American Radio RelayLeague is possibly the best introductionto electronics available. It doesn’t skimpon the math, but never goes beyondcomplex numbers. The focus is decided-ly on radios, since this is the bible ofham radio, but the basics of electronicsare covered here better than any otherbook I’ve found. There’s a new editionevery year; my dad bought me a copy in1966, and since then I’ve “upgraded”every decade or so. ■

ENDNOTES1. Johnson, Howard and Martin Graham.

High-Speed Digital Design 1993 PTR Pren-tice-Hall Inc, Englewood Cliffs, NJ.

2. The ARRL Handbook, American Radio Re-lay League. Published afresh every year.www.arrl.org.

break points

The driven device will gointo SCR latchup, where itinternally tries to connectpower to ground, destroy-ing the device. The chipsexplode. It’s cool.

!!!

The N2890A’s result, with proper and poor grounds.

Figure 5


DON’

T M

ISS

THE

LARG

EST CELEBRATION OF SCIEN

CE IN THE U.S.

USASCIENCEFESTIVAL.ORG

PROUD SPONSOR:

LOCKHEEDIUM / FESTIVAL HOST EINSTEINIUM

K&L GATESIUM

KRYPTON

PLATINUM

Vertex Pharmaceuticals, Celestron, Baxter International, American Nuclear Society, Association of Science-Technology Centers, Xconomy, You Can Do the Rubik's Cube, Amgen, U.S. Environmental Protection Agency, U.S. Department of Defense, Society for Maintenance and Reliability Professionals (SMRP), Johns Hopkins University Applied Physics Laboratory, Raytheon, Center for America, U.S. Army RDECOM and eCYBERMISSION, Purdue University, Project Lead The Way (PLTW), The Scripps Foundation for Science and the Environment, Northern Virginia Technology Council, 3M, Aldebaran Robotics Inc., Center for Biotechnology Education at Johns Hopkins University

TAKE THE METROBUS OR METRORAIL TO THE USA SCIENCE & ENGINEERING FESTIVAL

BOCKIUM

NOBELIUM

LEGO Education, CrazyEngineers.com, The Kavli Foundation, Medimmune, Sigma Xi, Illumina Inc., American Scientist, Physics Today, Forbes/Wolfe, SchoolTube, Washington Family Magazine, National Aeronautics and Space Administration, The Planetary Society, PBS Kids, ABC7/WJLA-TV, WAMU 88.5 - American University Radio, The George Washington University - School of Engineering and Applied Science (SEAS)

THE USA SCIENCE &ENGINEERING FESTIVAL

IS PROUD TO HOST THE 2012

“NATIONAL ROBOT FESTAND DIY EXPO -

WHERE CREATIVITY & TECHNOLOGY MEET”

OVER 3000 FUN HANDS-ON ACTIVITIES AND MORE THAN 100 STAGE SHOWS MEET AWARD-WINNING AUTHORS AND SCIENCE CELEBRITIES LIKEBILL NYE THE SCIENCE GUY AND ADAM SAVAGE & JAMIE HYNEMANNEW THIS YEAR: CAREER PAVILION & BOOK FAIR | A FREE EVENT

EXPO & BOOK FAIRAPRIL 28 & 29, 2012

GRAND FINALE

WALTER E. WASHINGTON CONVENTION CENTER, WASHINGTON, D.C.

DOWNLOAD THE FREE FESTIVAL APP (STARTING APRIL10)

INNOVATIVE PRODUCT

DEVELOPMENT, ON DEMAND

>> We’ve spent 25 years building a superior ecosystem for innovation. If you need a full

systems engineering team or a specialized area of expertise, Stratos is here to help.

VISIT US AT BOOTH #2314 AT DESIGN WEST 2012

TO LEARN MORE AND ENTER TO WIN A

3RD GENERATION IPAD™.March 26-29, 2012McEnery Convention Center

San Jose, CA

Embedded.systems.design..April.2012

Documents

technische universitt mnchen

flight system dynamics

coresight funnel combines

trace memory controller

trace memory controller

green hills software

embedded systems conferences

maxim integrated productsheres