How to increase your debugging skills! · Introduction Software debuggers and target monitors offer...

Post on 22-May-2020

10 views 0 download

Transcript of How to increase your debugging skills! · Introduction Software debuggers and target monitors offer...

ICE Technology, Nohau 800.686-6428 or 650.375.0409 www.icetech.com sales@icetech.com

IntroductionSoftware debuggers and target monitorsoffer economical debugging capabilitiessufficient for many applications. In-circuitemulators offer additional advanced real-time debugging facilities. There are majordifferences between each of these optionsin terms of debugging power, real-timeoperation, and non-intrusiveness. Somedebuggers, such as those from Keil, PLSand ChipTools can do advanced taskswhen interfaced to an emulator.

With these debuggers, one can load,single-step and run programs. Softwarebreakpoints can be set and memory can beexamined. Code Coverage and Perfor-mance Analysis provide statisticalinformation. Software debuggers do agood job, but have some shortcomingsthat can be crucial in detecting and fixingsome of the more elusive bugs or inspecial circumstances.

Interesting “what-if” ScenariosWhat if you are debugging code that is inROM ? Or even trickier: ROM inside thechip. What if you need the serial port thatdebuggers commonly use to communicatewith the controller ? What if you want todetect a certain situation: such as a writeof a certain value to an external periph-eral and if another variable equals 6,and then stop the execution ? Or recordthese bus cycles ? What if a bug causesyour program to jump off into never-landand you need to know what was happen-ing just before this event ? HardwareBreakpoints, a non-intrusive connection,Conditional Triggers and Trace Memoryare solutions to these problems and more.You need an emulator.

This article will explore some advantagesoffered by emulators and how you canproduce better code by using one.

The Development CycleThe typical microprocessor developmentproject begins with a C compiler produc-ing an object file from your source code.This object code will contain the physical

The Software Engineer’s Guide to In-Circuit EmulationHow to increase your debugging skills!

addresses and some debugging informa-tion. This object code can be executed anddebugged using a software simulator, atarget monitor or an in-circuit emulator. Amost undesirable method is to program anEPROM and simply run the target system.

The program is debugged by settingbreakpoints to halt execution at selectedinstruction locations. When execution ishalted, the memory and register contentsare examined for clues to help find bugs.

The debugged object code is re-compiledremoving the debug information andproducing a file in a standard format suchas Intel HEX. This file will be stored in thefinal product’s nonvolatile memory such asEPROM or FLASH. This process isillustrated below in Figure 1.

Why do we need emulators ?There are some cases where an emulator isneeded to resolve difficult to find bugs. Inall cases an emulator will pay for itself byproviding you with decreased debuggingtime, ease of system integration, increasein reliability and better testing procedures.Often, designers use both an emulator andsoftware debugger during different projectstages, especially in larger design teams.

Software simulators and debuggers offer

only a few features beyond breakpointssuch as displaying port contents and codecoverage. There are no means to detectevents or conditions and then act on them,and certainly not in real-time. There arealso no means to record controller buscycles to determine what actually hap-pened to the program flow. If your micro-controller has on-board EPROM or FLASHmemory, and is running in single chipmode: only an emulator can debug thisscenario without serious intrusion andconsumption of controller resources.

In-circuit emulators can easily do thesetasks and more for you. Emulators are thebridge between software and hardware. Atsome point in time, you have to run yourprogram in real hardware. An emulator willeasily help you accomplish this. Thisarticle examines how emulators will helpyou with your debugging sessions.

What exactly is an emulator ?“An emulator is a computer that engineersuse to design other computers” is the mostbasic definition . Emulmulators simplyreplace the microcontroller in yourtarget system. The emulator behavesexactly like the processor with the addedbenefit of allowing you to view data andcode inside the processor and control therunning of the CPU.

Figure 2 shows a Nohau emulator for theC166 and ST10 microcontroller families.Figure 3 shows the Nohau emulators forthe Motorola HC12 family. These emula-tors are compact handheld emulators thatgo anywhere you and your laptop can go.They are all powered with a 5 volt supply.

ICE Technology Nohau Brand Embedded Systems Tools

© ICE Technology

