Debugging.

Debugging

The embedded lifecycle
The Project Pre-Prototype Post-Prototype H/W Design Proto Debug Specification RTOS Integration Sys. Test Mfg. S/W Design The Integration “Loop” Yes No New Test? Yes Pass Test? Debug Start Run Test Re-design physical h/w and/or s/w Stop No Introduction to Embedded Systems

Introduction to Embedded Systems
A tools view of the lifecycle Processor Selection Phase Enter Here Packaged benchmarks Past Experience Other Similar Designs Applications support Instruction Set Simulator Benchmarking tools Literature Compiler Tool Chain Architectural Simulator Evaluation Board Design Phase Customer Benchmarks Design Win Software Design Team Hardware Designer(s) ASIC Compiler Tool Chain Logic Simulator Logic Analyzer Oscilloscope Instruction Set Simulator Evaluation Board Out-of-Circuit Emulation Initial hardware without working memory system Initial Software Logic Analyzer In-Circuit Emulator Oscilloscope Software running on Hardware Software Performance Analysis In-Circuit Emulation Logic Analyzer/Preprocessor JTAG Emulation ROM Emulation MiniMON29K SW/HW Integration Phase Maintenance and upgrade of existing products Courtesy of Daniel Mann Introduction to Embedded Systems

Debugging embedded system
Hardware/software integration The separate hardware designers, firmware designers and software designers have completed unit testing their code The hardware has been built and passes the smoke test The hardware is turned over to the software team Load the software image Validate the correctness of the hardware performance against the software design Integrate their software with the hardware Find the bugs Test for performance and reliability Introduction to Embedded Systems

“Typical” embedded system
Real World Interactive Peripheral Devices Embedded Target System To Host Serial Port uP RAM Glue Logic Buffers Address Decode Interrupt Control Watchdog Timer Reset Circuitry Clocks ROM Introduction to Embedded Systems

Debug kernel Debug monitor is the simplest way to debug an embedded system Consists of a block of code that may be: Linked to the user’s code when the image is formed Loaded separately, but takes over the key ISR vectors’ Resident in ROM Communicates with the host over a serial ( RS-232, Ethernet ) link Can override program execution by nature of a higher priority interrupt assignment Susceptible to hardware flaws in the target system Can be trashed by runaway code Requires a Board Support Package ( BSP ) or at least some rudimentary knowledge of the hardware Requires a system resource ( serial port ) in order to communicate with the host computer Introduction to Embedded Systems

Debug kernel ( continued )
A debug kernel implements the Run Control function Examine/modify memory or registers Single step Run to breakpoint Load code Cannot, in general, trace in real time Cannot set a breakpoint in ROM Debug kernel is a serious perturbation to a real-time system Generally, the entire application stops running when debugger takes over Interrupts are disabled Debuggers from RTOS vendors are capable of task-specific debugging That’s why you pay the big bucks Introduction to Embedded Systems

Debug kernel ( continued )
When executing under the debugger, code does not run at full speed Debugger can co-exist with real time interrupts through careful assignment of interrupt priority levels Example of debugger functionality, setting a breakpoint: Each time single step is executed the complete machine context must be save and restored Code image in memory: after ……… instruction n-1 trap vector to debugger entry point instruction n+1 instruction n Code image in memory: before ……… instruction n-1 instruction n instruction n+1 ………. Want to set breakpoint here Debugger inserts trap vector in place of instruction Moved to the debugger database for safe keeping Introduction to Embedded Systems

Debug monitor HOST-BASED DEBUGGER PROGRAM - Knowledge of source files - Knowledge of object files > Symbol Table > Cross reference files SYSTEM ROM CODE PARTITION 0xFFFFF Power on reset code Serial Port ISR Debug Kernel Application Program Software debug trap vector SERIAL COMM LINK Serial Port Int. Vector 0x00000 Introduction to Embedded Systems

Debug monitors: Advantages
Low cost: $0 to <$1K Same debugger can be used with remote kernel or on host Provides most of the services that software designer needs Simple serial link is all that is required Can be used with “virtual” serial port Can be linked with user’s code for ISR’s and field service Good choice for code development when hardware is stable Can easily be integrated into a design team environment Introduction to Embedded Systems

