In-circuit emulation

Last updated

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.

Contents

More recently the term also covers 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 bricked. Embedded systems often lack basic functions to detect signs of software failure, such as a memory management unit (MMU) to catch memory access errors. Without an ICE, the development of embedded systems can be extremely difficult, because there is usually no way to tell what went wrong. With an ICE, the programmer can usually test pieces of code, then isolate the fault to a particular section of code, and then inspect the failing code and rewrite it to solve the problem.

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.

Most modern microcontrollers use resources provided on the manufactured version of the microcontroller for device programming, emulating, and debugging features, instead of needing another special emulation-version (that is, bond-out) of the target microcontroller. [1] Even though it is a cost-effective method, since the ICE unit only manages the emulation instead of actually emulating the target microcontroller, trade-offs must be made to keep prices low at manufacture time, yet provide enough emulation features for the (relatively few) emulation applications.

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. These systems often use a standard version of the CPU chip, and can simply attach to a debug port on a production system. They are sometimes called in-circuit debuggers or ICDs, to distinguish the fact that they do not replicate the functionality of the CPU, but instead control an already existing, standard CPU. Since the CPU need not be replaced, they can operate on production units where the CPU is soldered in and cannot be replaced. On x86 Pentiums, a special 'probe mode' is used by ICEs to aid in debugging. [2]

In the context of embedded systems, the ICE is not emulating hardware. Rather, it is providing direct debug access to the actual CPU. The system under test is under full control, allowing the developer to load, debug and test code directly.

Most host systems are ordinary commercial computers unrelated to the CPU used for development. For example, a Linux PC might be used to develop software for a system using a Freescale 68HC11 chip, a processor that cannot run Linux.

The programmer usually edits and compiles the embedded system's code on the host system, as well. The host system will have special compilers that produce executable code for the embedded system, termed cross compilers or cross assemblers.

On-chip debugging

On-chip debugging is an alternative to in-circuit emulation. It uses a different approach to address a similar goal.

On-chip debugging, often loosely termed as Joint Test Action Group (JTAG), uses the provision of an additional debugging interface to the live hardware, in the production system. It provides the same features as in-circuit debugging, such as inspection of internal state or variables and may have the ability to set checkpoints, breakpoints and watchpoints. The difference is that this is provided by additional silicon within the production processor, rather than swapping the processor for an off-board debugging emulator. For this reason, some of the functions of the ICE is changed by the specifications of the processor. An additional JTAG interface is added to the controller board, and this is required on every production system, but as this only requires a few signal pins the extra cost is minimal. JTAG interfaces were originally developed for, and are still useful for, end of production testing.

Intel

