Technology people are generally familiar with the Open SystemsInterconnection model for computer networks and protocols, oftenreferred to as the OSIReference Model (ISO 7498) .The Basic Reference portion of the model consists of seven layers whichbuild upon each other with increasing levels of abstraction (See Figure 1 below ).
This article postulates that a similar abstraction may be applied tothe embedded debugging world, with functional layers analogous to theOSI model. Further, individual layers can be assigned to particulardebug entities, just like, for example, the association of the OSInetwork layer to routers, or the application layer association with ahost.
|Figure1. OSI Layers and Example implementations|
The intent here is to explore levels of debugging functionality,with the OSI model as a guide, and identify hierarchical layers andassociations among hardware and software to produce a model ofdebugging interrelationships. It is hoped that such a model may provideclarity in understanding the myriad ways debugger components interact.
Layer 1: The Test Access Port (TAP)Layer
In the embedded debug domain, the physical layer usually corresponds tosome form of synchronous serial interface that operates at a fractionof the target processor speed. Analogous to the ubiquity of TCP/IP in the networking world,the most common debug interface at the physical level is IEEE 1149.1,otherwise known as JTAG .
|Figure2. TAP Controller State Machine|
JTAG was not conceived as a debug interface originally; its formalname is Standard Test Access Port and Boundary-Scan Architecture, andit was designed as a mechanism for testing printed circuit boards. Theidea was to attach a shift register cell to every signal on the device,chaining the cells together around the periphery (hence boundary scan).
The Test Access Port, or TAP, is a state machine that cycles throughthe various TAP states, shifting in data and instructions (See Figure 2 below ). There are fourdedicated JTAG signals corresponding to clock (TCK), input (TDI),output (TDO), and mode (machine state) select (TMS). By clocking incommands on TDI via the IR scan path of the TAP controller, a devicecan be made to send or receive scan data through the DR scan path.
So how does JTAG apply to debugging? The JTAG interface providesexcellent visibility into the internal workings of a target, withlittle to no overhead affecting normal system operation. JTAG signalscan be daisy-chained among devices, giving access to any JTAG-enableddevices on a board, or more commonly in the present day to multiplemodules on a single piece of silicon.
Another form of physical connection peculiar to Freescale (the company I work for ) ColdFiredevices, and previously Motorola CPU32/16 processors, is the serialinterface to Background Debug Mode, or BDM2  . The signal interface consistsof data serial in (DSI), data serial out (DSO), data serial clock(DSCLK), breakpoint, and reset.
In later versions there are also pins for trace data, system clock,and transfer acknowledge. Data is shifted in and out in 17 bit packetsat a maximum clock rate of one-fifth the core processor speed. Machinestates are dictated by specific BDM commands, but the general flow isillustrated in Figure 3 below.
|Figure3. BDM Command Sequence Diagram|
Layer 2: The Controller Layer
Similar to the way the OSI model data link layer offers a measure oferror detection and ease of interfacing, the next layer up in theembedded debug realm recognizes basic commands and performs rudimentaryerror reporting.
For example, in some architectures it is necessary to shift throughthe entire device scan chain to isolate particular register values.Since the JTAG scan chain is the least critical path in a design, ittends to be arbitrarily placed by circuit routing algorithms.
This means the JTAG layout can change between different revisions ofa design. Moreover, the complete scan chain, since it encompasses everysignal on the device, can be quite large on modern integrated circuits.The upshot is that in order to obtain, say, the contents of a 32-bitgeneral-purpose register, thousands of bits must be shifted through thechain, slowing the overall debug process. All of these drawbacks areeloquently described by Craig Haller in his 1996 article, “The Zen ofBDM”  .
Chip designers have addressed this problem by subsetting the scanchain and providing higher-level controllers that extend the operationof the basic JTAG TAP. One such device is the On-Chip Emulation (OnCE)module found in Freescale DSPs4.
With OnCE, the JTAG instruction register command set is extended toprovide functions for selecting a TAP in a multi-processorconfiguration, obtaining processor status, issuing processor debugrequests, and multiplexing the data register scan path to furtherextend functionality and target accessibility.
For example, the OnCE is capable of performing arbitrary coreinstructions through a mechanism called instruction stuffing, where acore instruction encoding is literally stuffed into the executionpipeline. This is done by issuing an extended JTAG instructionENABLE_ONCE, which tells the OnCE circuit to expect a data shift intothe emulator control register (ECR,see Figure 4 below ).
For each shift into the ECR, selected bits indicate: 1) whether a subsequent operation isto be a read or write, 2 )whether or not the processor is to execute a shifted core instruction, 3) whether or not the processor isto exit debug mode after the subsequent operation, and 4) the offset toone of the myriad OnCE registers to be read or written, if applicable.
|Figure4. OnCE Emulator Control Register|
For the case of a stuffed instruction, the hexadecimal sequence 17Eis shifted through the DR scan chain into the ECR, indicating a writeto the OnCE CORE_CMD register, execution of the instruction written,and a return to debug mode thereafter. The following DR scan shifts theencoding into the CORE_CMD register, and the instruction is executed.
Any results from the instruction can be retrieved by moving the datainto the OnCE ETRSMT register and shifting out from there. The OnCE hasregisters for supporting high-level debugging tasks such as hardwarebreakpoints, watchpoints, and instruction tracing.
Another example at this layer is the previously-mentioned BDMcontroller on ColdFire processors. The BDM controller provides a richset of commands for performing familiar debugging tasks (see Figure 5 below ).
This command set is reminiscent of the commands found in older ROMmonitors, but the BDM controller is much less intrusive than a monitorprogram. Note that some operations can be done in parallel with normalsystem operation, or by stealing cycles during memory accesses.
|Figure5. BDM Command Summary|
Layer 3: The Driver Layer
The TAP and controller layers reside completely on the target. At thenext layer, we leave the target for functionality on the host or, morecommonly, on an intermediary device variously called an emulator probe,command translator, or protocol converter.
Similar to the routers that inhabit the corresponding OSI networklayer, protocol converters are special-purpose computers with firmwarestacks for deserializing target bit streams and communicating over ageneral-purpose network to a host.
Commercial examples of protocol converters include ARM'sRealView ICE, Green Hills Probe, Abatron's BDI 2000, P&E's Cyclone MAX, Lauterbach's ICD, Ashling's Opella, and Freescale's Ethernet TAP and USBTAP.
The driver layer interacts directly with the target, modulating theclocked signals and buffering and assimilating bit streams intoaggregate data blocks. Protocol converters generally have an FPGA orsimilar device which actually does the work of clocking and latchingthe signals for consumption by the target or driver firmware. Thedriver firmware then buffers values for use by the FPGA or otherfirmware modules.
Layer 4: The Device Template Layer
Just like the driver layer, the device template layer can reside eitheron the host or a separate probe device. Templates encapsulate thehighest level of run-control abstraction specific to the debuggedtarget. Template interfaces resemble standard debug command sets suchas those supported by ColdFire BDM, but they have internal knowledge ofa particular processor core and its relationship to the TAP driver andcontroller (Figure 6 below ).
|Figure6. Sample Generic Template Functions|
The template knows about internal core register numbering, core JTAGIR and bypass lengths, and initialization sequences to commenceinteraction with the target. Additionally, the template can provideoptimizations for multiple register retrieval and memory operations, inparticular high-speed download services.
Templates are usually implemented as shared or dynamically-linkedlibraries that can be loaded as needed by the host or interface device.This is useful in cases where a target consists of multipleheterogeneous cores, where arbitrary combinations of core functionalityare possible.
Hybrid forms of templates make it easier to handle special devicecases. A filtered template is analogous to a C++ virtual function inthat it augments or selectively replaces functionality in an existingtemplate. For example, a device might need to change its JTAG speed ina particular system, and this could be built as a lightweight filter ontop of a standard template for the device.
Another special-purpose type of template is an SOC template thatassumes an underlying set of cores that can be controlled as a group orsubgroup. Such a template would be useful where a single stop commanddirected to the SOC template would put all of the cores in debug modeas quickly and efficiently as possible, i.e. by scanning out debugrequests as JTAG IR commands to all cores simultaneously. Go and evenstep commands could be handled similarly.
Layer 5: The CommunicationsProtocol Layer
In the OSI model, the session layer manages connections between hostcomputers using mechanisms such as pipes and sockets. In the embeddeddebug world, a debugger host may be separated from its target by rooms,buildings, cities, or continents. It is useful to have a layer thatmanages these distances and multiple connections as well.
The communications layer is often implemented as a standalone serverthat listens for debug requests on a network socket address and eitherforwards the request to another server instance or dispatches thecommand to an underlying target probe device.
The GNU Debugge r  provides a mechanism for doingthis in gdbserver. Gdbserver uses a remote serial protocol made up ofrequest and reply packets. The packets themselves are comprised ofASCII character sequences representing debugger commands and targetresponses.
Assume a protocol converter running the Linux operating system.Gdbserver runs as a process on the probe, listening for connectionrequests on an arbitrary port number.
A host specifies the IP address of the probe and the agreed-uponport number and a connection is established. The host then sends debugcommands as remote serial protocol packets.
Gdbserver decodes these packets and either passes the information toan FPGA driver or another process that handles target debuginteractions. Gdbserver can also be used to debug processes andapplications running on the probe itself!
Another variation of a debugger server is Freescale's CodeWarrio r Connection Serverwhich uses a proprietary protocol encapsulated in anAPI to obtain debug information about the target. A host debugger usesthe API to establish a connection with the target via a probe device,configure target characteristics, and perform basic debugging tasksincluding resetting the target.
As a troubleshooting aid to avoid always programmatically accessingthe target, it includes a TCL interface that is implemented as acommand console (see Figure 7 below ).The commands correspond to the debugger server API calls, and loggingcapabilities makeit possible to reconstruct troublesome debugging sequences.
|Figure7. CodeWarrior Connection Server Console Window|
Layer 6: The Debug Layer
The OSI presentation layer is responsible for insuring that sessionlayer data is formatted or otherwise repackaged for efficient use bythe application layer. Some of these tasks are performed in thecorresponding debug layer, but this layer also comprises the focus offunctionality in the debug interconnect framework. When people refer toa particular debugger, such as CodeWarrior or GDB, this layerrepresents the bulk of what they mean.
The debug layer consists of most of the familiar abstractionsassociated with debuggers: support for setting breakpoints andwatchpoints, single stepping with source file mappings, register accessby name, formatted memory retrieval, target reset and run control.
At this level there is intimate familiarity with the target in termsof memory layout and processor initialization, but there is alsoknowledge of program files, object formats, and symbols. The domain ofthe debug layer is always on the host machine.
This layer may additionally encompass selected extensions to basicfunctionality, such as project support or source control accessmechanisms. Trace data collection, presentation, and assimilationunderlie clever innovations such as CodeWarrior CodeTest or Green HillsTime Machine.
The debug layer handles any connection operations from the hostside, e.g. what protocol converter if any, probe IP address or otheridentifier, server or direct-connect interaction, and debug clockspeed. The debugger must be capable of reading and loading objectfiles, exporting transportable versions of object code, and providingdisassembly of program code in memory.
Layer 7: The Application Layer
In the debug interconnect framework, the closest analog to the OSIapplication layer is the GUI or command window, the access point oruser interface to the debug layer. This may be implemented as a customintegrated development environment (IDE) or provided through athird-party offering such as Eclipse or Tcl/Tk .
For the latest incarnation of the CodeWarrior debugger, aproprietary front-end (“CodeWarrior Classic”) was replaced with acustom Eclipse-based GUI. This makes it possible to provide all of thefunctionality users have come to expect from the debugger, whilebenefiting from improvements offered by the open-source community.There is also a development discipline in the Eclipse world whichinsures that applications will not stray too far from a standardEclipse look-and-feel expected by users.
|Figure8. CodeWarrior Eclipse IDE|
At this layer, too, the GUI can not only accommodate debuggerfunctionality but other development operations as well, becoming a trueIDE that brings together building tools (editors, compilers, linkers ),source control programs (CVS,Subversion, Clearcase ), and bug reporting systems inside thedebug framework.
Broad-based integration such as this, combined withbottom-up integration of the debug interconnect model, comprise apowerful and flexible development environment for embedded systems.
1. Hubert Zimmermann, “OSIReference Model — The ISO Model of Architecture for Open SystemsInterconnection“, IEEE Transactions on Communications, April1980.
2. Freescale Semiconductor,”11.5 Background Debug Mode (BDM)”, ColdFire CF4e CoreUser'sManual, V4ECFUM/D, Rev. 0, 06/2001.
3. Craig Haller, “The Zen of BDM“,Macraigor Systems, Inc. 1996.
4. StarCore LLC, OCE30Architecture Specification, Rev. 03.02, April 5, 2006.
5. Free Software Foundation,Inc., “Debuggingwith GDB“, Ninth Edition, GDB Version 184.108.40.20670518.
6. O. Gruber, et. al., “TheEclipse 3.0 platform: Adopting OSGi technology“, IBM SystemsJournal, Vol. 44, No. 2, 2005.
7. John K. Ousterhout, Tcland the Tk Toolkit, Addison-Wesley, Reading, MA, USA, ISBN0-201-63337-X, 1994.
8. “Insight: The GDB GUI.”