Debug Monitor: Disadvantages
Depends upon a stable memory subsystem in the target Not suitable for initial hw/sw integration Not “real time” System performance may differ with a debugger present Difficulty in running out of ROM-based memory Can’t single step or insert breakpoints Requires that the target has additional services For many target systems this is an unacceptable cost Debugger may not always have control of the system Depends upon code being “well behaved” Introduction to Embedded Systems

ROM Emulation Provides a simple and fast way to download ROM-based code into a target system via the ROM socket Provides a virtual UART function to enable debugger to host communications for target systems that lack a serial port LAN, serial or parallel Simple plug-in probe substitutes for system ROMs Target system Main chassis- - Overlay memory - Trace Capability - System control and host interface Introduction to Embedded Systems

ROM Emulation: Advantages
Very cost-effective ( $1K - $5K ) Generic tool, compatible with many different memory configurations High-speed download to target system of large blocks of code Most cost-effective way to support large amounts of overlay memory Can trace ROM code activity in real time Provides “virtual UART” function, eliminating need for additional services in target system Can be integrated with other hw/sw integration tools Can set breakpoints in “ROM” Normally cannot do this in most target systems Introduction to Embedded Systems

ROM Emulation: Disadvantages
Requires that the target system memory is in a stable condition Only works if embedded code is contained in “standard ROM memories” Special ASIC’s Microcontrollers with onboard ROM’s ( ie 8751 ) Real time trace is possible only if program executes directly out of ROM memory Many targets transfer code to RAM for performance reasons Introduction to Embedded Systems

Hardware-assisted debug
Real time debugging places special requirements on tools designed to control and observe the behavior of embedded systems Software debug monitors are ineffective when the processor-to-memory interface is not functional Can be destroyed by code running wild Transitory real time events with low duty cycles cannot be observed Debug monitor can perturb the target system and may interfere or prevent its operation Specialized tools have evolved to address the needs of real time system debugging Premier ( read expensive! ) tool is the In-Circuit Emulator ( ICE ) ICE provides absolute control of the processor under all conditions Introduction to Embedded Systems

In-Circuit Emulator ( ICE )
An ICE provides an integration of the most important functions required to debug embedded systems Run Control Overlay Memory Real Time Trace Run control Similar to the functionality of a software debug kernel Peek/poke memory Modify registers Single step Set breakpoints Disassemble memory code Download code Introduction to Embedded Systems

In-Circuit Emulator ( continued )
Overlay memory Similar to functionality of ROM emulator Provides overlay ( substitution ) memory for target system memory Entire memory space can be “mapped” to provide memory regions in memory anywhere in the address space of the target processor Emulation memory can be interspersed with target system memory Emulation memory can be assigned special attributes ROM ( no writes allowed ) Guarded ( break on write ) Code space or data space Shared memory ( simulated I/O ) Introduction to Embedded Systems

In-Circuit Emulators (ICE )
Host computer runs emulator control software - Provides run control - Displays real time trace at source level - Loads overlay memory with object code - High-speed link to emulation chassis Typical vendors - Applied Microsystems - Hewlett-Packard - Kontron - Microtek Probe head contain emulation microprocessor - Substitutes for, or disables target microprocessor - Contains run control circuitry and cable buffers - May contain memory mapping hardware Target system Main chassis - Contains emulation ( overlay memory ) - Trace analysis hardware and trace memory - Performance analysis hardware ( SPA ) - Power supply - Control and communications Introduction to Embedded Systems

A typical engineer with emulator
Host Computer Typical engineer Target system Introduction to Embedded Systems

Run Control Absolute control of the microprocessor under all conditions Unstable hardware Unstable software Normal functions of a “debug kernel” Single-step Examine/Modify registers Peek/poke memory, I/O ports Software breakpoints Introduction to Embedded Systems

