Dipl-Phys Dr Kurt Bohringer and Dipl-Ing (FH) Jurgen Baumgartner report on how new standards are being set for in-circuit emulation to deal with the ever increasing variety and sophistication of microcontrollers.

About 10 years ago, the world of microcontrollers was relatively simple and straightforward. Developers were proud to specialise in frequently-used derivatives, often becoming experts able to interpret the meaning of each bit of information associated with these controllers.
Whenever possible, new projects were created around these well-known components with the intention of keeping learning time for the CPU instruction set, peripherals and tools to a minimum.
Use of high-level languages was almost unheard of and, for performance reasons, almost all programs were written in assembler. Real-time operating systems or software packages such as protocol stacks were hardly used. Code was either written from scratch or imported from previous projects and then modified or extended. Controllers were clocked at low frequencies and used busses of low bandwidth. Usually, all addresses and data, as well as status and bus control signals, were brought out to the pins of the device, making emulation relatively simple. The then popular DIP and PLCC packaging facilitated the easy connection of in-circuit emulators.
Nevertheless, such tools were at that time very expensive and were often considered to be a tough but necessary burden.
Since the old days, the diversity of microcontrollers available has grown enormously. This is true not only for the number of available architectures but also for the number of derivatives existing per architecture. Each application area contains its own tailor-made derivatives. Customised solutions are frequently created for bulk purchasers which often means that the controller or processor is no longer available on its own but rather as part of an asic or a system on chip (SoC).
The decision to use such a customised solution is often governed by the suitability of the controller to the individual project, whereby the chip price and, in particular, the price of development tools play, a large role.
It is now necessary for developers of embedded systems to be able to change rapidly between derivative and architecture types. To maintain short development times, a great deal of focus is now placed on the features and possibilities offered by the development tools themselves. Meanwhile, high-level language compilers are able to produce effective microcontroller code, enabling part of an application to be portable. Real-time operating systems are also portable, up to the area of the hardware layer.
For processor specific software, chip manufacturers sometimes provide tools that by means of graphical user interfaces and intuitive operation produce code for the hardware interfaces of the microcontroller. Such tools are often referred to as application builders. On the abstraction level, high-end design tools which facilitate easy program development and even generate code themselves are also no longer processor specific (ie, it is possible to port a software application from one architecture to another at any time). With such possibilities, it is increasingly important for the developer to have one uniform and ergonomically arranged user interface for the development tools he or she intends to use.
HiTOP is a good example of such a user interface and it is the common user environment for all Hitex in-circuit emulators. With such a common interface, a developer is truly free to create and test applications for different controllers without investing large amounts of time and money. This is achieved by being able to use the interface for emulators of different microcontrollers and by the fact that it is possible to integrate an emulator in the user interface (IDE) of readily available compilers. A user can for example begin with a C compiler and simulator from a well-known manufacturer and then later in the test and integration phase use an in-circuit emulator within the same environment. This is just as much possible with 'entry level' tools as well as with complex real-time in-circuit emulators of the high-end type. The user gets the same look and feel when working on different projects that use different architectures and development tools.
With state of the art development systems for microcontrollers, it is important that they provide easy access to and analyses of all on-chip peripherals, as well as consequent debugging at the high-level language plane. It should also be possible to integrate real-time operating systems and time saving application builders.

As an example, in HiTOP it is possible to analyse a displayed application running on an embedded real-time operating system so that all task changes are automatically recorded and time stamped. Furthermore, all calls to the operating system can be recorded. In this way, the calling sequence of tasks, the time interval required and operating system functions used can be visualised graphically and clearly using bar and flow charts. It is also possible to detect time violations by means of complex triggers. To do this, classic emulator features such as trigger, trace, trace-filter, timestamp and real-time counter are automatically programmed by the system according to requests made by the application. All of this takes place automatically, allowing the user to concentrate on the real task - the embedded application.
Due to the trend in development to separate self generating assembler or C functions more from hardware, the demand for tools to check and prove software efficiency and quality is becoming increasingly important. Performance analysis and the examination of code coverage under real-time conditions are to belong to the daily apparatus used by software developers for embedded systems. This is the only way a software developer can prove and improve the quality of his or her work.
The placing of several CPUs on the same piece of silicon (so called multiprocessor cores) also creates new demands on the development system, in particular transparency and user friendliness. It should be possible for an application to halt one CPU and to inspect its internal registers while allowing the other CPUs to proceed completely undisturbed and for example to take care of handling protocol for a communications interface.