ICE Technology, Nohau 800.686-6428 or 650.375.0409 www.icetech.com sales@icetech.com

External ModeExternal mode is when the programmemory and perhaps some data memory islocated externally to the controller. This isthe classic situation where the target boardcontains a microcontroller, some EPROMor FLASH, RAM and some type ofperipheral chips. The address and databusses are available to access this memoryand are the only means for an emulator togather information and control the CPU.Therefore information about internalregisters is not available in real-time. Theaddress and data busses may not be usedas general I/O ports. Production chips areeffective for emulating this mode as arethe special emulation chips.

Internal or Single-chip ModeInternal mode is when program and datamemory is located in the controller chipin the form of FLASH or EPROM. Thismethod is becoming preferred for embed-ded designs due to its low cost. Theaddress and data busses are not accessibleto the user. These busses are then avail-able as I/O ports. All program executionoccurs in the internal ROM. This moderequires a bondout, Enhanced Hooks,JTAG or BDM chip for emulation.

Nohau emulators generally run thesechips in external mode and use specialcircuitry to reconstruct the I/O ports. Thisprocess is transparent to the user. BDMand JTAG chips are special situations.

It is possible to embed a monitor kernel inthe ROM, coexisting with the programcode. The user can activate the kernelwith a switch connected to an I/O pin.This will allow communication with adebugger via a serial port. Of course,some system resources need to be reservedfor this scheme but it is still useful.

Bondout ChipsBondout chips allow single chip emula-tion by providing extra pins connected tointernal CPU nodes. Infineon C166,

ST Microelectronics ST10 and Intel 196and x86 emulators generally use bondoutchips for effective emulation. The NohauEMUL166-PC and EMUL-ST10 are goodexamples. It is possible to make emulatorsfor these families using production partsbut performance is usually lacking ininternal accesses.

The Infineon C167 and the ST 167 and 168microcontrollers use Ports 0 through 4 foraddress and data busses in external mode.Which ports are used depends on the busconfiguration as programmed at CPUinitialization. The bus configuration can bechanged “on-the-fly” while the processoris running. From 16 to 40 port bits can beused as address/data lines. These thencannot be used for general purpose I/Oports.

If the microcontroller is a version thatcontains internal ROM that containsprogram code and data, it can be run ininternal or single-chip mode. Ports 0through 4 can be used as general purposeI/O pins. The emulator bondout controllerallows operation in this mode. The targetcontroller will be disabled and thebondout controller will take its place.

It will use the emulator RAM to simulatethe ROM. All ports (serial and parallel)will be free for use by the target system.The internal CPU busses will be madeavailable to the emulator providing highperformance and visibility. The Destina-tion, Source and Value fields in Figure 4are examples of internal busses madevisible. A bondout chip can emulate bothinternal and external modes and uses noresources from the controller. Not allemulators are capable of this.

Hooks & Enhanced Hooks ChipsHooks and Enhanced Hooks chips takeadvantage of unused cycle times onvarious pins to provide the address anddata busses. Hooks and Enhanced Hookschips are used with the Infineon C500

family, Philips, and Intel 8051 parts for bothinternal and external modes. Interestingly,these chips are also standard productionchips. This increases emulation accuracysince the emulation chips are the sameused in regular production.

All Infineon C500 production chips haveEnhanced Hooks support built in. Figure5 is the Nohau Enhanced Hooks pod withthe C517A daughterboard installed.Shown are other daughterboards. Thesepods connect to the standard NohauEMUL51 emulator. Production chipemulators can emulate these 8051 partsonly in external mode so are not popular.

Standard Production ChipsThe emulator needs information from, andalso needs to control the target controller.This is done via the address and databusses and various control signals suchas interrupt and read and write pins. Sinceinternal information is not normallypresented on these busses during runtime, it is not available in real-time. Theemulation must be halted, the internalregisters must be read and stored andemulation continued. This results inunacceptable intrusion times. These typesof emulators make excellent tools if theaccess restrictions are acceptable.

Advantages are the same emulation chipas production, easy changing of samefamily processors and low cost emulators.

Figure 3