Architecture of emulation run control
1- “BREAK” signal forces an NMI to the uProcessor. 2- NMI Control logic blocks any target NMI and signals the Memory Space Control to swap in the shadow RAM. 3- Processor begins NMI service routine in shadow RAM. Entry point is at the debug monitor. 4- Debug monitor saves the state of the processor and waits for commands from the host via the MAILBOX Target System Data Bus DATA BUS BUFFERS uP Target System ADDR BUS DATA ADDR Memory Mapper STATUS Memory Space Control Target System Status Bus NMI Dual-ported “memory From control processor “MAILBOX” NMI Control Logic Overlay RAM SHADOW ROM ce ce Emulator NMI Input “BREAK” USER NMI Introduction to Embedded Systems

Process of Run Control ( Background )
“BREAK” signal generates system NMI Target system NMI is blocked Target system data buffers are disabled Emulation system ROM ( Background ) is enabled Memory mapper maps NMI vector to emulation ROM debug monitor Processor context is saved Debug monitor loops, waiting for instruction in MAILBOX Break signal can be generated by various events User keyboard action Illegal memory accesses Trace system event Breakpoint set at an address Important to understand that the processor isn’t stopped Introduction to Embedded Systems

Foreground monitor Target system stays alive while monitor program executes Monitor code and interrupt ISRs are linked with user applications Mailbox is mapped into memory space of Target Application Lower priority interrupt is given to emulator Tradeoffs Advantage: Target system is supportable during emulation Disadvantage: Takes effort to link to code, processor not always recoverable A foreground monitor is like a normal debug kernel The emulator circuitry converts the emulator hardware into a virtual serial port Introduction to Embedded Systems

Overlay memory Saves the user the need to continually program ROMs Provides memory to overlay ( replace ) target system memory resources or to temporarily fill memory regions with memory ( substitution ) Requires that host GUI be able to read compiler file output formats COFF, a.out, IEEE695, ELF, DWARF, sigh….. Dual-ported for easy access by control system Mappable in blocks to anywhere in address space Can be assigned attributes, ie, RAM, ROM, GUARDED, NO-MEMORY, Coverage Introduction to Embedded Systems

Concept of a memory mapper
Memory mapper may also map “characteristics” of memory Map memory as ROM, Guarded ( no-writes allowed ) Can also map regions as no-memory Map in 16K Blocks uP Memory Mapper 256K x 18 0x00000 A14..A31 eA14..eA31 ( D0..D17 ) To target system and emulation memory 0x3FFFF D0………..…………...D17 A0..A13 Introduction to Embedded Systems

Overlay memory system Introduction to Embedded Systems
To emulation BREAK control logic To Target Data Bus Buffers A0.A31 from Target uP Very High-Speed Mapper RAM Array R/W CE Emulation Memory High-speed Static Memory Array MUX A0.A31 from Emulation System A0..A31 D0..D31 A0..A31 D0..D31 Address Map data from emulation system To Target uP Data Bus Buffers Introduction to Embedded Systems

Real time trace system Dedicated logic analyzer within the emulator Sophisticated symbolic triggering Linked to run control for HW breakpoints Generate break signal based upon complex sequences of addresses, data and status conditions Knowledge of file formats and link maps for symbolic debug and HLL source debugging Records uP pin state at appropriate phase of processor clock Generally, post processes raw data for ease of understanding Dissassembles raw data Combines with HLL source file Post processed for register inferencing Introduction to Embedded Systems

Tracking processor bus activity
Record the state of the processor busses at each clock cycle Post-processing software reduces the trace data to instructions Memory Read Cycle Memory Write Cycle T1 T2 T3 T1 T2 T3 CLK ADDRESS A0..AN Address Valid Address Valid MREQ RD WR DATA D0..DN Data Valid Data Valid WAIT Introduction to Embedded Systems

Anatomy of a trace system
ADDR OUT 00000 00001 BREAK OUTPUTS 00002 00003 Control Bus TRACE TRIGGER LOGIC FFFFF D0..D166 To Target Address, Data, Status, Peripheral Busses To Control System R/W Introduction to Embedded Systems

