IN-CIRCUIT EMULATOR

In-circuit emulation (ICE) is the use of a hardware device or in-circuit emulator

used to debug the software of an embedded system. It operates by using a
processor with the additional ability to support debugging operations, as well as
to carry out the main function of the system. Particularly for older systems, with
limited processors, this usually involved replacing the processor temporarily
with a hardware emulator: a more powerful although more expensive version. It
was historically in the form of bond-out processor which has many internal
signals brought out for the purpose of debugging. These signals provide
information about the state of the processor.
More recently the term also covers Joint Test Action Group (JTAG) based
hardware debuggers which provide equivalent access using on-chip debugging
hardware with standard production chips. Using standard chips instead of
custom bond-out versions makes the technology ubiquitous and low cost, and
eliminates most differences between the development and runtime
environments. In this common case, the in-circuit emulator term is a misnomer,
sometimes confusingly so, because emulation is no longer involved.
Embedded systems present special problems for programmers because they
usually lack keyboards, monitors, disk drives and other user interfaces that are
present on computers. These shortcomings make in-circuit software debugging
tools essential for many common development tasks.
Function
An in-circuit emulator (ICE) provides a window into the embedded system. The
programmer uses the emulator to load programs into the embedded system, run
them, step through them slowly, and view and change data used by the system's
software.
An emulator gets its name because it emulates (imitates) the central processing
unit (CPU) of the embedded system's computer. Traditionally it had a plug that
inserts into the socket where the CPU integrated circuit chip would normally be
placed. Most modern systems use the target system's CPU directly, with special
JTAG-based debug access. Emulating the processor, or direct JTAG access to it,
lets the ICE do anything that the processor can do, but under the control of a
software developer.

ICEs attach a computer terminal or personal computer (PC) to the embedded

system. The terminal or PC provides an interactive user interface for the
programmer to investigate and control the embedded system. For example, it is
routine to have a source code level debugger with a graphical windowing
interface that communicates through a JTAG adapter (emulator) to an embedded
target system which has no graphical user interface.
Notably, when their program fails, most embedded systems simply become inert
lumps of non-functioning electronics. Embedded systems often lack basic
functions to detect signs of software failure, such as an memory management
unit (MMU) to catch memory access errors.
In usage, an ICE provides the programmer with execution breakpoints, memory
display and monitoring, and input/output control. Beyond this, the ICE can be
programmed to look for any range of matching criteria to pause at, in an attempt
to identify the origin of a failure.
Example
ICE example is shown using flow diagram

Advantages
Virtually all embedded systems have a hardware element and a software
element, which are separate but tightly interdependent. The ICE allows the
software element to be run and tested on the hardware on which it is to run, but
still allows programmer conveniences to help isolate faulty code, such as
source-level debugging (which shows a program as it was originally written)
and single-stepping (which lets programmers run programs step-by-step to find
errors).
Most ICEs consist of an adaptor unit that sits between the ICE host computer
and the system to be tested. A pin header and cable assembly connects the
adaptor to a socket where the actual central processing unit (CPU) or
microcontroller mounts within the embedded system. Recent ICEs enable
programmers to access the on-chip debug circuit that is integrated into the CPU
via JTAG or background debug mode interface (BDM) to debug the software of
an embedded system.
Compiler
A compiler is a computer program (or a set of programs) that transforms source
code written in a programming language (the source language) into another
computer language (the target language), with the latter often having a binary
form known as object code.[1] The most common reason for converting a
source code is to create an executable program.

The name "compiler" is primarily used for programs that translate source code
from a high-level programming language to a lower level language (e.g.,
assembly language or machine code). If the compiled program can run on a
computer whose CPU or operating system is different from the one on which
the compiler runs, the compiler is known as a cross-compiler. More generally,
compilers are a specific type of translator.
A program that translates from a low level language to a higher level one is a
decompiler. A program that translates between high-level languages is usually
called a source-to-source compiler or transpiler. A language rewriter is usually a
program that translates the form of expressions without a change of language.
The term compiler-compiler is sometimes used to refer to a parser generator, a
tool often used to help create the lexer and parser.
A compiler is likely to perform many or all of the following operations: lexical
analysis, preprocessing, parsing, semantic analysis (syntax-directed translation),
code generation, and code optimization. Program faults caused by incorrect
compiler behavior can be very difficult to track down and work around;
therefore, compiler implementors invest significant effort to ensure compiler
correctness.
Structure of a compiler
Compilers bridge source programs in high-level languages with the underlying
hardware. A compiler verifies code syntax, generates efficient object code,
performs run-time organization, and formats the output according to assembler
and linker conventions. A compiler consists of:
The front end: Verifies syntax and semantics, and generates an intermediate
representation or IR of the source code for processing by the middle-end.
Performs type checking by collecting type information. Generates errors and
warning, if any, in a useful way. Aspects of the front end include lexical
analysis, syntax analysis, and semantic analysis.
The middle end: Performs optimizations, including removal of useless or
unreachable code, discovery and propagation of constant values, relocation of
computation to a less frequently executed place (e.g., out of a loop), or
specialization of computation based on the context. Generates another IR for the
backend.

