RISC-V Debugger and Trace

Release 02.2025

MANUAL
RISC-V Debugger and Trace

TRACE32 Online Help

TRACE32 Directory

TRACE32 Index

TRACE32 Documents ...................................................................................................................... 

ICD In-Circuit Debugger ................................................................................................................ 

Processor Architecture Manuals .............................................................................................. 

RISC-V ...................................................................................................................................... 

RISC-V Debugger and Trace ............................................................................................... 1

History ................................................................................................................................ 6

Introduction ....................................................................................................................... 7
Brief Overview of Documents for New Users 7
Demo and Start-up Script 8
List of Abbreviations and Definitions 9

Warning .............................................................................................................................. 10

Quick Start of the JTAG Debugger .................................................................................. 11

Quick Start for Debug Module Configuration ................................................................. 16

Debug Module Access via JTAG-DTM 17
Implicit JTAG-DTM + DM Configuration 18
Explicit JTAG-DTM + DM Configuration via RVDMIAP + COREDEBUG 19
Debug Module Access via Arm CoreSight Debug Bus 21

Quick Start for Multicore Debugging ............................................................................... 23

SMP Debugging 23
SMP Debugging - Selective 24
SMP Debugging - Multiple Debug Modules 25
Homogeneous SMP/AMP Debugging 26
Heterogeneous SMP/AMP Debugging 27

Troubleshooting ................................................................................................................ 28
Communication Between Debugger and Processor Cannot Be Established 28

RISC-V Debugging ............................................................................................................ 30

Debug Specification for External Debug Support 30
Disassembler Configuration 30
Access Classes 32
Description of the Individual Access Classes 32
Combination of Several Access Classes 34
How to Create Valid Access Class Combinations 36

©1989-2025 Lauterbach RISC-V Debugger and Trace | 2

 Special RISC-V Access Classes 38
DMI Access Class: Byte Address vs Register Index 38
Breakpoints 39
Software Breakpoints 39
On-chip Breakpoint Resources 39
On-chip Breakpoints for Instruction Address 39
On-chip Breakpoints for Data Address 39
On-chip Data Value Breakpoints 40
Examples for Standard Breakpoints 41
Floating-Point Extensions 42
Hardware Performance Monitor 44
Hart State: Unavailable 45
Semihosting 46
Vector Extension 47

RISC-V Tracing .................................................................................................................. 48

RISC-V Trace Standards 48
RISC-V Trace Specifications 48
RISC-V Trace IP Blocks 49
N-Trace 50
E-Trace 50
Quick Start for Trace Configuration Basics 51
Quick Start for Trace Configuration Examples 53
Example A: Single-core N-Trace to On-chip Trace Sink 53
Example B: Multi-core N-Trace to Off-chip Trace Sink 54
N-Trace 55
Trace Message Types 55
Trace Trigger and Filter 55
E-Trace 55
Trace Message Types 55
Trace Trigger and Filter 55

Command Reference: SYStem Commands .................................................................... 56

[Link] Display target configuration 56
[Link] Configure debugger according to target topology 57
<parameters> Describing the “DebugPort” 60
<parameters> Describing the “JTAG” Scan Chain and Signal Behavior 63
<parameters> Configuring an Arm CoreSight Debug Access Port “CoreSight AP” 68
<parameters> Configuring a RISC-V Debug Access Port 75
<parameters> Describing Debug and Trace “Components” 77
<parameters> Describing Tessent Embedded Analytics Details 78
[Link] Set hart index 79
[Link].<sub_cmd> Configure N-Trace trace encoder 80
[Link].<sub_cmd> Configure RISC-V ATB bridge 81
[Link].<sub_cmd> Configure RISC-V E-TRACE 82

©1989-2025 Lauterbach RISC-V Debugger and Trace | 3

 [Link].<sub_cmd> Configure RISC-V trace funnel 83
[Link].<sub_cmd> Configure RISC-V pin interface block 85
[Link].<sub_cmd> System memory sink 86
[Link].<sub_cmd> RISC-V SRAM trace sink 87
[Link] Select the CPU to be debugged 88
[Link] Define JTAG frequency 89
[Link] Tristate the JTAG port 90
[Link] Select run-time memory access method 91
[Link] Memory access while stopped 93
[Link] Establish the communication with the target 94
[Link] Display [Link] window 95

Command Reference: SYStem Option Commands ....................................................... 96

[Link].Address32 Define address format display 96
[Link] Select AHB-AP HPROT bits 96
[Link] ACE enable flag of the AXI-AP 96
[Link] Configure AXI-AP cache bits 97
[Link] Select AXI-AP HPROT bits 98
[Link] Force debug power in DAP 99
[Link] No DAP instruction register check 99
[Link] Rearrange DAP memory map 100
[Link] Force system power in DAP 100
[Link] Options for debug port handling 101
[Link] Allow debugger to reset DM via dmactive 102
[Link] Allow the debugger to drive nRESET (nSRST) 102
[Link] Use Harvard memory model 103
[Link] Set reset duration time 103
[Link] Disable interrupts while single stepping 104
[Link] Disable interrupts while HLL single stepping 104
[Link] Disable JTAG IR width detection 104
[Link] Manually configure support for ISA extensions 105
[Link] Keep hart available for debugger 105
[Link] Separate address spaces by space IDs 106
[Link] Choose method to detect a target reset 107
[Link] Select reset method 107
[Link] Use 32-bit access to set SW breakpoints 110
[Link] Define action during [Link] 111
[Link] Allow debugger to drive TRST 111
[Link] Set reset wait time 112
[Link] Enable symbol management for zones 113

Command Reference: MMU Commands ......................................................................... 115

[Link] Page wise display of MMU translation table 115
[Link] Compact display of MMU translation table 117
[Link] Load MMU table from CPU 119

©1989-2025 Lauterbach RISC-V Debugger and Trace | 4

 Command Reference: TrOnchip Commands .................................................................. 122

Command Reference: RVATBBRIDGE Commands ....................................................... 122

RVATBBRIDGE.<sub_cmd> Control RISC-V trace ATB bridge 122

Command Reference: RVPIB Commands ....................................................................... 123

RVPIB.<sub_cmd> Control RISC-V pin interface block 123

Command Reference: RVETRACE (E-Trace) .................................................................. 125

[Link] Disable E-TRACE 125
[Link] Enable E-TRACE 125
[Link] Show trace control registers 125
[Link] Reset E-TRACE encoder 126
[Link] Configure trace source ID of E-TRACE encoder 126
[Link] Enable / disable E-TRACE encoder timestamps 126

Command Reference: NEXUS (N-Trace) ......................................................................... 127

[Link] Power on N-Trace encoder 127
[Link] Power off N-Trace encoder 127
[Link] Enable / disable N-Trace encoder timestamps 127
[Link] Configure trace source ID of N-Trace encoder 128
[Link] Configure trace source ID width of N-Trace encoder 128
[Link] Show trace control registers 129
[Link] Reset N-Trace encoder 130

Target Adaption ................................................................................................................. 131

Connector Type and Pinout 131
RISC-V Debug Cable with 20 pin Connector 131

©1989-2025 Lauterbach RISC-V Debugger and Trace | 5

RISC-V Debugger and Trace

Version 13-Feb-2025

History

12-Dec-2024 Chapter 'RISC-V Tracing' added. A set of commands for configuring the trace infrastructure
has been introduced.

05-Aug-2024 New command [Link].

02-Aug-2024 [Link], [Link], and [Link] commands updated: ‘CPU specific Tables’
descriptions added.

24-Jul-2024 New AccessPort RISC-V parameters for the [Link] command. A detailed
description can be found in '<parameters> Configuring a RISC-V Debug Access Port'.

22-Jul-2024 New subchapter ‘SMP Debugging - Multiple Debug Modules’.

17-Nov-2023 New command [Link].

18-Aug-2023 Marked [Link] as deprecated command and replaced by

[Link].

17-Oct-2022 New subchapter ‘Vector Extension’.

06-Oct-2022 New command [Link].

06-Oct-2022 New subchapter: ‘Hart State: Unavailable’.

29-Aug-2022 New command: [Link].

20-Jul-2022 For the [Link] ALL command, CLEAR is now possible as an optional second
parameter.

04-Sep-2017 Initial version.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 6

Introduction

This manual serves as a guideline for debugging and tracing one or multiple RISC-V cores via TRACE32.

Please note that only the Processor Architecture Manual (the document you are currently reading) is
specific to the core architecture. All other parts of the online help are general and independent of any core
architecture. Therefore, if you have questions related to the core architecture, the Processor Architecture
Manual should be your primary reference.

Brief Overview of Documents for New Users

Architecture-independent information:

• “Debugger Tutorial” (debugger_tutorial.pdf): Get familiar with the basic features of a TRACE32
debugger.

• “General Commands” (general_ref_<x>.pdf): Alphabetic list of debug commands.

• “OS Awareness Manuals” (rtos_<os>.pdf): TRACE32 PowerView can be extended for operating
system-aware debugging. The appropriate OS Awareness manual informs you how to enable the
OS-aware debugging.

Architecture-specific information:

• “Processor Architecture Manuals”: These manuals describe commands that are specific for the
processor architecture supported by your Debug Cable. To access the manual for your processor
architecture, proceed as follows:

- Choose Help menu > Processor Architecture Manual.

PRACTICE Script Language:

• “Training Script Language PRACTICE” (training_practice.pdf)

• “PRACTICE Script Language Reference Guide” (practice_ref.pdf)

Video Tutorials:

• Lauterbach YouTube channel

©1989-2025 Lauterbach RISC-V Debugger and Trace | 7

 To get started with the most important manuals, use the Welcome to TRACE32! dialog ([Link]):

Demo and Start-up Script

Lauterbach provides ready-to-run start-up scripts for known hardware that is based on RISC-V.

To search for PRACTICE scripts, do one of the following in TRACE32 PowerView:

• Type at the command line: [Link]

• or choose File menu > Search for Script.

You can now search the demo folder and its subdirectories for PRACTICE start-up scripts
(*.cmm) and other demo software.

You can also manually navigate in the ~~/demo/riscv/ subfolder of the system directory of TRACE32.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 8

List of Abbreviations and Definitions

CSR Control and Status Register

DM Debug Module, as defined by the RISC-V debug specification

DTM Debug Transport Module, as defined by the RISC-V debug

specification

HART Single RISC-V core contains one or multiple hardware threads

Hardware thread

XLEN Current width of a RISC-V general purpose register in bits

©1989-2025 Lauterbach RISC-V Debugger and Trace | 9

Warning

WARNING: To prevent debugger and target from damage it is recommended to connect or

disconnect the Debug Cable only while the target power is OFF.

Recommendation for the software start:

1. Disconnect the Debug Cable from the target while the target power is
off.

2. Connect the host system, the TRACE32 hardware and the Debug
Cable.

3. Power ON the TRACE32 hardware.

4. Start the TRACE32 software to load the debugger firmware.

5. Connect the Debug Cable to the target.

6. Switch the target power ON.

7. Configure your debugger e.g. via a start-up script.

Power down:

1. Switch off the target power.

2. Disconnect the Debug Cable from the target.

3. Close the TRACE32 software.

4. Power OFF the TRACE32 hardware.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 10

Quick Start of the JTAG Debugger

Starting up the debugger is done as follows:

1. Reset all debugger settings.

RESet

The RESet command ensures that no debugger settings persist from a previous debug session; all
settings are restored to their default values. Using RESet is unnecessary if you begin the debug
session immediately after launching TRACE32 PowerView. Note that RESet does not reset the
target.

2. Select the chip or core you intend to debug.

[Link] <cpu_type>

Select a core only if you are debugging a confidential chip or a chip not yet supported by TRACE32.
For chips already supported by TRACE32, the debugger automatically configures the
[Link] and [Link] commands for optimal compatibility, often requiring no
additional setup. However, please note that the default configuration may not always be ideal for your
specific target hardware.

3. Configure the JTAG interface.

The default clock frequency is 10 MHz. You can manually set the JTAG clock frequency used by the
debugger to communicate with the target hardware by using the [Link] command. The
maximum clock frequency may vary depending on your FPGA design configuration

In case of a JTAG daisy chain use command [Link] SHOWChain to scan the chain. The
result is shown in a window. Double-click on the desired core to tell the debugger which core you’d like
to debug.

3.A) Systems with RISC-V JTAG-DTM

If the RISC-V Debug Module (DM) is accessible via a RISC-V JTAG-DTM, and the JTAG TAP of that
JTAG-DTM is daisy-chained with other TAPs, then you can manually configure the JTAG daisy chain
in one of two ways:
- For simple systems use implicit JTAG-DTM configuration via [Link],
[Link], [Link] and [Link].
- For more complex systems use explicit JTAG-DTM configuration via [Link]

3.B) Systems with Arm CoreSight DAP

If the target system has an Arm CoreSight Debug Access Port (Arm DAP), and the JTAG TAP of the
DAP is daisy-chained with other TAPs, then you can manually configure the JTAG daisy chain with
[Link], [Link], [Link]
and [Link].

4. Configure memory access ports (if available).

4.1) Systems with RISC-V JTAG-DTM (DMI Access Port)

If the target system does have one or more RISC-V JTAG-DTMs, and if the Debug Module Interface
(DMI) debug bus behind these JTAG-DTMs needs to be accessible to the user via the ‘DMI’ access

©1989-2025 Lauterbach RISC-V Debugger and Trace | 11

 class, then DMI access ports need to be configured. See explicit JTAG-DTM configuration via
[Link] for details.

4.2) Systems with Arm CoreSight memory access ports

If the target SoC has an Arm CoreSight debug infrastructure, then the memory access ports need to
be configured in order to make their buses accessible via the respective access classes.
For Arm SoC-400, see [Link], [Link] and
[Link] for details.
For Arm SoC-600, see [Link], [Link] and
[Link] for details.

5. Tell the debugger how to access the RISC-V Debug Module.

See chapter “Quick Start for Debug Module Configuration” (debugger_riscv.pdf) for details.

6. Select the reset method.

[Link] <method>

If the debugger is supposed to perform a system reset or core reset while connecting to the target,
then the reset method that is most suitable for the target needs to be configured with
[Link].

7. Connect to target.

[Link]

This command establishes the JTAG communication to the target. It resets the processor and enters
debug mode (halts the processor; ideally at the reset vector). After this command is executed, it is
possible to access memory and registers.

Some devices can not communicate via JTAG while in reset or you might want to connect to a
running program without causing a target reset. In this case use

[Link] Attach

instead. A [Link] will halt the processor.

8. Load the program you want to debug.

[Link] <file>

This loads the executable to the target and the debug/symbol information to the debugger’s host. If
the program is already on the target and you just need the debug/symbol information then load with
/NoCODE option.

A detailed description of the [Link] command and all available options is given in the “General
Commands Reference”.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 12

 PRACTICE Script Example #1: RISC-V System with JTAG-DTM

LAUTERBACH recommends to prepare a PRACTICE script (*.cmm, ASCII file format) to be able to do all
the necessary actions with only one command, such as the command DO <file>.

The following example shows a system configuration for a RISC-V system with JTAG-DTM:

RESet ; Reset the debugger configuration

[Link] FU540-C000 ; Select the SoC/CPU/core

[Link] [Link] ; Set JTAG clock frequency

[Link] IRPRE 4. ; Configure JTAG daisy chain

[Link] IRPOST 0.
[Link] DRPRE 1.
[Link] DRPOST 0.

[Link] NDMRST ; Select the reset method

A typical example for a start sequence (in addition to the above configuration) might look like the following:

[Link] ; Reset the target, stop the core at

; the reset vector, enter debug mode

[Link] riscv_le.elf ; Load the application

[Link] PC main ; Set the PC to function main

[Link] X2 0x63FFFFFC ; Set the stack pointer to

; address 0x63FFFFFC

[Link] P:0x1000 /Program ; Set breakpoint to address P:0x1000

[Link] ; Open source code window

[Link] /SpotLight ; Open register window

[Link] /Locals /Caller ; Open the stack frame with

; local variables

[Link] %SpotLight var1 var2 ; Open watch window for variables

[Link] ; Open window for tree view of

; system peripherals

For more details about the configuration of a RISC-V system with JTAG-DTM, please see chapter
Debug Module access via JTAG-DTM.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 13

 PRACTICE Script Example #2: Arm CoreSight SoC-400

LAUTERBACH recommends to prepare a PRACTICE script (*.cmm, ASCII file format) to be able to do all
the necessary actions with only one command, such as the command DO <file>.

The following example shows a configuration for a RISC-V core in an Arm CoreSight SoC-400 system:

RESet ; Reset debugger configuration

[Link] RV32 ; Select the SoC/CPU/core

[Link] [Link] ; Set JTAG clock frequency

[Link] 4. ; Configure JTAG daisy chain

[Link] 0.
[Link] 1.
[Link] 0.

[Link] NDMRST ; Select the reset method

[Link] 4. ; Configure DAP memory

[Link] 5. ; access ports (SoC-400)

[Link] APB:0x2000 ; Configure APB base address

; of RISC-V debug module

[Link] ; Reset the target, stop the

; core at the reset vector and
; enter debug mode

For additional configuration examples of a RISC-V system integrated into an Arm CoreSight SoC-400
system, please see chapter “Debug Module Access via Debug Bus”, subchapter for SoC-400.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 14

 PRACTICE Script Example #3: Arm CoreSight SoC-600

LAUTERBACH recommends to prepare a PRACTICE script (*.cmm, ASCII file format) to be able to do all
the necessary actions with only one command, such as the command DO <file>.

The following example shows a configuration for a RISC-V core in an Arm CoreSight SoC-600 system:

RESet ; Reset debugger configuration

[Link] RV32 ; Select the SoC/CPU/core

[Link] [Link] ; Set JTAG clock frequency

[Link] 4. ; Configure JTAG daisy chain

[Link] 0.
[Link] 1.
[Link] 0.

[Link] NDMRST ; Select the reset method

[Link] DP:0x30000 ; Configure memory access port

[Link] DP:0x70000 ; base addresses (SoC-600)

[Link] APB:0x2000 ; Configure APB base address

; of RISC-V debug module

[Link] ; Reset the target, stop the

; core at the reset vector and
; enter debug mode

For additional configuration examples of a RISC-V system integrated into an Arm CoreSight SoC-600
system, please see chapter “Debug Module Access via Debug Bus”, subchapter for SoC-600.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 15