Real time trace system Trace system runs continuously Trace memory is a circular buffer New processor state data is always overwriting old data Trigger point determines when to stop overwriting Enables the trace to record events prior to the trigger point 00000 FFFFF States before trigger States after trigger Trigger point Introduction to Embedded Systems

Event system ( Trigger )
Event trigger system in an emulator is used to control tracing of instruction and data flow as well as stopping execution of the processor ( BREAKPOINT ) Trigger event is a single combination of processor states or a sequence of processor states Combination of ADDRESS, DATA, STATUS conditions May be a single event or sequence of events LABEL > ADDR SYMBOL DATA STAT _RAS _WE TR Base > Hex Symbol Hex Symbol Binary Binary Binary FIB.S:_fib :idle Introduction to Embedded Systems

Setting up a trace specification
IF ADDR=ErrorHandler AND Data=Fault AND Status=WRITE Level 1 THEN Emulation User Interface converts High Level Language Symbolic references to actual address and data values IF ADDR=XXXX AND DATA<0xA547 OR DATA=00 Level 2 THEN User can also provide absolute values. The address and data values can be ranges. TRIGGER AFTER 100,000 STATES When qualifiers have been met trigger is enabled and may be set anywhere in the buffer Introduction to Embedded Systems

Real time trace Example of Real Time Trace from HP64700 emulator Note: Prefetch pipeline or instruction cache can distort trace. Why? Introduction to Embedded Systems

Real time trace with source listing
The user interface software has access to the linker symbol table Can intersperse C or C++ source lines with assembly language execution Introduction to Embedded Systems

Ideal Emulator Completely non-intrusive No additional loading Mechanically benign No prop delays Runs transparently Available with first silicon Compatible with all compilers and file formats Rugged, easy to use Inexpensive, enduring value Introduction to Embedded Systems

Economics of development tool support
Silicon vendors ( Motorola, Intel, AMD, Hitachi, Mitsubishi, Infineon, NEC, etc. ) want to develop successful products Cost-effective choice for their customers Sell in large volumes Beat the competition Meet their customers’ needs for highly integrated products Specialized tools, such as In-Circuit Emulators, require large R&D investments to develop Tool vendors want to be able to recover their investment and make a profit by selling enough “seats” of their products Each variation of a microcontroller, or other processor variant, is almost a new emulation design Example: 683XX family has over 100 variant designs Different packages, pinouts, peripheral devices and features Introduction to Embedded Systems

Differing views of the world
Chip vendor wants to move silicon through their foundries Best case scenario is a few customers with very high volumes per design Tool vendor ( compiler, debugger, emulator, etc. ) wants to sell seats to designers A successful chip design means different things to both groups To Infinity Chip vendor’s heaven Processor Volume Tool vendor’s heaven To Infinity Design Starts Introduction to Embedded Systems

Economics of development tool support(2)
Embedded chips from silicon vendor will not be successful in the marketplace without high-quality development tool support and tool partners ( Applied Microsystems, Wind River, HP, etc. ) Silicon vendors don’t want to be dependent upon garage-shop suppliers for development tools Tool vendors need some guarantee of sales before they will support a chip Silicon vendors would like at least two high-quality tool suppliers for each tool in the tool chain Tool vendors want to maximize their individual sales ( exclusivity! ) Silicon vendor wants first-silicon availability Tool vendor wants to wait to see if chip will sell Introduction to Embedded Systems

Technical challenges to emulation design
Highly integrated microcontroller designs obscure access to control and observation Internal processor speeds are too fast for tightly-coupled external control schemes Greater control is gained at the expense of non-intrusiveness 68-pin DIP packages on 0.1” centers is but a fond memory Must be able to connect to 500 pin BGA and 256-pin SMT packages on 0.009” centers Instruction and data caches in microprocessors prevent real-time trace analyzers (bus analysis) from providing accurate data Introduction to Embedded Systems

Challenges to Real-time Trace Systems
Excedrin Headache #1 - Prefetch Queues Excedrin Headache #2 - Cached processors Limit of usefulness: Both possible branch destinations are within the cache Solution: Create dedicated on-chip resources to support real-time trace Intel: Bondout chips Motorola: Instruction flow status bits AMD: Traceable cache National: Program Counter bondout Introduction to Embedded Systems