Can hardware help?

With the introduction of single-chip controllers that frequently appear on the market in small compact forms, or as part of SoC applications, the address and data bus are no longer readily available to be monitored by external tools. This is where bondouts can help. In their simplest form, bondouts enable external access to the controller's internal busses by bonding the on-chip address and data busses to extra inner leads which are brought out to additional pins on a special package of the device (hence the name bondout).
In complex devices, these bondouts are lead out over additional busses that for example provide access to further on-chip areas that are to be monitored and accessed in real-time. In addition, serial debug interfaces such as JTAG, BDM, NEXUS or OCDS allow the debugging of such classically non observable chips. A prerequisite for this is that the chip manufacturer integrates such a serial interface into the mass produced component. Low priced entry-level development systems are often realised with little expenditure and will typically provide a simple run control, register inspection after halting the CPU or perhaps during run-time and possibly some additional functions.
However comfortable and quality development support is not realisable without a trace-port. This enables additional information on program flow to be communicated to the outside world over the dedicated pins of the debug interface.
A further trend is that of ever-increasing bus speed. Here it becomes more and more important to harness the immense computing power of modern microcontrollers and processors by means of adequate semiconductor packaging. An example of this is the use of asic technology to keep pace with the racy development of faster and faster semiconductors. Small, highly integrated emulators are of importance here since the high bus frequencies no longer permit any great physical separation between the target hardware and the in-circuit emulator.
It is important for both users and manufacturers of development systems that modular and cost-effective tools are developed which can be quickly adapted to meet market requirements. In the ideal world, these tools are as architecture specific as necessary and as universal as possible.
However, neither the universal wonder-tool or the sophisticated dedicated emulator have ever been publicised. Unfortunately, the universal emulator promising a fast switch between architectures will still be tied up in processor specific details and is far too expensive for most projects.
The dedicated emulator is more cost-effective, however a technological a dead end, without any expansion or possibility to work with other controller architectures or even to other derivatives of the same architecture (users sometimes become painfully aware of this fact only when trying to emulate new derivatives of the same architecture).
Hitex has an effective solution to the problem with its AX/MX systems and the DProbe/DBox concept. The ever so important compromise between cost-effective use of different derivatives, while having the usefulness of universal components for several microcontrollers, is provided, without having to settle for processor specific limitations.
Useful technologies such as the patented real time internal access supervisor (RIAS) are available, and allow outstanding debugging to take place without involving the user in processor specific detail.

Making contact

Modern space-saving microcontroller packages pose a big challenge to the world of ICE. From Finepitch-QFP (down to 0.4mm pin to pin) up to BGA-packages all have experienced a great deal of popularity. This trend results in tough demands on the adapter technology that is used to connect an in-circuit emulator to the target hardware. However, using the patented PressOn technology, these new targets are easier to access. PressOn adapters use conductive strips embedded into an elastic material that are pushed onto the pins of a soldered component with defined contact pressure. Electrical contact to all pins is achieved without the undesired bending or shorting of these pins as is often the case in classic adapter solutions.

Modular solution

In this article we have also seen how effective software, hardware and connection technology can be brought together to provide quality cost-effective modular tools. Developer solutions are offered for a very large assortment of processor architectures. This range is constantly expanded on account of the technology becoming increasingly portable across architectures and the close co-operation between Hitex and semiconductor manufacturers. The communication between tool and device manufacturer also increases the usefulness of the tools, so the tool user is set to benefit.

ENQUIRY No 61

Dipl-Phys Dr. Kurt Bohringer and Dipl-Ing (FH) Jurgen Baumgartner are with Hitex Development Tools, Karlsruhe, Germany. www.hitex.de or www.hitex.com