Nexus 5001 Forum Global Embedded Processor Debug Interface Standard

March 5, 2001
Few debugging standards exist, which makes the Nexus 5001 Forum's Global Embedded Processor Debug Interface standard stand out. Based on the IEEE-1149.1 JTAG bus, the Nexus 5001 standard provides a way to integrate general debugging tools with...

Few debugging standards exist, which makes the Nexus 5001 Forum's Global Embedded Processor Debug Interface standard stand out. Based on the IEEE-1149.1 JTAG bus, the Nexus 5001 standard provides a way to integrate general debugging tools with platform-dependent debugging hardware, versus the use of custom debugging tools and associated hardware.

Initially targeted at automotive control system-on-a-chip (SoC) applications, the IEEE Industry Standards and Technology Organization (ISTO) Nexus 5001 Forum standard is suitable to use in any processing environment. It's recognized by the IEEE Vehicular Technology Society.

The IEEE 1149.1 is primarily a serial bus employed for monitoring and setting register contents within a system under test (SUT). The Nexus 5001 Debug Interface Standard adds an AUX port to in-crease throughput to ac-commodate the movement of debugging data between the SUT and the debugging application.

The standard addresses both the hardware interface and the software application programming interface (API). The Nexus 5001 API consists of only half a dozen function definitions.

The standard nxapi.h file contains C function definitions al-though there is no restriction on the language used to implement either the underlying Emulator Hardware Abstraction Layer (HAL) that drives the Nexus 5001 bus interface, or the debug application that communicates with the Tool Abstraction Layer (TAL).

The standard does not dictate how the hardware or software is partitioned, so an implementation may consist of various hardware components. Although the standard does not specify a multiplexing protocol, it is possible to implement the Nexus API to handle multiple processors either on the same chip or spread across multiple boards. Multiplexing in this case can be handled in a fashion similar to multiplexing JTAG-enabled devices.

One of the first applications of the standard was in a design from Motorola Semiconductor, in the company's MMC 2080 32-bit microRISC processor. This product is based on the Motorola M*Core M431RISC processor and a Motorola 56000 DSP core.

See associated figure.

NEXUS NXAPI.H DEFINITIONS
nx_Open open a target connection
nx_Close close a target connection
nx_WriteMem write target memory
nx_ReadMem read target memory
nx_SetEvent set an event
nx_ClearEvent clear an event
DEVELOPMENT FEATURES
nx_Control() Read/write user registers in debug mode
nx_WriteMem() Write user memory in debug mode
nx_ReadMem() Read user memory in debug mode
nx_Control() Enter a debug mode from reset
nx_Control() Enter a debug mode from user mode
nx_Control() Exit a debug mode to user mode
nx_SetEvent() Single step instruction in user mode and re-enter debug mode
nx_SetEvent() Stop program execution on instruction/data breakpoint and enter debug mode (minimum 2 breakpoints)
nx_SetEvent() Ability to set breakpoint or watchpoint
nx_Control() Device Identification
nx_SetEvent() Ability to send out an event occurrence when watchpoint matches
nx_GetEvent() Monitor process ownership while processor runs in real time
nx_GetEvent() Monitor program flow while processor runs in real time (logical address)
nx_GetEvent() Monitor data writes while processor runs in real time
nx_WriteMem() Write memory locations while program runs in real time
nx_ReadMem() Read memory locations while program runs in real time
nx_GetEvent() Program execution (instruction/data) from Nexus port for reset or exceptions
nx_SetEvent() Ability to start ownership, program, or data trace upon watchpoint occurrence
nx_SetEvent() Ability to start memory substitution upon watchpoint occurrence or upon program access of device-specific address
nx_GetEvent() Monitor data reads while processor runs in real time
nx_Control() LSIO port replacement and HSIO port sharing
nx_SetEvent() Transmit data values for acquisition by tool
Nexus 5001 Class Specifications The Nexus 5001 Forum's Interface standard allows various levels of conformance. This permits im-plementation of different performance levels and the use of resources in a way desired by the hardware designer. The same API is supported regardless of the underlying implementation.

The Class-1 level provides a minimal implementation. This still supports breakpoints and access to memory and registers while minimizing the number of pins in the AUX port. The tradeoff is system performance be-cause it will take a longer time to read or write data. Class-1 implementations are very useful for cases where pin counts are critical, like in handheld applications or other portable environments.