Bond-out chips Provide special versions of the silicon to partners to enable them to develop tools to support silicon features that are normally difficult or impossible to support Extremely costly to create small volumes of different chips If the tool vendor is also the chip vendor, then bond-out features could lock-out any competition Called the “scotched earth” approach Led to the Intel/AMD lawsuit of Generally not practiced by silicon vendors ( except Texas Inst. ) National Semiconductor bonded-out the program counter (PC) Provided the address of non-sequential instruction fetches What is the significance of knowing the address of a non-sequential instruction fetch? Introduction to Embedded Systems

Bond-out chips (continued)
AMD (29K) developed “traceable cache” technology Run two microprocessors in lockstep with one microprocessor as “MASTER” and the other as “SLAVE” Tie their data busses together Execute the program The SLAVE microprocessor will output the current value of the program counter on its address bus, bypassing the cache Emulation or logic analysis tools can track the actual PC Introduction to Embedded Systems

Summary: ICE Advantages
The premier tool for embedded system hw/sw integration Provides all the functionality needed for connectivity, observation and control of an embedded system Control of the microprocessor is guaranteed, independent of the state of the target system hardware Overlay memory substitutes for the target system ROM to permit trace of code execution Traces program flow Filter out extraneous bus activity ( pre-fetches ) Special circuitry can display cache activity Tightly integrated through a single user interface on host Can provide very unique and valuable measurements SPA, RTOS tracing Introduction to Embedded Systems

ICE: Disadvantages Not always most cost-effective solution Can be extremely expensive ( ~ $20K ) Costly to equip a team of designers New emulator often required for new processor or upgrade Viewed as a complex and fragile instrument Availability usually lags early silicon Cannot easily track microcontroller variants Connectivity to surface-mounted processors is very difficult, and the problem is getting worse Viewing cached program activity can be very difficult ( or, at worst ) impossible Not the tool of choice for code design at the upper levels of abstraction Introduction to Embedded Systems

Chip vendors to the rescue
Without development tools they can’t sell embedded microprocessors It’s the fabs, Stupid! Dedicate a portion of uP silicon real estate to support external debug and development tools Motorola: Background Debug Mode ( BDM ) and JTAG AMD, Intel: JTAG ARM: Modified JTAG MIPS: Extended JTAG ( EJTAG ) Run control and limited breakpoint logic supported internally and accessed through serial port All these variant technologies can be summarized as N-Wire debug interfaces Introduction to Embedded Systems

N-Wire Emulation tools
Disadvantages Most only provides run control Feature set limited to what Si vendor provides Can be very slow No support for overlay memory No access to other busses LAN, serial or parallel Translates LAN data stream to n-wire commands n-wire connection to debug circuitry built into processor Advantages Simple mechanical connection Runs with uP on target Independent of uP variants Simple to design tools Low-cost, reuseable, simple Silicon vendor bears cost of support Target system Introduction to Embedded Systems

Joint Test Action Group (JTAG)
JTAG was originally developed as a board test methodology to replace expensive “bed of nails” testers Link all of the outputs of all the digital devices on a PC board with one long serial bit chain 100’s to 1000’s of bits Can observe whether any circuit node is stuck high, low, is shorted or disconnected While very tedious, JTAG serial streams is cost effective and supplies all of the information necessary to test a board without a BON tester Introduction to Embedded Systems

JTAG IEEE1149.1 Each JTAG cell “sniffs” the state of the corresponding output bit of the IC JTAG Connector JTAG bit stream in JTAG bit stream out PC Board Bit stream forms one long shift-register Introduction to Embedded Systems

Bright idea: JTAG can be a debug protocol
Link all the internal registers and other important circuit blocks in a JTAG loop Provide the capability to drive the output as well as sniff it Add internal debug registers that are accessible via JTAG Result is an N-Wire style, on-chip debug capability, that is built around the JTAG standard Can provide a low-cost standard debug interface, independent of chip variations Great for silicon vendors and end users One low-cost ( <$100 tool ) supports any JTAG-compatible device Not so great for tool vendors Introduction to Embedded Systems