ICE Technology, Nohau 800.686-6428 or 650.375.0409 www.icetech.com sales@icetech.com

BDM: Background Debug ModeThis is a Motorola scheme using adedicated serial port to gain access to aspecial debug module inside the micro-controller. This module operates parallelto the microcontroller and generally usesno resources. It has access to internalregisters and memory and can control theCPU. Some models have two hardwarebreakpoints for ROM operation. Figure 6 isthe Nohau HC12 BDM emulator.

A BDM emulator does not have a tracememory, triggers or emulation memory. ABDM emulator is sometimes used inconjunction with a full emulator. It canprogram FLASH and EEPROM into theHC12 controller in your target system.

You can load a program and single-stepor run the target processor. Source codewill be visible for HLL debugging. Youcan set software breakpoints (hardware inHC12) and view memory in real-time.

Variable, arrays and structures are viewedin a variety of formats. The emulator runsat full clock speed. A BDM emulator ismore robust than a monitor, but with lessfeatures than a full emulator.

JTAG and OCDS DebuggingThe higher speeds and complexity ofsome microprocessors has encouragedchip makers to incorporate debuggingfacilities on-chip. The BDM is oneexample. The JTAG interface wasdesigned to facilitate testing circuit boardconnections between large chips. This is aserial connection and signals can be sentto and read from I/O ports. This is alsocalled the JTAG Boundary Scan becausethe serial data scans the outside I/O pinsof the chip. A pattern sent from one chipto the next can be then compared to checkif the circuit board connections are intact.Since the JTAG port is unused duringnormal chip operation, and since it runs in

parallel to the controller’s CPU, it canaccess an on-chip debugging module inreal-time similar to the BDM interface.This debug module is called OCDS (On-Chip Debugging Support) in the newerInfineon microcontrollers such as theC161U and the UTAH. This module hasdirect access to the CPU core. Manufac-turers such as Motorola also use thisapproach in the PowerPC and some 68K.The ARM7 also uses a JTAG accesseddebugging module. Nohau supports theInfineon OCDS and ST MicroelectronicsOCE protocols. It is possible to build a fullemulator using a combination of the OCDSand standard trace and trigger hardwaregiving high performance.

No target or CPU resources usedMonitor kernels typically need about 10KROM and 10-20 bytes RAM and a freecommunication port. A good emulatoruses none of these. The emulator shouldbe invisible to the target. Better emulatorsare and in addition do not steal CPU cycletime for ordinary housekeeping duties.

Getting the Hardware WorkingSimulators are great, but they can not takeall the variables into account. A simulatordesigner has to think of everything: thebig problems are usually those items thatcome up after the hardware is constructed.Items like capacitance, timing, inductance,and chip versions. These become moreimportant as CPU speeds increase. It is avery difficult task to replicate the pipelinefound in many microcontrollers today andis best done with real hardware.

Target monitors are considerably better inthat they run on real hardware. But thetarget system must be a complete workingsystem in order to get the monitor kernel torun. Not so with an emulator. An emulatorwill run with no hardware at all or incom-plete sections. A target monitor can be

installed in the final target ready to beactivated at any time for debugging. Thisis useful for test and repair purposes.Figure 7 is the Nohau EMUL-ST10-PCemulator connected to the Phytec C167CRevaluation board. Evaluation boards arean economical and practical method ofshortening your product developmenttime. It is also a useful reference design.

Connecting to Your Target SystemThis is easy. Most issues will be handledby the board designer in conjunction withyour emulator representative. Connectionto the target is a two step process.

First, the adaptation method must bechosen. Solder-down and socket methodsare preferred. Clip-over adapters arehandy but expensive. Nohau provides theDelta probe. If you need to access thetarget in a hard-to-access area, considerNohau’s Flex Cable. Figure 8 is the adapterfor the Phytec KitCon167 board.

Second, the software and jumper settingson the emulator must be correctly set tomatch the target board and the softwareinitialization routines. This is easy to doand here is where good technical supportcounts. Usually the default settings work.