To support in-circuit emulator (ICE) debugging on Intel 286, five additional pins were available on the processor: one input pin to externally force an ICE breakpoint, (ICEBP#) and two alternative pairs of output pins to select operations via the ICE-bus instead of user memory. [3] On the 80286 two instructions (0F 04, 0F 05 ) exist to dump/restore the complete CPU state to memory offset 0x800, along with a single-byte override prefix (F1) to enable ICE-mode to access user-memory.

See also

Related Research Articles

<span class="mw-page-title-main">Embedded system</span> Computer system with a dedicated function

An embedded system is a specialized computer system—a combination of a computer processor, computer memory, and input/output peripheral devices—that has a dedicated function within a larger mechanical or electronic system. It is embedded as part of a complete device often including electrical or electronic hardware and mechanical parts. Because an embedded system typically controls physical operations of the machine that it is embedded within, it often has real-time computing constraints. Embedded systems control many devices in common use. In 2009, it was estimated that ninety-eight percent of all microprocessors manufactured were used in embedded systems.

<span class="mw-page-title-main">Debugger</span> Computer program used to test and debug other programs

A debugger or debugging tool is a computer program used to test and debug other programs. The main use of a debugger is to run the target program under controlled conditions that permit the programmer to track its execution and monitor changes in computer resources that may indicate malfunctioning code. Typical debugging facilities include the ability to run or halt the target program at specific points, display the contents of memory, CPU registers or storage devices, and modify memory or register contents in order to enter selected test data that might be a cause of faulty program execution.

<span class="mw-page-title-main">AVR microcontrollers</span> Family of microcontrollers

AVR is a family of microcontrollers developed since 1996 by Atmel, acquired by Microchip Technology in 2016. These are modified Harvard architecture 8-bit RISC single-chip microcontrollers. AVR was one of the first microcontroller families to use on-chip flash memory for program storage, as opposed to one-time programmable ROM, EPROM, or EEPROM used by other microcontrollers at the time.

<span class="mw-page-title-main">PIC microcontrollers</span> Line of single-chip microprocessors from Microchip Technology

PIC is a family of microcontrollers made by Microchip Technology, derived from the PIC1640 originally developed by General Instrument's Microelectronics Division. The name PIC initially referred to Peripheral Interface Controller, and is currently expanded as Programmable Intelligent Computer. The first parts of the family were available in 1976; by 2013 the company had shipped more than twelve billion individual parts, used in a wide variety of embedded systems.

<span class="mw-page-title-main">TI MSP430</span> Mixed-signal microcontroller family

The MSP430 is a mixed-signal microcontroller family from Texas Instruments, first introduced on 14 February 1992. Built around a 16-bit CPU, the MSP430 was designed for low power consumption, embedded applications and low cost.

JTAG is an industry standard for verifying designs of and testing printed circuit boards after manufacture.

Nios II is a 32-bit embedded processor architecture designed specifically for the Altera family of field-programmable gate array (FPGA) integrated circuits. Nios II incorporates many enhancements over the original Nios architecture, making it more suitable for a wider range of embedded computing applications, from digital signal processing (DSP) to system-control.

<span class="mw-page-title-main">In-system programming</span> Embedded system programming technique

In-system programming (ISP), or also called in-circuit serial programming (ICSP), is the ability of some programmable logic devices, microcontrollers, chipsets and other embedded devices to be programmed while installed in a complete system, rather than requiring the chip to be programmed prior to installing it into the system. It also allows firmware updates to be delivered to the on-chip memory of microcontrollers and related processors without requiring specialist programming circuitry on the circuit board, and simplifies design work.

<span class="mw-page-title-main">V850</span> 32-bit RISC CPU architecture

V850 is a 32-bit RISC CPU architecture produced by Renesas Electronics for embedded microcontrollers. It was designed by NEC as a replacement for their earlier NEC V60 family, and was introduced shortly before NEC sold their designs to Renesas in the early 1990s. It has continued to be developed by Renesas as of 2018.

<span class="mw-page-title-main">Hardware emulation</span> Emulating hardware devices in IC design

In integrated circuit design, hardware emulation is the process of imitating the behavior of one or more pieces of hardware with another piece of hardware, typically a special purpose emulation system. The emulation model is usually based on a hardware description language source code, which is compiled into the format used by emulation system. The goal is normally debugging and functional verification of the system being designed. Often an emulator is fast enough to be plugged into a working target system in place of a yet-to-be-built chip, so the whole system can be debugged with live data. This is a specific case of in-circuit emulation.

Background debug mode (BDM) interface is an electronic interface that allows debugging of embedded systems. Specifically, it provides in-circuit debugging functionality in microcontrollers. It requires a single wire and specialized electronics in the system being debugged. It appears in many Freescale Semiconductor products. Background commands are categorized into two types: Non-intrusive commands and Active background commands. Non-intrusive commands can be issued while the user program is running, which include memory access commands.

Nexus or IEEE-ISTO 5001-2003 is a standard debugging interface for embedded systems.

<span class="mw-page-title-main">Segger Microcontroller Systems</span> Private company in the embedded systems industry

Segger Microcontroller, founded in 1992, is a private company involved in the embedded systems industry. It provides products used to develop and manufacture four categories of embedded systems: real-time operating systems (RTOS) and software libraries (middleware), debugging and trace probes, programming tools, and in-system programmers. The company is headquartered in Monheim am Rhein, Germany, with remote offices in Gardner, Massachusetts; Milpitas, California; and Shanghai, China.

<span class="mw-page-title-main">PICkit</span>

PICkit is a family of programmers for PIC microcontrollers made by Microchip Technology. They are used to program and debug microcontrollers, as well as program EEPROM. Some models may also feature logic analyzers and serial communications (UART) tools.

<span class="mw-page-title-main">HP 64000</span> Software development system

The HP 64000 Logic Development System, introduced 17 September 1979, is a tool for developing hardware and software for products based on commercial microprocessors from a variety of manufacturers. The systems assisted software development with assemblers and compilers for Pascal and C, provided hardware for in-circuit emulation of processors and memory, had debugging tools including logic analysis hardware, and a programmable read-only memory (PROM) chip programmer. A wide variety of optional cards and software were available tailored to particular microprocessors. When introduced the HP 64000 had two distinguishing characteristics. First, unlike most microprocessor development systems of the day, such as the Intel Intellec and Motorola EXORciser, it was not dedicated to a particular manufacturer's microprocessors, and second, it was designed such that up to six workstations could be connected via the HP-IB (IEEE-488) instrumentation bus to a common hard drive and printer to form a tightly integrated network.

Each time Intel launched a new microprocessor, they simultaneously provided a system development kit (SDK) allowing engineers, university students, and others to familiarise themselves with the new processor's concepts and features. The SDK single-board computers allowed the user to enter object code from a keyboard or upload it through a communication port, and then test run the code. The SDK boards provided a system monitor ROM to operate the keyboard and other interfaces. Kits varied in their specific features but generally offered optional memory and interface configurations, a serial terminal link, audio cassette storage, and EPROM program memory. Intel's Intellec development system could download code to the SDK boards.

A debug port is a diagnostic interface included in an electronic system or integrated circuit to aid design, fabrication, development, bootstrapping, configuration, debugging, and post-sale in-system programming. In general terms, a debug port is not necessary for end-use function and is often hidden or disabled in finished products.

<span class="mw-page-title-main">NXP LPC</span> Family of 32-bit microcontroller integrated circuits

LPC is a family of 32-bit microcontroller integrated circuits by NXP Semiconductors. The LPC chips are grouped into related series that are based around the same 32-bit ARM processor core, such as the Cortex-M4F, Cortex-M3, Cortex-M0+, or Cortex-M0. Internally, each microcontroller consists of the processor core, static RAM memory, flash memory, debugging interface, and various peripherals. The earliest LPC series were based on the Intel 8-bit 80C51 core. As of February 2011, NXP had shipped over one billion ARM processor-based chips.

RL78 Family is a 16-bit CPU core for embedded microcontrollers of Renesas Electronics introduced in 2010.

MIPI Alliance Debug Architecture provides a standardized infrastructure for debugging deeply embedded systems in the mobile and mobile-influenced space. The MIPI Alliance MIPI Debug Working Group has released a portfolio of specifications; their objective is to provide standard debug protocols and standard interfaces from a system on a chip (SoC) to the debug tool. The whitepaper Architecture Overview for Debug summarizes all the efforts. In recent years, the group focused on specifying protocols that improve the visibility of the internal operations of deeply embedded systems, standardizing debug solutions via the functional interfaces of form factor devices, and specifying the use of I3C as debugging bus.

References

  1. Keil, Reinhard (July 22, 2008). "Debugging with Cortex-M3 Microcontrollers". www.embedded.com. Retrieved May 25, 2013.
  2. "Overview of Pentium Probe Mode".
  3. USpatent 4547849,Louie, Glenn; Retter, Rafi& Shaanan, Neveet al.,"Interface between a Microprocessor and a Coprocessor",issued 1985-10-15, assigned to Intel Corporation "User bus cycle status signals, S1# and S0# support the user's bus and ICE bus cycle status signals, ICES1# and ICES0# support the ICE bus. … The ICE bus is used only for Data Read, Code Read, Halt, Shutdown, and Memory Write cycles. … microprocessor is forced to compatible mode at reset, … it cannot be switched back to compatible mode except by reset (or ICE breakpoint), … ICE must be given special attention since it is the only case in which a switch of the master microprocessor from protection mode to compatibility mode can occur (except for reset). … ICE software begins execution following an ICE breakpoint in compatibility mode and then switches to protection mode for the bulk of its operations."