JTAG-based debug kernel
Clock in JTAG out JTAG in Program Counter - PC Status Bus Interface Register R1 JTAG Control State Machine Addr Bus Interface Register R2 Processor Core “SPECIAL” REGISTER SET Register Rn Data Bus Interface Introduction to Embedded Systems

More on JTAG JTAG has basically become the defacto standard for on-chip debug Very cost effective Can be re-programmed to support multiple processor families Typically priced under $1000 Debug capability is defined by features of debug core Can be slow Bus cycles must be constructed by laboriously shifting every bit Loops can be extremely long ( ~10,000 bits ) Method of choice for embedded processors in ASIC cores Lends itself to RISC processors because core logic tends to be simpler than CISC Still is design-intensive because JTAG loops must be hand crafted Respinning processor core creates new loops Introduction to Embedded Systems

Enter Nexus Consortium
The Nexus 5001 Forum™, formerly known as the Global Embedded Processor Debug Interface Standard Consortium, was formed in April 1998 to define and develop a much-needed embedded processor debug interface standard for embedded control applications. In September 1999, the group chose the IEEE Industry Standards and Technology Organization (IEEE-ISTO) for its unique forum and support services to facilitate its efforts to advance the development, marketing, validation, and implementation initiatives in support of IEEE-ISTO 5001™-1999. IEEE-ISTO 5001TM -1999, The Nexus 5001 ForumTM Standard for Global Embedded Processor Debug Interface is an open industry standard that provides a general-purpose interface for the software development and debug of embedded processors. The standard is available for download from this site at no charge. Introduction to Embedded Systems

ISTO-5001 A consortium of over 20 semiconductor manufacturers and support tool vendors Defines a standard interface for the debug core and the communications protocol between the tool and the silicon Scalable Processor cores can support various levels of performance Added features add silicon complexity Simple 8-bit processors would not require large debug cores Also scalable in the number of pins dedicated to debug More pins allow greater throughput for trace functionality Private messaging system allows selected tool vendors to take advantage of special features in debug core, such as performance registers, breakpoint registers, etc. Can mimic all of the functionality of an In-Circuit Emulator Run control, real-time trace, instruction substitution Introduction to Embedded Systems

Future of ISTO-5001? The standard is still in its infancy No 5001-conformant silicon is on the market today Several companies have chips under development Several major chip vendors do not belong AMD, Intel The desire for the standard is not widespread among users of embedded microprocessors Being “driven” by automotive industry No compliance testing methodology in existence Introduction to Embedded Systems

N-wire emulation: Advantages
Very cost effective ( < $1K - $5K ) Completely generic, configured by software Complexity is carried by support circuitry in uP Provides absolute run control Download code Start, stop, examine registers, single step If JTAG compatible design, then can be integrated into a manufacturing and test strategy for the entire target system Introduction to Embedded Systems

N-wire Emulation: Disadvantages
If poorly implemented, it can be very slow Requires silicon support to work Overhead carried by every uP sold Features do not support real-time trace or overlay memory Requires a 10-pin ( typical ) connector on the target system Introduction to Embedded Systems

Logic Analyzer Interface software, running on the host, enables LA to do real-time trace analysis and display at the C source level Typical vendors: - HP - Tektronix - Corelis Identical ( or slave processor ) mounted on pre-processor LAN Preprocessor module buffers appropriate signals and assigns them to LA channels Target processor is removed or disabled Mainframe: - Customized software to configure it for particular uP Target system Introduction to Embedded Systems

Logic Analyzer ( Continued )
Once considered the tool of choice for digital hardware design, the LA is becoming a powerful tool for the software designer Can display data as state or timing: State display: Data capture is synchronous to processor clock: LABEL > ADDR SYMBOL DATA STAT _RAS _WE TR Base > Hex Symbol Hex Symbol Binary Binary Binary FIB.S:_fib :idle Introduction to Embedded Systems

