Transcript csl.skku.edu

Debugging
1
The embedded lifecycle
The Project
Pre-Prototype
H/W Design Proto
Post-Prototype
Debug
Specification
RTOS Integration
Sys. Test
Mfg.
S/W Design
The Integration “Loop”
Start
Yes
New
Test?
Stop
Yes
Run Test
No
Pass
Test?
No
Debug
Re-design
physical h/w
and/or s/w
Introduction to Embedded Systems
2
A tools view of the lifecycle
Processor Selection Phase
Packaged benchmarks
Past Experience
Other Similar Designs
Applications support
Instruction Set Simulator
Benchmarking tools
Enter Here
Literature
Compiler Tool Chain
Architectural Simulator
Evaluation Board
Customer Benchmarks
Design Phase
Design Win
Hardware Designer(s)
Software Design Team
ASIC
Compiler Tool Chain
Instruction Set Simulator
Evaluation Board
Logic Simulator
Logic Analyzer
Out-of-Circuit Emulation
Oscilloscope
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
Introduction to Embedded Systems
Courtesy of
Daniel Mann
3
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
4
“Typical” embedded system
Real World Interactive Peripheral Devices
Embedded Target System
To
Host
Serial Port
uP
RAM
Glue Logic
ROM
Buffers
Address Decode
Interrupt Control
Watchdog Timer
Reset Circuitry
Clocks
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
6
Debug kernel ( continued )
•
A debug kernel implements the Run Control function
-
•
•
•
•
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
-
•
Examine/modify memory or registers
Single step
Run to breakpoint
Load code
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
7
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
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
………
………
instruction n-1
trap vector to debugger entry point
instruction n+1
………
………
instruction n
Introduction to Embedded Systems
Moved to the debugger
database for safe keeping
8
Debug monitor
HOST-BASED DEBUGGER PROGRAM
- Knowledge of source files
- Knowledge of object files
> Symbol Table
> Cross reference files
SYSTEM ROM
CODE PARTITION
Power on
reset code
0xFFFFF
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
Main chassis- Overlay memory
- Trace Capability
- System control and host interface
Target system
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-tomemory 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
15
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
17
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
Emulator
Host Computer
Target system
Introduction to Embedded Systems
19
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
Target System ADDR BUS
Dual-ported
“memory
From control
processor
“MAILBOX”
Overlay
RAM
DATA
ADDR
Memory Mapper
Memory
Space
Control
Target System
Status Bus
uP
STATUS
NMI
SHADOW
ROM ce
NMI
Control
Logic
ce
USER
NMI
Introduction to Embedded Systems
Emulator
NMI Input
“BREAK”
Process of Run Control ( Background )
•
“BREAK” signal generates system NMI
-
•
Break signal can be generated by various events
-
•
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
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
0x00000
A14..A31
Memory
Mapper
256K x 18
eA14..eA31
( D0..D17 )
0x3FFFF
uP
D0………..…………...D17
To target system
and emulation
memory
A0..A13
Introduction to Embedded Systems
25
Overlay memory system
To emulation BREAK control logic
To Target Data Bus Buffers
A0.A31
from
Target uP
R/W
CE
MUX
A0.A31
from
Emulation
System
Very
High-Speed
Mapper
RAM
Array
A0..A31
D0..D31
Emulation Memory
High-speed
Static Memory
Array
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
T1
T2
Memory Write Cycle
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
28
Anatomy of a trace system
ADDR OUT
00000
00001
BREAK
OUTPUTS
TRACE TRIGGER LOGIC
00002
........
00003
FFFFF
Control Bus
D0..D166
To Target Address, Data, Status, Peripheral Busses
R/W
Introduction to Embedded Systems
To Control System
Real time trace system
• Trace system runs continuously
• Trace memory is a circular buffer
- New processor state data is always overwriting old data
FFFFF
00000
• Trigger point determines when to stop overwriting
• Enables the trace to record events prior to the trigger point
States before trigger
States after trigger
Trigger point
Introduction to Embedded Systems
30
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 >
Base
1
ADDR
> Hex
010198
SYMBOL
Symbol
FIB.S:_fib+008
DATA
Hex
49608602
STAT
_RAS
_WE
Symbol
Binary
Binary
200. :idle
1110
Introduction to Embedded Systems
1
TR
Binary
0
31
Setting up a trace specification
IF ADDR=ErrorHandler AND Data=Fault AND Status=WRITE
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
THEN
Level 1
Level 2
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
32
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
33
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
34
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
36
Processor Volume
To Infinity
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
Chip vendor’s heaven
Tool vendor’s heaven
To Infinity
Design Starts
Introduction to Embedded Systems
37
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 tools @ first-silicon availability
• Tool vendor wants to wait to see if chip will sell
Introduction to Embedded Systems
38
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 1992-1994
- 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 nonsequential instruction fetch?
Introduction to Embedded Systems
41
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
42
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
47
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
48
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
49
JTAG-based debug kernel
Program Counter - PC
JTAG out
Status Bus Interface
Register R1
JTAG Control
State Machine
Register R2
Processor Core
Register Rn
Addr Bus Interface
Clock in
JTAG in
“SPECIAL” REGISTER SET
Data Bus Interface
Introduction to Embedded Systems
50
More on JTAG
•
•
JTAG has basically become the defacto standard for on-chip debug
Very cost effective
-
•
•
Debug capability is defined by features of debug core
Can be slow
-
•
•
•
Can be re-programmed to support multiple processor families
Typically priced under $1000
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
51
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
52
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
53
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
54
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
Base > Hex
1
010198
SYMBOL
Symbol
FIB.S:_fib+008
DATA
Hex
49608602
STAT
_RAS
_WE
TR
Symbol Binary Binary Binary
200. :idle 1110
1
0
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”
Start
Yes
New
Test?
Stop
Yes
Run Test
No
Pass
Test?
No
Debug
Re-design
physical h/w
and/or s/w
Introduction to Embedded Systems
61
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
62
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
63
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
64
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
65
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
66
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
67
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
-
•
What if the performance doesn’t meet the design requirements
-
•
Inefficient performance is masked by processor power and modest target
system 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
Performance Demand
What about the low duty cycle failures ( ~1 per week or less)
Introduction to Embedded Systems
68