Quick Start for Debug Module Configuration

The RISC-V Debug Module (DM) is the central IP block that contains the debug registers, which give the
debugger access to most RISC-V debug functionalities. Usually all RISC-V hardware threads (harts) in a
system are connected to the same DM.

A DM can be integrated into a system in various ways. Any abstract IP block which provides access to the
debug registers of the DM is called Debug Transport Module (DTM):

Chip
Debugger

RISC-V RISC-V hart #0

....
Debug Transport Module Debug Module
(DTM) (DM)
RISC-V hart #n

The RISC-V debug specification does not specify which interface and implementation the DTM needs to
have. In theory, the implementation of the DTM can be completely chip-specific. The RISC-V debug
specification does however define one standardized DTM, the so-called RISC-V JTAG-DTM.

The debugger needs to know how the DM’s debug registers can be accessed. That is why this chapter
provides a quick start for DM configuration. The following examples cover the most common use cases for
DM integration into a system:

• Example A: Debug Module Access via JTAG-DTM

- Example A.1: Implicit JTAG-DTM + DM Configuration

- Example A.2: Explicit JTAG-DTM + DM Configuration via RVDMIAP + COREDEBUG

• Example B: Debug Module Access via Arm CoreSight Debug Bus

©1989-2025 Lauterbach RISC-V Debugger and Trace | 16

Debug Module Access via JTAG-DTM

The simplest way to access a RISC-V Debug Module (DM) from an external JTAG interface is via a
JTAG Debug Transport Module (JTAG-DTM). The JTAG-DTM is specified and standardized by the RISC-V
debug specification. A simple example setup could look as follows:

Chip
RISC-V
Debugger

RISC-V RISC-V hart #0

Debug Port
JTAG Debug

....
JTAG or Debug Module
Transport Module
cJTAG (DM)
(JTAG-DTM) RISC-V hart #n

JTAG-DTM with JTAG port

If the JTAG-DTM does have a normal JTAG port (IEEE 1149.1), then
[Link] needs to be set to “JTAG” (default setting).

JTAG-DTM with cJTAG port

However, the RISC-V debugger does also support JTAG-DTMs with a cJTAG port (IEEE 1149.7). In this
case, [Link] needs to be set to “cJTAG”.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 17

Implicit JTAG-DTM + DM Configuration

The RISC-V debugger considers a JTAG-DTM the default way to access the RISC-V Debug Module (DM).
This means if no user configuration defines any other way to access the DM, then the RISC-V debugger
automatically implies (without any user configuration):

• the existence of a single RISC-V JTAG-DTM that is connected to the external debug port

• the existence of a single RISC-V DM that is directly connected to that JTAG-DTM at base
address DMI:0x0.

This implied setup is depicted in the above chapter Debug Module Access via JTAG-DTM. The implicit
JTAG-DTM configuration does not allow access to the “DMI” access class.

If the JTAG TAP of the JTAG-DTM is daisy-chained with other TAPs, then you can manually configure the
JTAG daisy chain with [Link], [Link], [Link]
and [Link]. These commands only apply to the implicit JTAG-DTM configuration.

For more complicated hardware setups, please refer to the Explicit JTAG-DTM Configuration instead.

NOTE: The implicit configuration mode and the explicit configuration mode of the
RVDMIAP and the RISC-V DM can not be mixed. This means if at least one
RVDMIAP was explicitly configured, then the RISC-V DM needs to be explicitly
configured via [Link] as well.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 18

Explicit JTAG-DTM + DM Configuration via RVDMIAP + COREDEBUG

The RISC-V debug specification defines the RISC-V JTAG Debug Transport Module (JTAG-DTM), which
is a standardized RISC-V IP block that can access the debug registers of the RISC-V Debug Module (DM).
The debug bus that connects the JTAG-DTM to the DM is called the Debug Module Interface (DMI).

As the RISC-V JTAG-DTM provides access to the DMI bus, it can be considered a
RISC-V DMI Access Port (RVDMIAP). See the chapter about the RVDMIAP for details.

The explicit configuration of the RVDMIAP and DM allows to represent more complex hardware setups, and
to get access to the “DMI:” access class. The following examples show common RVDMIAP and DM
configuration scenarios.

NOTE: The implicit configuration mode and the explicit configuration mode of the
RVDMIAP and the RISC-V DM can not be mixed. This means if at least one
RVDMIAP was explicitly configured, then the RISC-V DM needs to be explicitly
configured via [Link] as well.

Example #1: one JTAG TAP, one DM

TDI Chip

RISC-V RISC-V hart #0

RISC-V JTAG-DTM DMI:0x0
Debug Module
IR: 5 bits
(DM)
Debug RISC-V hart #1
(DMI Access Port, Module
"RVDMIAP") Interface
(DMI)
TDO

Debugger configuration example (for SMP debugging):

[Link] <cpu>
[Link] CORE 1. 1.
[Link] CoreNumber 2.
[Link] [Link] 0. 1.
[Link] 1. 2.

[Link] [Link] DebugPort ; External debug port

[Link] [Link] 5. ; Standard JTAG-DTM IR
[Link] [Link] 0. ; No other JTAG TAPs
[Link] [Link] 0.
[Link] [Link] 0.
[Link] [Link] 0.

[Link] [Link] DMI:0x0 DMI:0x0 ; RISC-V DM

©1989-2025 Lauterbach RISC-V Debugger and Trace | 19

 Example #2: multiple JTAG TAPs, multiple DMs

TDI Chip

JTAG Debug RISC-V hart #0