Logic Analyzer: Advantages
Probably the most prevalent tool used for digital system design Very powerful measurement and triggering capabilities Generic, easily customized with a proe-processor module LAN capability links the LA to hosts and high-level measurements Deep trace capability Totally configurable to any current microprocessor > 200 channels, > 1GHz data rates Can observe entire digital system at the same time Can be used in conjunction with instrumented code for real time measurements in cached processors Introduction to Embedded Systems

Logic Analyzer: Disadvantages
Can be very expensive Has the same connectivity problems as emulator Strictly passive, cannot provide control of processor Complex Currently, not well-integrated into a software design environment Must be combined with other tools for a complete solution Cached processors cannot be observed with silicon support Code must be instrumented if cache is not visible Introduction to Embedded Systems

Debugging embedded systems
Debugging embedded systems is made more difficult because of the added dimension brought about by untested hardware The process of debugging an embedded system is usually referred to as Hardware/Software Integration Identifies this as a unique process The Integration “Loop” Yes No New Test? Yes Pass Test? Debug Start Run Test Re-design physical h/w and/or s/w Stop No Introduction to Embedded Systems

Debugging hardware - 1 Use an oscilloscope to look at the parametric performance of the hardware system Is the power supply voltage stable? Minimal AC ripple Within limits Do the bus signals look clean? Ringing on the waveform is within bounds System noise is within acceptable bounds All busses are properly terminated, no reflections Is the clock(s) distribuition clean? Stable waveform without noise, undershoot or overshoot Clock skew within acceptable limits Introduction to Embedded Systems

Debugging Hardware - 2 Verify that the processor to memory interface is stable Memory set-up times are within acceptable limits Hold times are long enough Proper timing on reads and writes Use an In-Circuit Emulator to force simple memory test programs No need to load a program to test memory Use a Logic Analyzer to look at bus activity to verify that all signals are understood Verify that the memory decoding logic is working properly Introduction to Embedded Systems

Debugging Hardware - 3 Use emulator to force accesses to peripheral devices Memory access conflicts All glue logic PAL equations are correct Read and Write to ASIC registers Read and write to registers of other peripheral devices Use an ICE to load simple HW test programs (diagnostics) Diagnostics will exercise hardware and verify reliability Will not verify functionality Introduction to Embedded Systems

Driver code integration
Next step is to verify that the low-level driver code functions properly Write diagnostics and “throw-away code” to exercise the API’s to the hardware Have the caveat that any problems may be due to hardware failures Develop and test interrupt service routines ( ISR’s ) Best of class tool is the In-Circuit Emulator Software Driver ( Firmware or BIOS ) PROGRAMMER’S API Physical Hardware Introduction to Embedded Systems

RTOS Integration Map the RTOS support services into the actual hardware Write necessary getmem(), crt0(), hw_init() functions Develop the Board Support Package for the RTOS services Establish communications services with host computer Download debug kernel Operating System ( RTOS ) Software Driver ( Firmware or BIOS ) PROGRAMMER’S API Physical Hardware Introduction to Embedded Systems

Application integration
Now must map individual applications into the overall RTOS environment This is where the subtle bugs begin to appear Operating System ( RTOS ) Application Code Software Driver ( Firmware or BIOS ) PROGRAMMER’S API Physical Hardware Introduction to Embedded Systems

When are you done? For many embedded system developers you are done when it seems to work and doesn’t crash at regular intervals Performance demands are modest Inefficient performance is masked by processor power and modest target system requirements What if the performance doesn’t meet the design requirements How do you decide how to improve performance? Two types of performance failures: Time critical failures: System won’t work at all Time sensitive failures: System works, but not up to requirements specifications Other failures may be inadequate system resources when running under full load Malloc() errors What about the low duty cycle failures ( ~1 per week or less) Performance Demand Introduction to Embedded Systems

Debugging.

Similar presentations

Presentation on theme: "Debugging."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Debugging.

Similar presentations

Presentation on theme: "Debugging."— Presentation transcript:

Similar presentations

About project

Feedback