To connect the Nohau EMUL166 to thePhytec C167CR board, only four socketsneed to be soldered on it and one jumper(AutoMap) needs to be removed on theemulator. In the EMUL-ST10, two chipselects need to be activated with simplemouse clicks. Load the code, and theboard immediately goes into operation!The board behaves as before, but now youhave access to the internal workings ofthe system. You also have powerful traceand trigger features as already described.The same scenario works for other boardsas well as your custom prototype.

Figure 6

ICE Technology, Nohau 800.686-6428 or 650.375.0409 www.icetech.com sales@icetech.com

Hardware BreakpointsA software breakpoint is created byinserting a 2 byte TRAP instruction whichwill divert normal program flow to thedebugger. The program may crash if theprogram counter lands on the second byte.Nohau hardware breakpoints use com-parators to detect accesses to a locationand no code memory contents are modi-fied. Breaks on regions need hardwarebreakpoints. Software breaks are stilluseful and Nohau provides both types.

Software breakpoints are useless withROM memory since a TRAP can not beinserted. Only hardware breakpointsfunction in ROM systems.

Trace MemoryThe Trace records each processor cyclealong with a timestamp and optionallyexternal signal levels. The trace canrecord all code fetches and will distin-guish between instructions that arecancelled in the pipeline and thosesuccessfully executed. False triggering istherefore avoided on unexecuted instruc-tions. Simulators and monitors do nothave trace memory.

Trace Memory: An exampleThe trace window shown in Figure 4 isfrom the EMUL-ST10-PC and resultsfrom the code shown in Figure 9 which isthe source code window. Other emulatorsare similar. This recording was unfilteredand represents all executed instructions.Instructions entering the pre-fetch queue,then cancelled, are not erroneouslyclassified as been executed. They can beusually shown in the trace if desired.

Note the fields available. The trace can befiltered with the triggers so that onlyspecified cycles are recorded. This savestime searching for bugs. You can triggeron specific addresses, data values, andqualifying them as reads or writes and

many other similar qualifiers. The tracememory is a powerful tool, displayingevents as they really happened.

Conditional TriggersThese are extremely powerful and easy touse. They allow you to specify an actionwhen some event happens. The TriggerConfiguration window shown in Figure10 is a basic entry. If a data R/W cyclewith a value from 34 to 4E and in theaddress range from 5000 to 5017 occurs,a trigger event will be created.

The trigger can include address, data,clock cycles and external signals. Thesecan trigger a break, start/stop the tracecapture, record a timestamp or manyother things determined by the emulator’scapabilities. This powerful tool is foundonly in emulators.

Actual Memory and I/O PortsPorts and memory can be viewed from realhardware parts and not simply a softwaresimulation. It is possible to wire yourfavorite peripheral chip to the bottom ofthe emulator pod and access it. Accuratesoftware simulation depends on all thenuances of complex peripherals enteredcorrectly and is hard to achieve.

Often, it seems that problems only developwhen the program is run on the actualhardware. How often does it seem thatthings depend so much on the rise or falltime of some input signal ? Or the routingof a certain wire ? An emulator will helpget your development finished faster by

getting you to this point directly.

Data can be viewed in various forms suchas the graphical types shown in Figure 11,or in several handy numerical formats.

Since the emulator has its own internalRAM which can be substituted for ROM,you can debug and modify the programcode and data easily in ROM systems.

In the same fashion, memory not yetinstalled on the target can be substitutedby the emulator. The size and address ofthis RAM is selectable. The granularity is2 bytes on the EMUL166-PC allowingmapping around any external peripheral.

Performance Analysis in HardwareA debugger can only simulate Perfor-mance Analysis and it does a good job.The emulator goes one step further bydoing the analysis on the real hardwareincreasing accuracy. Once again, usingthe actual hardware will show problemsthat might not be evident in softwaresimulation. Spurious interrupts and otherfunctions that unexpectedly consume CPUresources can cause serious performanceproblems and can be difficult to find.Performance Analysis can easily find suchproblems. Figure 12 shows a PPA display.

ConclusionThis article has provided informationabout In-Circuit Emulators and thebenefits that accrue to you, the designer.You will be better able to select variouscomponents of the cycle depending onyour needs. See www.icetech.com for moreinformation on emulators and how theycan help you debug your projects faster.