Module RISC-V
TAP DMI:0x0
Debug Module
IR: 7 bits Interface
(DMI) (DM #1)
RISC-V hart #1

RISC-V JTAG-DTM
IR: 5 bits
RISC-V RISC-V hart #0
(DMI Access Port, DMI:0x800
Debug Module
"RVDMIAP") (DM #2)
RISC-V hart #1
TDO

Debugger configuration example (for SMP debugging):

[Link] <cpu>
[Link] CORE 1. 1.
[Link] CoreNumber 4.
[Link] [Link] 0. 1. 0. 1.
[Link] 1. 2. 3. 4.

[Link] [Link] DebugPort ; External debug port

[Link] [Link] 5. ; Standard JTAG-DTM IR
[Link] [Link] 0.
[Link] [Link] 7. ; other JTAG TAP
[Link] [Link] 0.
[Link] [Link] 1. ; other JTAG TAP

[Link] [Link] ; RISC-V DM byte offsets

DMI:0x0 DMI:0x0 DMI:0x800 DMI:0x800

©1989-2025 Lauterbach RISC-V Debugger and Trace | 20

Debug Module Access via Arm CoreSight Debug Bus

An alternative way to make the RISC-V Debug Module (DM) accessible to a debugger is to map the debug
registers of the DM on an existing debug bus.

If the DM debug registers are bus-mapped then the bus type (i.e. the access class) and the base address of
the DM must be configured with the command [Link] [Link].

Example: Arm CoreSight SoC-400

The following example shows a DM that is mapped on a debug bus of an Arm CoreSight SoC-400 system:

Chip
Arm CoreSight SoC-400

Arm
Debug Access Port
System
(DAP)
Memory
AHB
Memory
0 Access Port
RISC-V
Debugger

Debug Port (MEM-AP) 0x2000

JTAG or Debug
APB

cJTAG or Module (DM)

SWD Memory
1 Access Port
(MEM-AP)
RISC-V

RISC-V
hart #0

hart #n
...

TRACE32 configuration:
[Link] [Link] 0.
[Link] [Link] 1.
[Link] [Link] APB:0x2000

The type of the debug port (JTAG, cJTAG or SWD) can be configured via
[Link].

©1989-2025 Lauterbach RISC-V Debugger and Trace | 21

 Example: Arm CoreSight SoC-600

The following example shows a DM that is mapped on a debug bus of an Arm CoreSight SoC-600 system:

Chip
Arm CoreSight SoC-600

AXI
Memory System Memory
0x1000 Access
Port
(MEM-AP)
Debugger

Debug Link
DP
JTAG or
Memory
cJTAG or

APB1
0xA000 Access
SWD Memory
0x3000 Port 0x8000 RISC-V
Access

APB2
(MEM-AP) Debug
Port
Module (DM)
(MEM-AP)

RISC-V

RISC-V
hart #0

hart #n
..

TRACE32 configuration:
[Link] [Link] DP:0x1000
[Link] [Link] DP:0x3000
[Link] [Link] APB1:0xA000
[Link] [Link] APB2:0x8000

The type of the debug port (JTAG, cJTAG or SWD) can be configured via
[Link].

©1989-2025 Lauterbach RISC-V Debugger and Trace | 22

Quick Start for Multicore Debugging

This chapter provides a quick start for multicore processing. The following example scenarios cover the most
common use cases for symmetric multiprocessing (SMP) and asymmetric multiprocessing (AMP):

• Example A: SMP Debugging

• Example B: SMP Debugging - Selective

• Example C: SMP Debugging - Multiple Debug Modules

• Example D: Homogeneous SMP/AMP Debugging

• Example E: Heterogeneous SMP/AMP Debugging

SMP Debugging

This scenario for homogeneous symmetric multiprocessing (SMP) covers the following setup:

4 hardware threads (harts) of the same type are connected to the same RISC-V Debug Module of the same
chip, with the hart indexes of the RISC-V Debug Module ranging from 0 to 3. All 4 harts will be debugged
simultaneously via SMP.

Chip
Hart Hart Hart Hart
type A type A type A type A

RISC-V Debug Module

Hart indexes 0 1 2 3

[Link] 1. 2. 3. 4.

Example A:

[Link] <type_a_cpu>
[Link] CORE 1. 1. ; Core group 1 for chip 1
[Link] CoreNumber 4. ; 4 harts of type A in total
[Link] [Link] 0. 1. 2. 3.
[Link] 1. 2. 3. 4. ; Assign all 4 harts to the
; SMP session

©1989-2025 Lauterbach RISC-V Debugger and Trace | 23

SMP Debugging - Selective

This scenario for homogeneous symmetric multiprocessing (SMP) covers the following setup:

4 hardware threads (harts) of the same type are connected to the same RISC-V Debug Module of the same
chip, with the hart indexes of the RISC-V Debug Module ranging from 0 to 3. The harts with hart indexes 1
and 3 will be debugged simultaneously via SMP.

Chip
Hart Hart Hart Hart
type A type A type A type A

RISC-V Debug Module

Hart indexes 0 1 2 3

[Link] 2. 4.

Example B:

[Link] <type_a_cpu>
[Link] CORE 1. 1. ; Core group 1 for chip 1
[Link] CoreNumber 4. ; 4 harts of type A in total
[Link] [Link] 0. 1. 2. 3.
[Link] 2. 4. ; Assign harts with the
; logical indexes 2 and 4

©1989-2025 Lauterbach RISC-V Debugger and Trace | 24

SMP Debugging - Multiple Debug Modules

This scenario for homogeneous symmetric multiprocessing (SMP) covers the following setup:

4 hardware threads (harts) of the same type are connected to two RISC-V Debug Modules (DM) of the
same chip. Each RISC-V DM is connected to two harts. The hart indexes of each RISC-V DM start at 0, so
each DM has the hart indexes 0 and 1. All 4 harts will be debugged simultaneously via SMP.

Chip
Hart Hart Hart Hart
type A type A type A type A

RISC-V RISC-V
Debug Debug
Module Hart indexes 0 1 0 1 Hart indexes Module
#1 #2

[Link] 1. 2. 3. 4.

Example C:

[Link] <type_a_cpu>
[Link] CORE 1. 1. ; Core group 1 for chip 1
[Link] CoreNumber 4. ; 4 harts of type A in total
[Link] [Link] 0. 1. 0. 1. ; DM hart index starts at 0
[Link] 1. 2. 3. 4. ; Assign all 4 harts to the
; SMP session

©1989-2025 Lauterbach RISC-V Debugger and Trace | 25

Homogeneous SMP/AMP Debugging

This scenario covers both homogeneous symmetric multiprocessing (SMP) and asymmetric
multiprocessing (AMP).

6 hardware threads (harts) of the same type are connected to the same RISC-V Debug Module of the same
chip, with the hart indexes of RISC-V Debug Module ranging from 0 to 5. The first 4 harts will be debugged
in an SMP session, and the remaining 2 harts in another SMP session.

Chip
Hart Hart Hart Hart Hart Hart
type A type A type A type A type A type A

RISC-V Debug Module

Hart indexes 0 1 2 3 4 5

GUI #1
[Link] 1. 2. 3. 4.

[Link] 5. 6.
GUI #2

Example D:

; ---- TRACE32 PowerView GUI #1 ----------------------------------------

[Link] <type_a_cpu>
[Link] CORE 1. 1. ; Core group 1 for chip 1
[Link] CoreNumber 6. ; 6 harts of type A in total
[Link] [Link] 0. 1. 2. 3. 4. 5.
[Link] 1. 2. 3. 4. ; Assign the first 4 harts

; ---- TRACE32 PowerView GUI #2 ----------------------------------------

[Link] <type_a_cpu>
[Link] CORE 2. 1. ; Core group 2 for chip 1
[Link] CoreNumber 6. ; 6 harts of type A in total
[Link] [Link] 0. 1. 2. 3. 4. 5.
[Link] 5. 6. ; Assign the last 2 harts

©1989-2025 Lauterbach RISC-V Debugger and Trace | 26

Heterogeneous SMP/AMP Debugging

This scenario covers both heterogeneous symmetric multiprocessing (SMP) and asymmetric
multiprocessing (AMP).

6 hardware threads (harts) are connected to the same RISC-V Debug Module of the same chip, with the
hart indexes of the RISC-V Debug Module ranging from 0 to 5. The first 4 harts are of type A and will be
debugged in an SMP session, and the remaining 2 harts are of type B and will be debugged in another SMP
session.
Chip
Hart Hart Hart Hart Hart Hart
type A type A type A type A type B type B

RISC-V Debug Module

Hart indexes 0 1 2 3 4 5

GUI #1
[Link] 1. 2. 3. 4.

[Link] 1. 2.
GUI #2

Example E:

; ---- TRACE32 PowerView GUI #1 ----------------------------------------

[Link] <type_a_cpu>
[Link] CORE 1. 1. ; Core group 1 for chip 1
[Link] CoreNumber 4. ; 4 harts of type A in total
[Link] [Link] 0. 1. 2. 3. ; Hart indexes of type A
[Link] 1. 2. 3. 4. ; Assign all 4 harts of type A

; ---- TRACE32 PowerView GUI #2 ----------------------------------------

[Link] <type_b_cpu>
[Link] CORE 2. 1. ; Core group 2 for chip 1
[Link] CoreNumber 2. ; 2 harts of type B in total
[Link] [Link] 4. 5. ; Hart indexes of type B
[Link] 1. 2. ; Assign all 2 harts of type B

©1989-2025 Lauterbach RISC-V Debugger and Trace | 27

Troubleshooting

Communication Between Debugger and Processor Cannot Be Established

Typically [Link] Up or [Link] Attach is the first command of a debug session for which
communication with the target board is required. That is why it is the most common command to fail in case
that there is any issue with the user configuration, debug connection or target.

NOTE: In case of any error during the debug session, we highly recommend to open
the [Link] window. This window usually contains a list of all recent warnings
and error messages, which can be very helpful for error diagnosis.

The error messages in the [Link] window (which can be identified by their red color) usually try to give
the user a short error description and a reason for the error. However in some scenarios it can be difficult to
deduce the error cause from an error message, because the error message is either too generic or the error
message is only the follow-up error of another issue that has nothing to do with the actual error message. In
order to still be able to resolve the error in such scenarios, the following lists the most common error causes:

• The target has no power or the debug cable is not connected to the target. This results in the
error message “target power fail”.

• You did not select the correct core type via [Link] <type>.

• There is an issue with the JTAG interface. See [Link]/[Link] and the
manuals or schematic of your target to check the physical and electrical interface. Maybe there is
the need to set jumpers on the target to connect the correct signals of the JTAG connector.

• Your RISC-V Debug Module (DM) is mapped on a debug bus, but the base address of the DM is
either not configured or incorrect. Check the settings of [Link].

• You might have several TAP controllers in your JTAG-chain. Example: The TAP of the JTAG-DTM
could be in a chain with other TAPs from other CPUs. In this case you have to check your pre-
and post-bit configuration. See for example [Link] or
[Link].

• The default frequency of the JTAG/SWD/cJTAG debug port is too high, especially if you emulate
your core or if you use an FPGA-based target. In this case try [Link] 50kHz and
optimize the speed when you got it working.

• The target cannot communicate with the debugger while in reset. Try [Link] Attach
followed by [Link] instead of [Link] Up.

• The target does not support the configured reset method. Select a different reset method via
[Link].

• The target needs a certain setup time during the reset assertion or after the reset release. Try to
adapt the reset timing via [Link] and/or [Link].

• There is a watchdog which needs to be deactivated.

• There is the need to enable (jumper) the debug features on the target. It will e.g. not work if
nTRST signal is directly connected to ground on target side.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 28

 • The target is in an unrecoverable state. Re-power your target and try again.

• The core has no power or is kept in reset.

• The core has no clock.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 29

RISC-V Debugging

Debug Specification for External Debug Support

The Lauterbach debug driver for RISC-V is developed according to the official RISC-V debug specification
for external debug support. The latest official version can be found at
[Link]

Disassembler Configuration

The [Link] command enables you to format the disassembler display in TRACE32 windows, such as
[Link]. The following <constants> command parameters are specific to RISC-V:

• AbiNames, which activates the ABI (Application Binary Interface) naming convention for general-
purpose registers.

• RegNames (default naming scheme), which employs the register number format (x0, x1, …, x31)
for these registers.

Example:

[Link] AbiNames

This SETUP command displays the general-purpose registers in the [Link] window according to the
specified naming scheme. It also ensures that the general-purpose registers are displayed using the chosen
naming scheme in all TRACE32 windows that show disassembled code, such as [Link].

A B

A Register number naming scheme. B ABI naming scheme.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 30

 A

It is advisable to include the disassembler setup in the startup script.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 31

Access Classes

In TRACE32, addresses always consist of two parts:

• An access class which defines:

- What kind of memory (or register) to access
- How to perform the access

• A number that determines the address of the access

Each access class consists of one or more letters/numbers followed by a colon (:).

Examples:

[Link] D:0x100
[Link] AXI:0x80000000--0x80000FFF
PRINT [Link](CSR:0x300)

It is possible to combine individual access classes.

For more background information, see the chapter about access classes in the TRACE32 Concepts.

In this section:

• Description of the Individual Access Classes

• Combination of Several Access Classes

• How to Create Valid Access Class Combinations

Description of the Individual Access Classes

Description

P Program memory access.

See [Link] and [Link] for the used
access method.

D Data memory access.

See [Link] and [Link] for the used
access method.

M Machine privilege level

S Supervisor privilege level.

For debugger memory accesses with this access class, machine privilege
level is used.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 32

 Description

U User privilege level.

For debugger memory accesses with this access class, machine privilege
level is used.

A Absolute addressing (physical address) on SoCs with Memory

Management Unit (MMU).

C “Current”. Do not use this access class. It might be shown by the debugger
if it is unknown what access class shall be used. The actual used access
class is derived from the current processor mode.

CSR Control and Status Register (CSR) access.

The CSR address of this access class does always address data of
maximum CSR register width XLEN. If a CSR register is smaller than the
maximum size, the unused segment gets filled up with zero.

E Allow memory access while the CPU is running.

See [Link], [Link] and [Link].
Any memory access class can be prefixed with E, if the memory supports
access while the CPU is running.

VM Virtual Memory (memory on the debug system).

SB System bus access.

The memory accesses with this access class are performed via the
“System Bus Access block” of the RISC-V Debug Module.

DMI Debug Module Interface (DMI) bus access.

The DMI bus is defined in the RISC-V debug specification. The address of
this access class is a byte address.
See [Link] RVDMIAP and the chapter about the DMI address
definition for details.

APB APB bus access.

If the APB bus is accessible via an Arm CoreSight DAP (SoC-400), see
[Link] [Link] for details.
If the APB bus is accessible via an Arm CoreSight DAP (SoC-600), see
[Link] [Link] for details.

AHB AHB bus access.

NAHB, ZAHB If the AHB bus is accessible via an Arm CoreSight DAP (SoC-400), see
[Link] [Link] for details.
If the AHB bus is accessible via an Arm CoreSight DAP (SoC-600), see
[Link] [Link] for details.

AXI AXI bus access.

NAXI, ZAXI If the AXI bus is accessible via an Arm CoreSight DAP (SoC-400), see
[Link] [Link] for details.
If the AXI bus is accessible via an Arm CoreSight DAP (SoC-600), see
[Link] [Link] for details.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 33

Combination of Several Access Classes

It is possible to combine certain individual access classes for an access. An access class combination can
consist of up to five access class specifiers. But any of the five specifiers can also be omitted.

The following examples will demonstrate combinations of three access classes:

• E: Allow memory access while the CPU is running

• A: Physical access, i.e. the MMU is bypassed.

• D: Data memory access

Combination of three access class specifiers:

In this example, let’s assume...

• You want to view the data memory from the perspective of the CPU:
Use “D” access class specifier.

• You want to be able to access the data memory independent of whether the CPU is running or halted:
Use “E” access class specifier.

• You want to make a physical access without any MMU address translation:
Use “A” access class specifier.

When you put all three access class specifiers together, you will obtain the access class combination “EAD”:

[Link] EAD:0x80000000 // Physical data memory access during run-time

Combination of two access class specifiers:

In this example, let’s assume...

• You want to view the data memory from the perspective of the CPU:
Use “D” access class specifier.

• You want to be able to access the data memory independent of whether the CPU is running or halted:
Use “E” access class specifier.

• You want to make a virtual access including MMU address translation:

Do not use “A” access class specifier.

When you put the two access class specifiers together, you will obtain the access class combination “ED”:

[Link] ED:0x80000000 // Virtual data memory access during run-time

©1989-2025 Lauterbach RISC-V Debugger and Trace | 34

 One access class specifier:
In this example, let’s assume...

• You want to view the data memory from the perspective of the CPU:
Use “D” access class specifier.

• You do not want to be able to access the data memory while the CPU is running:
Do not use “E” access class specifier.

• You want to make a virtual access including MMU address translation:

Do not use “A” access class specifier.

This means in this case we wo not have a combination of access classes, but instead we simply have the
access class “D”:

[Link] D:0x80000000 // Virtual data memory access (only when stopped)

No access class specifier:

In this example, we will see what happens when you do not specify any access class at all. In this case the
memory access by the debugger will be a virtual access using the current CPU context, i.e. the debugger
has the same view on memory as the CPU:

[Link] 0x80000000 // Virtual memory access (only when stopped)

©1989-2025 Lauterbach RISC-V Debugger and Trace | 35

How to Create Valid Access Class Combinations

There are certain rules on if and how individual access classes can be combined. Only certain access
classes can be combined with each other, and they need to be combined in a certain order.

The illustrations below will show you how to combine access class specifiers for frequently-used access
class combinations.

Rules to create a valid access class combination:

• From each column of an illustration block, select only one access class specifier.

• You may skip any column - but only if the column in question contains an empty square.

• Do not change the original column order. Recommendation: Put together a valid combination by
starting with the left-most column, proceeding to the right.

Memory Access Through CPU (CPU View)

The debugger uses the CPU to access memory, so the CPU carries out the accesses requested by the
debugger. This can be either virtual or physical accesses. The accesses can either only happen when the
CPU is stopped, or also while the CPU is running.

E A M D

S P

Example combinations:

ED Data memory access at run-time

MD Data memory access with machine privilege level

EMD Data memory access with machine privilege level at run-time

AP Physical program memory access

©1989-2025 Lauterbach RISC-V Debugger and Trace | 36

 Control and Status Register (CSR) Access

This is used to access the CSRs of a core.

E CSR

Example combinations:

ECSR CSR access at run-time

System Bus Access

These accesses grant direct access to system buses, bypassing the CPU.

E N AXI E DMI

Z AHB SB

APB

Example combinations:

EZAXI Access secure memory location via AXI at run-time

ESB System bus access of RISC-V debug module at run-time

©1989-2025 Lauterbach RISC-V Debugger and Trace | 37

Special RISC-V Access Classes

DMI Access Class: Byte Address vs Register Index

The debug bus behind a RISC-V JTAG-DTM is called “Debug Module Interface” (DMI), and is associated
with the “DMI:” access class.

In the Lauterbach RISC-V debugger user interface, the “DMI:” access class uses a byte address.
In the example below, the base address of the RISC-V Debug Module has the byte address “DMI:0x800”.
So you would need to configure “ [Link] DMI:0x800”.

However, the RISC-V Debug Specification defines the “DMI address” as a 32bit register index.
In the example below, the equivalent DMI register index would be 0x200 (register index = byte address / 4).

Chip
TDI
Debug
Module
RISC-V JTAG-DTM Interface
(DMI)
(DMI Access Port, RISC-V hart #0
RISC-V
"RVDMIAP") DMI:0x800
Debug Module
(DM)
TDO RISC-V hart #1

NOTE: If you configure your RISC-V debugger for a system with RISC-V JTAG-DTM
and corresponding DMI access class, take into account that the RISC-V
debugger user interface considers DMI addresses as byte addresses.

On the other hand, some RISC-V specifications (such as the RISC-V Debug
Specification) use register indexes. Furthermore, take into account that the
memory maps of SoC reference manuals can either use byte addresses or
register indexes (this depends on the respective manual).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 38

Breakpoints

For general information about setting breakpoints, refer to the [Link] command.

Software Breakpoints

If a software breakpoint is used, the original instruction at the breakpoint location is temporarily patched by a
breakpoint instruction (RISC-V EBREAK instruction). There is no restriction in the number of software
breakpoints used in a debug session. However, using a software breakpoint requires both read and write
access to the respective memory location.

On-chip Breakpoint Resources

If on-chip breakpoints are used, the resources to set the breakpoints are provided by the hardware of the
core itself.

For this purpose, a RISC-V core can have generic on-chip triggers that can either be used for on-chip
instruction breakpoints or on-chip data breakpoints. These generic triggers are called “address/data match
triggers”. The availability of such triggers is optional, and the number of triggers that are available depends
on the respective hardware of the core.

This means that on-chip instruction and on-chip data breakpoints share the number of available trigger
resources among each other.

One breakpoint can require one or multiple hardware resources, depending on the complexity of the
breakpoint.

Example: We have a core with five address/data match trigger resources, and each breakpoint requires
exactly one hardware resource. We can either set five on-chip instruction breakpoints, or we could set three
instruction breakpoints and two data breakpoints.

On-chip Breakpoints for Instruction Address

On-chip breakpoints for instruction addresses are used to stop the core when an instruction at a certain
address is executed.

The resources to set instruction breakpoints are provided by the hardware of the core. For details about the
implementation and number of these breakpoints, see chapter On-chip Breakpoint Resources.

On-chip instruction breakpoints are particularly useful in scenarios where the program code lies in read-only
memory regions such as ROM or flash, as software breakpoints cannot be used in such scenarios.
Furthermore breakpoints for instruction address ranges can only be realized with on-chip breakpoints.

On-chip Breakpoints for Data Address

On-chip breakpoints for data addresses are used to stop the core after a read or write access to a memory
address.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 39

 The resources to set data address breakpoints are provided by the core. For details about the
implementation and number of these breakpoints, see chapter On-chip Breakpoint Resources.

On-chip data address breakpoints with address range

Some RISC-V on-chip data address breakpoint triggers allow to set triggers for address ranges. Address
ranges for on-chip breakpoint of RISC-V can be implemented in two different ways:

• Address range via address mask:

An address range can be expressed with an address mask, if the range matches the following
criteria:

Let the address range be from address A to address B (B inside range), with A < B.
Let X = A XOR B (infix operator XOR: “exclusive or”).
Let Y = A AND X (infix operator AND: “logical and”).
Then all bits in X that equal to one have to be in consecutive order, starting from the least
significant bit.
Then Y has to equal zero.

• Address range via two addresses:

An address range can be expressed with a start address and an end address.

An address range via address mask requires less hardware resources than an address range via two
addresses. If the criteria for the address mask are met then the debugger will always automatically
choose the mask method, in order to save hardware resources.

Examples:

[Link] 0x0000--0x0FFF /Read ; Address range suitable for

; address mask

[Link] 0x0100--0x01FF /Read ; Address range suitable for

; address mask

[Link] 0x3040--0x307F /Write ; Address range suitable for

; address mask

[Link] 0xA000--0xB0FF /Write ; Address range suitable for

; two addresses

[Link] 0xA000--0xA0FD /Write ; Address range suitable for

; two addresses

On-chip Data Value Breakpoints

The hardware resources of the core can be used to stop the core when a specific value is read or written:

• Data Value Breakpoint (Read):

Stop the core when a specific data value is read from a memory address.

• Data Value Breakpoint (Write):

Stop the core when a specific data value is written to a memory address.

For more information about data value breakpoints, see the [Link] command.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 40

Examples for Standard Breakpoints

Assume you have a target with

• FLASH from 0x0--0xffff

• RAM from 0x10000--0x3FFF

The command [Link] can be used to inform the debugger for which memory regions breakpoints
should only be implemented as on-chip breakpoints. That is why we mark the FLASH region as follows:

[Link] 0x0--0xffff

The following shows examples for setting standard software breakpoints:

[Link] P:0x20100 /Program ; Software breakpoint on

; instruction address

[Link] main /Program ; Software breakpoint on symbol

The following shows examples for setting standard on-chip breakpoints:

[Link] P:0x40 /Program ; On-chip breakpoint on

; instruction address.
; Use on-chip breakpoint because
; address inside [Link] range.

[Link] P:0x20200 /Program ; On-chip breakpoint on

/Onchip ; instruction address.
; Use on-chip breakpoint because
; of explicit ‘/Onchip’ option.

[Link] P:0x40--0x48 /Program ; On-chip breakpoint on

; instruction address range

[Link] D:0x1010 /Read ; On-chip read breakpoint on

; data address

[Link] D:0x1020 /Write ; On-chip write breakpoint on

; data address

[Link] D:0x1030 /ReadWrite ; On-chip read and write breakpoint

; on data address

[Link] D:0x1010--0x101F /Read ; On-chip read breakpoint on

; data address range

[Link] D:0x10 /Read ; On-chip read breakpoint on

/[Link] 0x123 ; data address, combined with
; condition for read data value

©1989-2025 Lauterbach RISC-V Debugger and Trace | 41

Floating-Point Extensions

The TRACE debugger for RISC-V supports the floating-point extensions of the RISC-V ISA, including both
the single-precision (“F” extension) and double-precision (“D” extension) floating-point extensions.

These extensions adhere to the IEEE 754-2008 arithmetic standard. Notably, any core that supports the
double-precision extension inherently supports the single-precision extension. According to the RISC-V ISA
specification, a 32-bit single-precision value is stored in a 64-bit double-precision floating-point register by
filling the upper 32 bits with all 1s (a process known as NaN boxing, short for "Not a Number" boxing).

The floating-point features are managed through the FPU (Floating-Point Unit) command group. When
modifying floating-point values using the [Link] command, users can specify the desired precision for
writing values.

Examples:

[Link] [Link] 1.4 ; Write to register with

; automatic detection of precision
[Link] [Link] 2.7 ; Write to register with single-precision
[Link] [Link] 3.2 ; Write to register with double-precision

[Link] [Link] 0xABCD ; Write to register with single-precision

; in hexadecimal notation
[Link] [Link] 12. ; Write to register with double-precision
; in decimal notation

The [Link] window automatically displays register values using the following conventions:

• Single-precision representation for values stored with NaN boxing.

• Double-precision representation for values stored without NaN boxing.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 42

 Example:

The following shows 64-bit floating-point registers displaying identical values in both single-precision and
double-precision representations.

A Single-precision representation

B Double-precision representation

©1989-2025 Lauterbach RISC-V Debugger and Trace | 43

Hardware Performance Monitor

The RISC-V ISA defines a so-called “Hardware Performance Monitor”, which consists of several hardware
counters (mcycle, minstret, mhpmcounter, ...). The existence of such a monitor and its counters is optional,
so it may not be available in all RISC-V devices.

The Lauterbach BMC (BenchMark Counter) command group does provide control and usage of these
hardware performance counters, if available on the chip:

For information about architecture-independent BMC commands, refer to “BMC” (general_ref_b.pdf).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 44

Hart State: Unavailable

The RISC-V Debug Module can flag a RISC-V hart as “unavailable”, by setting the respective
allunavail/anyunavail status bits of the dmstatus debug register.

The RISC-V debug specification says: “Harts may be unavailable for a variety of reasons including being
reset, temporarily powered down, and not being plugged into the hardware platform.”

If the debugger detects that a hart is currently flagged as unavailable, then it will display “unavailable” in the
bottom-right corner of the TRACE32 state line :

As long as the hart is in this state, it is not possible to manually halt the hart via the [Link] command.

NOTE: In order to poll the state of a hart, the debugger needs to have full access to all
debug registers of the RISC-V debug module. This means that even when a
RISC-V hart is for example in reset or power-down, then the debug IP such as
RISC-V Debug Module, Debug Module Interface (DMI), etc should still be active
and available to the [Link] however the debug IP, including the JTAG
connector, gets powered down as well (which is not recommended), then
please refer to [Link].

©1989-2025 Lauterbach RISC-V Debugger and Trace | 45

Semihosting

Semihosting is a technique for application programs running on a RISC-V processor to communicate with
the host computer of the debugger. This way the application can use the I/O facilities of the host computer
like keyboard input, screen output, and file I/O. This is especially useful if the target platform does not yet
provide these I/O facilities or in order to output additional debug information in printf() style.

RISC-V semihosting is based on the "Semihosting for AArch32 and AArch64: Release 2.0" specification
available here: [Link]

A RISC-V semihosting call is invoked by the following semihosting trap instruction sequence:

slli x0, x0, 0x1f # 0x01f01013 Entry NOP

ebreak # 0x00100073 Break to debugger
srai x0, x0, 7 # 0x40705013 NOP encoding the semihosting call #7

Semihosting register definitions:

• Operation number register: a0

• Parameter register: a1

• Return register: a0

• Data block field size: 32bits for RV32, 64bits for RV64

There is no need to set any additional breakpoints since the ebreak instruction itself will stop the core. The
debugger will restart the core after the semihosting data is processed.

Semihosting for RISC-V is enabled by [Link] RISCVSWI and by opening a [Link] window
for the semihosting screen output. The handling of the semihosting requests is only active when the
[Link] window does exist.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 46

Vector Extension

The Lauterbach debugger for RISC-V provides support for the vector register extension (“V” extension) of
the RISC-V ISA.

The vector features are provided by the VPU (Vector Processing Unit) command group. This command
group is only unlocked if the RISC-V target does support the vector extension.

The [Link] window does display the vector registers. The vector register width VLEN is automatically
detected by the debugger, and the width of the vector registers in the [Link] window is adjusted
accordingly.

As RISC-V vector registers (v0 - v31) can be quite large, the debugger displays them in sub-elements
(E0 - En), with a width of 32bits for each sub-element.

When modifying values with [Link], the user can write to each sub-element (E0 - En) of a vector register
individually.

Example:

[Link] V8_E2 0x12345678 ; Write to vector register v8, sub-element #2

©1989-2025 Lauterbach RISC-V Debugger and Trace | 47

RISC-V Tracing

RISC-V Trace Standards

RISC-V Trace Specifications

The Lauterbach RISC-V trace tools are mainly based on the official RISC-V trace standards. There are two
RISC-V trace standards:

• RISC-V N-Trace (Nexus-based Trace) Standard

• RISC-V E-Trace (Efficient Trace) Standard

Each of these two overall trace standards are composed of several sub-specifications, and each sub-
specification is a separate document. Some of these sub-specifications are exclusive to either N-Trace or E-
Trace, whereas some other sub-specifications are applicable to and shared among both N-Trace and E-
Trace.

The RISC-V N-Trace Standard is composed of the following sub-specifications:

• RISC-V N-Trace (Nexus-based Trace) Specification

• RISC-V Trace Control Interface Specification

• RISC-V Trace Connectors Specification

The RISC-V E-Trace Standard is composed of the following sub-specifications:

• RISC-V E-Trace (Efficient Trace) Specification

(Older versions of this specification (up to v1.0) were called “RISC-V Processor Trace
Specification”, but starting with v2.0.0 it was renamed to make it distinguishable from N-Trace)

• RISC-V Unformatted Trace & Diagnostic Data Packet Encapsulation Specification

• RISC-V Trace Control Interface Specification

• RISC-V Trace Connectors Specification

The following is a summary of the respective sub-specifications:

RISC-V RISC-V RISC-V RISC-V RISC-V
N-Trace E-Trace Unformatted Trace Control Trace
Specification Specification Trace Packet Interface Connectors
Encapsulation Specification Specification
Specification
RISC-V
N-Trace
RISC-V
E-Trace

©1989-2025 Lauterbach RISC-V Debugger and Trace | 48

RISC-V Trace IP Blocks

The RISC-V trace standards define the following RISC-V trace IP blocks:

• RISC-V N-Trace Trace Encoder (see [Link])

• RISC-V E-Trace Trace Encoder (see [Link])

• RISC-V Trace Funnel (see [Link])

• RISC-V SRAM On-Chip Trace Sink (see [Link])

• RISC-V System Memory On-chip Trace Sink (see [Link])

• RISC-V Pin Interface Block (PIB) Off-chip Trace Sink (see [Link])

• RISC-V ATB Bridge (see [Link])

The N-Trace Trace Encoder is only applicable to the N-Trace Standard.

The E-Trace Trace Encoder is only applicable to the E-Trace Standard.

All other RISC-V trace IP blocks that are mentioned in the list above are applicable to both, the N-Trace
Standard and the E-Trace Standard.

The following illustration shows two example setups to demonstrate which IP blocks are specific to and
which IP blocks are shared among the two RISC-V trace standards:
RISC-V N-Trace Standard RISC-V E-Trace Standard
Chip Chip
RISC-V RISC-V RISC-V RISC-V
hart #0 hart #1 hart #0 hart #1

N-Trace Standard N-Trace Standard Trace Encoder E-Trace Standard E-Trace Standard
Trace Encoder Trace Encoder is specific to the Trace Encoder Trace Encoder
("NEXUS") ("NEXUS") trace protocol ("ETRACE") ("ETRACE")
(N-Trace / E-Trace)

Standard RISC-V Standard RISC-V

Trace Funnel Trace Funnel
("RVFUNNEL") ("RVFUNNEL")

Other RISC-V
Standard RISC-V trace infrastructure Standard RISC-V
Pin Interface Block (PIB) (funnels, sinks, Pin Interface Block (PIB)
("RVPIB") connectors...) ("RVPIB")
is identical and can
Trace Connector Trace Connector
be shared among
Mictor38 or MIPI20 Mictor38 or MIPI20
N-Trace / E-Trace
(Standard RISC-V (Standard RISC-V
Trace Pinout) Trace Pinout)

Each of these RISC-V trace IP blocks does have its own separate trace control interface block. Each trace
control interface block is a set of 32-bit registers occupying an address space of up to 4KB. The base
address of each trace control interface block must be aligned on the 4KB boundary.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 49

N-Trace

E-Trace

©1989-2025 Lauterbach RISC-V Debugger and Trace | 50

Quick Start for Trace Configuration Basics

The configuration of trace requires several steps, which vary and depend on the trace hardware of your chip.
This chapter gives a brief overview over the most common trace configuration steps:

1. Configuration of the debug IP.

Before the configuration of the trace IP, it is necessary to configure the debug IP first. See for
example chapter “Quick Start of the JTAG Debugger” for details.

2. Define trace source(s).

[Link].<sub_cmd>
or
[Link].<sub_cmd>

These two command groups can be used to define and configure the existence of an N-Trace and/or
E-Trace trace encoder in the system, and its location in the system.

Each RISC-V hart that can be traced does have its own trace encoder.

3. Define trace funnel(s).

[Link].<sub_cmd>

If the trace system does have one or more RISC-V trace funnels, then the above command group
defines and configures the existence of a RISC-V trace funnel, and its location in the system.

If the system does have more than one trace encoder / more than one trace source (i.e. if it is a
multicore trace system), then it most probably does have a trace funnel.

4. Define trace sink(s).

[Link].<sub_cmd>
or
[Link].<sub_cmd>
or
[Link].<sub_cmd>

The above command groups define and configure the existence of one or more trace sink(s), and
their respective location in the system.
The RISC-V on-chip trace sink categories are SRAM and SMEM trace sink. The RISC-V off-chip
trace sink is PIB.

Each trace system must have at least one trace sink.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 51

 5. Define off-chip trace port.

[Link].<sub_cmd>

If the system has an off-chip trace sink, then the above command defines the type of the trace
port and the off-chip trace sink on the chip that is connected to it.

This command is only applicable to some off-chip trace sinks, but it is never applicable to on-chip
trace sinks.

6. Define trace method.

[Link] <method>

The above command selects the trace method that you want to use. This is particularly
important, if your system has more than one (type of) trace sink.

7. Configure trace source(s).

NEXUS.<sub_cmd>
or
RVETRACE.<sub_cmd>

The above command groups set the configuration settings of the control registers of the trace
source (e.g. N-Trace trace encoder or E-Trace trace encoder).

The command group can only be used, if the respective trace source has previously been
defined (see steps above).

8. Configure trace sink(s).

RVPIB.<sub_cmd>

The above command group sets the configuration settings of the control registers of the trace
sink.

The command group can only be used, if the respective trace sink has previously been defined
(see steps above).

9. Initialize trace sink(s).

[Link]

The above command initializes the trace sink and clears any previously recorded trace data.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 52

Quick Start for Trace Configuration Examples

This chapter shows configuration examples for certain RISC-V trace setups:

• Example A: Single-core N-Trace to On-chip Trace Sink

• Example B: Multi-core N-Trace to Off-chip Trace Sink

Example A: Single-core N-Trace to On-chip Trace Sink

Chip
Debug
Module DMI:0x0 RISC-V
RISC-V
TDI Interface Debug Module
("COREDEBUG") hart #0
(DMI)
N-Trace Standard
RISC-V JTAG-DTM DMI:0x1000
Trace Encoder
IR: 5 bits
("NEXUS")
(DMI Access Port,
"RVDMIAP")
Standard RISC-V
DMI:0x2000
SRAM on-chip trace sink
TDO ("RVSRAMTRACE")

Debugger configuration example

;----------- Debug configuration ---------------- --------------------

[Link] <cpu>

[Link] DebugPort ; JTAG-DTM / RVDMIAP

[Link] 5.
[Link] 0.
[Link] 0.
[Link] 0.
[Link] 0.

[Link] DMI:0x0 ; Debug Module

;----------- Trace configuration ---------------- --------------------

[Link] DMI:0x1000 ; N-Trace Encoder

[Link] NTRACE

[Link] DMI:0x2000 ; RISC-V SRAM

[Link] NEXUS ; on-chip trace sink

[Link] Onchip

[Link]

©1989-2025 Lauterbach RISC-V Debugger and Trace | 53

Example B: Multi-core N-Trace to Off-chip Trace Sink
Chip
RISC-V
DMI:0x0 RISC-V
Debug Debug Module hart #0
RISC-V
Module ("COREDEBUG")
TDI hart #1
Interface
(DMI) System Bus
Access Master
N-Trace Standard
RISC-V JTAG-DTM
SB:0x1000 Trace Encoder
IR: 5 bits
("NEXUS")
N-Trace Standard
(DMI Access Port,
"RVDMIAP") SB:0x2000 Trace Encoder
("NEXUS")

TDO Standard RISC-V

SB:0x3000 Trace Funnel
("RVFUNNEL")

Standard RISC-V
SB:0x4000 Pin Interface Block (PIB)
("RVPIB")

Trace Connector
Mictor38 or MIPI20
(Standard RISC-V
Trace Pinout)

Debugger configuration example (for SMP debugging):

;----------- Debug configuration ---------------- --------------------

[Link] <cpu>
[Link] 1. 1.
[Link] 2.
[Link] 0. 1.
[Link] 1. 2.

[Link] DebugPort ; JTAG-DTM / RVDMIAP

[Link] 5.
[Link] 0.
[Link] 0.
[Link] 0.
[Link] 0.

[Link] DMI:0x0 DMI:0x0 ; Debug Module

;----------- Trace configuration ---------------- --------------------

[Link] SB:0x1000 SB:0x2000 ; N-Trace Encoders

[Link] NTRACE

©1989-2025 Lauterbach RISC-V Debugger and Trace | 54

 [Link] SB:0x3000 ; RISC-V Funnel
[Link] 3. ; 3 Funnel inputs
[Link] ; Input source
NEXUS.0 0 NEXUS.1 1 ; assignment

[Link] SB:0x4000 ; RISC-V PIB sink

[Link] RVFUNNEL1 ; on-chip trace sink

[Link] PTI ; Parallel trace

[Link] RVPIB ; interface

[Link] ANALYZER

[Link]
[Link] ON

[Link] 8.
[Link] 1.

N-Trace

Trace Message Types

Trace Trigger and Filter

E-Trace

Trace Message Types

Trace Trigger and Filter

©1989-2025 Lauterbach RISC-V Debugger and Trace | 55

Command Reference: SYStem Commands

[Link] Display target configuration

Format: [Link] [/<tab>]

<tab>: DebugPort | Jtag | AccessPorts | COmponents

Opens the [Link] window, where you can view and modify most of the target
configuration settings. The configuration settings tell the debugger how to communicate with the chip on
the target board and how to access the on-chip debug and trace facilities in order to accomplish the
debugger’s operations.

Alternatively, you can modify the target configuration settings via the TRACE32 command line with the
[Link] commands. Note that the command line provides additional [Link]
commands for settings that are not included in the [Link] window.

<tab> Opens the [Link] window on the specified tab. For tab
descriptions, see below.

DebugPort The DebugPort tab informs the debugger about the debug connector type
(default) and the communication protocol it shall use.

For descriptions of the commands on the DebugPort tab, see DebugPort.

Jtag The Jtag tab informs the debugger about the position of the Test Access
Ports (TAP) in the JTAG chain which the debugger needs to talk to in order
to access the debug and trace facilities on the chip.

For descriptions of the commands on the Jtag tab, see Jtag.

AccessPorts This tab informs the debugger about an Arm CoreSight Access Port (AP)
and about how to control the AP to access chip-internal memory busses
(AHB, APB, AXI) or chip-internal JTAG interfaces.

For a descriptions of a corresponding commands, refer to AP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 56

 COmponents The COmponents tab informs the debugger (a) about the existence and
interconnection of on-chip debug and trace modules and (b) informs the
debugger on which memory bus and at which base address the debugger
can find the control registers of the modules.

For descriptions of the commands on the COmponents tab, see

COmponents.

[Link] Configure debugger according to target topology

Format: [Link] <parameter>

<parameter>: CJTAGFLAGS <flags>

(DebugPort) CJTAGTCA <value>
CONNECTOR [MIPI34 | MIPI20T]
CORE <core> <chip>
CoreNumber <number>
DEBUGPORT [DebugCable0]
DEBUGPORTTYPE [JTAG | CJTAG | SWD]
Slave [ON | OFF]
SWDP [ON | OFF]
SWDPIdleHigh [ON | OFF]
SWDPTargetSel <value>
TriState [ON | OFF]

<parameter>: DAPDRPOST <bits>

(JTAG) DAPDRPRE <bits>
DAPIRPOST <bits>
DAPIRPRE <bits>
DRPOST <bits>
DRPRE <bits>
IRPOST <bits>
IRPRE <bits>
IRWIDTH <bits>
Slave [ON | OFF]
TAPState <state>
TCKLevel <level>
TriState [ON | OFF]

<parameter>: [Link] [<value> | <name>]

(AccessPorts [Link]
Arm [Link]
CoreSight) [Link] <name>

©1989-2025 Lauterbach RISC-V Debugger and Trace | 57

 <parameter>: [Link] [<value> | <name>]
(AccessPorts [Link]
Arm CoreSight [Link]
cont.) [Link] <name>

[Link] [ON | OFF]

[Link] <value>
[Link] [<value> | <name>]
[Link]
[Link]
[Link] <name>

[Link]
[Link]
[Link] <name>

<parameter>: [Link] <port>

(AccessPorts [Link] <port>
Arm [Link] <port>
CoreSight [Link] <port>
SoC-400) [Link] <port>

<parameter>: [Link] <address>

(AccessPorts [Link] <address>
Arm [Link] <address>
CoreSight [Link] <address>
SoC-600)

<parameter>: [Link] <source>

(AccessPorts [Link] <value>
RISC-V) [Link] <value>
RVDMIAPn.IRCODE_DMI <value>
RVDMIAPn.IRCODE_DTMCS <value>
RVDMIAPn.IRCODE_IDCODE <value>
[Link] <value>
[Link] <value>
[Link] <value>

<parameter>: [Link] <address>

(COmponents) [Link]
[Link]

[Link] <address>

<parameter>: COREJPAM <name>

(Tessent
Embedded
Analytics)

©1989-2025 Lauterbach RISC-V Debugger and Trace | 58

 The [Link] commands inform the debugger about the available on-chip debug and trace
components and how to access them.

The [Link] command information shall be provided after the [Link] command, which
might be a precondition to enter certain [Link] commands, and before you start up the debug
session, e.g. by [Link].

Syntax Remarks

The commands are not case sensitive. Capital letters show how the command can be shortened.
Example: “[Link] ON” -> “[Link] ON”

The dots after “[Link]” can alternatively be a blank.

Example:
“[Link] ON” or “[Link] TriState ON”

©1989-2025 Lauterbach RISC-V Debugger and Trace | 59

<parameters> Describing the “DebugPort”

CJTAGFLAGS Activates workarounds for incomplete or buggy cJTAG (IEEE 1149.7)

<flags> implementations.
Bit 0 (“NOTCA”): Disable scanning of cJTAG ID (TCA-scanning).
Bit 1 (“NOKEEPER”): Target has no “keeper”. Use TRACE32 pseudo
keeper.
Bit 2 (“INVSREDGE”): Inverted meaning of SREDGE register.
Bit 3 (“OLDOPCODES”): Old command opcodes (cJTAG < 1.14).
Bit 4 (“APFCUNLCK”): APFC unlock required.
Bit 5 (“USEOAC”): OAC required

Default: 0

CJTAGTCA <value> Selects the TCA (TAP Controller Address) to address a device in a
cJTAG (IEEE 1149.7) Star-2 configuration. The Star-2 configuration
requires a unique TCA for each device on the debug port.

CONNECTOR Specifies the connector “MIPI34” or “MIPI20T” on the target. This is

[MIPI34 | MIPI20T] mainly needed in order to notify the trace pin location.

Default: MIPI34 if CombiProbe is used, MIPI20T if µTrace (MicroTrace) is

used.

CORE <core> The command helps to identify debug and trace resources which are
<chip> commonly used by different cores. The command might be required in a
multicore environment if you use multiple debugger instances (multiple
TRACE32 PowerView GUIs) to simultaneously debug different cores on
the same target system.

Because of the default setting of this command

debugger#1: <core>=1 <chip>=1

debugger#2: <core>=1 <chip>=2
...

each debugger instance assumes that all notified debug and trace
resources can exclusively be used.

But some target systems have shared resources for different cores, for
example a common trace port. The default setting causes that each
debugger instance controls the same trace port. Sometimes it does not
hurt if such a module is controlled twice. But sometimes it is a must to tell
the debugger that these cores share resources on the same <chip>.
Whereby the “chip” does not need to be identical with the device on your
target board:

debugger#1: <core>=1 <chip>=1

debugger#2: <core>=2 <chip>=1

©1989-2025 Lauterbach RISC-V Debugger and Trace | 60

 CORE <core> For cores on the same <chip>, the debugger assumes that the cores
<chip> share the same resource if the control registers of the resource have the
same address.
(cont.)
Default:
<core> depends on CPU selection, usually 1.
<chip> derives from the CORE= parameter in the configuration file
(config.t32), usually 1. If you start multiple debugger instances with the
help of [Link], you will get ascending values (1, 2, 3,...).

CoreNumber Number of cores to be considered in an SMP (symmetric

<number> multiprocessing) debug session. There are RISC-V core types which can
be used as a single core processor or as a scalable multicore processor
of the same type. If you intend to debug more than one such core in an
SMP debug session you need to specify the number of cores you intend
to debug.

Default: 1.

DEBUGPORT It specifies which probe cable shall be used e.g. “DebugCable0”. At the
[DebugCable0] moment only the CombiProbe allows to connect more than one probe
cable.

Default: depends on detection.

DEBUGPORTTYPE It specifies the used debug port type “JTAG”, “CJTAG” or “SWD”. It
[JTAG | CJTAG | assumes the selected type is supported by the target.
SWD]
Default: JTAG.

Slave [ON | OFF] If several TRACE32 debugger GUIs share the same debug port (AMP
debugging), all GUIs except one must have this option set to ON.

JTAG: Only one debugger GUI - the “master GUI” - is allowed to control
the signals nTRST and nSRST (nRESET), and perform a test-logic-reset
or system reset. Only this master GUI must have Slave OFF.

All other debugger GUIs are considered “slave GUIs” and need to have
the setting Slave ON.

Default: OFF.
Default: ON if CORE=... >1 in the configuration file (e.g. config.t32).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 61

 SWDPIdleHigh Keep SWDIO line high when idle. Only for Serialwire Debug mode.
[ON | OFF] Usually the debugger will pull the SWDIO data line low, when no
operation is in progress, so while the clock on the SWCLK line is
stopped (kept low).

You can configure the debugger to pull the SWDIO data line
high, when no operation is in progress by using
[Link] SWDPIdleHigh ON

Default: OFF.

SWDPTargetSel Device address in case of a multidrop serial wire debug port.

<value>
Default: none set (any address accepted).

TriState [ON | OFF] TriState has to be used if several debug cables are connected to a common
JTAG port. TAPState and TCKLevel define the TAP state and TCK level
which is selected when the debugger switches to tristate mode.
Please note:
• nTRST must have a pull-up resistor on the target.
• TCK can have a pull-up or pull-down resistor.
• Other trigger inputs need to be kept in inactive state.

Default: OFF.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 62

<parameters> Describing the “JTAG” Scan Chain and Signal Behavior

With the JTAG interface you can access a Test Access Port controller (TAP) which has implemented a state
machine to provide a mechanism to read and write data to an Instruction Register (IR) and a Data Register
(DR) in the TAP. The JTAG interface will be controlled by 5 signals:

• nTRST (reset)

• TCK (clock)

• TMS (state machine control)

• TDI (data input)

• TDO (data output)

Multiple TAPs can be controlled by one JTAG interface by daisy-chaining the TAPs (serial connection). If you
want to talk to one TAP in the chain, you need to send a BYPASS pattern (all ones) to all other TAPs. For this
case the debugger needs to know the position of the TAP it wants to talk to.

The width of the JTAG instruction register of the TAP of a RISC-V JTAG Debug Transport Module
(JTAG-DTM) can be defined with IRWIDTH.

The TAP position of a RISC-V JTAG Debug Transport Module (JTAG-DTM) can be defined with the
commands IRPRE, IRPOST, DRPRE, and DRPOST.

The TAP position of an Arm CoreSight Debug Access Port (Arm DAP) can be defined with the
commands DAPIRPRE, DAPIRPOST, DAPDRPRE, and DAPDRPOST.

DRPOST <bits> Defines the TAP position of the RISC-V JTAG-DTM in a JTAG scan chain.
Number of TAPs in the JTAG chain between the TDI signal and the TAP
you are describing. In BYPASS mode, each TAP contributes one data
register bit. See example below.
This command only applies to the implicit JTAG-DTM configuration. For
the explicit JTAG-DTM configuration, refer to
[Link] instead.

Default: 0.

DRPRE <bits> Defines the TAP position of the RISC-V JTAG-DTM in a JTAG scan chain.
Number of TAPs in the JTAG chain between the TAP you are describing
and the TDO signal. In BYPASS mode, each TAP contributes one data
register bit. See example below.
This command only applies to the implicit JTAG-DTM configuration. For
the explicit JTAG-DTM configuration, refer to
[Link] instead.

Default: 0.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 63

 IRPOST <bits> Defines the TAP position of the RISC-V JTAG-DTM in a JTAG scan chain.
Number of Instruction Register (IR) bits of all TAPs in the JTAG chain
between TDI signal and the TAP you are describing. See example below.
This command only applies to the implicit JTAG-DTM configuration. For
the explicit JTAG-DTM configuration, refer to
[Link] instead.

Default: 0.

IRPRE <bits> Defines the TAP position of the RISC-V JTAG-DTM in a JTAG scan chain.
Number of Instruction Register (IR) bits of all TAPs in the JTAG chain
between the TAP you are describing and the TDO signal. See example
below.
This command only applies to the implicit JTAG-DTM configuration. For
the explicit JTAG-DTM configuration, refer to
[Link] instead.

Default: 0.

IRWIDTH <bits> Defines the JTAG Instruction Register (IR) width of the JTAG TAP of the
RISC-V JTAG-DTM. See example below.
This command only applies to the implicit JTAG-DTM configuration. For
the explicit JTAG-DTM configuration, refer to
[Link] instead.

Default: 5.

NOTE: If you are not sure about your settings concerning IRPRE, IRPOST, DRPRE,
and DRPOST, you can try to detect the settings automatically with the
[Link] or [Link] command.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 64

 Example:

TAP 0 TAP 1 TAP 2 TAP 3

TDI RISC-V JTAG-DTM TDO
IR: 7 bits IR: 5 bits IR: 4 bits IR: 6 bits

This example shows four TAPs in a JTAG daisy chain. The relevant TAP for RISC-V debugging is the
JTAG Debug Transport Module (JTAG-DTM) TAP. In order to address this TAP, the following settings are
necessary:

[Link] IRWIDTH 5.
[Link] IRPRE 10.
[Link] IRPOST 7.
[Link] DRPRE 2.
[Link] DRPOST 1.

If your system contains an Arm CoreSight Debug Access Port (DAP) and the DAP is accessible via JTAG,
then the DAP’s JTAG Test Access Port controller (TAP) may be inside a JTAG daisy-chain together with
other TAPs. To tell the debugger the exact position of the DAP’s TAP within the JTAG daisy-chain, you will
require the commands DAPIRPRE, DAPIRPOST, DAPDRPRE, and DAPDRPOST. These settings are
especially important if the CoreSight DAP is not only used to access memory, but also to access the debug
registers of the RISC-V Debug Module.

DAPDRPOST <bits> (default: 0) <number> of TAPs in the JTAG chain between the
DAP and the TDO signal of the debugger.

DAPDRPRE <bits> (default: 0) <number> of TAPs in the JTAG chain between the
TDI signal of the debugger and the DAP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 65

 DAPIRPOST <bits> (default: 0) <number> of instruction register bits in the JTAG
chain between the DAP and the TDO signal of the debugger.
This is the sum of the instruction register length of all TAPs
between the DAP and the TDO signal of the debugger.

DAPIRPRE <bits> (default: 0) <number> of instruction register bits in the JTAG

chain between the TDI signal and the DAP. This is the sum of the
instruction register lengths of all TAPs between the TDI signal of
the debugger and the DAP.

Slave [ON | OFF] If several debuggers share the same debug port, all except one must
have this option active.

JTAG: Only one debugger - the “master” - is allowed to control the signals
nTRST and nSRST (nRESET). The other debuggers need to have the
setting Slave OFF.

Default: OFF.
Default: ON if CORE=... >1 in the configuration file (e.g. config.t32).

TAPState <state> This is the state of the TAP controller when the debugger switches to
tristate mode. All states of the JTAG TAP controller are selectable.

During an AMP debug session, this parameter must be set to the same
value in all TRACE32 instances.

0 Exit2-DR
1 Exit1-DR
2 Shift-DR
3 Pause-DR
4 Select-IR-Scan
5 Update-DR
6 Capture-DR
7 Select-DR-Scan
8 Exit2-IR
9 Exit1-IR
10 Shift-IR
11 Pause-IR
12 Run-Test/Idle
13 Update-IR
14 Capture-IR
15 Test-Logic-Reset

Default: 7 = Select-DR-Scan.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 66

 TCKLevel <level> Level of TCK signal when all debuggers are tristated. Normally defined
by a pull-up or pull-down resistor on the target.

Default: 0.

TriState [ON | OFF] TriState has to be used if several debug cables are connected to a common
JTAG port. TAPState and TCKLevel define the TAP state and TCK level
which is selected when the debugger switches to tristate mode.
Please note:
• nTRST must have a pull-up resistor on the target.
• TCK can have a pull-up or pull-down resistor.
• Other trigger inputs need to be kept in inactive state.

Default: OFF.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 67

<parameters> Configuring an Arm CoreSight Debug Access Port “CoreSight AP”

An Arm CoreSight Access Port (AP) is a CoreSight module from Arm which provides access via its debug
link (JTAG, cJTAG, SWD, USB, UDP/TCP-IP, GTL, PCIe...) to:

1. Memory busses (AHB, APB, AXI). This is especially important if the on-chip debug register
needs to be accessed this way. You can access the memory buses by using certain access
classes with the debugger commands: “AHB:”, “APB:”, “AXI:. The interface to these buses is
called Memory Access Port (MEM-AP).
The debug registers of some cores are accessible via such a memory bus (mostly APB).

2. A transactor name for virtual connections to AMBA bus level transactors can be configured by
the property [Link].*[Link] <name>. A JTAG or SWD transactor must be
configured for virtual connections to use the property “Port” or “Base” (with “DP:” access) in case
XtorName remains empty.

Example 1: Arm SoC-400

SoC-400

ROM table

Memory
Access Port
(MEM-AP) CoreSight
Component

Debug Memory ROM table

Port Access Port
(DP) (MEM-AP)
CoreSight
Component
JTAG
Access Port
(JTAG-AP)

DAP

©1989-2025 Lauterbach RISC-V Debugger and Trace | 68

 Example 2: Arm SoC-600

SoC-600

Debug
MEM-AP ROM table
link(s)

32/64-bit
CoreSight
Component
MEM-AP ROM table
Memory System 2
DP (32/64-bit)

CoreSight
CoreSight Component

32/64-bit
MEM-AP
Component

Memory System 1
ROM table

ROM table (expected)

CoreSight
Component

CoreSight Memory System 3

(possible)
Component

[Link] [<value> | Default: 0.

<name>] Selects the value used for the HPROT bits in the Control Status
[Link]- Word (CSW) of a CoreSight AHB Access Port, when using the AHB:
PROT [<value> | <name>] memory class.
(deprecated)

©1989-2025 Lauterbach RISC-V Debugger and Trace | 69

 [Link] [<value> | Default: 0.
<name>] This option selects the value used for the HPROT bits in the Control
Status Word (CSW) of a CoreSight APB Access Port, when using
the APB: memory class.
The secure access bit HPROT[1] is not controlled by this option,
but via the access class prefixes “Z” and “N” as well as “L” and
“O” if the Access Port supports Realm Management Extension.

[Link] [<value> | Default: 0.

<name>] This option selects the value used for the HPROT bits in the Control
[Link] Status Word (CSW) of a CoreSight AXI Access Port, when using
[<value> | <name>] (depre- the AXI: memory class.
cated) The secure access bit HPROT[1] is not controlled by this option,
but via the access class prefixes “Z” and “N” as well as “L” and
“O” if the Access Port supports Realm Management Extension.

[Link] [ON | Default: OFF.

OFF] Enables ACE transactions on the AXI-AP, including barriers. This
[Link]- does only work if the debug logic of the target CPU implements
able [ON | OFF] (deprecated) coherent accesses. Otherwise this option will be without effect.

[Link] Default: DeviceSYStem (=0x30: Domain=0x3, Cache=0x0).

<value> This option configures the value used for the Cache and Domain
[Link]- bits in the Control Status Word (CSW[27:24]->Cache, CSW[14:13]-
CACHEFLAGS <value> >Domain) of an Access Port, when using the AXI: memory class.
(deprecated)

The below offered selection options are all non-bufferable. Alternatively you can enter a <value>, where
value[5:4] determines the Domain bits and value[3:0] the Cache bits.

<name> Description

DeviceSYStem =0x30: Domain=0x3, Cache=0x0

NonCacheableSYStem =0x32: Domain=0x3, Cache=0x2

ReadAllocateNonShareable =0x06: Domain=0x0, Cache=0x6

ReadAllocateInnerShareable =0x16: Domain=0x1, Cache=0x6

ReadAllocateOuterShareable =0x26: Domain=0x2, Cache=0x6

WriteAllocateNonShareable =0x0A: Domain=0x0, Cache=0xA

WriteAllocateInnerShareable =0x1A: Domain=0x1, Cache=0xA

©1989-2025 Lauterbach RISC-V Debugger and Trace | 70

 WriteAllocateOuterShareable =0x2A: Domain=0x2, Cache=0xA

ReadWriteAllocateNonShareable =0x0E: Domain=0x0, Cache=0xE

ReadWriteAllocateInnerShareable =0x1E: Domain=0x1, Cache=0xE

ReadWriteAllocateOuterShareable =0x2E: Domain=0x2, Cache=0xE

... .RESet Undo the configuration for this access port. This does not cause
a physical reset for the access port on the chip.

... .view Opens a window showing the current configuration of the access
port.

[Link] AHB bus transactor name that shall be used for “AHBn:” access
<name> class.

[Link] <name> APB bus transactor name that shall be used for “APBn:” access
class.

[Link] <name> AXI bus transactor name that shall be used for “AXIn:” access
class.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 71

 SoC-400 Specific Commands

In an Arm SoC-400 system, the following [Link] commands configure the port-number for the
memory busses:

[Link] <port> Access Port Number (0-255) of a SoC-400 system which shall be
AHBACCESSPORT <port> used for “AHBn:” access class.
(deprecated) Default: port not available.

[Link] <port> Access Port Number (0-255) of a SoC-400 system which shall be
APBACCESSPORT <port> used for “APBn:” access class.
(deprecated) Default: port not available.

[Link] <port> Access Port Number (0-255) of a SoC-400 system which shall be
AXIACCESSPORT <port> used for “AXIn:” access class.
(deprecated) Default: port not available.

[Link] <port> JTAG-AP port number (0-7) connected to the core which shall be
COREJTAGPORT <port> debugged.
(deprecated)

[Link] <port> Access port number (0-255) of a SoC-400 system of the JTAG
JTAGACCESSPORT <port> Access Port.
(deprecated)

©1989-2025 Lauterbach RISC-V Debugger and Trace | 72

 SoC-600 Specific Commands

[Link] <address> This command informs the debugger about the start address of
the register block of the “AHBAPn:” access port. And this way it
notifies the existence of the access port. An access port typically
provides a control register block which needs to be accessed by
the debugger to read/write from/to the bus connected to the
access port.

Example: [Link] DP:0x80002000

Meaning: The control register block of the AHB access ports
starts at address 0x80002000.

[Link] <address> This command informs the debugger about the start address of
the register block of the “APBAPn:” access port. And this way it
notifies the existence of the access port. An access port typically
provides a control register block which needs to be accessed by
the debugger to read/write from/to the bus connected to the
access port.

Example: [Link] DP:0x80003000

Meaning: The control register block of the APB access ports
starts at address 0x80003000.

[Link] <address> This command informs the debugger about the start address of
the register block of the “AXIAPn:” access port. And this way it
notifies the existence of the access port. An access port typically
provides a control register block which needs to be accessed by
the debugger to read/write from/to the bus connected to the
access port.

Example: [Link] DP:0x80004000

Meaning: The control register block of the AXI access ports
starts at address 0x80004000.

[Link] <address> This command informs the debugger about the start address of
the register block of the “JTAGAPn:” access port. And this way it
notifies the existence of the access port. An access port typically
provides a control register block which needs to be accessed by
the debugger to read/write from/to the bus connected to the
access port.

Example: [Link] DP:0x80005000

Meaning: The control register block of the JTAG access ports
starts at address 0x80005000.

It is possible to configure multiple Arm SoC-600 buses of one type (e.g. multiple APB buses). This is only
necessary if all these buses need to be accessed from within the same TRACE32 PowerView GUI (i.e. from
the same SMP session). To do so, each bus can be given its individual bus index.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 73

 If no explicit bus index is specified during configuration or use of an access class, then the debugger will
automatically imply and assume the index value 1.

Example:

[Link] DP:0x1000000 ; first APB AP: index 1

[Link] DP:0x2000000 ; second APB AP: index 2
[Link] DP:0x3000000 ; first AXI AP: index 1 (implied)

[Link] APB:0x80000000 ; use access class of first APB AP

[Link] APB2:0x90000000 ; use access class of second APB AP
[Link] AXI:0x30000000 ; use access class of first AXI AP

©1989-2025 Lauterbach RISC-V Debugger and Trace | 74

<parameters> Configuring a RISC-V Debug Access Port

RISC-V Debug Module Interface Access Port (RVDMIAP) Configuration

The RISC-V debug specification defines the RISC-V JTAG Debug Transport Module (JTAG-DTM), which
is a standardized RISC-V IP block that can access the debug registers of the RISC-V Debug Module (DM).
The debug bus that connects the JTAG-DTM to the DM is called the Debug Module Interface (DMI).

TDI Chip

RISC-V Debug Module

RISC-V RISC-V hart #0
JTAG-DTM Interface (DMI)

....
Debug Module
(DMI Access Port, (DM)
RISC-V hart #n
"RVDMIAP")

TDO

As the RISC-V JTAG-DTM provides access to the DMI bus, it can be considered a
RISC-V DMI Access Port (RVDMIAP).

The RVDMIAP is associated with the “DMI:” access class.

The command group [Link].* allows to configure such a DMI access port. The
configuration options are described in the table below. For more detailed example configurations, please
refer to the chapter about explicit JTAG-DTM configuration.

[Link].* configuration:

[Link] Defines the JTAG port that the JTAG TAP of the RVDMIAP /
<source> RISC-V JTAG-DTM is connected to.

<source> options:
None: no JTAG port configured
DebugPort: JTAG TAP is connected to the external debug port.
Default: None

[Link] <bits> Defines the TAP position of the RVDMIAP / RISC-V JTAG-DTM
in a JTAG scan chain.
DRPOST defines the number of TAPs in the JTAG chain between
the TDI signal and the TAP of the RVDMIAP. In BYPASS mode,
each TAP contributes one data register bit.
Default: undefined

©1989-2025 Lauterbach RISC-V Debugger and Trace | 75

 [Link] <bits> Defines the TAP position of the RVDMIAP / RISC-V JTAG-DTM
in a JTAG scan chain.
DRPRE defines the number of TAPs in the JTAG chain between
the TDO signal and the TAP of the RVDMIAP. In BYPASS mode,
each TAP contributes one data register bit.
Default: undefined

RVDMIAPn.IRCODE_DMI Defines the JTAG instruction register code (IRCODE) for the
<value> ‘dmi’ data register of the RVDMIAP / RISC-V JTAG-DTM.
Default: 0x11 (as defined by the RISC-V debug specification)

RVDMIAPn. Defines the JTAG instruction register code (IRCODE) for the
IRCODE_DTMCS <value> ‘dtmcs’ data register of the RVDMIAP / RISC-V JTAG-DTM.
Default: 0x10 (as defined by the RISC-V debug specification)

RVDMIAPn. Defines the JTAG instruction register code (IRCODE) for the
IRCODE_IDCODE <value> ‘idcode’ data register of the RVDMIAP / RISC-V JTAG-DTM.
Default: 0x1 (as defined by the RISC-V debug specification)

[Link] <bits> Defines the TAP position of the RVDMIAP / RISC-V JTAG-DTM
in a JTAG scan chain.
IRPOST defines the number of Instruction Register (IR) bits of all
TAPs in the JTAG chain between TDI signal and the TAP of the
RVDMIAP.
Default: undefined

[Link] <bits> Defines the TAP position of the RVDMIAP / RISC-V JTAG-DTM
in a JTAG scan chain.
IRPRE defines the number of Instruction Register (IR) bits of all
TAPs in the JTAG chain between the TAP of the RVDMIAP and
the TDO signal.
Default: undefined

[Link] <bits> Defines the JTAG Instruction Register (IR) width of the JTAG TAP
of the RVDMIAP / RISC-V JTAG-DTM.
Default: undefined

©1989-2025 Lauterbach RISC-V Debugger and Trace | 76

<parameters> Describing Debug and Trace “Components”

On the Components tab in the [Link] window, you can comfortably add the debug and
trace components your chip includes and which you intend to use with the debugger’s help.

Components and Available Commands

[Link] <address>
[Link]
[Link]

RISC-V Debug Module: bus type and base address of bus-mapped debug registers.

In some systems the debug registers of the RISC-V Debug Module (DM) are mapped on a debug bus
(without the use of a JTAG-DTM). In that case this command configures the bus type and the base address
of the DM register address space.

Example:

RISC-V DM debug registers mapped on APB bus with base address 0x80000000:

[Link] APB:0x80000000

For further examples, see “Debug Module Access via Arm CoreSight Debug Bus”, page 21.

… .Base <address> Configure the start address of the debug register block of the
RISC-V debug module.
Configuring this address also notifies the debugger that the
debug registers are directly accessible for the debugger via
memory (and not e.g. via a JTAG-DTM).

… .RESet Undo the configuration of the start address of the debug register
block of the RISC-V debug module.
This does not cause a physical reset for the component on the chip.

… .view Opens a window showing the current configuration of this

command.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 77

<parameters> Describing Tessent Embedded Analytics Details

Technical information regarding TRACE32 debugging through the Tessent Embedded Analytics Ecosystem
is currently confidential. If you require documentation on this topic, please contact Lauterbach Support.

… .COREJPAM <name> Configure a Tessent Embedded Analytics JTAG Processor

Analytic Module to access the RISC-V JTAG-DTM for debugging.
Use the name of an already configured JPAM.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 78

[Link] Set hart index

Format: [Link] <index>

[Link] <index> (deprecated)

<index>: 0. | 1. … n

Default: 0.

Configures the hardware thread index (hart index) that is used by the RISC-V Debug Module to interact with
a specific hart.

The command requires a hart index for each hart that is covered by [Link].

Example:

[Link] 5.
[Link] 3. 4. 5. 6. 7.

The Debug Module “hart index” should not be confused with other values such as the “hart ID” of the
mhartid CSR.

For further examples, see “Quick Start for Multicore Debugging”, page 23.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 79

[Link].<sub_cmd> Configure N-Trace trace encoder

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

Type <type>
Flags <flags>
RESet

The command [Link].<sub_cmd> configures a RISC-V N-Trace Trace Encoder, which

complies to the official RISC-V N-Trace Standard.

To configure the user settings for the RISC-V N-Trace Trace Encoder, see the NEXUS.<sub_cmd>
command group.

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V N-Trace Trace
Encoder.

Type <type> Configure the type of the N-Trace Trace Encoder. Possible values for
<type> are:

None: no type specified.

NTRACE: N-Trace Trace Encoder complies to the official RISC-V

N-Trace Standard, and does not have any vendor-specific modifications
or features.

SiFive: N-Trace Trace Encoder complies to the official RISC-V

N-Trace Standard, but does have SiFive-specific features.

Default: None

Flags <flags> This command allows to notify the Lauterbach N-Trace decoder, that this
N-Trace Trace Encoder does have (known) hardware issues. The <flags>
parameter represents a bit field and each bit represents one hardware
issue.

RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 80

[Link].<sub_cmd> Configure RISC-V ATB
bridge

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

RESet
TraceSource <source>

The command [Link].<sub_cmd> configures a RISC-V Trace ATB Bridge as

defined in the official RISC-V Trace Control Interface Specification.

The Advanced Trace Bus (ATB) is used to transport trace data within trace infrastructure such as e.g., Arm
CoreSight debug systems. A RISC-V Trace ATB Bridge is necessary in order to send trace data from a
RISC-V trace infrastructure (compliant to the RISC-V Trace Control Interface Specification) to an ATB bus.
Among others, the RISC-V Trace ATB Bridge adds an ATB ID/ATID that is used as its source identifier on the
ATB bus.

To configure the user settings for the RISC-V ATB Bridge, see the RVATBBRIDGE.<sub_cmd> command
group.

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V Trace ATB
Bridge.

RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

TraceSource Define the trace source that is connected to the RISC-V Trace ATB
<source> Bridge’s input port.

You need to configure [Link], before

you can use this command to configure the trace source.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 81

[Link].<sub_cmd> Configure RISC-V E-TRACE

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

RESet
Type <type>

The command [Link].<sub_cmd> configures a RISC-V E-Trace Trace Encoder,

which complies to the official RISC-V E-Trace Standard.

To configure the user settings for the RISC-V E-Trace Trace Encoder, see the RVETRACE.<sub_cmd>
command group.

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V E-Trace Trace
Encoder.

RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

Type <type> Configure the type of this components control interface. Possible values
for <type> are:

None: no type specified.

STANDARD: E-Trace Trace Encoder complies to the official RISC-V

Trace Control Interface Specification

Default: None

©1989-2025 Lauterbach RISC-V Debugger and Trace | 82

[Link].<sub_cmd> Configure RISC-V trace funnel

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

RESet
SourcePortNumber <number>
TraceSource <source>

The command [Link].<sub_cmd> configures a RISC-V Trace Funnel, as defined in

the official RISC-V Trace Control Interface Specification.

A RISC-V Trace Funnel that complies to the RISC-V Trace Control Interface Specification v1.0 or newer can
have up to 16 input ports and one output port. It combines the trace data of various trace sources to a
common trace stream.
A RISC-V Trace Funnel’s input ports can only be connected to RISC-V trace sources (such as N-Trace
encoder or E-Trace encoder), or to other RISC-V Trace Funnels. Its input port can however not be connected
to other trace source types (such as Arm ETM), or to other trace funnel types (such as Arm CoreSight Trace
Funnels).
A RISC-V Trace Funnel’s output port can only be connected to a RISC-V trace sink (such as RISC-V PIB, or
RISC-V ATB Bridge), or to another RISC-V Trace Funnel. Its output port can however not be connected to
other trace sink types (such as Arm ETB), or to other trace funnel types (such as Arm CoreSight Trace
Funnels).

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V Trace Funnel.

RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 83

 SourcePortNumber Number of input ports of the RISC-V Trace Funnel.
<number>
You need to configure [Link] <address>,
before you can use this command to configure the source port number.

TraceSource Define the trace sources that are connected to the RISC-V Trace
<source> Funnel’s input ports.
You need to configure [Link] before you
can use this command to configure the trace sources.

<source> parameters:
Each trace source that is connected to the RISC-V Trace Funnel needs to
be assigned to one of the funnel’s input ports.

Example #1:

Configuration for example #1:

[Link] NEXUS 0 RVFUNNEL2 4

Meaning: The RISC-V Trace Funnel #1 gets trace data from a Nexus
trace source at funnel input #0 and from another RISC-V Trace Funnel #2
at funnel input #4.

Example #2:

In an SMP (Symmetric MultiProcessing) debug session, some trace

sources are defined as a list of base addresses to specify one
component per core (for example [Link]). In
this case, the assignment between RISC-V Trace Funnel input port and
trace source needs to specify the core index of the trace source.

Configuration for example #2:

[Link] SB:0x1000 SB:0x2000 SB:0x3000
[Link] NEXUS.0 0 NEXUS.1 1
NEXUS.2 2

Meaning: Three RISC-V cores with N-Trace encoders, connected to the

first three input ports of RISC-V Trace Funnel #1.
“NEXUS.2” refers to the third NEXUS module, which has the base
address SB:0x3000. The indices of trace source components are 0, 1, 2,
3, ...
If the numbers of the indices are steadily increasing, starting from 0 and
without gaps (like in the example above), then you can shorten the
command and alternatively write:

[Link] NEXUS

©1989-2025 Lauterbach RISC-V Debugger and Trace | 84

 [Link] configuration example

[Link] 3. ; 3 RISC-V cores

[Link] NTRACE
[Link] SB:0x1000 SB:0x2000 ; 3 Trace Encoders
SB:0x3000

[Link] SB:0x4000
[Link] 3. ; 3 Funnel inputs
[Link] NEXUS.0 0 ; Input source
NEXUS.1 1 NEXUS.2 2 assignment

NOTE: Please note that this command only refers to RISC-V trace funnels, which
comply to the official RISC-V Trace Control Interface Specification.

It should not be confused with other trace funnels, such as for example Arm
CoreSight trace funnels.

[Link].<sub_cmd> Configure RISC-V pin interface block

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

RESet
TraceSource <source>

The command [Link].<sub_cmd> configures a RISC-V Pin Interface Block (PIB) as

defined in the official RISC-V Trace Control Interface Specification.

The RISC-V PIB block is a trace sink with an off-chip trace interface. For further configuration of this IP block,
refer to the RVPIB command.

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V PIB sink.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 85

 RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

TraceSource Define the trace source that is connected to the RISC-V PIB’s input port.
<source>
You need to configure [Link], before you can
use this command to configure the trace source.

[Link] configuration example

[Link] SB:0x1000
[Link] RVFUNNEL4

[Link].<sub_cmd> System memory sink

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

RESet
TraceSource <source>

The command [Link].<sub_cmd> configures a RISC-V system memory

trace sink (SMEMTRACE) as defined in the official RISC-V Trace Control Interface Specification.

The RISC-V SMEMTRACE block is an on-chip trace sink.

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V SMEMTRACE
sink.

RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

TraceSource Define the trace source that is connected to the RISC-V SMEMTRACE
<source> sink’s input port.

You need to configure [Link], before

you can use this command to configure the trace source.

[Link] configuration example

[Link] SB:0x1000
[Link] RVFUNNEL4

©1989-2025 Lauterbach RISC-V Debugger and Trace | 86

[Link].<sub_cmd> RISC-V SRAM trace sink

Format: [Link].<sub_cmd>

<sub_cmd>: Base <address>

RESet
TraceSource <source>

The command [Link].<sub_cmd> configures a RISC-V SRAM trace sink

(SRAMTRACE) as defined in the official RISC-V Trace Control Interface Specification.

The RISC-V SRAMTRACE block is an on-chip trace sink.

The following subcommands are possible for [Link].<sub_cmd>:

Base <address> Base address of the control register block of the RISC-V SRAMTRACE
sink.

RESet Undo the user configuration for this component. This does not cause a
physical reset of the component on the chip.

TraceSource Define the trace source that is connected to the RISC-V SRAMTRACE
<source> sink’s input port.

You need to configure [Link], before

you can use this command to configure the trace source.

[Link] configuration example

[Link] SB:0x1000
[Link] RVFUNNEL4

©1989-2025 Lauterbach RISC-V Debugger and Trace | 87

[Link] Select the CPU to be debugged

Format: [Link] <cpu>

<cpu>: RV32 | RV64 | …

Selects the target core / CPU / SoC / chip to be debugged.

<cpu> For a list of supported cores/CPUs/SoCs/chips, use the command

“[Link] *” or refer to the chip search on the Lauterbach
website.

NOTE: RV32 and RV64 are default entries for 32-bit and 64-bit RISC-V cores, respectively.
These entries should only be selected if there is no dedicated <cpu> entry available
that matches the target. If RV32/RV64 is selected then all chip-specific
configuration needs to be made manually by the user.

NOTE: All core entries have a prefix that is specific to the core vendor, in order to
prevent naming collisions.
Example: the E21 core from SiFive has the name “SF-E21”.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 88

[Link] Define JTAG frequency

Format: [Link] [<frequency> | RTCK | ARTCK <frequency> |

CTCK <frequency> | CRTCK <frequency>]
[Link] <frequency> (deprecated)

<frequency>: 10000. … 40000000.

Default frequency: 10 MHz.

Selects the JTAG port frequency (TCK) used by the debugger to communicate with the processor. The
frequency affects e.g. the download speed. It could be required to reduce the JTAG frequency if there are
buffers, additional loads or high capacities on the JTAG lines or if VTREF is very low. A very high frequency
will not work on all systems and will result in an erroneous data transfer.

<frequency> The debugger cannot select all frequencies accurately. It chooses the
next possible frequency and displays the real value in the [Link]
window.
Besides a decimal number like “100000.” short forms like “10kHz” or
“15MHz” can also be used. The short forms imply a decimal value,
although no “.” is used.

RTCK The JTAG clock is controlled by the RTCK signal (Returned TCK). The
debugger does not progress to the next TCK edge until after an RTCK edge
is received. This mode is not recommended for this debugger since it is not
needed here.

ARTCK Accelerated method to control the JTAG clock by the RTCK signal
(Accelerated Returned TCK). In ARTCK mode the debugger uses a fixed
JTAG frequency for TCK, independent of the RTCK signal. This frequency
must be specified by the user. TDI and TMS will be delayed by 1/2 TCK clock
cycle. TDO will be sampled with RTCK. This mode is not recommended for
this debugger since it is not needed here.

CTCK With this option higher JTAG speeds can be reached. The TDO signal will be
sampled by a signal which derives from TCK, but which is timely
compensated regarding the debugger-internal driver propagation delays
(Compensation by TCK).

CRTCK With this option higher JTAG speeds can be reached. The TDO signal will be
sampled by the RTCK signal. This compensates the debugger-internal driver
propagation delays, the delays on the cable and on the target
(Compensation by RTCK). This feature requires that the target sends back
the TCK signal onto the RTCK signal. In contrast to the RTCK option, the
TCK is always output with the selected, fixed frequency.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 89

[Link] Tristate the JTAG port

Format: [Link] [ON | OFF]

Default: OFF.

If the system is locked, no access to the JTAG port will be performed by the debugger. While locked the
JTAG connector of the debugger is tristated. The intention of the [Link] command is, for example,
to give JTAG access to another tool. The process can also be automated, see [Link] TriState.

It must be ensured that the state of the RISC-V DTM JTAG state machine remains unchanged while the
system is locked. To ensure correct hand-over, the options [Link] TAPState and
[Link] TCKLevel must be set properly. They define the TAP state and TCK level which is
selected when the debugger switches to tristate mode.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 90

[Link] Select run-time memory access method

Format: [Link] <method>

<method>: Denied
SB
StopAndGo

Default: Denied.

This command defines if and how memory can be accessed with the “D:” and “P:” access classes while
the CPU is running.

NOTE: This command only takes effect while the CPU is running. For memory access
while the CPU is stopped, see [Link].

A prerequisite for run-time access with the “D:” and “P:” access classes is that they are combined with the
access class prefix “E”.
An “ED:” or “EP:” access can make a run-time access according to the setting of this command.
A “D:” or “P:” access (without “E” prefix”) however will always deny run-time access, independent of the
setting of this command.

Although the CPU is not halted, run-time memory access creates an additional load on the CPU’s internal
data bus.

If [Link] is not Denied, it is possible to read from memory, to write to memory and to set
software breakpoints while the CPU is running. For more information, see [Link] and
[Link].

AHB, AXI, SB, ... Depending on which memory buses are available on the chip, the
run-time memory access is done through the specified bus.

Denied No memory access is possible while the CPU is running.

StopAndGo Temporarily halts the core(s) to perform the memory access. Each stop
takes some time depending on the speed of the JTAG port, the number of
the assigned cores, and the operations that should be performed.
For more information, see below.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 91

 If [Link] StopAndGo is set, it is possible to read from memory, to write to memory and to
set software breakpoints while the CPU is executing the program. To make this possible, the program
execution is shortly stopped by the debugger. Each stop takes some time depending on the speed of the
JTAG port and the operations that should be performed. A white S against a red background in the
TRACE32 state line warns you that the program is no longer running in real-time:
No real-time

To update specific windows that display memory or variables while the program is running, select the
memory class E: or the format option %E.

[Link] E:0x100

[Link] %E first

©1989-2025 Lauterbach RISC-V Debugger and Trace | 92

[Link] Memory access while stopped

Format: [Link] <method>

<method>: AUTO
AAM
PROGBUF
SB

Default: AUTO.

This command defines the memory access method with the “D:” and “P:” access classes while the CPU
is stopped.

NOTE: This command only takes effect while the CPU is stopped. For memory access
while the CPU is running, see [Link].

AUTO Automatically choose the most suitable memory access method among
the methods that are supported by the target.

AAM Use the ‘access memory’ abstract command of the RISC-V Debug
Module.

PROGBUF Use program buffer execution via the RISC-V Debug Module.

SB Use the ‘system bus access’ block of the RISC-V Debug Module.

If the AUTO method is configured, then the method that got automatically selected by the debugger can be
seen as soon as the debugger has performed at least one successful memory access. To see the selected
method, type “[Link] “ (with whitespace at the end) into the TRACE32 command line.
The method should appear in the status line below the command line:

©1989-2025 Lauterbach RISC-V Debugger and Trace | 93

[Link] Establish the communication with the target

Format: [Link] <mode>

[Link] (alias for [Link] Attach)

[Link] (alias for [Link] Down)
[Link] (alias for [Link] Up)

<mode>: Down
Prepare
Go
Attach
StandBy
Up

Down Disables the debugger. The state of the CPU remains unchanged. The
(default) JTAG port is tristated.

Prepare Initializes a debug connection.

The debugger does initialize the debug IP, but it does not perform any
interaction with the CPU.

This debug mode is used if the CPU shall not be debugged or if it shall be
bypassed. The debugger can still access the memory, e.g. via direct
system bus access. However, any operation that could alter the CPU
state or would require CPU interaction (such as starting or stopping the
CPU, accessing memory via the CPU, or accessing GPR/CSR registers)
is not possible in this debug mode.

Go Initializes a debug connection, resets the target (see

[Link]) and lets the CPU run from its reset vector.

Attach Initializes a debug connection. The debugger does not reset the CPU and
does not interact with the CPU in any intrusive way. Consequently the
CPU stays running if it was running, or stays stopped if it was stopped.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 94

 StandBy Keeps the target in reset via the JTAG reset line and waits until power is
detected on the JTAG port. For a reset, the SRST reset line has to be
connected to the debug connector.

Once power has been detected, the debugger initializes the debug
connection, briefly halts the CPU at the reset vector, restores as many
debug registers as possible (e.g. on-chip breakpoints, trace control) and
resumes the CPU from the reset vector to start the program execution.

When a CPU power-down is detected, the debugger switches

automatically back to the StandBy mode. This allows debugging of a
power cycle because debug registers will be restored on power-up.

NOTE: Since this mode requires SRST to be asserted right from the
beginning of the connect sequence, this mode is only applicable in
combination with [Link] SRST2.

NOTE: This method only works under very specific circumstances. A

more recommended and less error-prone method to handle a core
power-down is described in chapter “Hart State: Unavailable”.

Up Initializes a debug connection, resets the target (see

[Link]) and stops the CPU at its reset vector.

[Link] Display [Link] window

Format: [Link]

Displays the [Link] window for system settings that configure debugger and target behavior.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 95

Command Reference: SYStem Option Commands

[Link].Address32 Define address format display

Format: [Link].Address32 [ON | OFF | AUTO | NARROW]

Default: AUTO.

Selects the number of displayed address digits in various windows, e.g. [Link] or [Link].

ON Display all addresses as 32-bit values. 64-bit addresses are truncated.

OFF Display all addresses as 64-bit values.

AUTO Number of displayed digits depends on address size.

NARROW 32-bit display with extendible address field.

[Link] Select AHB-AP HPROT bits

Format: [Link] <value>

Default: 0

Selects the value used for the HPROT bits in the Control Status Word (CSW) of an AHB Access Port of a
DAP, when using the AHB: memory class.

This option is only meaningful if the chip contains an Arm CoreSight DAP.

[Link] ACE enable flag of the AXI-AP

Format: [Link] [ON | OFF]

Default: OFF.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 96

 Enables ACE transactions on the DAP AXI-AP, including barriers. This does only work if the debug logic of
the target CPU implements coherent AXI accesses. Otherwise this option will be without effect.

This option is only meaningful if the chip contains an Arm CoreSight DAP.

[Link] Configure AXI-AP cache bits

Format: [Link] <value>

<value>: DeviceSYStem
NonCacheableSYStem
ReadAllocateNonShareable
ReadAllocateInnerShareable
ReadAllocateOuterShareable
WriteAllocateNonShareable
WriteAllocateInnerShareable
WriteAllocateOuterShareable
ReadWriteAllocateNonShareable
ReadWriteAllocateInnerShareable
ReadWriteAllocateOuterShareable

Default: DeviceSYStem (=0x30: Domain=0x3, Cache=0x0)

This option configures the value used for the Cache and Domain bits in the Control Status Word
(CSW[27:24]->Cache, CSW[14:13]->Domain) of an AXI Access Port of a DAP, when using the AXI: memory
class.

The below offered selection options are all non-bufferable. Alternatively you can enter a <value>, where
value[5:4] determines the Domain bits and value[3:0] the Cache bits.

DeviceSYStem =0x30: Domain=0x3, Cache=0x0

NonCacheableSYStem =0x32: Domain=0x3, Cache=0x2

ReadAllocateNonShareable =0x06: Domain=0x0, Cache=0x6

ReadAllocateInnerShareable =0x16: Domain=0x1, Cache=0x6

ReadAllocateOuterShareable =0x26: Domain=0x2, Cache=0x6

WriteAllocateNonShareable =0x0A: Domain=0x0, Cache=0xA

WriteAllocateInnerShareable =0x1A: Domain=0x1, Cache=0xA

WriteAllocateOuterShareable =0x2A: Domain=0x2, Cache=0xA

ReadWriteAllocateNonShareable =0x0E: Domain=0x0, Cache=0xE

ReadWriteAllocateInnerShareable =0x1E: Domain=0x1, Cache=0xE

ReadWriteAllocateOuterShareable =0x2E: Domain=0x2, Cache=0xE

©1989-2025 Lauterbach RISC-V Debugger and Trace | 97

 This option is only meaningful if the chip contains an Arm CoreSight DAP.

[Link] Select AXI-AP HPROT bits

Format: [Link] <value>

Default: 0

This option selects the value used for the HPROT bits in the Control Status Word (CSW) of an AXI Access
Port of a DAP, when using the AXI: memory class.

This option is only meaningful if the chip contains an Arm CoreSight DAP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 98

[Link] Force debug power in DAP

Format: [Link] [ON | AlwaysON | OFF]

Default: ON.

This option controls the DBGPWRUPREQ bit of the CTRL/STAT register of the Debug Access Port (DAP)
before and after the debug session. Debug power will always be requested by the debugger on a debug
session start because debug power is mandatory for debugger operation.

AlwaysON Debug power is requested by the debugger on a debug session start, and
the control bit is set to 1.
The debug power is not released at the end of the debug session, and the
control bit is set to 0.

OFF Only for test purposes: Debug power is not requested and not checked by
the debugger. The control bit is set to 0.

ON Debug power is requested by the debugger on a debug session start, and

the control bit is set to 1.
The debug power is released at the end of the debug session, and the
control bit is set to 0.

Use case:

Imagine an AMP session consisting of at least of two TRACE32 PowerView GUIs, where one GUI is the
master and all other GUIs are slaves. If the master GUI is closed first, it releases the debug power. As a
result, a debug port fail error may be displayed in the remaining slave GUIs because they cannot access the
debug interface anymore.

To keep the debug interface active, it is recommended that [Link] is set to

AlwaysON.

This option is only meaningful if the chip contains an Arm CoreSight DAP.

[Link] No DAP instruction register check

Format: [Link] [ON | OFF]

Default: OFF.

Bug fix for derivatives which do not return the correct pattern on a DAP (Arm CoreSight Debug Access Port)
instruction register (IR) scan. When activated, the returned pattern will not be checked by the debugger.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 99

 This option is only meaningful if the chip contains an Arm CoreSight DAP.

[Link] Rearrange DAP memory map

Format: [Link] {<address_range> <address>}

The Debug Access Port (DAP) can be used for memory access during runtime. If the mapping on the DAP is
different than the processor view, then this re-mapping command can be used

NOTE: Up to 16 <address_range>/<address> pairs are possible. Each pair has to

contain an address range followed by a single address.

This option is only meaningful if the chip contains an Arm CoreSight DAP.

[Link] Force system power in DAP

Format: [Link] [AlwaysON | ON | OFF]

Default: ON.

This option controls the SYSPWRUPREQ bit of the CTRL/STAT register of the Debug Access Port (DAP)
during and after the debug session.

AlwaysON System power is requested by the debugger on a debug session start, and
the control bit is set to 1.
The system power is not released at the end of the debug session, and the
control bit remains at 1.

OFF System power is not requested by the debugger on a debug session start,
and the control bit is set to 0.

ON System power is requested by the debugger on a debug session start, and

the control bit is set to 1.
The system power is released at the end of the debug session, and the
control bit is set to 0.

This option is only meaningful if the chip contains an Arm CoreSight DAP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 100

[Link] Options for debug port handling

Format: [Link] <option>

<option>: SWITCHTOSWD.[TryAll | None | JtagToSwd | LuminaryJtagToSwd | Dor-

mantToSwd | JtagToDormantToSwd]
SWDTRSTKEEP.[DEFault | LOW | HIGH]

Default: [Link], [Link].

See Arm CoreSight manuals to understand the used terms and abbreviations and what is going on here.

SWITCHTOSWD tells the debugger what to do in order to switch the debug port to serial wire mode:

TryAll Try all switching methods in the order they are listed below. This is
the default. Normally it does not hurt to try improper switching
sequences. Therefore this succeeds in most cases.

None There is no switching sequence required. The SW-DP is ready

after power-up. The debug port of this device can only be used as
SW-DP.

JtagToSwd Switching procedure as it is required on SWJ-DP without a

dormant state. The device is in JTAG mode after power-up.

LuminaryJtagToSwd Switching procedure as it is required on devices from

LuminaryMicro. The device is in JTAG mode after power-up.

DormantToSwd Switching procedure which is required if the device starts up in

dormant state. The device has a dormant state but does not
support JTAG.

JtagToDormantToSwd Switching procedure as it is required on SWJ-DP with a dormant

state. The device is in JTAG mode after power-up.

SWDTRSTKEEP tells the debugger what to do with the nTRST signal on the debug connector during serial
wire operation. This signal is not required for the serial wire mode but might have effect on some target
boards, so that it needs to have a certain signal level.

DEFault Use nTRST the same way as in JTAG mode which is typically a low-pulse
on debugger start-up followed by keeping it high.

LOW Keep nTRST low during serial wire operation.

HIGH Keep nTRST high during serial wire operation

This option is only meaningful if the chip contains an Arm CoreSight DAP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 101

[Link] Allow debugger to reset DM via dmactive
[build 150897 - DVD 09/2022]

Format: [Link] [ON | OFF]

Default: ON

If ON, the debugger will reset the RISC-V debug module via its [Link] bit, before using it for the
first time. This is usually done while connecting to the target.

If OFF, the debugger will not reset the RISC-V debug module via its [Link] bit, before using it
for the first time. Instead, it will only set the bit to high (if it is not high already).

[Link] Allow the debugger to drive nRESET (nSRST)

[[Link] window> EnReset]

Format: [Link] <sub_cmd> (removed)

<sub_cmd>: ON (removed)
Use [Link] SRST instead

OFF (removed)
Use [Link] NDMRST instead

NOTE: Since release R.2021.02 this command is no longer available for the RISC-V
debugger. Please refer to its replacement, [Link].

Default: ON.

If this option is OFF the debugger will never drive the nRESET (nSRST) line on the JTAG connector.
This is necessary if nRESET (nSRST) is no open collector or tristate signal.
Instead, during a [Link], the debugger will only assert a soft system reset via the “non-debug
module reset” bit (ndmreset) of the dmcontrol register.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 102

[Link] Use Harvard memory model

Format: [Link] [ON | OFF]

Default: OFF.

This option must be disabled if the RISC-V target does not use a Harvard memory model, i.e. if the target
does not have physically separate storage and signal pathways for program and data memory.

This option must be enabled if the RISC-V target does use a Harvard memory model.

[Link] Set reset duration time

Format: [Link] <time>

<time>: 1us... 10s

Default: 50ms.

Set the minimum time the debugger holds the reset active, before either deasserting the reset or continuing
with other operations such as debug register accesses (whichever occurs first).

This affects the sequences of [Link] and [Link].

minimum hold time

nRESET ?

debug register access access

In case of [Link], this command affects the wait time starting after detection of the target
power-on (during which SRST is already asserted).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 103

[Link] Disable interrupts while single stepping

Format: [Link] [ON | OFF]

Default: OFF.

If enabled, the ‘Step Interrupt Enable Bit’ ([Link]) will be cleared during assembler single-step
operations ([Link]). No interrupt routines will be executed during assembler single-step operations.

If disabled, the ‘Step Interrupt Enable Bit’ ([Link]) will be set during assembler single-step operations
([Link]). Interrupt routines will be executed during assembler single-step operations.

NOTE: Some RISC-V hardware implementations may have hardwired the [Link]
bit to zero.

[Link] Disable interrupts while HLL single stepping

Format: [Link] [ON | OFF]

Default: OFF.

If enabled, the interrupt enable bits of the CPU ([Link]/SIE/UIE) will be cleared during HLL single-step
operations ([Link] or [Link]). No interrupt routines will be executed during HLL single-step
operations. After the HLL single-step, the interrupt enable bits are restored to their original values before the
step.

If disabled, the debugger does not modify the interrupt enable bits of the CPU during HLL single-step
operations.

[Link] Disable JTAG IR width detection

[build 171438 - DVD 09/2024]

Format: [Link] [ON | OFF]

Default: ON.

If OFF, the debugger disables the sanity check for detecting the JTAG IR width of the debug TAP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 104

[Link] Manually configure support for ISA
extensions
[build 164710]

Format: [Link].<extension> [AUTO | ON | OFF]

<extension>: D
ZCM

This command makes the debugger aware of the ISA extensions implemented in the current RISC-V hart
under debug. This may be needed when optional RISC-V ISA extensions reuse instruction opcodes from
other extensions and the debugger has no other means to resolve an opcode into the correct instruction.
Usually the debugger can detect which ISA extensions the current RISC-V hart under debug supports. But if
that is not the case, this command can be used to enable/disable the debugger’s support for it.

AUTO Enables the debugger’s auto detection for the given ISA extension.

ON Enable the support for the given ISA extension.

This prevents the debugger’s auto detection mechanism.

OFF Disable the support for the given ISA extension.

This prevents the debugger’s auto detection mechanism.

NOTE: The support for some RISC-V ISA extensions might not be settable when there
are conflicts with another extension that is already set.

[Link] Keep hart available for debugger

[build 145331 - DVD 09/2022]

Format: [Link] [ON | OFF]

Default: ON.

Sets or clears the KEEPALIVE bit of the RISC-V hart.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 105

 The ‘keepalive’ bit suggests that the hardware should attempt to keep the hardware thread (hart) available
for the debugger, e.g. by keeping it from entering a low-power state once powered on. Even if the bit is
implemented by the hardware, the hardware might not be able to keep a hart available.

[Link] Separate address spaces by space IDs

Format: [Link] [ON | OFF]

[Link] [ON | OFF] (deprecated)
[Link] [ON | OFF] (deprecated)

Default: OFF.

Enables the use of space IDs for logical addresses to support multiple address spaces.

For an explanation of the TRACE32 concept of address spaces (zone spaces, MMU spaces, and machine
spaces), see “TRACE32 Concepts” (trace32_concepts.pdf).

NOTE: [Link] should not be set to ON if only one translation

table is used on the target.

If a debug session requires space IDs, you must observe the following
sequence of steps:

1. Activate [Link].

2. Load the symbols with [Link].

Otherwise, the internal symbol database of TRACE32 may become

inconsistent.

Examples:

;Dump logical address 0xC00208A belonging to memory space with

;space ID 0x012A:
[Link] D:0x012A:0xC00208A

;Dump logical address 0xC00208A belonging to memory space with

;space ID 0x0203:
[Link] D:0x0203:0xC00208A

©1989-2025 Lauterbach RISC-V Debugger and Trace | 106

[Link] Choose method to detect a target reset

Format: [Link] <method>

<method>: nSRST | None

Default: nSRST

Selects the method how an external target reset can be detected by the debugger.

nSRST Detects a reset if nSRST (nRESET) line on the debug connector is pulled
low.

None Detection of external resets is disabled.

[Link] Select reset method

Format: [Link] <method>

<method>: SRST
SRST2
NDMRST
HartRST

Default: SRST.

Configures the reset method used by [Link] and [Link] Go.

SRST System reset via the SRST signal of the JTAG connector. This signal is
sometimes also called nSRST, RST or RESET.
SRST is asserted directly before the halt request. See paragraph
ResetMode SRST for details.
This reset method is only allowed for [Link] OFF.

SRST2 System reset via the SRST signal of the JTAG connector. This signal is
sometimes also called nSRST, RST or RESET.
SRST is asserted before the first debug register access. See paragraph
ResetMode SRST2 for details.
This reset method is only allowed for [Link] OFF.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 107

 NDMRST System reset via the ‘ndmreset’ bit of the ‘dmcontrol’ debug register in
the RISC-V Debug Module.
See paragraph ResetMode NDMRST for details.
This reset method is only allowed for [Link] OFF.

HartRST Hardware thread (hart) reset via the ‘hartreset’ bit of the ‘dmcontrol’
debug register in the RISC-V Debug Module.
Resets all harts that are currently selected via [Link].
See paragraph ResetMode HartRST for details.
This reset method is possible for both, [Link] OFF and
[Link] ON.

The behavior of the respective reset method can be further influenced by the following configuration options:

• [Link]

• [Link]

ResetMode SRST

The sequence of [Link] with [Link] SRST looks as follows:

system reset: nSRST

test-logic-reset: 5xTMS + nTRST

debug register access DM initialization halt debug

halt request

CPU state ? reset halted

The above debug register access sequence labeled with ‘halt’ does only contain accesses to the ‘dmcontrol’
debug register.

The test-logic-reset via nTRST can be configured by [Link].

©1989-2025 Lauterbach RISC-V Debugger and Trace | 108

 ResetMode SRST2

The sequence of [Link] with [Link] SRST2 looks as follows:

system reset: nSRST

test-logic-reset: 5xTMS + nTRST

debug register access DM initialization halt debug

halt request

CPU state ? reset halted

The above debug register access sequence labeled with ‘DM initialization’ (Debug Module initialization) can
contain accesses to any arbitrary debug register. That is why this sequence should only be used if the target
allows debugger access to all debug registers while SRST is asserted.

The test-logic-reset via nTRST can be configured by [Link].

ResetMode NDMRST

The sequence of [Link] with [Link] NDMRST looks as follows:

system reset: [Link]

test-logic-reset: 5xTMS + nTRST

debug register access DM initialization halt debug

halt request

CPU state ? reset

halted

The above debug register access sequence labeled with ‘halt’ does only contain accesses to the ‘dmcontrol’
debug register.

The test-logic-reset via nTRST can be configured by [Link].

©1989-2025 Lauterbach RISC-V Debugger and Trace | 109

 ResetMode HartRST

The sequence of [Link] with [Link] HartRST looks as follows:

hart reset: [Link]

test-logic-reset: 5xTMS + nTRST

debug register access DM initialization halt debug

halt request

CPU state ? reset halted

The above debug register access sequence labeled with ‘halt’ does only contain accesses to the ‘dmcontrol’
debug register.

The test-logic-reset via nTRST can be configured by [Link].

[Link] Use 32-bit access to set SW breakpoints

Format: [Link] [ON | OFF]

Default: OFF.

Instructs the debugger to only use 32-bit accesses to patch the code of software breakpoints.

NOTE: If the debugger should be restricted to only use 32-bit accesses for any kind of
memory access (not only for software breakpoints), then please see the
command MAP.BUS32 instead.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 110

[Link] Define action during [Link]

Format: [Link] <action>

<action>: NONE
DCSRRST

Default: NONE.

Defines the action that shall be taken when a [Link] is performed.

The respective action, however, will not be executed if the debugger performs an automated [Link]
after an error situation.

NONE No action.

DCSRRST Reset certain bits of the Debug Control and Status Register (DCSR) of
the core under debug to their respective default values. This does not
affect the [Link] bits or bitfields with implementation-specific reset
values (“preset reset values”).
This action can be intrusive, as it may be necessary to temporarily halt
the core in order to access the register.

[Link] Allow debugger to drive TRST

[[Link] window > TRST]

Format: [Link] [ON | OFF]

Default: ON.

If this option is disabled, the nTRST line is never driven by the debugger (permanent high).

If this option is enabled, the debugger may make a test-logic-reset via nTRST during the connect sequence
to the target.

Independent of whether this option is ON or OFF, the debugger’s connect sequence may contain other
mechanisms for test-logic-reset or test-logic initialization (for example in case of JTAG debugging, the
sequence may additionally contain five consecutive TMS pulses to reset the JTAG TAP).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 111

[Link] Set reset wait time

Format: [Link] <time>

<time>: 1us... 10s

Default: 50ms.

Set the time that the debugger will wait after deassertion of a reset, e.g. during [Link] or
[Link].

Before the wait time is over, the debugger will not perform any other target interactions such as JTAG shifts
or debug register accesses.

wait time

nRESET

debug register access access

©1989-2025 Lauterbach RISC-V Debugger and Trace | 112

[Link] Enable symbol management for zones
[Example]

Format: [Link] [ON | OFF]

Default: OFF.

The [Link] command must be set to ON if separate symbol sets are used for the
following RISC-V modes:

• Machine mode (access classes M:, MD:, and MP:)

• Supervisor mode (S:, SD:, and SP:) and

• User mode (access classes U:, UD,: and UP:)

RISC-V has two CPU mode dependent address spaces. Within TRACE32, these two CPU mode
dependent address spaces are referred to as zones:

• In Machine mode, no address translation is performed. TRACE32 treats the Machine mode as
one zone.

• In Supervisor mode as well as in User mode, addresses are translated by the hardware MMU.
Both modes share the same address space because they use the same translation. Thus,
TRACE32 treats both Supervisor mode and User mode as one single zone.

Due to the different address translation in these modes, different code and data can be visible on the same
logical address.

NOTE: For an explanation of the TRACE32 concept of address spaces (zone spaces,
MMU spaces, and machine spaces), see “TRACE32 Concepts”
(trace32_concepts.pdf).

OFF TRACE32 does not separate symbols by access class. Loading two or
more symbol sets with overlapping address ranges will result in
unpredictable behavior. Loaded symbols are independent of the CPU
mode.

ON Separate symbol sets can be loaded for each zone, even with
overlapping address ranges. Loaded symbols are specific to one of the
CPU zones.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 113

 [Link] ON

[Link] is set to ON if the user wants to debug code which is executed in

Supervisor or User mode, such as a operating system, and code which is executed in Machine mode, such
as exception handlers.

If [Link] is ON, TRACE32 enforces any memory address specified in a TRACE32

command to have an access class which clearly indicates to which zone the memory address belongs.

If an address specified in a command uses an anonymous access class such as D:, P: or C:, the access
class of the current PC context is used to complete the addresses’ access class.

If a symbol is referenced by name, the associated access class of its zone will be used automatically, so that
the memory access is done within the correct CPU mode context. As a result, the symbol’s logical address
will be translated to the physical address with the correct MMU translation table.

Example:

[Link] ON

; 1. Load a Linux image to Supervisor mode

; (access classes S:, SP: and SD: are used for the symbols of Linux.
; access classes U:, UP: and UD: are used for User mode applications):
[Link] vmlinux S:0x0 /NoCODE

; 2. Load a secure driver image to Machine mode:

; (access classes M:, MP: and MD: are used for the symbols):
[Link] secdriver M:0x0 /NoCODE

©1989-2025 Lauterbach RISC-V Debugger and Trace | 114

Command Reference: MMU Commands

[Link] Page wise display of MMU translation table

Format: [Link] <table> [<range> | <address> | <range> <root> |

<address> <root>]

<table>: PageTable
KernelPageTable
TaskPageTable <task_magic> | <task_id> | <task_name> | <space_id>:0x0
<cpu_specific_tables>

Displays the contents of the CPU specific MMU translation table.

• If called without parameters, the complete table will be displayed.

• If the command is called with either an address range or an explicit address, table entries will
only be displayed if their logical address matches with the given parameter.

<root> The <root> argument can be used to specify a page table base address
deviating from the default page table base address. This allows to display a
page table located anywhere in memory.

<range> Limit the address range displayed to either an address range

<address> or to addresses larger or equal to <address>.

For most table types, the arguments <range> or <address> can also be
used to select the translation table of a specific process if a space ID is
given.

PageTable Displays the entries of an MMU translation table.

• if <range> or <address> have a space ID: displays the translation
table of the specified process
• else, this command displays the table the CPU currently uses for
MMU translation.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 115

 KernelPageTable Displays the MMU translation table of the kernel.
If specified with the [Link] command, this command reads the
MMU translation table of the kernel and displays its table entries.

TaskPageTable Displays the MMU translation table entries of the given process. Specify
<task_magic> | one of the TaskPageTable arguments to choose the process you want.
<task_id> | In MMU-based operating systems, each process uses its own MMU
<task_name> | translation table. This command reads the table of the specified process,
<space_id>:0x0 and displays its table entries.
• For information about the first three parameters, see “What to
know about the Task Parameters” (general_ref_t.pdf).
• See also the appropriate OS Awareness Manuals.

CPU specific Tables in [Link] <table>

SupervisorPageTa- Displays the page table of modi S:/U:, based on register SATP.
ble

VirtSupervisorPag- Displays the page table of modi VS:/VU:, based on register VSATP.
eTable Note that in case G-stage (stage 2) is disabled (bare mode), VS:/VU:
addresses will directly be translated to physical addresses (A:) instead of
guest physical/intermediate physical addresses I:.

IntermedPageTable Displays the G-stage page table (stage 2), translating guest
physical/intermediate physical addresses I: to physical addresses A:. Based
on register HGATP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 116

[Link] Compact display of MMU translation table

Format: [Link] <table> [<range> | <address> | <range> <root> | <address> <root>]

[/<option>]

<table>: PageTable
KernelPageTable
TaskPageTable <task_magic> | <task_id> | <task_name> | <space_id>:0x0
<cpu_specific_tables>

<option>: MACHINE <machine_magic> | <machine_id> | <machine_name>

Fulltranslation

Lists the address translation of the CPU-specific MMU table.

In contrast to [Link], multiple consecutive page table entries with identical page attributes are listed as
a single line, showing the total mapped address range.

• If called without address or range parameters, the complete table will be displayed.

• If called without a table specifier, this command shows the debugger-internal translation table.
See [Link].

• If the command is called with either an address range or an explicit address, table entries will
only be displayed if their logical address matches with the given parameter.

<root> The <root> argument can be used to specify a page table base address
deviating from the default page table base address. This allows to display a
page table located anywhere in memory.

<range> Limit the address range displayed to either an address range

<address> or to addresses larger or equal to <address>.

For most table types, the arguments <range> or <address> can also be
used to select the translation table of a specific process or a specific
machine if a space ID and/or a machine ID is given.

PageTable Lists the entries of an MMU translation table.

• if <range> or <address> have a space ID and/or machine ID: list
the translation table of the specified process and/or machine
• else, this command lists the table the CPU currently uses for MMU
translation.

KernelPageTable Lists the MMU translation table of the kernel.

If specified with the [Link] command, this command reads the
MMU translation table of the kernel and lists its address translation.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 117

 TaskPageTable Lists the MMU translation of the given process. Specify one of the
<task_magic> | TaskPageTable arguments to choose the process you want.
<task_id> | In MMU-based operating systems, each process uses its own MMU
<task_name> | translation table. This command reads the table of the specified process,
<space_id>:0x0 and lists its address translation.
• For information about the first three parameters, see “What to
know about the Task Parameters” (general_ref_t.pdf).
• See also the appropriate OS Awareness Manuals.

<option> For description of the options, see [Link].

CPU specific Tables for [Link] <table>

Supervisor- Lists the page table of modi S:/U:, based on register SATP.
PageTable

VirtSupervisor- Lists the page table of modi VS:/VU:, based on register VSATP.
PageTable Note that in case G-stage (stage 2) is disabled (bare mode), VS:/VU:
addresses will directly be translated to physical addresses (A:) instead of
guest physical/intermediate physical addresses I:.

IntermedPageTable Lists the G-stage page table (stage 2), translating guest
physical/intermediate physical addresses I: to physical addresses A:. Based
on register HGATP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 118

[Link] Load MMU table from CPU

Format: [Link] <table> [<range> <address>]

<table>: PageTable
KernelPageTable
TaskPageTable <task_magic> | <task_id> | <task_name> | <space_id>:0x0
ALL [Clear]
<cpu_specific_tables>

Loads the CPU-specific MMU translation table from the CPU to the debugger-internal static translation table.

• If called without parameters, the complete page table will be loaded. The list of static address
translations can be viewed with [Link].

• If the command is called with either an address range or an explicit address, page table entries
will only be loaded if their logical address matches with the given parameter.

Use this command to make the translation information available for the debugger even when the program
execution is running and the debugger has no access to the page tables and TLBs. This is required for the
real-time memory access. Use the command [Link] to enable the debugger-internal MMU table.

PageTable Loads the entries of an MMU translation table and copies the address
translation into the debugger-internal static translation table.
• if <range> or <address> have a space ID: loads the translation table
of the specified process
• else, this command loads the table the CPU currently uses for MMU
translation.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 119

 KernelPageTable Loads the MMU translation table of the kernel.
If specified with the [Link] command, this command reads the table
of the kernel and copies its address translation into the debugger-internal
static translation table.

TaskPageTable Loads the MMU address translation of the given process. Specify one of
<task_magic> | the TaskPageTable arguments to choose the process you want.
<task_id> | In MMU-based operating systems, each process uses its own MMU
<task_name> | translation table. This command reads the table of the specified process,
<space_id>:0x0 and copies its address translation into the debugger-internal static translation
table.
• For information about the first three parameters, see “What to know
about the Task Parameters” (general_ref_t.pdf).
• See also the appropriate OS Awareness Manual.

ALL [Clear] Loads all known MMU address translations.

This command reads the OS kernel MMU table and the MMU tables of all
processes and copies the complete address translation into the debugger-
internal static translation table.
See also the appropriate OS Awareness Manual.
Clear: This option allows to clear the static translations list before reading
it from all page translation tables.

<range> The address range of the page table which will be scanned for valid
entries.

<address> The start address from which the page table will be scanned for valid
entries.
The end address for the scan is <address> + <scan_range>
<scan_range> is explained below.

If neither <range> nor <address> are specified, the page table will be scanned from 0 to <scan_range>

<scan_range> depends on the selected or auto-detected MMU format.

• MMU format SV32: <scan_range> = 232 - 1

• MMU format SV39: <scan_range> = 239 - 1

• MMU format SV48: <scan_range> = 248 - 1

• MMU format SV57: <scan_range> = 257 - 1

©1989-2025 Lauterbach RISC-V Debugger and Trace | 120

CPU specific Table for [Link] <table>

SupervisorPageTa- Loads the page table of modi S:/U:, based on register SATP.
ble

VirtSupervisorPag- Loads the page table of modi VS:/VU:, based on register VSATP.
eTable Note that in case G-stage (stage 2) is disabled (bare mode), VS:/VU:
addresses will directly be translated to physical addresses (A:) instead of
guest physical/intermediate physical addresses I:.

IntermedPageTable Loads the G-stage page table (stage 2), translating guest
physical/intermediate physical addresses I: to physical addresses A:. Based
on register HGATP.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 121

Command Reference: TrOnchip Commands

The TrOnchip command group is not available for the RISC-V debugger and trace.

Command Reference: RVATBBRIDGE Commands

RVATBBRIDGE.<sub_cmd> Control RISC-V trace ATB bridge

Format: RVATBBRIDGE.<sub_cmd>

<sub_cmd>: TraceID AUTO | <trace_id>

RESet

The command RVATBBridge.<sub_cmd> controls a RISC-V Trace ATB Bridge as defined in the official
RISC-V Trace Control Interface Specification.

The RISC-V trace ATB bridge is necessary in order to send trace data from a RISC-V trace infrastructure
(compliant to the RISC-V Trace Control Interface Specification) to an ATB bus. For basic configuration of this
IP block, refer to the [Link] command group.

NOTE: You must make all necessary configurations for the

[Link].<sub_cmd> command group, before you can
use the RVATBBRIDGE command group.

The following subcommands are possible for RVATBBRIDGE.<sub_cmd>:

TraceID Configure the ATB ID / ATID of the RISC-V Trace ATB Bridge that is used on
the ATB bus that it is connected to.

RESet Reset settings of RVATBBRIDGE to default.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 122

Command Reference: RVPIB Commands

RVPIB.<sub_cmd> Control RISC-V pin interface block

Format: RVPIB.<sub_cmd>

<sub_cmd>: CLocKDIVider <divider>

PortMode <mode>
PortSize <size>
RESet

The command RVPIB.<sub_cmd> controls a RISC-V Pin Interface Block (PIB) as defined in the official
RISC-V Trace Control Interface Specification.

The RISC-V PIB block is a trace sink with an off-chip trace interface. For basic configuration of this IP block,
refer to the [Link] command group.

NOTE: You must make all necessary configurations for the

[Link].<sub_cmd> command group, before you can use the
RVPIB command group.

The following subcommands are possible for RVPIB.<sub_cmd>:

CLocKDIVider The clock of the off-chip trace output signal of the PIB module gets
<divider> divided by the configured <divider> value.

PortMode <mode> Configure transmission mode of the PIB output port.

Possible <mode> parameter values are:

Parallel:
PIB is used as a parallel trace interface with a TRC_CLK clock signal and
one or more TRC_DATA data signals. The number of the data signals is
configured by the [Link] command.

PortSize <size> Configure the number of TRC_DATA data signals for parallel trace
transmission mode.

Possible parallel port <size> options are: 1, 2, 4 or 8.

This command is only applicable if [Link] Parallel is

configured.

RESet Reset settings of [Link] window to default.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 123

 RVPIB configuration example

[Link] Parallel
[Link] 8.
[Link] 1.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 124

Command Reference: RVETRACE (E-Trace)

The RVETRACE command group configures the control registers of all E-Trace encoder(s) that were
previously configured via the [Link] command group.

NOTE: You must make all necessary configurations for the

[Link].<sub_cmd> command group, before you can use
the RVETRACE command group.

[Link] Disable E-TRACE

Format: [Link]

Disable tracing with an E-Trace trace encoder.

[Link] Enable E-TRACE

Format: [Link]

Enable tracing with an E-Trace trace encoder.

[Link] Show trace control registers

Format: [Link]

Show the trace control registers of all trace IP blocks that are configured (e.g. E-Trace trace encoder(s),
RISC-V trace funnel(s), trace sink(s)).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 125

[Link] Reset E-TRACE encoder

Format: [Link]

Reset and initialize the E-Trace trace encoder.

[Link] Configure trace source ID of E-TRACE encoder

Format: [Link] [AUTO | <id>]

Default: AUTO.

Configure the trace source ID that is associated with the E-Trace trace encoder(s). The trace source ID is
used to identify and distinguish trace packets from multiple trace sources.

Depending on the trace setup, this trace ID can either be:

• Trace ID embedded in the Encapsulation Structure defined by the “RISC-V Unformatted Trace &
Diagnostic Data Packet Encapsulation Specification”: srcID field, configured via trTeSrcID. The
width gets configured via trTeSrcBits.

• Trace ID that is part of an encapsulation trace transport layer (e.g. ATID of Arm CoreSight Trace
Formatter Protocol).

Depending on the hardware, the trace ID width may either be configurable or hardcoded.

AUTO The debugger automatically assigns suitable trace ID widths to each

trace source.

<width> Manually assign trace ID widths to each trace source.

[Link] Enable / disable E-TRACE encoder timestamps

Format: [Link] [ON | OFF]

Enable or disable the generation of timestamps in the Encapsulation Structure defined by the “RISC-V
Unformatted Trace & Diagnostic Data Packet Encapsulation Specification”.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 126

Command Reference: NEXUS (N-Trace)

The NEXUS command group configures the control registers of all N-Trace trace encoder(s) that were
previously configured via the [Link].<sub_cmd> command group.

NOTE: You must make all necessary configurations for the

[Link].<sub_cmd> command group, before you can use the
NEXUS command group.

[Link] Power on N-Trace encoder

Format: [Link]

Power on the N-Trace trace encoder.

[Link] Power off N-Trace encoder

Format: [Link]

Power off the N-Trace trace encoder.

[Link] Enable / disable N-Trace encoder timestamps

Format: [Link] [ON | OFF]

Enable or disable the generation of timestamps in the N-Trace messages of the N-Trace trace encoder.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 127

[Link] Configure trace source ID of N-Trace encoder

Format: [Link] [AUTO | <id>]

Default: AUTO.

Configure the trace source ID that is associated with the N-Trace trace encoder(s). The trace source ID is
used to identify and distinguish trace packets from multiple trace sources.

Depending on the trace setup, this trace ID can either be:

• Trace ID embedded in the N-Trace messages themselves: SRC field, configured via trTeSrcID.

• Trace ID that is part of the trace transport layer (e.g. ATID of Arm CoreSight Trace Formatter
Protocol).

Depending on the hardware, the trace ID may either be configurable, hardcoded or permanently off.

AUTO The debugger automatically assigns unique trace IDs to each trace
source.

<id> Manually assign trace IDs to each trace source.

[Link] Configure trace source ID width of N-Trace encoder

Format: [Link] [AUTO | <width>]

Default: AUTO.

Configure the width (in bits) of the trace source ID that is associated with the N-Trace trace encoder(s). The
trace source ID is used to identify and distinguish trace packets from multiple trace sources.

Depending on the trace setup, this trace ID can either be:

• Trace ID embedded in the N-Trace messages themselves: SRC field, configured via trTeSrcID. The
width gets configured via trTeSrcBits.

• Trace ID that is part of the trace transport layer (e.g. ATID of Arm CoreSight Trace Formatter
Protocol).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 128

 Depending on the hardware, the trace ID width may either be configurable or hardcoded.

AUTO The debugger automatically assigns suitable trace ID widths to each

trace source.

<width> Manually assign trace ID widths to each trace source.

[Link] Show trace control registers

Format: [Link]

Show the trace control registers of all trace IP blocks that are configured (e.g. N-Trace trace encoder(s),
RISC-V trace funnel(s), trace sink(s)).

©1989-2025 Lauterbach RISC-V Debugger and Trace | 129

[Link] Reset N-Trace encoder

Format: [Link]

Reset and initialize the N-Trace trace encoder.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 130

Target Adaption

Connector Type and Pinout

RISC-V Debug Cable with 20 pin Connector

Adaption for RISC-V Debug Cable: See [Link]/[Link]

Signal Pin Pin Signal

VREF-DEBUG 1 2 N/C
TRST- 3 4 GND
TDI 5 6 GND
TMS 7 8 GND
TCK 9 10 GND
RTCK 11 12 GND
TDO 13 14 GND
RESET- 15 16 GND
N/C 17 18 GND
N/C 19 20 GND

Pin 2, pin 17 and pin 19 must under no circumstances be connected on the

target side. Otherwise the hardware of the debugger can get damaged.

©1989-2025 Lauterbach RISC-V Debugger and Trace | 131