Class 4 is at the other end of the spectrum, where there's a full complement of features. The AUX port maxes out at 16 bits, but it can handle information from a 32- or 64-bit processor.

The size of the AUX port doesn't affect the message-passing protocol controlled by the IEEE-1149.1 port. The interface doesn't impose performance requirements. But, an implementation should have the upload and download speeds specified and an indication of whether the AUX port will operate in a full- or half-duplex mode. Class 1 operates in a half-duplex mode while Classes 2, 3, and 4 operate in full duplex. Also, Class 1 doesn't need an AUX port because it simply uses the IEEE-1149.1 port.

AUX port messages start with a 6-bit TCODE that uniquely defines the message type. There are 56 values reserved or defined by the standard. For Vendor Defined Messages, 8 TCODEs are allocated. The number of messages supported by an implementation is based on the class that, in turn, supports various features, including breakpoints, watchpoints, and even tracing capabilities found in Classes 3 and 4.

The standard defines a number of different mechanical interfaces for board-level connections. This enables debug interface hardware that supports the Nexus 5001 standard to plug into a Nexus 5001-compatible DUT. The complete standard can be found on the Forum's Web site.

STATIC DEVELOPMENT FEATURES
DEVELOPMENT FEATURE CLASS 1 CLASS 2 CLASS 3 CLASS 4 NEXUS FEATURE
Read/write user registers in debug mode V V V V Read/Write Access
Read/write user memory in debug mode A A A A Read/Write Access
Enter a debug mode from reset A A A A Development Control and Status
Enter a debug mode from user mode A A A A Development Control and Status
Exit a debug mode to user mode A A A A Development Control and Status
Single-step instruction in user mode and re-enter debug mode A A A A Development Control and Status
Stop-program execution on instruction/data breakpoint and enter debug mode (minimum 2 breakpoints) A A A A Breakpoints/Watchpoints
DYNAMIC DEVELOPMENT FEATURES
DEVELOPMENT FEATURE CLASS 1 CLASS 2 CLASS 3 CLASS 4 NEXUS FEATURE
Ability to set breakpoint or watchpoint A A A A Breakpoints/Watchpoints
Device Identification A A and P A and P A and P Device ID Message
Ability to send out an event occurrence when watchpoint matches P P P P Watchpoint Message
Monitor process ownership while processor runs in real time P P P Ownership Trace
Monitor program flow while processor runs in real time (logical address) P P P Program Trace
Monitor data writes while processor runs in real time P P Data Trace (Writes only)
Read/write memory locations while program runs in real time A and P A and P Read/Write Access
Program execution (instruction/data) from Nexus port for reset or exceptions P Memory Substitution
Ability to start ownership, program, or data trace upon watchpoint occurrence A Development Control and Status
Ability to start memory substitution upon watchpoint occurrence or upon program access of device-specific address O Development Control and Status
Monitor data reads while processor runs in real-time O O Data Trace (Reads and Writes)
LSIO port replacement and HSIO port sharing O O O Port Replacement/Sharing
Transmit data values for acquisition by tool O O Data Acquisition
 
V: a required vendor-defined development feature implemented in the Nexus API
A: a required development feature that must be implemented via the Nexus API
P: a required development feature that must be implemented via the Nexus development port as a Public Message or with a Nexus port pin (as appropriate)
O: an optional development feature as defined by the Nexus standard

Sponsored Recommendations

Understanding Thermal Challenges in EV Charging Applications

March 28, 2024
As EVs emerge as the dominant mode of transportation, factors such as battery range and quicker charging rates will play pivotal roles in the global economy.

Board-Mount DC/DC Converters in Medical Applications

March 27, 2024
AC/DC or board-mount DC/DC converters provide power for medical devices. This article explains why isolation might be needed and which safety standards apply.

Use Rugged Multiband Antennas to Solve the Mobile Connectivity Challenge

March 27, 2024
Selecting and using antennas for mobile applications requires attention to electrical, mechanical, and environmental characteristics: TE modules can help.

Out-of-the-box Cellular and Wi-Fi connectivity with AWS IoT ExpressLink

March 27, 2024
This demo shows how to enroll LTE-M and Wi-Fi evaluation boards with AWS IoT Core, set up a Connected Health Solution as well as AWS AT commands and AWS IoT ExpressLink security...

Comments

To join the conversation, and become an exclusive member of Electronic Design, create an account today!