1.6 Debugger concepts

Lists some of the useful concepts to be aware of when working with DS-5 Debugger.


Asymmetric Multi-Processing (AMP) system has multiple processors that may be different architectures. See 1.3.2 Debugging AMP Systems for more information.


A bare-metal embedded application is one which does not run on an OS.


The old name for the MTB.


Component Architecture Debug Interface. This is the API used by debuggers to control models.

Configuration database

The configuration database is where DS-5 Debugger stores information about the processors, devices, and boards it can connect to.

The database exists as a series of .xml files, python scripts, .rvc files, .rcf files, and other miscellaneous files within the <DS-5 installation directory>/sw/debugger/configdb/ directory.

DS-5 comes pre-configured with support for a wide variety of devices out-of-the-box, and you can view these within the Debug Configuration dialog within Eclipse IDE.

You can also add support for your own devices using the Platform Configuration Editor (PCE) tool.


Each processor in the target can run more than one process. However, the processor only executes one process at any given time. Each process uses values stored in variables, registers, and other memory locations. These values can change during the execution of the process.

The context of a process describes its current state, as defined principally by the call stack that lists all the currently active calls.

The context changes when:

  • A function is called.
  • A function returns.
  • An interrupt or an exception occurs.

Because variables can have class, local, or global scope, the context determines which variables are currently accessible. Every process has its own context. When execution of a process stops, you can examine and change values in its current context.


The Cross Trigger Interface (CTI) combines and maps trigger requests, and broadcasts them to all other interfaces on the Embedded Cross Trigger (ECT) sub-system. See 3.16 Cross-trigger configuration for more information.


The Debug Access Port (DAP) is a control and access component that enables debug access to the complete SoC through system master ports. See Debug Access Port for more information.


A debugger is software running on a host computer that enables you to make use of a debug adapter to examine and control the execution of software running on a debug target.

Debug agent

A debug agent is hardware or software, or both, that enables a host debugger to interact with a target. For example, a debug agent enables you to read from and write to registers, read from and write to memory, set breakpoints, download programs, run and single-step programs, program flash memory, and so on.

gdbserver is an example of a software debug agent.

Debug session

A debug session begins when you connect the debugger to a target for debugging software running on the target and ends when you disconnect the debugger from the target.

Debug target

A debug target is an environment where your program runs. This environment can be hardware, software that simulates hardware, or a hardware emulator.

A hardware target can be anything from a mass-produced development board or electronic equipment to a prototype product, or a printed circuit board.

During the early stages of product development, if no hardware is available, a simulation or software target might be used to simulate hardware behavior. A Fixed Virtual Platform (FVP) is a software model from ARM® that provides functional behavior equivalent to real hardware.


Even though you might run an FVP on the same host as the debugger, it is useful to think of it as a separate piece of hardware.

Also, during the early stages of product development, hardware emulators are used to verify hardware and software designs for pre-silicon testing.

Debug adapter

A debug adapter is a physical interface between the host debugger and hardware target. It acts as a debug agent. A debug adapter is normally required for bare-metal start/stop debugging real target hardware, for example, using JTAG.

Examples include DSTREAM and the ULINK family of debug and trace adapters.


ARM DSTREAM combined debug and trace unit. See DSTREAM for more information..


Debug and Trace Services Layer (DTSL) is a software layer within the DS-5 Debugger stack. DTSL is implemented as a set of Java classes which are typically implemented (and possibly extended) by Jython scripts. A typical DTSL instance is a combination of Java and Jython. ARM has made DTSL available for your own use so that you can create programs (Java or Jython) to access/control the target platform.


DWARF is a debugging format used to describe programs in C and other similar programming languages. It is most widely associated with the ELF object format but it has been used with other object file formats.


Executable and Linkable Format (ELF) is a common standard file format for executables, object code, shared libraries, and core dumps.


Embedded Trace Buffer (ETB) is an optional on-chip buffer that stores trace data from different trace sources. You can use a debugger to retrieve captured trace data.


Embedded Trace FIFO (ETF) is a trace buffer that uses a dedicated SRAM as either a circular capture buffer, or as a FIFO. The trace stream is captured by an ATB input that can then be output over an ATB output or the Debug APB interface. The ETF is a configuration option of the Trace Memory Controller (TMC).


Embedded Trace Macrocell (ETM) is an optional debug component that enables reconstruction of program execution. The ETM is designed to be a high-speed, low-power debug tool that supports trace.


Embedded Trace Router (ETR) is a CoreSight component which routes trace data to system memory or other trace sinks, such as HSSTP.


Fixed Virtual Platform (FVP) enables development of software without the requirement for actual hardware. The functional behavior of the FVP is equivalent to real hardware from a programmers view.


Instruction Trace Macrocell (ITM) is a CoreSight component which delivers code instrumentation output and specific hardware data streams.


The Java API implementation of RDDI.


An implementation of the Python language which is closely integrated with Java.


Micro Trace Buffer. This is used in the Cortex-M0 and Cortex-M0+.


Program Trace Macrocell (PTM) is a CoreSight component which is paired with a core to deliver instruction only program flow trace data.


RealView Device Debug Interface (RDDI) is a C-level API which allows access to target debug and trace functionality, typically through a DSTREAM box, or a CADI model.


ARM Realview ICE unit, predecessor to DSTREAM.


The scope of a variable is determined by the point within an application at which it is defined.

Variables can have values that are relevant within:

  • A specific class only (class).
  • A specific function only (local).
  • A specific file only (static global).
  • The entire application (global).

A Symmetric Multi-Processing (SMP) system has multiple processors with the same architecture. See 1.3.1 Debugging SMP systems for more information.


System Trace Macrocell (STM) is a CoreSight component which delivers code instrumentation output and other hardware generated data streams.


Trace Port Interface Unit (TPIU) is a CoreSight component which delivers trace data to an external trace capture device.


The Trace Memory Controller (TMC) enables you to capture trace using:

  • The debug interface such as 2-pin serial wire debug.
  • The system memory such as a dynamic Random Access Memory (RAM)
  • The high-speed links that already exist in the System-on-Chip (SoC) peripheral.
Non-ConfidentialPDF file icon PDF versionARM DUI0446Z
Copyright © 2010-2016 ARM Limited or its affiliates. All rights reserved.