The back end: Generates the assembly code, performing register allocation in
process. (Assigns processor registers for the program variables where possible.)
Optimizes target code utilization of the hardware by figuring out how to keep
parallel execution units busy, filling delay slots. Although most algorithms for
optimization are in NP, heuristic techniques are well-developed.
Compiler output
One classification of compilers is by the platform on which their generated code
executes. This is known as the target platform.
A native or hosted compiler is one which output is intended to directly run on
the same type of computer and operating system that the compiler itself runs on.
The output of a cross compiler is designed to run on a different platform. Cross
compilers are often used when developing software for embedded systems that
are not intended to support a software development environment.
The output of a compiler that produces code for a virtual machine (VM) may or
may not be executed on the same platform as the compiler that produced it. For
this reason such compilers are not usually classified as native or cross
compilers.
Debugger
A debugger or debugging tool is a computer program that is used to test and
debug other programs (the "target" program). The code to be examined might
alternatively be running on an instruction set simulator (ISS), a technique that
allows great power in its ability to halt when specific conditions are
encountered. but which will typically be somewhat slower than executing the
code directly on the appropriate (or the same) processor. Some debuggers offer
two modes of operationfull or partial simulationto limit this impact.
A "trap" occurs when the program cannot normally continue because of a
programming bug or invalid data. For example, the program might have tried to
use an instruction not available on the current version of the CPU or attempted
to access unavailable or protected memory. When the program "traps" or
reaches a preset condition, the debugger typically shows the location in the
original code if it is a source-level debugger or symbolic debugger, commonly
now seen in integrated development environments. If it is a low-level debugger
or a machine-language debugger it shows the line in the disassembly (unless it

also has online access to the original source code and can display the
appropriate section of code from the assembly or compilation).
Features
Typically, debuggers offer a query processor, a symbol resolver, an expression
interpreter, and a debug support interface at its top level. [1] Debuggers also offer
more sophisticated functions such as running a program step by step (singlestepping or program animation), stopping (breaking) (pausing the program to
examine the current state) at some event or specified instruction by means of a
breakpoint, and tracking the values of variables.[2] Some debuggers have the
ability to modify program state while it is running. It may also be possible to
continue execution at a different location in the program to bypass a crash or
logical error.
The same functionality which makes a debugger useful for eliminating bugs
allows it to be used as a software cracking tool to evade copy protection, digital
rights management, and other software protection features. It often also makes it
useful as a general verification tool, fault coverage, and performance analyzer,
especially if instruction path lengths are shown
Some debuggers operate on a single specific language while others can handle
multiple languages transparently. For example if the main target program is
written in COBOL but calls assembly language subroutines and PL/1
subroutines, the debugger may have to dynamically switch modes to
accommodate the changes in language as they occur
Reverse debugging
Some debuggers include a feature called "reverse debugging", also known as
"historical debugging" or "backwards debugging". These debuggers make it
possible to step a program's execution backwards in time. Various debuggers
include this feature. Microsoft Visual Studio (2010 Ultimate edition, 2012
Ultimate, 2013 Ultimate, and 2015 Enterprise edition) offers IntelliTrace
reverse debugging for C#, Visual Basic .NET, and some other languages, but not
C++. Reverse debuggers also exist for C, C++, Java, Python, Perl, and other
languages. Some are open source; some are proprietary commercial software.
Some reverse debuggers slow down the target by orders of magnitude, but the

best reverse debuggers cause a slowdown of 2 or less. Reverse debugging is

very useful for certain types of problems, but is still not commonly used yet.
Hardware support for debugging
Most modern microprocessors have at least one of these features in their CPU
design to make debugging easier:
Hardware support for single-stepping a program, such as the trap flag.
An instruction set that meets the Popek and Goldberg virtualization
requirements makes it easier to write debugger software that runs on the same
CPU as the software being debugged; such a CPU can execute the inner loops
of the program under test at full speed, and still remain under debugger control.
In-system programming allows an external hardware debugger to reprogram
a system under test (for example, adding or removing instruction breakpoints).
Many systems with such ISP support also have other hardware debug support.
Hardware support for code and data breakpoints, such as address comparators
and data value comparators or, with considerably more work involved, page
fault hardware.[5]
JTAG access to hardware debug interfaces such as those on ARM architecture
processors or using the Nexus command set. Processors used in embedded
systems typically have extensive JTAG debug support.
Micro controllers with as few as six pins need to use low pin-count
substitutes for JTAG, such as BDM, Spy-Bi-Wire, or debugWIRE on the Atmel
AVR. DebugWIRE, for example, uses bidirectional signaling on the RESET
pin.