Nexus (standard)

Nexus or IEEE-ISTO 5001-2003 is a standard debugging interface for embedded systems.

Features

The IEEE-ISTO 5001-2003 (Nexus) feature set is based on today’s best on-chip debug implementations. Its goal is to create the best possible debug feature set while minimizing the required pin-count and die area. The standard is designed to be processor- and architecture independent and to support multi-core or multi-processor designs.

Physically, IEEE-ISTO 5001-2003 defines a standard set of connectors for connecting the debug tool to the target or system under test. Logically, data is transferred using a packet-based protocol. This protocol can be IEEE JTAG 1149.1; or, for high-speed systems, an auxiliary port can be used that supports full duplex, higher bandwidth transfers.

Run-time control

This is the most basic feature and is standard on all on-chip debug implementations. It allows the debug tool to start and stop the processor, to modify registers and to single-step (execute a single assembly instruction).

Memory access

Nexus supports memory access while the processor is running (“on-the-fly”). This allows the debug tool to read and write memory while the processor is running without affecting or intruding on the currently executing instructions. On-the-fly access is a very powerful feature and is a requirement for debugging truly real-time systems were it is not possible to halt the system under test. In particular, Data Memory Access is essential for the Calibration of Engine Control Units.

Breakpoints

Nexus provides support for breakpoints that halt the program when a specified event (the breakpoint) has occurred. The event can be specified as code execution at a specified address or as a data access (read or write) to a specified address with a specified value (for example, break when 0x55 is written to address 0x123456; break when 0xAA is read from 0xFFFF00). Nexus breakpoints are similar to the hardware breakpoints found in other processor architectures and can be set in Flash or ROM memory. A watchpoint is a similar concept; however, when a watchpoint occurs a message is sent to the debug tool (as opposed to halting the processor).

Instruction or program trace

Nexus uses the branch-trace technique to compress the information needed to trace program execution. Executed code address information is emitted via the Nexus port at branch or exception instructions only; the debug tool interpolates the program trace for sequential (non-branch) instructions from a local image of code memory contents. This allows full reconstruction of the program flow by the debug tool.

Data trace

This feature allows the debug tool to track real-time data accesses to memory locations. The trace can be qualified be specifying a specific range (start and stop address) and a specific access type (read or write).

Ownership trace

The ownership trace feature allows a real-time operating system (RTOS) to identify the currently executing process or task to the debug tool. The RTOS simply writes to a predefined Nexus register when switching tasks; this write forces an ownership trace message to be emitted from the Nexus port. The message will contain an ID that identifies the task or process to the debug tool.

Memory substitution and port replacement

This feature allows internal memory or port accesses to be implemented over the auxiliary Nexus port. For example, this feature can be used to implement ROM patching; that is, instead of reading on-chip ROM, the instruction is fetched from the debug tool via the auxiliary port. Port replacement is useful when relatively slow I/O pins have a secondary function, for example, a Nexus port function; it allows the debug tool to ‘emulate’ their primary functionality.

Data acquisition

This feature was added to support rapid prototyping; it allows the rapid transfer of arbitrarily large amounts of data via the auxiliary port to the debug tools. Its uses a more efficient protocol than that used in data trace. It is also of major importance for calibration in automotive applications.

Software API

This is a low-level Application Programming Interface (API) that ‘hides’ the target specifics such as host connection (such as an emulator or Calibration-instrument) mechanism and processor specific Nexus register details. This API is produced jointly by the tool and semiconductor vendor.

Compliance classes

IEEE-ISTO 5001-2003 is a scalable standard; there are currently four classes of compliance to the standard, ranging from the basic (JTAG only) Class 1 up to Class 4.

Class 1

This class supports run-time control (run, stop, memory upload/download when the processor is halted, breakpoints, read or set registers) using the JTAG interface. Communications are half duplex only and bandwidth is limited. Trace is not supported.

Class 2

This class adds ownership trace and program trace and allows the auxiliary debugging port to be shared with "slow" I/O port pins. Ownership trace allows current task or current process trace for systems based on real-time kernels or operating-systems.

Class 3

This class adds data write trace and memory read/write on-the-fly without halting execution. Data read/write tracing, sharing of the auxiliary port with high speed I/O ports such as the address/data bus, and support for data acquisition (visibility of related data parameters stored in internal resources, typically related calibration variables) may also be optionally part of Class 3 compliance.

Class 4

The class adds memory substitution (fetching or reading data over the Nexus auxiliary port) and allows tracing to be triggered by a watchpoint. Triggering memory substitution on a watchpoint is an optional feature of Class 4 compliance.

External links

NEXUS 5001 Forum
Nexus 5001 Forum Global Embedded Processor Debug Interface Standard, by William Wong
Multi-core analysis made easy with the Nexus 5001 debug spec, by Dr. Neal Stollon
The NEXUS Debug Standard: Gateway to the Embedded Systems of the Future, by Ashling Microsystems, Inc.