In-circuit emulator
An In-Circuit Emulator ( ICE ) is a tool used to develop software for an embedded system . For the development of the software, the controller normally present in the system is replaced by a special variant that is directly connected to the ICE.
SW development with logic analyzer
One method of testing software for an embedded system is with logic analyzers . They are connected to the control, address and data bus and record their signals. The software of the logic analyzer can thus understand what the controller is doing on the target hardware. By means of a so-called trace memory, the program sequence of the controller can be traced over several hundred or thousand program steps. The disadvantages of the method are a high number of signals that have to be picked up on the target system (even a 16-bit controller can easily reach over 60 signals), the lack of control over the program flow, no possibility of determining the content of registers, and the program code can only be represented as assembler code . In addition, modern controllers often have their memory integrated, which means that no external lines are available for control, address and data buses. For these reasons, the use of logic analyzers for software development is rarely used today.
SW development with in-circuit emulator
In-circuit emulators can remedy these problems. These devices replace the actual controller on the target system with hardware that has the necessary analysis functions built in.
There are several options for implementing the in-circuit emulators. In many cases, a special version of the chip to be emulated is used that brings out additional signals in order to be able to follow the program sequence, so-called "bond-out chips". This bond-out chip (so called because the process of connecting the signals of a chip with the connections of the housing is called " bonding " and signals that otherwise only exist internally) are then either located on a so-called pod, a Adapter that is installed in the target system instead of the normal controller, or directly in the emulator and only the signals are routed to the pod.
If such a bond-out chip does not exist, the controller can also be completely simulated by FPGA or other logic circuits. However, this is then possibly associated with significantly higher effort and also does not guarantee a 100 percent faithful replication.
The ICE is usually directly integrated into the development software for the controller. This means that not only can the recorded command code be displayed, but what the controller is currently doing can be traced in the source code. Debugging in high-level language and even the resolution of operating system data is possible.
Usually the ICE is used for debugging . Since he can practically also see and influence the “inner workings” of the controller (for example program counter, stack pointer, status register ), the program sequence can now be controlled. Since access is also possible in (true) "real time", it is also possible to analyze problems that can no longer be recorded with so-called in-system programmers , since they get their data via relatively slow interfaces. The trace memory, which has already been used in the logic analyzers, is a decisive element here. The deeper this memory is, the more it can record, the longer back you can follow the program sequence. This helps enormously when debugging complex systems. Above all, problems with interrupts are comparatively easy to detect in this way.
Analysis options with in-circuit emulators
The equipment with analysis functions is very different between different emulators. As a minimum function, all emulators can actually interrupt program execution on user command, interrupt program execution when a certain point in the program is reached, and execute the program in individual steps. In addition, there is the option of being able to read out the contents of the registers and the memory.
The following are the analysis functions that an emulator can offer.
Conditional program interruption (breakpoint)
In the simplest case, the program execution is interrupted when a certain point (i.e. a certain address in the program memory) of the program is reached. This makes it easy to determine whether a certain part of the program is being executed, or it can be checked how the state is at the end of the execution of a certain part of the program.
However, more detailed conditions for a program interruption may also be possible, such as interruption after reaching the memory location n times, write or read access to certain data memory addresses, or even to certain data values that are written to a memory address or read from there. Very comfortably equipped emulators allow such conditions to be linked in order to then e.g. B. to generate an interruption if a certain point in the program was reached first and then a certain address was accessed.
Single step execution
Single-step execution is often helpful when analyzing non-time-critical code. Here the processor only executes one command at a time and the user can then check the current status before executing the next command. This makes it possible to watch the processor in detail at work.
Event recording (trace buffer)
If problems arise in a program section that has to react to external signals, neither breakpoints nor single steps are adequate means, as the time behavior of the program is then changed so that the desired function is not possible or the error does not occur. A trace buffer is very helpful in such situations, but it is far from being available in every emulator and not necessarily provided with all desirable options. The trace buffer records the executed program steps, depending on the respective implementation, register contents and other signals can also be recorded. If the program is interrupted, the last program steps carried out can be followed. How many program steps are recorded depends on the emulator; there are usually at least 500 program steps available. The trace buffer can also appear in a wide variety of designs. In the best case, the trace buffer can be configured to “pre-”, “post” and “center triggers” so that it records the program steps executed before, after or around (i.e. before and after) a breakpoint. Some emulators also offer conditional recording, so that e.g. B. only program steps that are in a certain memory section are recorded in order to reserve the scarce trace buffer for the really interesting data.
Limitations of In-Circuit Emulators
The big problem with the ICE is the high clock speed of today's high-end controllers and their sometimes extremely short product life. For the manufacturer of the controller, a bond-out chip means almost a new development of the same. It is only really interesting if it can be produced in large numbers. However, this is usually not the case with development systems. Some chip manufacturers are not interested in developing a bond-out chip, but other chip manufacturers are now providing practically all new controllers with an ICE interface. The high clock speed is another hurdle. With a processor clock of several hundred megahertz, the technical effort required to route the signals from the bond-out chip to the emulator is correspondingly high.
Depending on the equipment and the complexity and speed of the controller to be emulated, ICE can be quite expensive products, several thousand euros are quite common (the “Rolls-Royce” of the ICE is in the six-digit range!). A bond-out chip is also often not cheap (prices in the four-digit range are possible here). And with a little inattention, these chips are easy to destroy.
In the area of professional development, however, the cost expenditure is offset by considerable time savings.
In-System-Programmer / In-System-Debugger
The in-system programmers (ISP) and in-system debuggers provide a way out of this economic and technical predicament . In some cases, these do not offer the depth of control over the target controller like an ICE, so the trace buffer is often missing, which means that complex timing errors are not so easy to clear. However, they are orders of magnitude cheaper (some of the prices are in the double-digit range) and do not require a bond-out chip. As a rule, however, at least for the development sample, an additional connector for your interface must be integrated on the circuit board.
The hardware for accessing the internal registers, for example to set breakpoints, is no longer housed in the pod or emulator, but is already included on every microcontroller chip. The ISP only provides the interface to the chip-internal debugging options. In addition to proprietary interfaces (e.g. the BDM interface from Freescale ), more and more manufacturers of microcontrollers are using the standardized JTAG interface , which was actually developed for Boundary Scan . The higher-level protocol, i.e. which JTAG scan chains can be used to access the debug options of the respective controller, is different for each manufacturer and each product and is mostly secret. The plugs used also differ from manufacturer to manufacturer. The IEEE 1149.7 standard tries to establish a uniform protocol.
With the PSoC microcontrollers from Cypress , the complete function of an ICE including trace buffer and conditional breakpoints is implemented via such an interface. For this purpose, Cypress offers at least the best equipped chip with this in-system debug interface from each subfamily of controllers, which then serves both as a bond-out chip for the emulator and can be used for production.
Web links
Some chip manufacturers offer their own ICE or ISP, but there are also independent providers who usually use the same program surface for a wide variety of processors - which reduces the familiarization time when changing the processor.
- iSYSTEM manufactures ICEs and debuggers for many microcontroller architectures
- Hitex manufactures ICEs and debuggers for a wide variety of processors
- Lauterbach produces ICEs, debuggers and logic analyzers for almost all architectures
- Signum offers ICEs with and without trace for different architectures
- Wind River offers ICEs with and without trace for different architectures
- SEGGER J-Link and J-Trace SEGGER support ARM and other architectures in conjunction with software debuggers from IAR, Keil or YAGARTO