Jürgen Baumgartner

Abstract   –   This paper discusses the on-chip debugging capabilities of ARM® cores and its use with appropriate hardware-based debugging tools. The ARM® core offers superior debugging support based on special resources that are addressable through a chip's JTAG interface. The functionality available to debugging tools and the resulting benefits to a software engineer designing and testing a new application are explained in detail using the Tanto test and analysis tool from Hitex.

Index Terms   –   ARM®, on-chip debug support, debugging tools, JTAG port, EmbeddedICE™ Macrocell, Embedded Trace Macrocell, ETM, Debug Communication Channel.

1. Introduction
During the last couple of years, Embedded systems have been subject to a great deal of change – more and more embedded products now employ powerful microcontrollers, which serve to improve the sophistication of their user interfaces or simply make them easier and more enjoyable to use. This steadily growing demand for user friendliness and comfort poses new challenges for the electronics built into such products. As an example, compare a mobile phone from five years ago with one from the latest generation – the speed at which development is being pushed forward then becomes obvious. Consumers are no longer content with a mobile phone that simply telephones. Programmable ring tones, internet access, speech recognition and other comfort features are now part of the norm.

2. Effects On Development
These comfort features are built into a product at the cost of an increased development expenditure, although the product itself may not become more expensive and design cycles are to be continuously shortened. The make-up of a development team has also changed with time.

Traditionally, embedded systems were mainly a hardware-oriented affair, whereas today the main part of the expenditure is due to software. This is clearly demonstrated by the ever-increasing numbers of software engineers taking part in embedded systems projects. This does not only apply to the telecommunications area, but also to other industries.

If a development team decides to go ahead and use an ARM® core in a design, the team's software engineers will often be faced with the challenge of writing a program that is able to utilize the benefits of ARM® in the most efficient way. To fulfill this task a deep insight into the execution of the software and the resulting behavior of the target system is necessary. Since knowledge of a processor's real-time behavior is vital in most embedded system developments, software-based simulation tools are inadequate in most cases. To allow real-time observation and debugging of the "actual" chip itself, ARM® provides a sophisticated set of debug and performance monitoring features.

3. ARM® On-Chip Debugging Features
Traditional emulation methods approach their limits at speeds above 100 MHz. Furthermore, the integration of more and more features on the silicon render it impossible to observe processor behavior via its pins. Hence, it's either necessary to use expensive solutions based on special chips – i.e. the so-called bondout processors, or the processor itself is to provide on-chip debugging features.

The debug and emulation unit of the ARM® core (here the ARM7TDMI® core as an example) can be addressed via the processor's JTAG interface and the so-called EmbeddedICE™ Macrocell. Besides providing standard debugging features such as single steps and software breakpoints which are commonly used with other processors, ARM® offers the following extended debugging features:

Watchpoints – These allow the user to set up specific watchpoint addresses or address ranges that will halt the processor whenever they are accessed. Hardware and software breakpoints for code as well as watchpoints for data can be implemented. The user is then free to examine the state of the processor and continue with instruction execution afterwards.

Trace History – An on-chip trace logic – the Embedded Trace Macrocell (ETM) –transmits information on the current program flow or the information on data accessed to a special trace port. This allows the most recent path of program execution and processing of data to be recreated. For the majority of errors that occur, a program trace provides vital information on what caused the error to occur in the first place.

Trigger, Sequencer and Counter – In addition to trace history, the on-chip trigger, sequencer and counter capabilities of the Embedded Trace Macrocell (ETM) enable the user to track and qualify more complex events. With this it's possible to influence the trace recording (e.g. start, stop, filter). Depending on the implementation of the ETM on chip, it's also possible to halt the processor on special events detected. These on-chip resources are highly scalable and may differ in functionality.

Real-time Data Communication and Real-time Debug – Facilitates the communication of data to and from the embedded target system using the JTAG port. The JTAG port enables access to the so-called Debug Communication Channel. This allows for example program variables to be monitored during execution without having to halt the program. This can be managed by means of a real-time monitor program which is part of the user application. The debugging of foreground tasks while interrupts continue to be served is another feature which can be provided by a real-time monitor. This holds particularly true for real-time applications. Furthermore, a statistical profile of the program execution can be established.

4. Hardware-Based Debugging Tools
All of these features can be accessed through the JTAG interface and an additional trace port. In order to be able to access these debugging features from a host PC, specific hardware is required. The hardware to access the JTAG interface can be a simple module that is connected between the JTAG port of the chip and the printer port of the PC. However, modern test and analyzing tools offer the choice of using Ethernet or USB as communication channels to reduce the download and response times during debugging. Furthermore, Ethernet connections offer the added advantage of being able to support remote debugging.
The preprocessing and recording of the information coming from the trace port requires a quite complex hardware tool anyway – so a simple module interfacing the JTAG port doesn't serve.

