1.6 Debugger concepts

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

AMP

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

Bare-metal

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

BBB

The old name for the MTB.

CADI

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.

Contexts

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.

CTI

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.

DAP

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.

Debugger

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.

Note:

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.

DSTREAM

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

DTSL

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

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.

ELF

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

ETB

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.

ETF

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).

ETM

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.

ETR

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

FVP

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.

ITM

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

jRDDI

The Java API implementation of RDDI.

Jython

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

MTB

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

PTM

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

RDDI

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.

RVI

ARM Realview ICE unit, predecessor to DSTREAM.

Scope

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).
SMP

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

STM

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

TPIU

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

TMC

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.