If a test and analysis tool is additionally equipped with local intelligence, as in case of the Tanto System from Hitex, which is used to illustrate examples in this paper, this drastically improves real-time debugging, since most of the needed computations to analyze the raw data coming from the trace port are performed locally in the tool and do not need to be evaluated in the host PC. This saves limited recording resources, reduces the load on the communications interface and hence provides a faster and more efficient access to results.

Tanto can also provide additional features that are not directly supported by the chip itself, such as trigger in and out signals, which allow the use of external signals. These signals could be break conditions or triggers for other instruments such as a digital storage oscilloscope or a logic analyzer. Also, additional trigger and sequencer logic is available to compensate possibly missing on-chip resources and process the information coming from the trace port. In addition, timestamp information can be added and external signals can be included – e.g. for trace recording or to specify trigger events.

Figure 1: Tanto Test and Analysis Tool

To connect the tool to the target system, a corresponding debug connector is required. Standard connectors have been specified by ARM® and they are recommended for this purpose.

5. The Integrated Development Environment
While the hardware part of the test and analysis tool needs to be set up only once at the beginning of the project, the software developer is required to spend a lot of time in front of the tool's user interface. Hence, the efficiency of this software is of major interest.

HiTOP is the Windows-based universal user interface for nearly all tools coming from Hitex. It provides complete HLL debugging and rapid access to all in-circuit emulator resources such as Trace, Trigger, Sequencer, Performance Analysis, Coverage, Memory mapping and Setup of the target system.

As well as being packed with useful features, HiTOP can read object files in almost any format and it makes efficient use of debug information included.

A powerful command language included can be used to record and replay user actions. This language facilitates automatic testing of applications and remote control of the user interface.

Kernel awareness for most RTOSs can be added to HiTOP and it's possible to integrate it with a great deal of products, including visual design and test tools, analyzers, editors, etc.

6. Embedding Software Quality
The main reason for using a debugging tool is to detect bugs in the application software and eliminate them. Another important objective is to test the performance of the application and improve it. This can also be achieved with the use of modern "debugging" tools. Since their functionality exceeds pure debugging by far, it is more appropriate to refer to such systems as "test and analysis tools". Generally speaking, the objective of the entire process is to increase the quality of software.

Software quality can be rated according to the following criteria:

Functionality – does the software do what it is expected to do and is it free of errors?

Reliability – does the software work correctly under all circumstances?

Usability – how easy is the software to use?

Efficiency – which part of the program consumes the most execution time? Could this be improved?

Maintainability – how complex is the software and how well is it documented? Is the software easy to change? Is the software easily extended?

Portability – how easy is it to port the software to another operating system or to another target architecture? Are compiler-dependent features used in the software?

Maintainability, Usability and Portability are mostly a matter of the software specification and documentation. To adhere to a defined level of maintainability it is recommended to conform to a standard such as ISO9000 for the documentation of the source code, and [1] discuss several ideas on how to implement the ISO9000 standard in software development.

The following section lists some practical examples of how the Tanto system's software testing features can be used to achieve quality in software for ARM® cores.

Functionality and Reliability – Basic functionality tests are possible using software simulation, but real-time behavior is the most important factor, especially in embedded systems. Simulation is only acceptable as long as no working application hardware is available. Nevertheless, a simple test by single stepping through the program often reveals the first errors and, when at decision points in particular (conditional branches), stepping through the code with various input parameters gives a good indication of the logical correctness of the software.

The real-time debug functionality (enabled by use of a real-time monitor) allows the debugging of foreground tasks while interrupts continue to be served – it is possible to step through the program, set further breakpoints, read or write memory, or restart the foreground task. This is particularly important when it comes to using real-time applications. Since real-time driven tasks can still be processed, the system is able to handle time-critical external events, for example.

Use of a hardware-based test tool is vital to test functionality under real-time conditions. Watchpoints placed at critical positions of code or on variables give a good indication of whether program execution is still in its normal state or not.
Additionally, real-time data communication is used to examine the contents of variables without the necessity to stop the program or to reduce its execution speed. The user thus has the ability to react to critical changes, or for testing purposes to even cause such events to take place to check the error handling of the program.

The most efficient feature to document program execution is the trace buffer. ARM®'s on-chip trace macrocell, the ETM, transmits program flow or data access. For the best use of this buffer when recording code, only indirect branches, exceptions, mode changes and synchronization frames are recorded. Using the recorded information and access to program memory, it's possible e.g. to recreate program flow at the source level. When combined with a watchpoint or a Tanto trigger, the trace recording provides valuable information, e.g. about the cause of exception: the watchpoint may freeze the trace recording allowing the user to analyze the instructions leading to the exception.

Efficiency – This is normally the last phase of the development cycle. After proving that the program can run without errors, there is still room for optimization. Since most optimization options offered by the processor itself are already used during code generation by the compiler, it is up to the user to find ways to speed up the program using improved algorithms. The first objective should be to find the bottlenecks of the program. The best way to do this is to use profiling tools. With Tanto's analysis functionality, there are various possibilities to do so.

7. Test Strategies
A typical software test process [2] consists of the following phases:

• Static Phase
  Production of source code
  Tests: static analysis (syntax and semantics)
  Environment: real code, no hardware – not in real time
  
• Dynamic Phase 1
  Simulation
  Tests: statement coverage and decision coverage
  Environment: real code with no hardware – not in real time
  
• Dynamic Phase 2
  Target hardware available
  Tests: statement coverage and decision coverage
  Environment: real hardware, instrumented code – not in real time
  
• Dynamic Phase 3
  In-circuit testing with scripts
  Environment: real code, real hardware – in real time
  

Dynamic phase 1 would normally find about 80% of software bugs.

Dynamic phase 3 will find the remainder of bugs residing in both software and hardware.

In dynamic phase 3, use of a hardware-based tool is a must, but such a tool can also be used efficiently in the other dynamic test phases, e.g. in phase 1, in combination with an evaluation board. This approach will shift parts of the necessary real-time testing to an earlier stage, thus reducing risk at the end of the project.

8. Regression Testing And In-Circuit Test Harnesses
A final important phase that should not be ignored is that of maintaining the software after its first release.

Testing modifications to an existing system is more difficult than testing new code because of the danger that a modification will inadvertently cause a malfunction elsewhere. Code optimization phases in major projects can also introduce errors and studies show that compared to new code, modified programs are ten times more likely to contain bugs.

The technique of regression testing relies on running the program under special conditions. This is usually performed under the control of some sort of "test harness" designed to simulate the behavior of external code and hardware so that the operation and outputs of the software object under test can be recorded for later analysis. The most common and useful example of a test harness is where test data is taken from a PC disk file and fed into the parameters of a called function in the embedded application that is then executed. The return value or other outputs are then captured and stored on the PC's hard disk. As the function is enhanced or optimized during the project, periodic testing with the same test harness and input data set should yield the same outputs. Any change would indicate that the operation of the function has been altered in some way, intentionally or otherwise.

Pure software tools are available that contain powerful aids for generating test harnesses, but they have to run the application in an entirely artificial (i.e. PC) environment, or alter in some significant way the conditions under which the software is executed, i.e. under a target monitor.

For this purpose, using the Tanto system with the HiTOP debugger results in a method that is as close as possible to reality. The HiSCRIPT script language of the debugger allows automatic control of the processor and documents the response of the target system.

Use of the test and analysis tool ensures that no changes are required to the code when testing it – i.e. there is no software instrumentation and since the final target hardware is used, the memory map and stack usage remain unchanged. These last two points are absolutely critical as the majority of residual software errors are caused by misuse of the compiler, linker and the CPU architecture and these are exactly the errors that a pure software test tool will not reveal. Finally, the use of the real processor, even if it has no external bus, means that tests including coverage, can be performed in true real time. Thus the code tested is exactly the same code that will be shipped to the customer.

The creation of test harnesses is a manual process (but can be made semi-automatic) and so represents some additional software design effort that needs to be budgeted for. However, this is often more than compensated by the time it saves in regression testing and the increased efficiency of the test phase.

Points in the program at which test data is to be inserted into, or retrieved from, are usually chosen to be near function entry and exit. The program's parameters and variables are accessible from the script as the full symbol table is available. Run/stop control of the program is under harness control as are hardware-based execution timers. Thus it is possible to conduct tests that exercise code whilst measuring true run times in an automatic and repeatable way on the real processor.

In summary, the use of a hardware-based test and analysis tool is the only way to fully utilize all of the on-chip debugging and profiling functionality offered by ARM® cores. The usage of such a tool is necessary to obtain a documented level of software quality under real-time conditions and helps to maintain it throughout the whole life cycle of the software. Development time can be reduced significantly and more efficient testing in the earlier stages reduces the design risks that normally appear during the last final phase of development.

References
 [1] Hitex, "Software Testing Ideas For ISO9000/TickIT"
 [2] Hitex, "Embedding Software Quality, Part 1"

Contact
Hitex Development Tools, Greschbachstrasse 12, D-76229 Karlsruhe / Germany
www.hitex.de / www.hitex.com