Debugger Tricore

TriCore Debugger and Trace
TRACE32 Online Help
TRACE32 Directory
TRACE32 Index
TRACE32 Documents ...................................................................................................................... 
ICD In-Circuit Debugger ................................................................................................................ 
Processor Architecture Manuals .............................................................................................. 
TriCore ...................................................................................................................................... 
TriCore Debugger and Trace ............................................................................................... 1
History ................................................................................................................................ 7
Safety Precautions ............................................................................................................ 8
Introduction ....................................................................................................................... 9
Brief Overview of Documents for New Users 9
Available Tools 10
Debugger 10
Software-only Debugger for XCP 10
On-chip Trace 10
Serial Off-chip Trace (AGBT) 11
Parallel Off-chip Trace 11
Co-Processor Debugging (PCP/GTM) 11
Multicore Debugging and Tracing 11
Software Installation 12
Configuration 12
System Overview 12
Related Documents 13
Demo and Start-up Scripts 13
OCDS Levels 14
Debugging .......................................................................................................................... 15
Single-Core Debugging (AUDO) 16
Single-Core Debugging - Quick Start 16
Multicore Debugging (AURIX) 18
SMP Debugging - Quick Start 18
AMP Debugging - Quick Start 20
AMP vs. SMP 22
Selecting the right AURIX CPU 23
Understanding Multicore Startup by Application Code 23
About Ambiguous Symbols 24
©1989-2021 Lauterbach GmbH

TriCore Debugger and Trace 1
Access Classes 25
Breakpoints 26
Software Breakpoints 26
On-chip Breakpoints 26
MAP.BOnchip Command 27
Advanced Breakpoints 27
Single Stepping 28
Assembler Level 28
HLL Level 28
Flash 29
Onchip Triggers (TrOnchip Window) 31
BenchMarkCounter 32
Example: Measuring Instructions and Stalls per Clock Cycle 33
Example: A-to-B Mode (single shot) 34
Example: A-to-B Mode (average) 35
Example: Record Counters Periodically 36
Watchpins 37
AUDO 37
AURIX 37
Accessing Cached Memory Areas and Cache Inspection 41
AUDO Devices 41
AURIX Devices 42
Parallel Usage of a 3rd-Party Tool 46
Physical Sharing of the Debug Port 46
Debugging an Application with the Memory Protection Unit Enabled 48
TriCore v1.6 and Later 48
TriCore v1.3.1 and Earlier 48
Debugging with MPU Enabled in RAM 48
Debugging with MPU Enabled in FLASH 49
Debugging through Resets and Power Cycles 50
Soft Resets 50
Hard Resets 51
Power Cycles 52
Suspending the System Timers of TC3xx 54
Suspending the Watchdogs 54
Cerberus Access Protection 55
Target Code Execution 55
Internal Break Bus (JTAG) 55
Troubleshooting 56
SYStem.Up Errors 56
Debugging Optimized Code 56
FAQ ..................................................................................................................................... 57
Tracing ............................................................................................................................... 58
On-chip Trace (OCDS-L3) 58
Quick Start for Tracing with On-chip Trace (OCDS-L3) 58
Supported Features 59
Trace Control 60
Trace Evaluation 60
Impact of the Debugger on FPI Bus Tracing 60
Simple Trace Control 61
Examples 61
CPU specific Commands .................................................................................................. 65

CPU specific BMC Commands 65
BMC.SELect Select counter for statistic analysis 65
BMC.<counter>.ATOB Control A-to-B mode 65
BMC.<counter>.TRIGMODE BMC trigger mode 66
BMC.<counter>.TRIGVAL BMC trigger value 66
CPU specific SYStem.CONFIG Commands 67
SYStem.CONFIG.state Display target configuration 67
SYStem.CONFIG Configure debugger according to target topology 68
Daisy-Chain Example 70
TapStates 71
SYStem.CONFIG.CORE Assign core to TRACE32 instance 72
SYStem.CONFIG BreakPIN Define mapping of break pins 73
SYStem.CONFIG CAN Configure CAN interface 74
SYStem.CONFIG CAN.BaseCLOCK Base clock for CAN interface 74
SYStem.CONFIG CAN.NominalBRP Set CAN nominal baud rate prescaler 75
SYStem.CONFIG CAN.NominalTSEG1 Set CAN nominal Phase_seg1 75
SYStem.CONFIG CAN.NominalTSEG2 Set CAN nominal Phase_seg2 75
SYStem.CONFIG CAN.NominalSJW Set CAN nominal SJW parameter 75
SYStem.CONFIG CAN.DataBRP Set CAN data baud rate prescaler 76
SYStem.CONFIG CAN.DataTSEG1 Set CAN data Phase_seg1 76
SYStem.CONFIG CAN.DataTSEG2 Set CAN data Phase_seg2 76
SYStem.CONFIG CAN.DataSJW Set CAN data SJW 77
SYStem.CONFIG DAP Configure DAP interface 78
SYStem.CONFIG DAP.BreakPIN Define mapping of break pins 78
SYStem.CONFIG DAP.DAPENable Enable DAP mode on PORST 78
SYStem.CONFIG DAP.USERn Configure and set USER pins 79
SYStem.CONFIG.DEBUGPORT Select target interface 80
SYStem.CONFIG.DEBUGPORTTYPE Set debug cable interface mode 80
SYStem.CONFIG DXCM Configure DXCM 81
SYStem.CONFIG DXCM.TXID Control frame message ID 81
SYStem.CONFIG DXCM.TXIDE Control frame format 82
SYStem.CONFIG DXCM.TXFDF Control frame format 82
SYStem.CONFIG DXCM.TXBRS Control the use of baud rate switching 82
SYStem.CONFIG DXCM.RXID Set ID for frames from target 82

SYStem.CONFIG DXCM.RXIDE Expect extended frames from target 83
SYStem.CONFIG DXCPL Configure DXCPL 84
SYStem.CONFIG DXCPL.Timing Configure SPD timing for DXCPL 84
SYStem.CONFIG.EXTWDTDIS Disable external watchdog 84
SYStem.CONFIG PortSHaRing Control sharing of debug port with other tool 85
SYStem.CPU Select CPU 86
SYStem.JtagClock Set the JTAG frequency 87
SYStem.LOCK Tristate the JTAG port 88
SYStem.MemAccess Run-time memory access (non-intrusive) 89
SYStem.Mode Establish the communication with the CPU 90
CPU and Architecture specific SYStem.Option Commands 92
SYStem.Option BREAKFIX Enable workaround for asynchronous breaking 92
SYStem.Option CBSACCEN<x> Cerberus access protection 93
SYStem.Option DCFREEZE Do not modify cache structure 94
SYStem.Option DCREAD Control cache behavior of reads 94
SYStem.Option DSYNC Force data synchronization 95
SYStem.Option DOWNMODE Behavior of SYStem.Mode Down 96
SYStem.Option DUALPORT Implicitly use run-time memory access 96
SYStem.Option DataTrace Enable data tracing 97
SYStem.Option EndInitProtectionOverride Override ENDINIT protection 97
SYStem.Option ETK Debugging together with ETK from ETAS 97
SYStem.Option HeartBeat Bug fix to avoid FPI bus conflict 98
SYStem.Option HoldReset Reset duration 98
SYStem.Option HSMRESTART Restart HSM on connect 99
SYStem.Option ICFLUSH Flush instruction cache at 'Go' or 'Step' 99
SYStem.Option IMASKASM Disable interrupts while single stepping 99
SYStem.Option IMASKHLL Disable interrupts while HLL single stepping 100
SYStem.Option INTSTART Start address of interrupt routines 100
SYStem.Option INTUSE Number of implemented interrupts 100
SYStem.Option JTAGENSEQ Use JTAG initialization sequence 101
SYStem.Option KEYCODE Set debug interface password 101
SYStem.Option KEYCODEWarnNotAccepted Set warning level 101
SYStem.Option LBIST LBIST gap handling 102
SYStem.Option MACHINESPACES Address extension for guest OSes 103
SYStem.Option MAPCACHE Map cache automatically 103
SYStem.Option OCDSELOW Set OCDS line to low 104
SYStem.Option OVC Enable OVERLAY memory access 104
SYStem.Option OVERLAY Enable overlay support 105
SYStem.Option PERSTOP Enable global peripheral suspend 106
SYStem.Option PMILBFIX Enable PMI line buffer invalidation workaround 107
SYStem.Option PostResetDELAY Delay after RESET is released 108
SYStem.Option ReadOnly Block all write accesses 108
SYStem.Option RESetBehavior Set behavior when a reset occurs 109

SYStem.Option ResetDetection Set how hard resets are detected 109
SYStem.Option ResetMode Select reset method 110
SYStem.Option RESetTMS State of TMS line at reset 110
SYStem.Option SLOWRESET Long timeout for resets 110
SYStem.Option SOFTLONG Set 32 bit software breakpoints 111
SYStem.Option STEPONCHIP Step with onchip breakpoints 111
SYStem.Option STEPSOFT Step with software breakpoints 111
SYStem.Option TB1766FIX Bug fix for some TC1766 TriBoards 112
SYStem.Option TRAPSTART Start address of trap vectors 112
SYStem.Option WDTFIX Disables the watchdog on SYStem.Up 112
SYStem.Option WDTSUS Link the watchdog timer to the suspend bus 113
SYStem.RESetOut In-target reset 113
SYStem.state Open SYStem.state window 113
CPU specific TrOnchip Commands ................................................................................. 114

TrOnchip.BreakBusN.BreakIN Configure break pin of 'BreakBus N' 114
TrOnchip.BreakBusN.BreakOUT Configure break pin of 'BreakBus N' 114
TrOnchip.BreakIN.<target> Connect break <target> to BreakBus 115
TrOnchip.BreakOUT.<source> Connect break <source> to BreakBus 115
<source> 116
HaLTEN 116
TrOnchip.CONVert Adjust range breakpoint in on-chip resource 117
TrOnchip.CountX Event X counter value 117
TrOnchip.CountY Event Y counter value 117
TrOnchip.EXTernal Configure TriCore break on BreakBus event 118
TrOnchip.PERSTOPOUT Route suspend signal to pin 118
TrOnchip.RESet Reset settings for the on-chip trigger unit 118
TrOnchip.SoftWare Configure 'TriCore' break on debug instruction 119
TrOnchip.SusSWitch Enable or disable suspend switch 119
TrOnchip.SusSWitch.FORCE Force generation of suspend signal 119
TrOnchip.SusSWitch.Mode Set suspend switch mode 120
TrOnchip.SusTarget Connect special targets to the suspend bus 120
TrOnchip.SYNCHRONOUS Switches mode for data breakpoints 120
TrOnchip.TDelay Trace trigger delay 121
TrOnchip.TExtMode Mode for external trigger input 121
TrOnchip.TExtPol Polarity of external trigger input 121
TrOnchip.TMode Trace mode 121
TrOnchip.TR0 Specify trigger event 0 122
TrOnchip.TR1 Specify trigger event 1 123
TrOnchip.state Show on-chip trigger window 123
TrOnchip.WatchPin Route core trigger to pin 124
TrOnchip.X Select trigger source X 124
TrOnchip.Y Select trigger source Y 125
Technical Data ................................................................................................................... 126

JTAG Connector 126
Trace Connector 128
AMP 40 Connector 128
ERF8 22-pin Power.org Connector 129
Samtec 60 Connector 129
Technical Data for Debugger 131
Operation Voltage 131
Mechanical Dimensions 131
Technical Data for Trace 132
Operation Frequency 132
Operation Voltage 132
Mechanical Dimensions 133
Appendix ............................................................................................................................ 134

Parallel Off-chip Trace - OCDS-L2 Flow Trace (Analyzer) 134
Overview 134
Quick Start for Tracing with OCDS-L2 Trace (Analyzer) 134
Supported Features 135
Version History 136
Timestamp Accuracy 136
Concurrent Usage of OCDS-L2 Off-chip Trace and OCDS-L3 On-chip Trace 137
Simple Trace Control 137
Trace Break Signals (OCDS-L2) 137
Trace Examples 138
Troubleshooting for OCDS-L2 Trace 140
No Data in Trace.List Visible 140
Error Diagnosis 140
Searching for Errors 141
Error Messages 142

TriCore Debugger and Trace
Version 30-Apr-2021
History
11-Jan-21 Added descriptions for the command group SYStem.CONFIG.CAN, and the command
group SYStem.CONFIG.DXCM.
27-Jul-20 Update description of command: SYStem.Option MAPCACHE.
11-May-20 Updated chapter “Accessing Cached Memory Areas and Cache Inspection”.
20-Dec-19 New commands: SYStem.Option DSYNC, SYStem.Option HoldReset.
17-Jul-19 New commands: SYStem.Option MAPCACHE, SYStem.Option SLOWRESET.
28-Jan-19 New command: SYStem.Option EndInitProtectionOverride.

Safety Precautions
Caution: 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:

• Disconnect the debug cable from the target while the target power
is off.
• Connect the host system, the TRACE32 hardware and the debug
cable.
• Power ON the TRACE32 hardware.
• Start the TRACE32 software to load the debugger firmware.
• Connect the debug cable to the target.
• Switch the target power ON.
• Configure your debugger e.g. via a start-up script.
Power down:
• Switch off the target power.
• Disconnect the debug cable from the target.
• Close the TRACE32 software.
• Power OFF the TRACE32 hardware.

Introduction
This document describes the processor specific settings and features for the TRACE32 TriCore debugger.
Please keep in mind that only the Processor Architecture Manual (the document you are reading at the
moment) is CPU specific, while all other parts of the online help are generic for all CPUs supported by
Lauterbach. So if there are questions related to the CPU, the Processor Architecture Manual should be your
first choice.
Brief Overview of Documents for New Users
Architecture-independent information:
• “Debugger Basics - Training” (training_debugger.pdf): Get familiar with the basic features of a
TRACE32 debugger.
• “T32Start” (app_t32start.pdf): T32Start assists you in starting TRACE32 PowerView instances

for different configurations of the debugger. T32Start is only available for Windows.
• “General Commands” (general_ref_<x>.pdf): Alphabetic list of debug commands.
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.
• “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.
• “XCP Debug Back-End” (backend_xcp.pdf): This manual describes how to debug a target over a
3rd-party tool using the XCP protocol.

Available Tools
This chapter gives an overview of available Lauterbach tools for the TriCore architecture.
Debugger
Debugging an Infineon TriCore device requires a

Lauterbach Debug Cable together with a Lauterbach Debug
Module.
To connect to the target the following Debug Cables can be

used:
• Debugger for TriCore Automotive

(DEBUG-TRICORE-AUTO or
DEBUG-MPC-TC-AUTO)
• Debugger for TriCore (Standard)

(OCDS-TRICORE)
The Debug Cable comes with a license for debugging. Detailed information is available in chapter “Debug
Cables” (app_tricore_ocds.pdf). Lauterbach also offers various “Adapter 16-pin 100 mil to 50 mil”
(app_tricore_ocds.pdf).
Furthermore it is required to use a Debug Module from the POWER series, e.g.
• POWER DEBUG INTERFACE / USB 3
• POWER DEBUG INTERFACE / USB 2
• POWER DEBUG PRO
• POWER TRACE / ETHERNET
• POWER TRACE II
The DEBUG INTERFACE (LA-7701) cannot be used for debugging TriCore.
Software-only Debugger for XCP
TRACE32 supports debugging over a 3rd-party tool using the XCP protocol. For details see Parallel Usage
of a 3rd-Party Tool and “XCP Debug Back-End” (backend_xcp.pdf).
On-chip Trace
On-chip tracing requires no extra Lauterbach hardware, it can be configured and read out with a regular
Debugger. The trace related features are enables with the Trace License for TriCore ED (TriCore-MCDS).
Note that only TriCore Emulation Devices (ED) provide an onchip trace buffer.

Serial Off-chip Trace (AGBT)
Lauterbach offers an off-chip trace solutions for AURIX

devices equipped with a serial off-chip trace port (Aurora
Giga-Bit Trace, AGBT).
Tracing requires either the PREPROCESSOR SERIAL

licensed for the TriCore AGBT and a POWER TRACE
module,
or a POWER TRACE SERIAL licensed for the TriCore

AGBT. The TRACE32 online help provides a “PowerTrace
Serial User´s Guide” (serialtrace_user.pdf), please refer to
this manual if you are interested in details about PowerTrace
Serial.
Parallel Off-chip Trace
For devices of the AUDO-NG family, a parallel off-chip trace is available. For more information, see chapter
“Parallel Off-chip Trace - OCDS-L2 Flow Trace (Analyzer)”, page 134.
Co-Processor Debugging (PCP/GTM)
Debugging the Peripheral Control Processor (PCP) or Generic Timer Module (GTM) comes free of charge
with the TriCore debug license, i.e. an additional license is not required.
Details are available in the “PCP Debugger Reference” (debugger_pcp.pdf) and “GTM Debugger and
Trace” (debugger_gtm.pdf) manuals.
Multicore Debugging and Tracing
Lauterbach offers multicore debugging and tracing solutions (particularly for AURIX devices), which can be
done in two different setups: Symmetric Multiprocessing (SMP) and Asymmetric Multiprocessing (AMP). For
details, see “AMP vs. SMP”, page 22.
Multicore debugging can be activated with the License for Multicore Debugging (MULTICORE) in case you
only have a single TriCore license.
AURIX devices can be traced with an On-chip Trace or a Serial Off-chip Trace (AGBT) if a connector is
available on the target.
Software Installation
Please follow chapter “Software Installation” (icd_quick_installation.pdf) on how to install the TRACE32
software:
• An installer is available for a complete TRACE32 installation under Windows.

See “MS Windows” in ICD Quick Installation, page 24 (icd_quick_installation.pdf).
• For a complete installation of TRACE32 under Linux, see “PC_LINUX” in ICD Quick Installation,
page 26 (icd_quick_installation.pdf).
Configuration
System Overview
This figure shows an example of how to connect the TRACE32 hardware to your PC and your target board.
PC or
Workstation
Target
POWER DEBUG USB INTERFACE / USB 3

Debug Cable

USB
Connector
Cable
Debug
POWER DEBUG INTERFACE / USB 3

Related Documents
• “Onchip/NOR FLASH Programming User’s Guide” (norflash.pdf): Onchip FLASH and off-chip
NOR FLASH programming.
• “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf): All about the TriCore debug
cables and available accessories.
• “Debugger Basics - SMP Training” (training_debugger_smp.pdf): SMP debugging.
• “AURIX Trace Training” (training_aurix_trace.pdf): Training for AURIX devices.
• “MCDS User’s Guide” (mcds_user.pdf): Basic and advanced information on the MCDS and the
Infineon Emulation Devices.
• “PCP Debugger Reference” (debugger_pcp.pdf): Debugging and tracing the Peripheral Control
Processor (PCP).
• “GTM Debugger and Trace” (debugger_gtm.pdf): Debugging and tracing the Generic Timer
Module (GTM).
• “XCP Debug Back-End” (backend_xcp.pdf): Debugging over a 3rd-party tool using the XCP
protocol.
Demo and Start-up Scripts
Lauterbach provides ready-to-run start-up scripts for all TriCore chips. Choose File menu > Search for
Script.
In your TRACE32 installation directory there is a subdirectory ~~/demo/tricore/ where you will find
example scripts and demo software. The subdirectory ~~/demo/tricore/ includes:
hardware/ Ready-to-run debugging and flash programming demos for evaluation

boards (e.g. Infineon TriBoard).
Recommended for getting started!
flash/ Binaries for target based programming and example declarations for
internal flash.
etc/ Various examples, e.g. data trace, terminal application, PCP debugging,
MCDS, …
kernel/ Various OS Awareness examples.
compiler/ Compiler examples.
fdx/ Example applications for the FDX feature.

OCDS Levels
OCDS (On-chip Debug Solution) is the on-chip logic that implements the debug, trace and calibration
functionality. Infineon defines three OCDS levels:
• OCDS-L1 refers to the basic debug functionality (execution control, register and memory
access). The 16-pin JTAG connector is often called OCDS-L1 connector.
• OCDS-L2 refers to the (deprecated) parallel off-chip trace. The 40-pin AMP connector and the
60-pin SAMTEC connector for the parallel trace is called OCDS-L2 connector.
• OCDS-L3 is the trace, trigger and calibration functionality in the MCDS. Although defined by
Infineon the term is rarely used. Instead the term MCDS is used. MCDS is accessed by the
debugger via the debug port (JTAG or DAP), the connector for the AGBT high-speed serial trace
is called AGBT connector.
Today the differentiation between the OCDS levels is not very common any more. OCDS refers to the
debugging features and MCDS to the trace- and calibration features. Calibration is not supported by
TRACE32, but TRACE32 cooperates with third-party tools performing calibration.

Debugging
Debugging, as described in this chapter, includes:
• Core debugging (run control, breakpoints)
• Memory and register access
• Trace configuration
• Additional debug features (performance counter, run-time memory access, …)
It is performed via classic JTAG or alternatively via DAP.
This chapter covers the following topics:
• “Single-Core Debugging (AUDO)”, page 16
• “Multicore Debugging (AURIX)”, page 18
• “Access Classes”, page 25
• “Flash”, page 29
• “Onchip Triggers (TrOnchip Window)”, page 31
• “Internal Break Bus (JTAG)”, page 55
• “Suspending Peripherals”, page 54
• “Assembler and Disassembler Options”, page 45
• “Parallel Usage of a 3rd-Party Tool”, page 46
• “Internal Break Bus (JTAG)”, page 55
• “Troubleshooting”, page 56
• “FAQ”, page 53

Single-Core Debugging (AUDO)
This chapter introduces a typical start-up sequence for single-core debugging. Depending on your
application not all steps might be necessary. The example shown uses a TC1766 B-Step on an Infineon
TriBoard-TC1766.
For other chips and more examples, see the chapter Demo and Start-up Scripts.
Single-Core Debugging - Quick Start

1. Prepare the start.
To prevent damage please take care to follow this sequence all the time
you are preparing a start.
- Connect the Debug Cable to your target. Check the orientation of the connector. Pin 1 of the
Debug Cable is marked with a small triangle next to the nose of the target connector.
- Power up your TRACE32 system.
- Start the TRACE32 Debugger Software for TriCore.
- Power up your target.
2. Inform TRACE32 which chip you want to debug.
SYStem.CPU TC1766
3. Establish the communication between the debugger and your target chip.
SYStem.Up
This command resets the chip and enters debug mode. After this command is executed, it is possible
to access memory and registers.
4. Load your application program.
Data.LOAD.Elf myprog.elf
The sub-command of the Data.LOAD command (here, Elf) depends on the file format generated by
the compiler. A detailed description of the Data.LOAD command is given in “General Commands
Reference”.
If your application runs from FLASH, FLASH programming has to be enabled before the Data.LOAD
command is used. Scripts that enable FLASH programing can be found in
~~/demo/tricore/flash.

5. Write a start-up script.
It is recommended to prepare a start-up script that performs the start-up sequence of the commands.
This sequence can be written to a PRACTICE script file (*.cmm, ASCII format) and executed with the
command DO <file>.
Here is a typical start sequence:
WinCLEAR ; clear all windows
SYStem.RESet
SYStem.CPU TC1766 ; select CPU
SYStem.Up ; reset the target and enter debug

; mode
Data.LOAD.Elf myprog.elf ; load the application
List.auto ; open a source listing *)
Register.view /SpotLight ; open register window *)
Frame.view /Locals /Caller ; open the stack frame with

; local variables *)
Var.Watch %Spotlight flags ast ; open watch window for variables *)
PER.view ; open window with peripheral

; register *)
Break.Set main ; set breakpoint to function main
*) These commands open windows on the screen. The window position can be specified with the WinPOS
command.

Multicore Debugging (AURIX)
• “SMP Debugging - Quick Start”, page 18
• “AMP Debugging - Quick Start”, page 20
• “AMP vs. SMP”, page 22
• “Selecting the right AURIX CPU”, page 23
• “Understanding Multicore Startup by Application Code”, page 23
• “About Ambiguous Symbols”, page 24
SMP Debugging - Quick Start

1. Inform TRACE32 which chip you want to debug.
SYStem.CPU TC275TE
2. Inform TRACE32 which cores form the SMP system.
Select the cores you want to debug. Do this with the CORE.ASSIGN command before running the
SYStem.Up command, e.g.:
CORE.ASSIGN 1. 2. 3. ; assign cores to an SMP

; system
3. Establish the communication between the debugger and all cores of the SMP system.
SYStem.Up
This command resets the chip and enters debug mode. After reset only TC 1.6.1 CPU0 is ready, TC
1.6.1 CPU1 and TC 1.6.1 CPU2 have to be initialized by code running on TC 1.6.1 CPU0.
4. Convenient debugging
The command CORE.select allows to switch between cores (also visible and changeable via the
“State Line” (ide_user.pdf)). Many commands also offer the option /CORE <core>, e.g.:
CORE.select 0. ; select core 0

Register.view ; view registers of
; currently selected core
; i.e. core 0
Register.view /CORE 1. ; view registers of core
; 1

5. Summary
Refer to the SMP demo scripts for details, e.g.:
PSTEP tc275te_smp_demo_multisieve.cmm
The above script above can be found in ~~/demo/tricore/hardware/triboard-tc2x5/tc275te.
Copy the demo script and adjust it to your needs to get started with your own application in SMP
mode.

AMP Debugging - Quick Start
Master-Slave Script Concept
For AMP it is recommended to write one start-up script, which is intended to run on the “master” GUI
controlling the “slave” GUIs via InterCom commands.
Hint: Setting up user-defined commands with ON CMD improves readability, e.g.:
; startup_script.cmm running on GUI0:

&addressGUI2="127.0.0.1:20002" ; address and port of
; GUI2
ON CMD CORE2 GOSUB ; define command “CORE2”
(
LOCAL &params
ENTRY %Line &params
InterCom.execute &addressGUI2 &params ; execute command on
; remote GUI
RETURN
)
CORE2 PRINT "executed on core 2" ; use the user-defined
; command: text will be
; printed on GUI2
1. Start the TRACE32 PowerView GUIs
To set up an AMP multicore debugging scenario, multiple TRACE32 instances (GUIs) need to be started.
Please make sure InterCom is enabled and the “File config.t32” (installation.pdf) contains:
CORE=<integer> ; e.g. CORE=1
IC=NETASSIST ; enable InterCom

PORT=<port_number> ; e.g. PORT=20000
For details on “CORE=”, please refer to “Config file settings for single device solution” in ICD Debugger
User’s Guide, page 21 (debugger_user.pdf).
For details on InterCom, please refer to “Config file settings for both single and multi device
solutions” in ICD Debugger User’s Guide, page 22 (debugger_user.pdf).

2. Set up the Multicore Environment
After starting the TRACE32 PowerView GUIs, each instance assumes to be connected to a separate chip by
default. Mounting the cores into the same chip makes TRACE32 aware of the resources to be shared
between the cores. This is especially important for multicore synchronization and shared resources like the
on- and off-chip trace (MCDS, AGBT).
Before bringing the system up, use the SYStem.CONFIG.CORE command on each GUI to mount all cores
into one chip, e.g.:
CORE0 SYStem.CONFIG CORE 1. 1. ; GUIO: core 0 in chip 1

CORE1 SYStem.CONFIG CORE 2. 1. ; GUI1: core 1 in chip 1
CORE2 SYStem.CONFIG CORE 3. 1. ; GUI2: core 2 in chip 1
3. Synchronize Go / Step / Break
The SYnch command allows for start stop synchronization between multiple GUIs. For details, please refer
to “Start Stop Synchronisation” in ICD Debugger User’s Guide, page 34 (debugger_user.pdf).
4. Summary
All steps described above are included in the AMP multisieve demo scripts, e.g.:
; step through AMP demo script

PSTEP tc275te_amp_demo_multisieve.cmm
Copy the demo script and adjust it to your needs to get started debugging your own application in AMP
mode.
The above script above can be found in ~~/demo/tricore/hardware/triboard-tc2x5/tc275te.

AMP vs. SMP
For multicore debugging and tracing, TRACE32 supports two different setups:
• Symmetric Multiprocessing (SMP)
- Homogeneous (e.g. three TriCore CPUs)
• Asymmetric Multiprocessing (AMP)
- Homogeneous AMP (e.g. three TriCore CPUs)
- Heterogeneous AMP (e.g. TriCore, GTM, HSM CPUs)
The following table gives an overview of the differences between SMP and AMP:
SMP AMP
One GUI Multiple GUIs
Controls all cores at Control cores individually.

the same time.
Cores are GUIs can be synchronized (Go/Step/Break/SystemMode), see SYnch /

automatically InterCom
synchronized, i.e. all
cores will run at the
same time and halt at
the same time.
Same onchip Individual onchip breakpoints per core

breakpoints on each
core
Recommended for Required for heterogenous systems, e.g. debugging TriCore concurrently
RTOS (esp. with with GTM core
dynamic core/thread
assignment)
More: “SMP More: “AMP Debugging - Quick Start”, page 20

Debugging - Quick
Start”, page 18
The debug concept is explained in

www.lauterbach.com/publications/debugging_amp_smp_systems.pdf.
To get started with a new AURIX target, we recommend to start with our “Demo and Start-up Scripts”,
page 13. (~~/demo/tricore/hardware/):
PSTEP ~~/demo/tricore/hardware/*.cmm ; step through a demo

; script

Selecting the right AURIX CPU
An AURIX CPU can be selected with the SYStem.CPU command as usual. Please note that for all TC27x
devices there are two variants available per device. Devices with the -Astep suffix reflect the major silicon
stepping “A”. When using a device with another major stepping, select a CPU without the -Astep suffix.
The following table gives some examples:
SYStem.CPU TC275TE-Astep ; e.g. TC277TE-64F200S AA EES
SYStem.CPU TC275TF ; e.g. TC275TF-64F200W BC EES
SYStem.CPU TC275TP ; e.g. TC275TP-64F200W CA EES
SYStem.DETECT.CPU ; Detect the device automatically
PRINT CHIP.STEPping() ; Stepping is available with a

; function (for scripting)
The connected device can be detected automatically with SYStem.DETECT.CPU.
Understanding Multicore Startup by Application Code
After bringing the system up (SYStem.Up), all cores are halted at their respective reset vector.
When starting program execution (Go), at first only core 0 will start running application code (your
application). The other “slave” cores are yet not initialized, i.e. it is not possible to start them as long as their
Program Counter is at the reset vector. TRACE32 indicates this with the special state “running (reset)” or
“stopped at reset vector” in the state line.
The other “slave” cores will switch to a special state “running (reset)”, waiting to be initialized and started by
core 0. When the debugger detects that the slave cores were initialized and started by core 0, it will switch to
“running” state in the state line.
Debugging and tracing is possible right from the reset vector.

About Ambiguous Symbols
Each TriCore core of an AURIX chip is equipped with directly attached memories: Program Scratch Pad
Ram (PSPR) and Data Scratch Pad Ram (DSPR), accessible by itself via core-local and global addressing,
accessible by other cores via global addressing.
When accessing its own memory, accessing via global addresses has no (!) impact on access speed.
When having different code and therefore different symbols on each core, core-local addressing can easily
lead to ambiguous symbols. Imagine a function “foo” at address P:0xC0000100 on core 0 and a completely
different function “bar” at address P:0xC0000100 on core 1.
Using global addressing avoids such ambiguities, in the above example “foo” would be at address
P:0x70100100 and “bar” at P:0x60100100. The following table illustrates the differences:
e.g. PSPR on TC275TE Global addressing Core-local addressing
Core 0 P:0x70100000 P:0xC0000000
Core 1 P:0x60100000 P:0xC0000000
Core 2 P:0x50100000 P:0xC0000000
Summary Unambiguous addresses Ambiguous addresses (!)
In general, we strongly recommend to use global addressing only, avoid core-local-addressing whenever
possible. You might have to modify the linker script file in your compiler tool chain.

Access Classes
For background information about the term access class, see “TRACE32 Glossary” (glossary.pdf).
For TriCore, the following memory access classes are available:
Memory Access Description

Class
P Program (memory as seen by CPU’s instruction fetch)
D Data
EEC Emulation Memory on EEC

Only available on TriCore Emulation Devices for accessing the Emulation
Extension Chip.
IC Instruction Cache
DC Data Cache (memory as seen by CPU’s data access)
NC No Cache (access with caching inhibited)
P: and D: display the same memory, the difference is in handling the symbols.
Prepending an E as attribute to the memory class will make memory accesses possible even when the CPU
is running. See SYStem.MemAccess and SYStem.CpuAccess for more information.
SYStem.Option DUALPORT will enable the runtime update of almost all windows so memory class
attribute E is not necessary. Although the core is not stopped for accessing the memory this can slow down
program execution since the CPU and debugger both access the on-chip buses.
With SYStem.Option DCREAD ON all data memory accesses (D:) will be redirected cached data memory
accesses (DC:). For details, see “Accessing Cached Memory Areas and Cache Inspection”, page 41.

Breakpoints
TRACE32 uses two techniques to implement breakpoints: Software breakpoints and on-chip breakpoints.
Software Breakpoints
Software breakpoints are only available for program breakpoints. If a program breakpoint is set to an
instruction, the original instruction at the breakpoint location is patched by a break code. This patching is the
reason why software breakpoints are usually only used in RAM areas.
Software breakpoints in FLASH memory are also supported (see FLASH.AUTO in “General Commands
Reference Guide F” (general_ref_f.pdf), chapter FLASH), but their use is not recommended since they
drastically reduce the FLASH’s lifetime.
On-chip Breakpoints
• On-chip breakpoints: Total amount of available on-chip breakpoints.
• Instruction breakpoints: Number of on-chip breakpoints that can be used to set program
breakpoints into FLASH/ EEPROM.
• Read/write breakpoints: Number of on-chip breakpoints that can be used as read or write
breakpoints.
• Data breakpoint: Number of on-chip data breakpoints that can be used to stop the program
when a specific data value is written to an address or when a specific data value is read from an
address.
On-chip Instruction Read / Write Data

Breakpoints Breakpoints Breakpoints Breakpoints
(up to AUDO-FG)
up to 4 instruction, up to 4 single or up to 4 single or —

up to 4 read/write up to 2 ranges up to 2 ranges
(AUDO-MAX,
AURIX)
up to 8 up to 8 single up to 8 single —
address or address or
up to 4 ranges up to 4 ranges
You can view your currently set breakpoints with the command Break.List.
If no more on-chip breakpoints are available, you will get an error message when trying to set one.

Intrusive Breakpoints
TRACE32 PowerView uses so-called intrusive breakpoint to implement a breakpoint, if the core in use
does not provide the means to set a complex breakpoint.
; stop the program execution at the 1000. call of the function sieve
Break.Set sieve /Program /COUNT 1000.
; stop the program execution if the byte 0x0 is written

; to the variable flags[3]
Var.Break.Set flags[3] /Write /DATA.Byte 0x0
Note Only one intrusive breakpoints can be set on read/write breakpoints.
MAP.BOnchip Command
Previously it was necessary to inform the debugger about the location of read-only memory on the target.
This allows the debugger to automatically use on-chip breakpoints. Meanwhile, the debugger automatically
sets Onchip breakpoints when read-only memory is detected. Today the command MAP.BOnchip
<address_range> is rarely used.
Advanced Breakpoints
When using an Infineon Emulation Device, the MCDS part of the Emulation Extension Chip allows to set
advanced breakpoints. Please refer to the “MCDS Breakpoints” in MCDS User’s Guide, page 26
(mcds_user.pdf) for details.

Single Stepping
OCDS does not offer a single-stepping feature so this has to be emulated by the debugger. We differentiate
between single-stepping on assembler level and single-stepping on HLL level.
Assembler Level
For single-stepping on assembler level, use the Step.Asm command. An assembler level single-step is
performed by default in mixed or assembler mode.
Use SYStem.Option IMASKASM to control whether interrupts should be enabled during single-stepping.
On-chip Breakpoint Ranges (Default)
By default, the TriCore uses on-chip breakpoint ranges for implementing single-stepping. This allows the
detection of exceptions (interrupts, traps) or any abnormal program execution.
SYStem.Option STEPSOFT and SYStem.Option STEPONCHIP both have to be disabled (OFF) for
activating the default behavior.
Software Breakpoints
With SYStem.Option STEPSOFT one or two software breakpoint instructions are used for single-stepping.
This is required when the Memory Protection Unit shall be used for memory protection. Note that software
breakpoints can also be used in FLASH memory. A special setup is required for this to work.
As side effect, the interrupt handler may run silently in the background without the user noticing. So data
required for the current function may change while stepping, thus resulting in a different behavior.
On-chip Breakpoint
With SYStem.Option STEPONCHIP an on-chip breakpoint with Break-After-Make is used for single-
stepping.
This is mainly used as a workaround for a silicon bug (CPU_TC.115) which prevents a proper suspend of an
already taken interrupt. As a result, the interrupt handler will run silently in the background without the user
noticing. So data required for the current function may change while stepping, thus resulting in a different
behavior.
In case SYStem.Option STEPSOFT is enabled at the same time, SYStem.Option STEPONCHIP will have
no effect.
HLL Level
For single-stepping on HLL level, use the Step.Hll command. An HLL level single-step is performed by
default in HLL mode.
Use SYStem.Option IMASKHLL to control whether interrupts should be enabled during single-stepping.
There are no options to configure the behavior, the debugger will always choose the correct implementation
depending on the kind of memory.
Flash
Programming the flash memory is explained in detail in chapter “FLASH” (general_ref_f.pdf). This chapter
will only give a short overview.
TriCore devices can be efficiently programmed with target controlled flash algorithms. They require a flash
declaration, which can be found in the ~~/demo/tricore/flash/directory of the TRACE32 installation.
After the flash is declared, TRACE32 offers three approaches:
• FLASH.Erase and FLASH.Program
• FLASH.Auto
• FLASH.ReProgram (recommended)
Flashing an application typically follows these steps:
1. Prepare flash programming (declarations)
- Using FLASH.Create commands
- Or using provided scripts in ~~/demo/tricore/flash/
2. Enable flash programming using FLASH.ReProgram ALL.
3. Load an application usingData.LOAD <file>.
4. Finally program the flash using FLASH.ReProgram off.
All these steps, including device-specific declarations, are provided in the flash demo scripts. Use
PSTEP ~~/demo/tricore/flash/tc*.cmm ; run flash script
for a comprehensive step-by-step procedure.

Flashing and Debugging AURIX Devices
General help for flashing is available in chapter “FLASH” in General Commands Reference Guide F, page
22 (general_ref_f.pdf).
AURIX devices have several security features. Be careful not to lock yourself
out when flashing a device!
• Boot Mode Headers (BMHD):

Do not reboot or unpower your device in case all BMHD (Boot Mode
Headers) do not contain valid information. This is normally the case
after having erased the internal program flash or loading an object or
binary file without a valid BMHD.
• Hardware Security Module (HSM):

Do not enable HSM boot when no valid HSM code is present. This will
lock your device permanently. See also “Flashing the Hardware
Security Module (HSM)”, page 31.
• User Configuration Blocks (UCB):

Pay special attention when modifying the UCB. An invalid or
erroneous content will lock your device permanently. This also
happens in case the confirmation code is neither “unlocked” nor
“confirmed”.
The onchip flash on AURIX devices has three states: 0, 1 and Bus Error.
By default, an erased flash sector returns a Bus Error on read access, indicated as “????????” in a
Data.dump window. It is caused by an ECC error in the chip, which can be changed with the
FLASH0_MARP.TRAPDIS and FLASH0_MARD.TRAPDIS register fields.
If you prefer to have an erased flash set to zero, simply run Data.Set <range> %Long 0x0 before loading
your application, e.g.:
FLASH.ReProgram 0xA0080000-- ; Activate flash region

0xA009FFFF /Erase ; for programming
Data.Set 0xA0080000--0xA009FFFF %Long 0x0 ; set to zero
Data.LOAD.Elf myapp.elf ; load ELF file
FLASH.ReProgram off ; Erase and program

; modified region
To make sure that another core is not intervening while flashing, it is recommended to switch to single-core
debugging before flashing an application. All required steps are demonstrated in the flash script, e.g. in
~~/demo/tricore/flash/tc27x.cmm:
DO ~~/demo/tricore/flash/tc2*.cmm ; run flash script

After flashing the application, a multicore debug scenario can be started as usual.
Hint: Use the option /NoCODE of the Data.LOAD command to load only the symbols (without downloading
code), e.g.:
Data.LOAD.elf my_application.elf /NoCODE ; Load just the symbolic

; information of an al-
; ready flashed appli-
; cation
Flashing the Hardware Security Module (HSM)
When flashing the HSM, use the same precautions as described in “Flashing and Debugging AURIX
Devices”, page 30.
The HSM can be flashed with the scripts ~~/demo/tricore/flash/tc2*-hsm.cmm:
DO ~~/demo/tricore/flash/tc2*-hsm.cmm ; run flash script
Do not enable HSM boot when no valid HSM code is present. This will lock your
device permanently. See the Infineon documentation and contact your Infineon
FAE for more information on HSM.
Onchip Triggers (TrOnchip Window)
Onchip triggers can be influenced with the TrOnchip.view window. It affects primarily “On-chip
Breakpoints”, page 26, and allows to control the Multi-Core Break Switch (MCBS) providing two internal
Break Buses and a Suspend Switch.
See the TrOnchip commands for more information.

BenchMarkCounter
Benchmark counters are on-chip counters that count specific hardware events, e.g., the number of executed
instructions. This allows to calculate typical performance metrics like clocks per instruction (CPI).The
benchmark counters can be read at run-time.
TriCore CPUs support three different types of benchmark counters:
• Performance counters in the core debug controller of each core. These counters are available in
AUDO MAX and AURIX CPUs.
- Clock counter CCNT.
- Instruction counter ICNT.
- Multi counters M1CNT, M2CNT, M3CNT that can be configured to count specific events, e.g.,
cache hits and misses. The available events depend on the used device.
• Event Counters in the OTGS. These counters are only available for AURIX and later devices.
These counters can capture events generated by breakpoints with action alpha, beta, charly,
delta or echo.
• Event counters in the MCDS. These counters are only available in emulation devices. For AUDO
CPUs these counters are named CNT0 to CNT15. For AURIX CPUs these counters are named
PMN0 to PMN31. Refer to “Benchmark Counters” in MCDS User’s Guide, page 50
(mcds_user.pdf) for more information.
In TRACE32, these benchmark counters can be programmed through the BMC.state window.
Performance counters and event counters of TriCore CPUs can be started or stopped using on-chip
breakpoints. This A-to-B mode allows to determine performance metrics for a single code block. This mode
is available for AUDO MAX CPUs with a TC1.6 core and all AURIX CPUs.
A B C
A Enable or Disable A-to-B mode. In A-to-B mode only events between the Alpha and Beta marker
are counted. See BMC.<counter>.ATOB.
B Defines the BenchMarkCounter trigger value. See BMC.<counter>.TRIGVAL.
C Enables/disables the BenchMarkCounter trigger. See BMC.<counter>.TRIGMODE.

Example: Measuring Instructions and Stalls per Clock Cycle
This example explains how to measure the number of instructions [A] and the stalls per clock cycle [B].
The analysis can be set up in the BMC.state window:
A
or using the following commands in PRACTICE:
BMC.CLOCK 100.Mhz ; Set the BMC Clock

BMC.ICNT.EVENT ON ; Set the Events
BMC.M1CNT.EVENT IP_DISPATCH_STALL
BMC.M2CNT.EVENT LS_DISPATCH_STALL
BMC.M3CNT.EVENT DMEM_STALL
BMC.ICNT.RATIO X/CLOCK ; Set the counters RATIO
BMC.M1CNT.RATIO X/CLOCK

Example: A-to-B Mode (single shot)
In the following example, the runtime of the function sieve() is measured, and the instructions executed
during runtime are counted. The result is displayed in the BMC.state window.
Alpha breakpoint
Break.Set sieve /Program /Alpha
Instructions are only counted in

this range.
Beta breakpoint
Break.Set sYmbol.EXIT(sieve)-2
/Program /Beta
A-to-b mode active
Runtime
This example can be set up using the following PRACTICE script.
CLOCK.ON
Break.Set sieve /Program /Alpha
Break.Set sYmbol.EXIT(sieve)-2 /Program /Beta
Break.Set sYmbol.EXIT(sieve)
BMC.ICNT.EVENT ON
BMC.ICNT.ATOB ON
It is not possible to have different A-to-B mode settings for the counters of the core debug controller.
Executing the command for one of the counters will automatically set the state for the other counters.
For the performance counters of the core debug controller, the alpha and beta marker must not overlap with
another breakpoint.

Example: A-to-B Mode (average)
Starting from AURIX devices and release R.2020.02, average runtimes can be measured using a
combination of the performance counters in the core debug controller and the event counters in the OTGS.
In the following example, the average runtime of the function sieve() is measured. The result is displayed
in the BMC.state window.
CLOCK.ON
Break.SetFunc sieve
BMC.ICNT.EVENT ON
BMC.ICNT.ATOB ON
BMC.OTGSC0.EVENT Alpha
BMC.OTGSC0.RATIO TIME/X
; measure for one second

Go
WAIT 1.s
Break
BMC.state
Result:
A complex example recording the results in BTrace can be found in the demo folder under
~~/demo/tricore/etc/bmc.

Example: Record Counters Periodically
The TRACE32 SNOOPer trace can be used to record the event counters periodically, if the target system
allows to read the event counters while the program execution is running.
BMC.state ; display the BMC configuration

; window
BMC.M1CNT.EVENT DATA_X_HIT ; count data cache / data buffer

; hits
BMC.M2CNT.EVENT DATA_X_CLEAN ; count data cache / data buffer

; misses
BMC.SnoopSet ON ; configure the TRACE32 SNOOPer

; trace for event counter recording
Go ; start the program execution to

; fill the SNOOPer trace
Wait 1.s
Break ; stop the program execution
SNOOPer.PROfileChart.COUNTER %Up ; display a profile statistic

M1CNT M2CNT M3CNT
The SNOOPer.List and SNOOPer.PROfileChart.COUNTER commands allow to specify the counters you
want to display.

Watchpins
Watchpins can be used to pulse a physical output pin on the target or on the debugger when a special
breakpoint is hit (without halting the cpu). The breakpoints use the action /WATCH. Watchpins are especially
useful for analyzing the timing of an application.
Watchpins use the on-chip logic of the chip. Thus, they differ between AUDO and AURIX devices.
AUDO
To set up watchpins on AUDO devices, first set the watch-breakpoint, then route the watch event to an
output pin using the TrOnchip.BreakBus feature, e.g.:
Break.Set sieve /WATCH ; set WATCH breakpoint

TrOnchip.BreakBus0.BreakOUT Enable ; route to pin
See the chapter “CPU specific TrOnchip Commands”, page 114 for details.
NOTE: The GPIO pins are not driven automatically, they have to be configured manually.
AUDO devices do not allow to set Alpha/Beta/Charly/Delta/Echo breakpoints as watchpoints (as opposed to
AURIX devices.
AURIX
AURIX devices can pulse up to eight different output pins, for details see chapter “Features and
Restrictions”, page 39.
Setup
Setting up watchpins on AURIX devices requires three basic steps:
1. Setting the breakpoint
2. Routing to the pin
3. Changing the speedgrade
All these steps are also shown in a demo script:
PSTEP ~~/demo/tricore/etc/watchpins/aurix_watchpin.cmm

1. Setting the breakpoint:
Set a breakpoint with action watch, e.g.:
Break.Set sieve /WATCH ; set WATCH breakpoint
2. Routing to the pin:
The watch event can be routed to an output pin using the TrOnchip.WatchPin feature, e.g.:
TrOnchip.WatchPin.WATCH.Pin0 ; route to pin
NOTE: Enabling WatchPins automatically enables the respective pin as Trigger Output Pin
(overriding user configuration), so make sure not to use the GPIO pin for something
else at the same time.
AURIX devices allow to set additional watchpoints using the Alpha/Beta/Charly/Delta/Echo breakpoints (as
opposed to AUDO devices), e.g.:
Break.Set sieve /ALPHA ; set WATCH breakpoint

TrOnchip.WatchPin.ALPHA.Pin1 ; route to pin
For a sample pin mapping see chapter “Features and Restrictions”, page 39.
3. Changing the speedgrade:
In order to see short pulses (i.e. watch breakpoints on single addresses or on an address range with only a
few hundred instructions) the speed grade of the respective GPIO pin has to be changed manually.

This can be done either by command, e.g.:
; set P20_PDR0.PD0 to "Speed Grade 1" (Pad Driver Mode for Port 20 Pin 0)
PER.Set D:0xf003c040 (Data.Long(D:0xf003c040)&(~0x7))
Or in the peripheral window, e.g.:
Features and Restrictions
In general there are 8 output pins. Please be aware that they might be used for a different purpose already.
For example, it might not be a good idea to use Pin3, which is used for the TDO/DAP2.
Sample pin mapping (See Infineon documentation for details):
Pin Package Pin Note
Pin0 P20.0 /BRKOUT
Pin1 P20.1 /BRKIN
Pin2 P21.6 (TDI)
Pin3 P21.7 (TDO, DAP2)
Pin4 P32.6
Pin5 P32.7
Pin6 P33.14
Pin7 P33.15
There is a maximum of 4 watch breakpoints per core, i.e. 12 watch breakpoints for a device with three cores.

The most restrictive part is the availability of the internal lines for routing the watch breakpoints. There are 7
lines, but some of them are already preoccupied:
• Two of them are already occupied internally
• One line is occupied per core
So there are 2-4 lines still available to be routed dynamically (e.g. 4 lines available for a single-core
device, 2 lines when multi-core debugging a device with three cores). TRACE32 tries to find an optimal
routing.
To sum up, at most 4 different pins can be used at the same time. Still, multiple watch breakpoints can be
routed to the same output pin. This might be especially useful when no more resources are available.

Accessing Cached Memory Areas and Cache Inspection
Most AURIX devices and some AUDO devices have data caches as well as instruction caches. There is one
cache per CPU and these caches are located between the CPU and the system bus. The CPU will use this
cache for certain address ranges only. These address ranges are referred to as cached memory areas in the
following.
If a CPU with active cache modifies data in a cached memory area (e.g., the LMU). This modification will be
first stored to it’s local cache only. It will be written back to memory if explicitly requested by the CPU or
implicitly when the cache line shall be reused.
Normally, TRACE32 will access memory using the system bus. This will bypass the caches. When you, e.g.,
view data that is currently cached by a CPU, this will lead to a difference in the data displayed by the
debugger and the data seen by the CPU. TRACE32 provides the following methods to view the correct data:
• Use access class “DC”. For example, the data at address 0x90040000 (LMU of TC39x) can be
displayed using the command
Data.dump DC:0x90040000
• Set SYStem.Option DCREAD ON to display the correct cached data when using access class “D”.
This access class is used by default for all data accesses. This is especially useful when displaying
variables in the Var.Watch / Var.View window, because they will then be displayed from the CPUs
point of view.
The exact behavior differs between AUDO (TC1xxx) and AURIX (TC2xx and later) CPUs and is described
below.
A similar issues occurs when TRACE32 tries to write data in a memory area that is currently cached by a
CPU. An access through the system bus will only update the memory but not the data cached by the CPU.
TRACE32 provides different methods to handle this. This is also described below.
Please note, that it is not possible to access cached memory areas while the CPU is running. In this case,
physical memory is accessed.
In some use cases (e.g., performance optimization) the exact cache state is of interest. In the following this is
referred to as cache inspection. The corresponding commands can be found in the CACHE command
group. For TC2xx and later devices this is subject to certain constraints that are described below.
AUDO Devices
• Reads using access class “DC” will always evaluate the cache tags to present the cached data if
applicable.
• Writes using access class “DC” will first flush the respective cache lines and then write the new
values to memory.
• Reads using access class “D” with SYStem.Option DCREAD ON will be redirected to access
class “DC”.
• Write using access class “D” with SYStem.Option DCFREEZE OFF will be redirected to access
class DC.
Cache inspection is always possible.

AURIX Devices
This section does not apply to early AURIX devices (TC27x-Astep, TC2Dx). These behave like AUDO
devices.
TC1.6E (efficiency) cores implement a small data read buffer instead of a data cache. The data read buffer is
not accessible by TRACE32.
For TC1.6P and TC1.6.2 cores TRACE32 provides two different methods how cached memory areas can
be accessed:
• cache evaluation method: this method will evaluate the cache tags and content to reconstruct the
cached memory area.
• target code method: this method will execute code on the CPU to read or write cached memory
areas.
The cache evaluation method can only be used when certain constraints are fulfilled. This is explained in the
following.
CPU Constraints for Cache Evaluation and Cache Inspection
The cache evaluation method as well as cache inspection require that TRACE32 is able to read out the
cache tags and contents. AURIX CPUs allow reading this by mapping the cache into the CPU address
space using the MTU. As soon as the cache is mapped by TRACE32, the CPU will clean the cache content
due to security reasons. In addition, this might be reported to other units as security/safety alarm. This has
the following implications:
• The cache must only be mapped when the cache is empty. Otherwise data might be lost.
• The cache must stay mapped during the complete debug session.
• In some use-cases mapping the cache might not be possible at all.
This is considered by TRACE32 as follows:
• SYStem.Option MAPCACHE controls if TRACE32 will map the cache at all. By default it is
activated (ON).
• TRACE32 will map the cache only if SYStem.Option MAPCACHE ON and the cache is known to
be empty. This is the case after the following commands: SYStem.Up, CACHE.INVALIDATE IC,
CACHE.INVALIDATE DC, CACHE.FLUSH DC.
• TRACE32 will unmap the cache only if executing SYStem.Option MAPCACHE OFF.
This implies that the cache is not mapped after connecting to the device using SYStem.Mode.Go,
SYStem.Mode.Attach and after power losses or external resets while SYStem.Option RESetBehavior
RunRestore is set. In this case, the cache can be manually mapped by halting the CPU and executing
CACHE.INVALIDATE DC, CACHE.FLUSH DC and/or CACHE.INVALIDATE IC.
Due to the internal architecture of the CPU (e.g. usage of the store buffers), stores might not become visible
outside the CPU until an isync or dsync instructions is executed. The latter can be done automatically by
TRACE32. Please see SYStem.Option DSYNC for further details.

Reading and Writing using Cache Evaluation Method
This method will evaluate the cache tags to display and modify the cached data where applicable. This has
the advantage that the cache structure (i.e., which memory content is cached) does not change.
On writes, the corresponding physical memory will be modified in parallel. This is done to avoid marking
the cache line as dirty and thus triggering writebacks that will not occur during normal operation.
This method requires a mapped cache. Please see the previous section for more details.
TRACE32 will potentially use this method if SYStem.Option MAPCACHE ON.
In particular:
• Reads and writes using access class “DC” will always use this method. In case the cache is not
mapped an error will be returned.
• Reads using access class “D” with SYStem.Option DCREAD ON will first evaluate the core
configuration with respect to cache bypass and physical memory attributes. In case the cache is
relevant for the current access, it will use the cache evaluation method. Otherwise physical
memory is accessed directly. In case the cache is not mapped an error will be shown and physical
memory will be accessed.
• Writes using access class “D” will first evaluate the core configuration with respect to cache
bypass and physical memory attributes. In case the cache is relevant for the current access it will
use the cache evaluation method. Otherwise physical memory is accessed directly. In case the
cache is not mapped an error will be shown and physical memory will be accessed.
Reading and Writing using Target Code Method
This method implements reads and writes by executing appropriate code on the CPU. This has the
advantage that the result always matches the CPU view. This method will modify the cache structure (i.e.,
which memory content is cached) and trigger additional writebacks. The effort for this method is
considerably higher since the CPU state and some target memory needs to be saved and restored.
TRACE32 will potentially use this method if SYStem.Option MAPCACHE OFF:
In particular:
• Reads and writes using access class “DC” will always use this method.
• Reads using access class “D” with SYStem.Option DCREAD ON and SYStem.Option
DCFREEZE OFF will first evaluate the core configuration with respect to cache bypass and
physical memory attributes. In case the cache is relevant for the current access it will use the
target code method. Otherwise physical memory is accessed directly.
• Writes using access class “D” with SYStem.Option DCFREEZE OFF will first evaluate the core
configuration with respect to cache bypass and physical memory attributes. In case the cache is
relevant for the current access it will use the target code method. Otherwise physical memory is
accessed directly.
For further details about target code execution, see “Target Code Execution”, page 55.

Use Case: No cache used
Set SYStem.Option MAPCACHE OFF in case of unwanted security/safety alerts or concerns about the
cache being mapped in the CPU access space.
Use Case: Cache used, Cache Mapping Possible
Leave SYStem.Option MAPCACHE ON to use cache evaluation method.
Consider setting SYStem.Option DCREAD ON for correct display of variables. Consider setting
SYStem.Option DSYNC ReadWrite to ensure no data remains in the CPU.
In case you experience problems with unwanted security/safety alerts, see “Use Case: Cache used,
Cache Mapping Not Possible”, page 44
Use Case: Cache Inspection
In case you want to analyze the cache behavior of your application, the cache must be mapped. This means
SYStem.Option MAPCACHE ON is required.
Use Case: Cache used, Cache Mapping Not Possible
In case you experience problems with unwanted security/safety alerts or you are concerned about the cache
being mapped in the CPU access space, use target code method. This means set SYStem.Option
MAPCACHE OFF and SYStem.Option DCFREEZE OFF.
Consider setting SYStem.Option DCREAD ON for correct display of variables.

Assembler and Disassembler Options
By default, the disassembler displays all opcodes as defined by Infineon (Simple). Alternatively the 16-bit
opcodes can be marked with a “16” tag to identify them more easily (Generic); see [A] in figure below. The
SETUP.DIS command is used to configure the behavior.
Generic disassembler mode:
Simple disassembler mode:
In case an assembler mnemonic is available in 16-bit as well as in a 32-bit flavor, the 32-bit variant is
preferred. To force the usage of the 16-bit equivalent the “16” tag can be used.

Parallel Usage of a 3rd-Party Tool
Some 3rd-party tools require access to the debug port and/or debug resources as well. Examples of 3rd-
party tools are tools for measurement, calibration and data-stimulation (MC tools). This section describes
how to use such a 3rd-party tool in parallel with TRACE32.
There are different options of how to share the debug port. The appropriate method depends on the 3rd-
party tool. In general, TRACE32 supports the following options:
• Software debugging over XCP: In this mode, all debug commands are send to the 3rd-party tool
using the standardized XCP protocol. For details, see “XCP Debug Back-End”
(backend_xcp.pdf).
• Physical sharing: In this mode, the debug signals are shared using a special debug adapter for
the 3rd-party tool. This mode is described in the next section.
The 3rd-party tool might also require certain debug resources of the target CPU. Typical examples are:
• The Core Debug Controller covers all debug resources that are part of the CPU like hardware
breakpoints.
• The Cerberus block (CBS) covers all chip-wide debug resources. See also “Cerberus Access
Protection”, page 55.
• Emulation Memory can be divided up between a calibration tool and TRACE32 to allow
calibration and tracing in parallel. For details and configuration, please refer to chapter
“Emulation Memory” (mcds_user.pdf).
You must make sure TRACE32 is not trying to use these resources in parallel, e.g. by special configuration.
Examples for known 3rd-party tools can be found under ~~/demo/tricore/etc/. In doubt, please
contact Lauterbach and/or the 3rd-party tool vendor.
NOTE: Please be aware that some debug operations are intrusive, e.g., Go, Break,
SYStem.Mode Up, or FLASH programming, and therefore might interfere with the
operation of the 3rd-party tool.
Physical Sharing of the Debug Port
The general configuration is depicted below.

Request
PowerDebug Module
Grant 3rd party
+ target
tool
Debug Cable
JTAG or DAP JTAG or DAP
The 3rd-party tool is connected between the debugger and the target. It acts as an arbiter for the JTAG or
DAP debug port. In order to communicate with the target, the debugger requests the debug port from the
tool and waits until access is granted.

Sharing of the debug port must be configured using SYStem.CONFIG PortSHaRing before bringing the
system up. Typical start-up sequences:
• JTAG (e.g., ETAS ETK for AUDO CPUs):
SYStem.CPU TC1796ED ; select your CPU
SYStem.CONFIG DEBUGPORTTYPE JTAG ; switch debug port to JTAG
SYStem.CONFIG PortSHaRing ON ; enable port sharing
SYStem.CONFIG TCKLEVEL 0 ; pull-down on TCK (default)
SYStem.CONFIG TAPState 12. ; Run-Test/Idle (default)
SYStem.Mode Attach ; connect to CPU
The JTAG clock must be between 10 MHz (default) and 40 MHz.
• DAP (e,g., ETAS ETK-S20 for AURIX CPUs):
SYStem.CPU TC277TE ; select your CPU
SYStem.CONFIG DEBUGPORTTYPE DAP2 ; switch debug port to DAP
SYStem.CONFIG PortSHaRing ON ; enable port sharing
SYStem.Mode Attach ; connect to CPU
For the most common CPUs and 3rd-party tools, PRACTICE start-up scripts (*.cmm) can be found under
~~/demo/tricore/etc/.
PSTEP ~~/demo/tricore/etc/etk/*.cmm ; step through a demo

; script
Avoid displaying invalid memory locations (Bus Error).
Details about electrical requirements and connector pin-outs can be found in “Application Note Debug
Cable TriCore” (app_tricore_ocds.pdf).

Debugging an Application with the Memory Protection Unit Enabled
Debugging a TriCore device with the Memory Protection Unit enabled requires different device-dependent
strategies.
TriCore v1.6 and Later
For TriCore devices with core architecture v1.6 and later, the Memory Protection Unit and the on-chip
breakpoint implementation have been separated. Debugging such a device with the MPU enabled does not
require any specific setup or configuration.
TriCore v1.3.1 and Earlier
TriCore devices with a core architecture up to v1.3.1 have the on-chip breakpoint feature implemented in the
Memory Protection Unit. This means that either on-chip breakpoints or the MPU can be used, but not both at
the same time. Do not activate the MPU for single stepping on assembler level.
For simplification debugging an application in RAM is explained first, then the additional configuration for an
application located in FLASH.
Debugging with MPU Enabled in RAM
The first step is to prevent the debugger from configuring any on-chip breakpoint:
1. Single-stepping
Disable the usage of on-chip breakpoints for single-stepping on assembler level
SYStem.Option STEPSOFT ON
2. Program breakpoints
While single addresses are automatically configured as software breakpoints, make sure not to
program any address range.
3. Data breakpoints
Do not configure any breakpoint on data accesses.
Watch the Break.List window and check the configured breakpoints.

Debugging with MPU Enabled in FLASH
For debugging an application running in FLASH using the MPU first apply the same configuration as for
debugging in RAM. Additionally perform the following steps:
1. Enable software breakpoints in FLASH by configuring your flash, e.g. as you would do for FLASH
programming:
; Set up FLASH programming for affected FLASH

FLASH.Create 1. 0xA0000000--0xA000FFFF 0x4000
FLASH.CREATE …
…
FLASH.TARGET 0xD4000000 0xD0000000 0x1000 tc1797.bin
2. Enable FLASH programming in AUTO mode:
FLASH.AUTO ALL
3. Set software breakpoints as preferred breakpoint implementation:
Break.SELect Program SOFT
For more information, see:
• FLASH programming and commands: “FLASH” (general_ref_f.pdf)
• “Software Breakpoints in FLASH” (norflash.pdf)
NOTE: Software breakpoints in FLASH drastically reduce the life-time of your FLASH.

Debugging through Resets and Power Cycles
While debugging a TriCore CPU, resets and power cycles can be caused by the application software, on-
chip logic or external logic, e.g., a watchdog. These events can lead to a reset of the debug logic and loss of
the connection to the debugger. TRACE32 supports debugging despite such events for the following
scenarios.
Soft Resets
Soft resets cover application and system resets of the TriCore. These are typically caused by the application
software or on-chip logic. They do not reset the debug logic. Programmed on-chip breakpoints will be
preserved. Such a reset will be automatically detected by the debugger by reading the corresponding status
register.
TRACE32 provides the following options to handle soft resets.
• CPU running after soft reset
VTREF
soft reset
RESET
CPU application INFINEON application

status running boot code running
TRACE32 re-
up up
status attaching
This behavior is selected by using SYStem.Option RESetBehavior RestoreGo or

SYStem.Option RESetBehavior RunRestore.
• CPU halted after soft reset
VTREF
soft reset
RESET
CPU application INFINEON halted

status running boot code
TRACE32 re-
up up
status attaching
This behavior is selected by using SYStem.Option RESetBehavior Halt.

Hard Resets
Hard resets cover warm power-on resets. These are typically caused by external logic pulling the RESET pin
low. They reset the debug logic and the connection to the debugger. Programmed on-chip breakpoints will
not be preserved.
Such a reset will be automatically detected by the debugger in the following ways:
• Reading status of RESET line. This does only work if all hard resets are visible at the RESET pin
of the debug connector. Details can be found in “Application Note Debug Cable TriCore”
• Polling of the debug port using DAP. The debugger will detect the begin of a hard reset when the
connection to the target is lost. The debugger will detect the end of a hard reset by polling the
debug port until the target responds again. This requires that DAP2 is selected as type of the
debug port, see SYStem.CONFIG.DEBUGPORTTYPE DAP2.
TRACE32 provides the following options to handle hard resets.
• Restore debug resources after hard reset, start CPU
VTREF
RESET
CPU application hard INFINEON application

halted
status running reset boot code running
TRACE32 restoring debug

up reattaching up
status resources
After a hard reset, TRACE32 will halt the CPU for a short time to restore the debug resources
and continue execution afterwards. Breakpoints will trigger from the reset vector. This behavior is
selected by using SYStem.Option RESetBehavior RestoreGo.
• Restore debug resources while CPU is running after hard reset
VTREF
RESET
CPU application hard INFINEON application

status running reset boot code running
TRACE32 restoring debug

up reattaching up
status resources
After a hard reset, TRACE32 will not halt the CPU. The debug resources will be restored while
the CPU is running. Breakpoints triggered during this time will be missed. This behavior is
selected by using SYStem.Option RESetBehavior RunRestore.

• CPU halted after hard reset
VTREF
RESET
CPU application hard INFINEON halted

status running reset boot code
TRACE32
up reattaching up
status
After a hard reset, TRACE32 will halt the CPU at the reset vector. This behavior is selected by
using SYStem.Option RESetBehavior Halt.
Power Cycles
Power cycles cover cold power-on resets caused by switching off CPU power completely, and then on again.
They reset the debug logic and the connection to the debugger. Programmed on-chip breakpoints will not be
preserved.

The debugger will automatically detect a power cycle by observing the VTREF pin of the debug connector.
Details can be found in “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf). Debugging
through power cycles is supported by TRACE32 if SYStem.Mode StandBy is selected beforehand. The
following options are available:
• Restore debug resources after power cycle, start CPU
VTREF
RESET

running off halted running
status boot code
TRACE32 up restoring debug up

status (standby) standby reattaching resources (standby)
After detecting the end of a power cycle, TRACE32 will halt the CPU for a short time to restore
the debug resources. Breakpoints will trigger from the reset vector. This behavior is selected by
using SYStem.Option RESetBehavior RestoreGo.
• Restore debug resources while CPU is running after power cycle
VTREF
RESET

running off running
status boot code

After detecting the end of a power cycle, TRACE32 will not halt the CPU. The debug resources
will be restored while the CPU is running. Breakpoints triggered during this time will be missed.
This behavior is selected by using SYStem.Option RESetBehavior RunRestore.
• CPU halted after power cycle
VTREF
RESET

running off halted running
status boot code

After detecting the end of a power cycle, TRACE32 will halt the CPU at the reset vector. This
behavior is selected by using SYStem.Option RESetBehavior Halt.

Suspending Peripherals
TriCore CPUs allow to suspend peripheral modules automatically when the core(s) are halted. Depending
on the CPU family, dedicated mechanisms are used for watchdogs and system timers. These are described
after the general mechanism.
The general mechanism consists of two components:
• A chip-wide level signal (suspend signal) that is generated by the debug logic of the chip. If
SYStem.Option PERSTOP is set, TRACE32 manages this signal according to the overall debug
configuration.
• Configuration bits for every peripheral module that allow to configure if and how the module is
suspended. For AURIX devices, this is typically done using the OCDS Control and Status Register
<module>_OCS . For AUDO devices, this is typically done using the Clock Control Register
<module>_CLC. These registers must be programmed by the target application, or using Per.Set
commands in the debugger startup script. Example: Suspend GTP12 on a TC3xx chip
SYStem.Option PERSTOP ON
; GTP12_OCS.SUS[_P]=0x11
Per.Set.Field D:0xF00018E8 %Long 0x1F000000 0x11
In case such a setting shall be automatically restored after a reset or power less, this can be achieved using
Data.STANDBY and Data.STARTUP.
During an assembler step (Step.Asm), Go.direct /SingleCORE and target code executed by TRACE32
(see “Target Code Execution”, page 55), the suspend signal will be kept active.
Suspending the System Timers of TC3xx
In TC3xx CPUs the system timers are directly connected to the suspend out signal of the CPU. In case
SYStem.Option PERSTOP ON is set, TRACE32 will manage the suspend out signal for all assigned cores.
The suspend of the system timer must still be configured by setting STMx_OCS.SUS. Example:
SYStem.Option PERSTOP ON
; STM0_OCS.SUS[_P]=0x12
Per.Set.Field D:0xF00010E8 %Long 0x1F000000 0x12
Suspending the Watchdogs
TriCore CPUs disable their internal watchdogs automatically if the debugging system is enabled. Optionally,
the watchdogs can be connected to suspend signal as well. See SYStem.Option WDTSUS for more
details.

Cerberus Access Protection
The Cerberus of a TriCore CPU is one of the main debug modules. Some implementations have access
control registers. By default, TRACE32 will configure this register to allow access by the debugger only. This
behavior can be changed using SYStem.Option CBSACCEN<x>.
When configuring these registers manually, make sure to grant access to the debugger.
Please consider also “Parallel Usage of a 3rd-Party Tool”, page 46.
Target Code Execution
In certain situations TRACE32 will download and/or execute code to your target to achieve specific actions.
This includes but is not limited to:
• target controlled flash programming (see FLASH command group)
• target code referenced in Data.EPILOG.TARGET, Data.PROLOG.TARGET, etc.
• Var.Set, Var.Assign if used with a function.
• CACHE.INVALIDATE, CACHE.FLUSH, CACHE.CLEAN.
• Memory access using access class “D” or “DC” if core access is enabled. For further details, see
“Reading and Writing using Target Code Method”, page 43.
Internal Break Bus (JTAG)
The JTAG connector has two break lines (see target connector) which can be connected to an internal
Break Bus of TriCore devices of the AUDO family:
Pin Break Bus
nBRKIN 0
nBRKOUT 1
An AUDO-TriCore chip has several modules (Break Target) which can react on break signals, such as
TriCore PCP, MCDS and the Suspend Switch and several modules (Break Source) which can generate
break signals, such as TriCore, PCP, MCDS, DMA, Peripheral Buses and MLI bridges.
The Break Buses can be used to distribute break signals from a Break Source to one or more Break Targets.
For example TriCore can be stopped concurrently when PCP breaks and vice versa.
NOTE: Break signals are edge signals and only active for a short period of time.

Troubleshooting
In this section:
• SYStem.Up Errors
• Debugging Optimized Code
• Please also see the chapter “FAQ”, page 53.
SYStem.Up Errors
The SYStem.Up command is the first command of a debug session where communication with the target is
required. If you receive error messages while executing this command this may have the following reasons.
• The target has no power or the debug connector is mounted in wrong orientation.
• External controlled /RESET line:

The debugger controls the processor reset and uses the /RESET line to reset the CPU on most
of the SYStem.Mode commands. Therefore only non-active, open-drain driver may be connected
to this signal.
• There is logic added to the JTAG signals:

The debugger supports multi-processor debugging only in certain cases. When inserting other
processors in the JTAG chain, TriCore must be the first processor. No other TriCore and no
processor with a Cerberus based JTAG interface (e.g. XC16x, XC2000) are allowed in the chain.
• There are additional loads or capacities on the JTAG line.
For more information on pins, signals and daisy-chaining please refer to “Debug Interface Configuration”
Debugging Optimized Code
It is recommended to debug applications with compiler-optimizations turned off. However, this is not always
possible.
Optimized code often splits a single HLL line into multiple blocks of non-consecutive assembler instructions.
Depending on the compiler a single HLL line can generate multiple blocks of code, making single stepping
fiddly and setting breakpoints complex.
Such lines can be summarized when loading an application with the Data.LOAD command:
• The /SingleLineAdjacent option summarizes adjacent blocks of assembler code generated for an
HLL line.
• The /SingleLine option summarizes blocks of assembler code generated for an HLL line.
For example:
Data.LOAD.Elf my_application.elf /SingleLineAdjacent

These options are explained in detail in chapter “Details on Generic Load Options” in General
Commands Reference Guide D, page 85 (general_ref_d.pdf).
FAQ
Please refer to our Frequently Asked Questions page on the Lauterbach website.

Tracing
Tracing allows an in-depth analysis of the behavior and the timing characteristics of the embedded system.
A trace records information about a program’s execution during runtime, usually including program flow and
read/written data. The cores as well as chip internal buses can act as trace sources.
• “On-chip Trace (OCDS-L3)”, page 58
• “Serial Off-Chip Trace”, page 64
• “Parallel Off-Chip Trace”, page 64
Only basic information will be given here, details and advanced tasks are described in separate documents,
see “Further Reading”, page 63.
The trace messages for the On-chip Trace and the Serial Off-chip Trace are generated by the MCDS or Mini-
MCDS. The MCDS is only implemented in Emulation Devices, the Mini-MCDS in some Product Devices.
Please refer to “MCDS User’s Guide” (mcds_user.pdf) for more information.
On-chip Trace (OCDS-L3)
On-chip tracing is only possible with an Infineon Emulation Device (ED), offering the MCDS (MultiCore
Debug Solution) for implementing trace triggers, filters and generation of trace messages (MCDS
messages).
Use Trace.METHOD Onchip for selecting the on-chip trace.
Quick Start for Tracing with On-chip Trace (OCDS-L3)
It is assumed that you are tracing a TC1766ED B-Step on an Infineon TriBoard-TC1766.300 or above.
1. Prepare the Debugger
Load your application and prepare for debug. For details, see “Single-Core Debugging - Quick Start”,
page 16.

2. Specify Trace Source and Recording Options
Select the core to trace (e.g. TriCore), and what should be recorded (e.g. program flow and timestamps).
When enabling timestamps, the CPU clock has to be added also.
MCDS.SOURCE TriCore FlowTrace ON ; enable TriCore program flow

; trace
MCDS.TimeStamp TICKS ; enable Ticks as timestamps
MCDS.CLOCK SYStem 20.0MHz ; configure CPU clock for correct

; timestamp evaluation
3. Start and Stop Tracing
Go ; start tracing
Break ; stop tracing
Note that tracing can also be stopped by a breakpoint.
4. View the Results
Onchip.List ; view recorded trace data
Supported Features
• Program Flow Trace for TriCore and PCP
• Data Trace for TriCore and PCP
• Ownership Trace for PCP
• FPI Bus Trace (independent of TriCore or PCP), both System Peripheral Bus (SPB) and Remote
Peripheral Bus (RPB, if available)
• Timestamps
• Simple Trace Control
See the Onchip.Mode commands for a general setup of the on-chip trace, the MCDS commands and
“Basic Trace Usage” (mcds_user.pdf) for a detailed setup of the on-chip MCDS resources.
NOTE: A trace source can either be TriCore, PCP or both at the same time.
It is not possible to enable a trace stream (e.g. Program Flow or Data
Trace) for only one trace source when both are enabled.

Trace Control
The On-chip settings can be done with the Onchip commands, e.g. from the Onchip.state window. The
settings affect both TriCore and PCP trace.
NOTE: Onchip.AutoArm has an effect only on TriCore, but not on PCP. Always
make sure that PCP is running when arming the trace.
Trace Evaluation
In case one or more of the FBI buses have been traced, the Onchip.List window features two additional
columns with information on the bus access:
BusMaster Shows which Bus Master initiated the FPI bus access, e.g. DMA, PCP, …
BusMODE Shows in which mode the FPI Bus access was performed: User or Supervisor
mode.
Bus accesses performed in User Mode are displayed in light gray.
See <trace>.List in “General Commands Reference Guide T” (general_ref_t.pdf) on how to customize

the Onchip.List window to your needs.
Impact of the Debugger on FPI Bus Tracing
The debugger is either connected as Bus Master via the System Peripheral Bus (AUDO-NG and previous)
or via the DMA controller (all other AUDO and AURIX).
All accesses performed by the debugger are visible on the buses and will be traced which consumes a large
amount of on-chip trace memory. Enabling SYStem.Option DUALPORT will increase the amount of traced
bus data depending on the size and number of displayed data windows.
By default, accesses generated by the debugger are not displayed. To display those, use Onchip.Mode
SLAVE OFF.

Simple Trace Control
The TriCore OCDS-L3 trace supports the same features as TriCore OCDS-L2 trace. Additionally triggers
and filters on data address and data value can be configured.
• Trace all
• Trace to
• Trace from
• Trace from to
• Trigger
• Enable
The simple triggers work on all TriCore fetches and write accesses. Bus accesses are not considered by the
simple trigger.
NOTE: MCDS uses compression to efficiently use the limited amount of on-chip
trace memory. TRACE32 requires a synchronization point to decode all
consecutive trace messages.
Examples
A successfully loaded target application is needed for the following examples.
Example 1: Trace only the Function sieve()
Enable the trace as long as the function sieve() is executed. Execution in sub-functions is not recorded.
MCDS.view ; show MCDS setup window
MCDS.SOURCE TriCore FlowTrace ON ; enable TriCore program flow trace
Onchip.List ; show trace list window
Break.Set Var.RANGE(sieve) /Program ; enable the trace as long as

/Onchip /TraceEnable ; function sieve() is executed

Example 2: Trace the Function sieve() and Sub-Functions
Trace the complete function sieve(), including execution in any sub-function.
Break.Set sieve /Program /Onchip ; enable trace on entering

/TraceON ; function sieve()
Break.Set sYmbol.EXIT(sieve) ; disable trace on leaving

/Program /Onchip /TraceOFF ; function sieve()
Example 3: Trace Until
Stop tracing when the end of function sieve() is reached, TriCore keeps running. Onchip.TDelay can
be used to stop recording after a programmable period (percentage of the trace memory). See the
Trace.Trigger command for more information.
Break.Set sYmbol.EXIT(sieve) ; disable trace on leaving

/Program /Onchip /TraceTrigger ; function sieve()
Example 4: Trace Write Accesses to a Variable
Trace all write accesses to variable flags with offset 0xC, program flow trace is disabled to save on-chip
trace memory.
MCDS.SOURCE TriCore FlowTrace OFF ; disable TriCore program flow

; trace
MCDS.SOURCE TriCore WriteAddr ON ; enable TriCore write address

MCDS.SOURCE TriCore WriteData ON ; and write data trace
Break.Set flags+0x0C /Write /Onchip ; enable recording when TriCore

/TraceEnable ; writes to address flags+0x0C

Example 5: Trace Specific Write Accesses to a Variable while Executing a Function
Enable recording when TriCore writes 0x01 with an access width of 8 bits to address flags+0x0C. The
code that triggered the write access is also recorded. Due to pipeline effects and internal delays the
recorded code may not exactly match the write instruction.

Break.Set flags+0x0C /Write ; enable recording when TriCore

/Data.Byte 0x01 /Onchip ; writes 0x01 to address flags+0x0C
/TraceEnable
Example 6: Trace Specific Write Accesses to a Variable
Enable recording when TriCore writes 0x01 with an access width of 8 bits to address flags+0x0C while
executing function sieve() (excluding sub-function). The code that triggered the write access is also
recorded. Due to pipeline effects and internal delays the recorded code may not exactly match the write
instruction.

Break.Set Var.RANGE(sieve) ; enable recording when TriCore

/MemoryWrite flags+0x0C ; writes 0x01 to address flags+0x0C
/Data.Byte 0x01 /Onchip ; while executing function sieve()
/TraceEnable
Further Reading
For AURIX and similar devices, see “AURIX Trace Training” (training_aurix_trace.pdf).
For advanced tasks regarding the MCDS, see “MCDS User’s Guide” (mcds_user.pdf).

Serial Off-Chip Trace
The Aurora Giga-Bit Trace (AGBT) is a high-speed serial trace for AURIX devices.
This trace is explained in the “AURIX Trace Training” (training_aurix_trace.pdf).
For advanced tasks, see the “MCDS User’s Guide” (mcds_user.pdf).
Parallel Off-Chip Trace
For more information, see chapter “Parallel Off-chip Trace - OCDS-L2 Flow Trace (Analyzer)”, page 134.

CPU specific Commands
This chapter explains TriCore specific commands only. All other commands are documented in the
“General Commands” (general_ref_<x>.pdf) manuals.
CPU specific BMC Commands
The BMC (BenchMark Counter) commands provide control and usage of the on-chip benchmark and
performance counters on the chip if available.
For information about architecture-independent BMC commands, refer to “BMC” (general_ref_b.pdf).
For information about architecture-specific BMC commands, see command descriptions below.
BMC.SELect Select counter for statistic analysis
Format: BMC.SELect <counter>
<counter>: PMN0 | PMN1 | …
The exported event counter values can be combined with the exported instruction flow in order to get a
clearer understanding of the program behavior. The command BMC.SELect allows to specify which counter
is combined with the instruction flow to get a statistical evaluation.
BMC.<counter>.ATOB Control A-to-B mode
Format: BMC.<counter>.ATOB [ON | OFF]
Enable or disable A-to-B mode of the counter. In A-to-B mode only events between the alpha and beta
marker are counted.
The Alpha and Beta markers may be of type Program, Read, Write and ReadWrite. For details about setting
the Alpha and Beta markers see Break.Set.

BMC.<counter>.TRIGMODE BMC trigger mode
Format: BMC.<counter>.TRIGMODE [OFF | TRACEOVERFLOW]
Enables/disables the generation of BenchMark Counter trace messages.
An example can be found under “Example: Record BMC Counters in the Trace” in MCDS User’s Guide,
page 53 (mcds_user.pdf).
BMC.<counter>.TRIGVAL BMC trigger value
Format: BMC.<counter>.TRIGVAL [<value>]
Defines the BenchMark Counter trigger value. Entry in the trace when counter has reached trigger value and
is then reset.
An example can be found under “Example: Record BMC Counters in the Trace” in MCDS User’s Guide,
page 53 (mcds_user.pdf).

CPU specific SYStem.CONFIG Commands
The SYStem.CONFIG commands are used to configure the behavior of the complete target system for
debugging, e.g., the debug interface or the chaining of several CPUs.
SYStem.CONFIG.state Display target configuration
Format: SYStem.CONFIG.state [/<tab>]
<tab>: DebugPort | Jtag | XCP
Opens the SYStem.CONFIG.state 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
SYStem.CONFIG commands. Note that the command line provides additional SYStem.CONFIG
commands for settings that are not included in the SYStem.CONFIG.state window.
<tab> Opens the SYStem.CONFIG.state window on the specified tab:

DebugPort, JTAG, and XCP.
DebugPort Lets you configure the electrical properties of the debug connection, such
as the communication protocol or the used pinout.
Jtag 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.
XCP Lets you configure the XCP connection to your target.
For descriptions of the commands on the XCP tab, see “XCP Debug
Back-End” (backend_xcp.pdf).

SYStem.CONFIG Configure debugger according to target topology
Format: SYStem.CONFIG <parameter> <number_or_address>

SYStem.MultiCore <parameter> <number_or_address> (deprecated)
<parameter>: CORE <core>
<parameter>: DRPRE <bits>

(JTAG): DRPOST <bits>
IRPRE <bits>
IRPOST <bits>
TAPState <state>
TCKLevel <level>
TriState [ON | OFF]
Slave [ON | OFF]
The four parameters IRPRE, IRPOST, DRPRE, DRPOST are required to inform the debugger about the
TAP controller position in the JTAG chain, if there is more than one core in the JTAG chain (e.g. ARM +
DSP). The information is required before the debugger can be activated e.g. by a SYStem.Up. See Daisy-
chain Example.
For some CPU selections (SYStem.CPU) the above setting might be automatically included, since the
required system configuration of these CPUs is known.
TriState has to be used if several debuggers (“via separate cables”) are connected to a common JTAG port
at the same time in order to ensure that always only one debugger drives the signal lines. 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.
Multicore debugging is not supported for the DEBUG INTERFACE (LA-7701).
CORE For multicore debugging one TRACE32 PowerView GUI has to be started
per core. To bundle several cores in one processor as required by the
system this command has to be used to define core and processor
coordinates within the system topology.
Further information can be found in SYStem.CONFIG.CORE.
DRPRE (default: 0) <number> of TAPs in the JTAG chain between the core of
interest and the TDO signal of the debugger. If each core in the system
contributes only one TAP to the JTAG chain, DRPRE is the number of
cores between the core of interest and the TDO signal of the debugger.

DRPOST (default: 0) <number> of TAPs in the JTAG chain between the TDI signal
of the debugger and the core of interest. If each core in the system
contributes only one TAP to the JTAG chain, DRPOST is the number of
cores between the TDI signal of the debugger and the core of interest.
IRPRE (default: 0) <number> of instruction register bits in the JTAG chain

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

between the TDI signal and the core of interest. This is the sum of the
instruction register lengths of all TAPs between the TDI signal of the
debugger and the core of interest.
TAPState (default: 7 = Select-DR-Scan) This is the state of the TAP controller when
the debugger switches to tristate mode. All states of the JTAG TAP
controller are selectable.
TCKLevel (default: 0) Level of TCK signal when all debuggers are tristated.
TriState (default: OFF) If several debuggers share the same debug port, this
option is required. The debugger switches to tristate mode after each
debug port access. Then other debuggers can access the port. JTAG:
This option must be used, if the JTAG line of multiple debug boxes are
connected by a JTAG joiner adapter to access a single JTAG chain.
Slave (default: OFF) If more than one debugger 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).

Daisy-Chain Example
TDI Core A Core B Core C Core D TDO
Chip 0 Chip 1
Below, configuration for core C.
Instruction register length of
• Core A: 3 bit
• Core B: 5 bit
• Core D: 6 bit
SYStem.CONFIG.IRPRE 6. ; IR Core D
SYStem.CONFIG.IRPOST 8. ; IR Core A + B
SYStem.CONFIG.DRPRE 1. ; DR Core D
SYStem.CONFIG.DRPOST 2. ; DR Core A + B
SYStem.CONFIG.CORE 0. 1. ; Target Core C is Core 0 in Chip 1

TapStates
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

SYStem.CONFIG.CORE Assign core to TRACE32 instance
Format: SYStem.CONFIG.CORE <core_index> <chip_index>

SYStem.MultiCore.CORE <core_index> <chip_index> (deprecated)
<chip_index>: 1…i
<core_index>: 1…k
Default core_index: depends on the CPU, usually 1. for generic chips
Default chip_index: derived from CORE= parameter of the configuration file (config.t32). The CORE
parameter is defined according to the start order of the GUI in T32Start with ascending values.
To provide proper interaction between different parts of the debugger, the systems topology must be
mapped to the debugger’s topology model. The debugger model abstracts chips and sub cores of these
chips. Every GUI must be connect to one unused core entry in the debugger topology model. Once the
SYStem.CPU is selected, a generic chip or non-generic chip is created at the default chip_index.
Non-generic Chips
Non-generic chips have a fixed number of sub cores, each with a fixed CPU type.
Initially, all GUIs are configured with different chip_index values. Therefore, you have to assign the
core_index and the chip_index for every core. Usually, the debugger does not need further information to
access cores in non-generic chips, once the setup is correct.
Generic Chips
Generic chips can accommodate an arbitrary amount of sub-cores. The debugger still needs information
how to connect to the individual cores e.g. by setting the JTAG chain coordinates.
Start-up Process
The debug system must not have an invalid state where a GUI is connected to a wrong core type of a non-
generic chip, two GUIs are connected to the same coordinate or a GUI is not connected to a core. The initial
state of the system is valid since every new GUI uses a new chip_index according to its CORE= parameter
of the configuration file (config.t32). If the system contains fewer chips than initially assumed, the chips must
be merged by calling SYStem.CONFIG.CORE.

SYStem.CONFIG BreakPIN Define mapping of break pins
Format: SYStem.CONFIG BreakPIN [PortPort | TdiPort | PortTdo | TdiTdo]
Default: PortPort.
Maps a Break Bus to either a GPIO port pin or an unused JTAG pin. It is dependent on the Interface Mode
which Break Bus can be mapped to which pin:
Break Bus 0 Break Bus 1
PortPort GPIO port pin GPIO port pin
TdiPort TDI pin GPIO port pin
PortTDO GPIO port pin TDO pin
TdiTdo TDI pin TDO pin

SYStem.CONFIG CAN Configure CAN interface
The command group SYStem.CONFIG.CAN configures the timing properties for debugging over a
Controller Area Network (CAN) interface. Currently, the only supported protocol that uses the CAN interface
is DxCM (DAP over CAN messages).
These timing parameters must be chosen to be compatible with the bus. Refer to ISO 11898 for details
about these parameters.
These settings can also be viewed and changed using the command SYStem.CONFIG.state /DXCM.
Use the command group SYStem.CONFIG.DXCM to set parameters specific to the DxCM protocol.
SYStem.CONFIG CAN.BaseCLOCK Base clock for CAN interface
Format: SYStem.CONFIG.CAN.BaseCLOCK <frequency>
Configures the base clock used for the CAN interface. The <frequency> can be in the range of 10 MHz to
200 MHz. For optimum performance, it is suggested to prefer higher frequencies.

SYStem.CONFIG CAN.NominalBRP Set CAN nominal baud rate prescaler
Format: SYStem.CONFIG.CAN.NominalBRP <prescaler>
<prescaler>: 1. ... 4095.
Configures the baud rate prescaler used for nominal transmission.
The effective bit rate during nominal transmission can be computed as BaseCLOCK / NominalBRP / (1
+ NominalTSEG1 + NominalTSEG2).
SYStem.CONFIG CAN.NominalTSEG1 Set CAN nominal Phase_seg1
Format: SYStem.CONFIG.CAN.NominalTSEG1 <length>
<length>: 1. ... 4095.
Configures the length of Phase_Seg1 for nominal transmission.
SYStem.CONFIG CAN.NominalTSEG2 Set CAN nominal Phase_seg2
Format: SYStem.CONFIG.CAN.NominalTSEG2 <length>
<length>: 1. ... 4095.
Configures the length of Phase_Seg2 for nominal transmission.
SYStem.CONFIG CAN.NominalSJW Set CAN nominal SJW parameter
Format: SYStem.CONFIG.CAN.NominalSJW <length>
<length>: 1. ... 4095.
Configures the Synchronization Jump Width for nominal transmission.

SYStem.CONFIG CAN.DataBRP Set CAN data baud rate prescaler
Format: SYStem.CONFIG.CAN.DataBRP <length>
<length>: 1. ... 4095.
Configures the baud rate prescaler used for data transmission.
This setting is only relevant for CAN-FD (ISO 11898-1:2015) transmission with baud rate switching. Note
that this needs to be set correctly if the bus used baud rate switching, even if the frames for debugging do
not.
The effective bit rate during data transmission can be computed as BaseCLOCK / DataBRP / (1 +
DataTSEG1 + DataTSEG2).
SYStem.CONFIG CAN.DataTSEG1 Set CAN data Phase_seg1
Format: SYStem.CONFIG.CAN.DataTSEG1 <length>
<length>: 1. ... 4095.
Configures the length of Phase_Seg1 for data transmission.
not.
SYStem.CONFIG CAN.DataTSEG2 Set CAN data Phase_seg2
Format: SYStem.CONFIG.CAN.DataTSEG2 <length>
<length>: 1. ... 4095.
Configures the length of Phase_Seg2 for data transmission.
not.

SYStem.CONFIG CAN.DataSJW Set CAN data SJW
Format: SYStem.CONFIG.CAN.DataSJW <length>
<length>: 1. ... 4095.
Configures the Synchronization Jump Width for data transmission.
not.

SYStem.CONFIG DAP Configure DAP interface
The SYStem.CONFIG DAP commands are used to configure the debugger connection to the target CPU
via the DAP interface mode. Before these commands can be used, a DAP interface mode has to be selected
by using the SYStem.CONFIG Interface command.
For details, see “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf).
SYStem.CONFIG DAP.BreakPIN Define mapping of break pins
Format: SYStem.CONFIG DAP.BreakPIN [PortPort | TdiPort | PortTdo | TdiTdo]
Default: PortPort.
This command is an alias to SYStem.CONFIG BreakPIN for backward compatibility reasons.
SYStem.CONFIG DAP.DAPENable Enable DAP mode on PORST
Format: SYStem.CONFIG.DAP.DAPEN [TARGET | ON | OFF]
Default: TARGET.
Defines if the DAP interface of the CPU is enabled during a Power On Reset (PORST). This command
requires that the debugger DAP interface is enabled by SYStem.CONFIG.Interface before.
For target boards where a pull-up resistor on TRST line permanently enables the DAP interface the TARGET
setting is required.
In case the CPU DAP interface should not be enabled although a debugger is attached to the target board,
the OFF setting is recommended. When performing a SYStem.Mode Go or SYStem.Mode Up, the
debugger enables the CPU DAP interface automatically when performing the PORST. SYStem.Mode
Attach is not possible in this case.
If the CPU DAP interface should be enabled as long as the debugger is attached, the ON setting is required.
All SYStem.Mode options are possible in this case, including hot attach.

See the “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf) for details.
NOTE: This command only has an effect in case the TRST line is connected to the
DAPEN output pin.
The ALTEN pin always behaves like the OFF setting and should only be
used in case DAP or JTAG mode should be possible via the 16-pin
connector.
SYStem.CONFIG DAP.USERn Configure and set USER pins
Format: SYStem.CONFIG.DAP.USER0 [In | Out | Set <level>]

SYStem.CONFIG.DAP.USER1 [In | Out | Set <level>]
<level>: Low | High
• Default for USER0: In.
• Default for USER1: Out and Low.
Configures the USER0 and USER1 pins of the 10 pin DAP Debug Connector as input or output. The output
level can be Low or High.
Use the functions DAP.USER0() and DAP.USER1() for reading the current status.
The availability of the USER pins depends on the Debug Cable, the selected interface mode and the DAP
Enabling Mode. See the “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf) for details.

SYStem.CONFIG.DEBUGPORT Select target interface
Format: SYStem.CONFIG.DEBUGPORT <port>
<port>: DebugCable0 | DebugCableA | InfineonDAS0 | XCP0 | Unknown
Selects the interface to the target. The available options depend on whether TRACE32 uses a hardware
debugger or runs in HostMCI mode (without TRACE32 hardware).
With TRACE32 hardware
DebugCable0 Uses the debug cable directly connected to a PowerDebug hardware

module.
DebugCableA Uses the whisker connected to a CombiProbe.
HostMCI mode
InfineonDAS0 Selects the Infineon DAS backend as interface. For a detailed description
and examples, see “Debugging via Infineon DAS Server”
(backend_das.pdf).
XCP0 Selects the XCP backend as interface. For a detailed description and
examples, see “XCP Debug Back-End” (backend_xcp.pdf).
Unknown No backend is selected. Debugging is not possible.
SYStem.CONFIG.DEBUGPORTTYPE Set debug cable interface mode
Format: SYStem.CONFIG.DEBUGPORTTYPE [JTAG | DAP2 | DAP3 | DXCPL]

SYStem.CONFIG.Interface [JTAG | DAP2] (deprecated)
Default: DAP2 (JTAG).
Configures the debug port type to be used by the debugger. Both CPU and Debug Cable must support this
mode, see “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf) for details.
As of build 92378 - DVD 02/2018, the default is DAP2, unless the Debug Cable or CPU do not support this
mode.
DAP3: Supported for AURIX only.

SYStem.CONFIG DXCM Configure DXCM
Format: SYStem.CONFIG.DXCM <length>
<length>: 1. ... 4095.
The command group SYStem.CONFIG.DXCM configures the protocol parameters for the DxCM (DAP over
CAN messages).
These settings can also be viewed and changed using the command SYStem.CONFIG.state /DXCM.
Use the command group SYStem.CONFIG.CAN to set general CAN timing parameters.
SYStem.CONFIG DXCM.TXID Control frame message ID
Format: SYStem.CONFIG.DXCM.TXID <id>
<id>: 0x000 ... 0x7FF (base frame format)

0x00000000 ... 0x1FFFFFFF (extended frame format)
Sets the message ID to be used for frames sent to the device.

SYStem.CONFIG DXCM.TXIDE Control frame format
Format: SYStem.CONFIG.DXCM.TXIDE [ON | OFF]
Controls whether frames sent to the device will use the base frame format (setting OFF) or the extended
frame format (setting ON). This corresponds to the value of the IDE (Identifier Extension) field of the frames.
SYStem.CONFIG DXCM.TXFDF Control frame format
Format: SYStem.CONFIG.DXCM.TXFDF [ON | OFF]
Controls whether frames sent to the device will use the ISO 11898-1:2015 FD format (setting ON) or the
classic format (setting OFF).
Setting will also cause the device to reply using FD frames.
SYStem.CONFIG DXCM.TXBRS Control the use of baud rate switching
Format: SYStem.CONFIG.DXCM.TXBRS [ON | OFF]
Controls whether frames sent to the device will use baud rate switching. This only has an effect if
SYStem.CONFIG.DXCM.TXFDF is also set.
Setting will also cause the device to reply with baud rate switching.
SYStem.CONFIG DXCM.RXID Set ID for frames from target
Format: SYStem.CONFIG.DXCM.RXID <id>
<id>: 0x000 ... 0x7FF (base frame format)

0x00000000 ... 0x1FFFFFFF (extended frame format)
Sets the message ID of the debugger used to listen to reply telegrams from the device.

SYStem.CONFIG DXCM.RXIDE Expect extended frames from target
Format: SYStem.CONFIG.DXCM.RXIDE [ON | OFF]
Configures whether the debugger expects frames in the base frame format (setting OFF) or the extended
frame format (setting ON).

SYStem.CONFIG DXCPL Configure DXCPL
The abbreviation DXCPL stands for DAP over CAN Physical Layer by Infineon.
SYStem.CONFIG DXCPL.Timing Configure SPD timing for DXCPL
Format: SYStem.CONFIG DXCPL.Timing [AUTO | <time>]
Default: AUTO.
Configures the edge distance for a ‘0’ bit.
• For AURIX device about 0.80µs recommended.
• For AUDO MAX device it depends on the crystal which is used for the clock. 0.50µs for a 20MHz
crystal and 1.00µs for a 10MHz crystal.
AUTO The option AUTO checks the working timing settings and prints it in the
AREA.view window. AUTO should only used with SYStem.Mode Attach.
SYStem.CONFIG.EXTWDTDIS Disable external watchdog
Format: SYStem.CONFIG EXTWDTDIS <option>
<option>: OFF
High
Low
HighwhenStopped
LowwhenStopped
Default for Automotive/Automotive PRO Debug Cable: High.

Default for XCP: OFF.
Controls the WDTDIS pin of the debug port. This configuration is only available for tools with an Automotive
Connector (e.g., Automotive Debug Cable, Automotive PRO Debug Cable) and XCP.
OFF The WDTDIS pin is not driven. (XCP only)
High The WDTDIS pin is permanently driven high.

Low The WDTDIS pin is permanently driven low.
HighwhenStopped The WDTDIS pin is driven high when program is stopped (not XCP).
LowwhenStopped The WDTDIS pin is driven low when program is stopped (not XCP).
See also “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf).
SYStem.CONFIG PortSHaRing Control sharing of debug port with other tool
Format: SYStem.CONFIG PortSHaRing [ON | OFF | Auto]
Configure if the debug port is shared with another tool, e.g., an ETAS ETK.
ON Request for access to the debug port and wait until the access is granted
before communicating with the target.
OFF Communicate with the target without sending requests.
Auto Automatically detect a connected tool on next SYStem.Mode Up,

SYStem.Mode Attach or SYStem.Mode Go. If a tool is detected switch to
mode ON else switch to mode OFF.
The current setting can be obtained by the PORTSHARING() function, immediate detection can be
performed using SYStem.DETECT PortSHaRing.
See also “Parallel Usage of a 3rd-Party Tool”, page 46.

SYStem.CPU Select CPU
Format: SYStem.CPU <cpu>
Default: TC1797.
Selects the processor type.
<cpu> For a list of supported CPUs, use the command SYStem.CPU * or refer
to the chip search on the Lauterbach website.
NOTE: In case your device is listed on the website but not listed in the SYStem.CPU *
list, you may require a software update. Please contact your responsible
Lauterbach representative.

SYStem.JtagClock Set the JTAG frequency
Format: SYStem.JtagClock <rate>

SYStem.BdmClock (deprecated)
<rate>: 10000. … 50000000.
Default: 10 MHz.
Selects the frequency for the JTAG clock. This influences the speed of data transmission between target and
debugger.
Not all values in between the frequency range can be generated by the debugger. The debugger will select
and display the possible value if it cannot generate the exact value.
It is also possible to enter units, e.g. 10.0 MHz.
SYStem.JtagClock EXT is not supported by TriCore.
NOTE: The JTAG clock must be lower or equal to the CPU clock. Otherwise JTAG
communication will fail.
The possible maximum of the JTAG clock is extremely dependent of the
target board layout.

SYStem.LOCK Tristate the JTAG port
Format: SYStem.LOCK [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 SYStem.LOCK command is, for example,
to give JTAG access to another tool. The process can also be automated, see SYStem.CONFIG TriState.
It must be ensured that the state of the TriCore JTAG state machine remains unchanged while the system is
locked. To ensure correct hand-over, the options SYStem.CONFIG TAPState and SYStem.CONFIG
TCKLevel must be set properly. They 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.
There is a single cable contact on the casing of the Debug Cable which can
be used to detect if the JTAG connector of the debugger is tristated. If
tristated also this signal is tristated, otherwise it is pulled low.

SYStem.MemAccess Run-time memory access (non-intrusive)
Format: SYStem.MemAccess <mode>

SYStem.ACCESS (deprecated)
<mode>: Enable | StopAndGo | Denied
Default: CPU.
This option declares if and how a non-intrusive memory access can take place while the CPU is executing
code. Although the CPU is not halted, run-time memory access creates an additional load on the
processor’s internal data bus. The currently selected run-time memory access mode is displayed in the state
line.
The run-time memory access has to be activated for each window by using the memory class E: (e.g.
Data.dump ED:0xA1000000) or by using the format option %E (e.g. Var.View %E var1). It is also possible
to enable non-intrusive memory access for all memory areas displayed by setting SYStem.Option
DUALPORT ON.
Enable The debugger performs non-intrusive memory accesses via the CPU
CPU (deprecated) internal buses (FPI Bus).
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.
Denied Non-intrusive memory access is disabled while the CPU is executing

code. Instead intrusive accesses can be configured with
SYStem.CpuAccess.

SYStem.Mode Establish the communication with the CPU
Format: SYStem.Mode <mode>
SYStem.Attach (alias for SYStem.Mode Attach)

SYStem.Down (alias for SYStem.Mode Down)
SYStem.Up (alias for SYStem.Mode Up)
<mode>: Down
NoDebug
Prepare
Go
Attach
Up
StandBy
Initial mode: Down.
Down Default state and state after fatal errors. The behavior can be configured
with SYStem.Option DOWNMODE.
NoDebug The CPU is running. Debug mode is not active, debug port is tristate. In
this mode the target behaves as if the debugger is not connected.
Prepare Establishes connection to the target and resets the debug module. This
debugging mode is used if no CPU shall be debugged.
The mode allows to access memory and peripherals.
Attach User program remains running (no reset) and the debug mode is
activated. After this command the user program can be stopped with the
break command or if any break condition occurs. The debugger should be
in NoDebug mode when performing an Attach.
Go The CPU is reset and starts executing user code. Debug mode is active.
After this command the CPU can be stopped with the Break command or
if any break condition occurs.
Up The CPU is reset and halted at the reset vector. Debug mode is active. In
this mode the CPU can be started and stopped. This is the most common
way to activate debugging.
StandBy Activates debugging through power cycles, see “Power Cycles”, page 52.
The SYStem modes are not only commands to bring the debugger in a certain debug state, they also reflect
the current debug state of the target. SYStem.Mode Attach and SYStem.Mode Go are only transitional
states which will result in an Up state on success. Any critical failure will transition the debug state to
SYStem.Mode Down immediately.

The “Emulate” LED on the debug module is ON when the debug mode is active and the CPU is running.
NOTE: For the SYStem.Mode Up the JTAG clock must be high enough. Otherwise
the debugger is not able to configure the Halt-After-Reset before the on-
chip startup firmware has completed.
SYStem.JtagClock 500.0KHz or higher is a saved value for all CPUs.

CPU and Architecture specific SYStem.Option Commands
The SYStem.Option commands are architecture and CPU specific commands.
SYStem.Option BREAKFIX Enable workaround for asynchronous breaking
Format: SYStem.Option BREAKFIX [ON | OFF]
Default: ON for all TriCore v1.3.1 cores, OFF otherwise.
This option is mainly used as a workaround for silicon bug OCDS_TC.028, where the functionality of the
loop instruction may be corrupted by FPI accesses to the [0xF7E10000--0xF7E1FFFF] address region. The
Debug Status Register (DBGSR), used for asynchronous breaking, resides in this region.
Switching the SYStem.Option BREAKFIX ON will temporarily suspend the TriCore when breaking to allow
safe accesses to the critical region. The break is then issued by configuring the Memory Protection System
of the TriCore.

SYStem.Option CBSACCEN<x> Cerberus access protection
Format: SYStem.Option CBSACCEN<x> TarGeT | <value>
<x>: 0
<value>: CerBeruS | <mask> [CerBeruS | <mask>] …
Default: CerBeruS.
Handles the behavior of TRACE32 with respect to the CBS_ACCEN<x> registers of the Cerberus block.
TarGeT TRACE32 will not touch the specified CBS_ACCEN<x> register.
<value> The value is written to the register when the core is started.
The <value> is the OR-composition of the following:
CerBeruS Access for the debugger.
<mask> Arbitrary mask. For valid masks, refer to the TriCore User Manual.
Example 1: Do not touch the CBS_ACCEN0 register.
SYStem.Option CBSACCEN0 TarGeT
Example 2: Enable access from the debugger to the Cerberus block.
SYStem.Option CBSACCEN0 CerBeruS
Example 3: Enable access from the debugger and two more masters (described by <mask>) to the
Cerberus block. The two syntax examples are equivalent:
; |---------- <value> -----------|

; <mask> <mask>
SYStem.Option CBSACCEn0 CerBeruS 0x000000001 0x00000002
; |---------- <value> -----------|

; <mask> <mask>
SYStem.Option CBSACCEn0 0x000000001 CerBeruS 0x00000002

SYStem.Option DCFREEZE Do not modify cache structure
Format: SYStem.Option DCFREEZE [ON | OFF]
Default: ON.
If enabled the data cache contents will not be touched on write accesses. If disabled, cache lines may be
invalidated/flushed on write accesses. For details, see “Accessing Cached Memory Areas and Cache
Inspection”, page 41.
SYStem.Option DCREAD Control cache behavior of reads
Format: SYStem.Option DCREAD [ON | OFF]
Default: OFF.
If disabled, physical memory is read directly (as seen from the bus).
If enabled, memory reads with access class D: (data) and variable windows display the memory values
from the data cache, if valid. If data is not available in cache, physical memory will be read. Memory will be
seen as from the CPU’s point of view.
TriCore cores do not allow cache access during CPU runtime. All accesses will be automatically redirected
to physical memory when the CPU is running, given that run-time memory access is enabled (e.g. with
SYStem.Option DUALPORT). The following table illustrates the effect.
DCREAD CPU is Read Access class D: is like
ON stopped through data cache DC:
ON running physical memory NC:
OFF stopped or running physical memory NC:
More information is available in chapter “Accessing Cached Memory Areas and Cache Inspection”,
page 41.

SYStem.Option DSYNC Force data synchronization
Format: SYStem.Option DSYNC OFF | ReadWrite | Halt
Default: OFF
Automatically executes a dsync instruction to make sure the CPU writes all data back to caches and
memory.
OFF Feature disabled.
ReadWrite Execute dsync instruction on first read or write on that core.
Halt Execute dsync instruction when the CPU is halted.
SYStem.Option DSYNC ReadWrite is expected to have better performance in a multi-core system if

only one or few cores are of interest.
This system option uses target code execution (see “Target Code Execution”, page 55).

SYStem.Option DOWNMODE Behavior of SYStem.Mode Down
Format: SYStem.Option DOWNMODE TriState | ReSeT
Configures the behavior of SYStem.Mode Down:
TriState (default) All drivers of the debug port are switched off.
ReSeT The CPU is held in reset.
SYStem.Option DUALPORT Implicitly use run-time memory access
Format: SYStem.Option DUALPORT [ON | OFF]
All TRACE32 windows that display memory are updated while the processor is executing code (e.g.
Data.dump, Data.List, PER.view, Var.View). This setting has no effect if SYStem.MemAccess is disabled.
If only selected memory windows should update their content during runtime, leave SYStem.Option
DUALPORT OFF and use the access class prefix E or the format option %E for the specific windows.
As of build 108805, SYStem.Option DUALPORT ON no longer interferes with flash programming.

SYStem.Option DataTrace Enable data tracing
OCDS-L2 trace only
Format: SYStem.Option DataTrace [ON | OFF]
Default is OFF.
The CPU trace port does not support data tracing. This option uses code instrumentation to output some
data. See the example in ~~/demo/tricore/etc/tracedata/ in your demo directory for more
information on how to modify your application.
This is not a real data trace since it doesn’t trace the buses. But it may be enough to output some RTOS
related information as thread IDs or task IDs.
For transferring more data, you may want to use the FDX command group, for a real bus trace, you may
want to use the on-chip tracing features of the Emulation Devices (TC17xxED).
SYStem.Option EndInitProtectionOverride Override ENDINIT protection
Format: SYStem.Option EndInitProtectionOverride [ON | OFF | AUTO]
Default: AUTO.
Handles the behavior of TRACE32 with respect to the ENIDIS bit of the CBS_OSTATE register.
AUTO TRACE32 automatically sets/unsets ENIDIS for accesses to protected

registers.
OFF The ENIDIS bit unset for accesses to protected registers.
ON The ENIDIS bit set for accesses to protected registers.
SYStem.Option ETK Debugging together with ETK from ETAS
Format: SYStem.Option ETK [ON | AUTO | OFF] (deprecated)

Use SYStem.CONFIG PortSHaRing instead.

SYStem.Option HeartBeat Bug fix to avoid FPI bus conflict
Format: SYStem.Option HeartBeat [ON | OFF]
Default: OFF.
This option should be used as a workaround for the FPI bus problem on RiderA and AudoLite only.
Otherwise bus errors occur when the debugger checks if the processor is running by reading a core special
function register via FPI bus. With this option active there are two additional conditions checked first before
any read via FPI bus will be done by the debugger. If one of these conditions is true, it is assumed that the
processor is still running.
NOTE: RiderA and AudoLite are not supported any more, so this feature is obsolete.
If a RiscTrace is used together with the debugger, the debugger first checks if the RiscTrace is still recording.
The RiscTrace may not be used in stack mode.
If a RiscTrace is not used or stack mode is required, the debugger checks if pin 15 (reserved) of the JTAG
connector will be toggled. If toggled it is assumed that the processor is running. Therefore it is required to
connect a signal there, which will be toggled while the processor is running. A good signal would be the
ORed signal of the pipeline status information EMUSTAT0-4 which are available on the OCDS Level 2
connector pin 4-8. Please note that on AudoLite these pins must be activated by
Data.Set 0xF0003748 %Long 0xFFFFFFFF.
The connection of one of these pipeline status information lines (e.g. pin 6) might be sufficient. The signal
high level must be lower or equal than VCCS (Pin 2 of JTAG connector) and at least 2.0 V. The signal low
level must be lower than 0.8 V. The switching frequency should be higher than 10 Hz.
To avoid other FPI bus conflicts, do not use SYStem.Option DUALPORT and do not use the access class
attribute E.
SYStem.Option HoldReset Reset duration
Format: SYStem.Option HoldReset <time>
Configure the minimum time the debugger holds the RESET line active on SYStem.Up or SYStem.Mode
Go.

SYStem.Option HSMRESTART Restart HSM on connect
Format: SYStem.Option HSMRESTART [ON | OFF]
Default: OFF
Issues an additional application reset during SYStem.Up or if the chip is reset while
SYStem.Option RESetBehavior Halt or SYStem.Option RESetBehavior RestoreGo is active. This will
release the HSM from halt state. Use only if HSM is not accessible for the debugger.
SYStem.Option ICFLUSH Flush instruction cache at "Go" or "Step"
Format: SYStem.Option ICFLUSH [ON | OFF]
Default: ON.
If enabled, an instruction cache flush will be performed with each Go or Step. This is especially required if
software breakpoints are used.
AURIX TC1.6P cores are unable to flush the instruction cache while the core is halted. Thus, flushing will be
performed as soon as the core switches to running state. During flush sequence accesses to cacheable
memory will stall the CPU, which can result in a slight asynchronity in a multicore system.
Newer AUDO-Future TriCore derivatives (TC11xx, TC1762, TC1764, TC1766, TC1766ED, TC1792,
TC1796 and TC1796ED) have a silicon bug which prevents the line buffer cache to be invalidated during
CPU halt. See the demo scripts for a workaround.
SYStem.Option IMASKASM Disable interrupts while single stepping
Format: SYStem.Option IMASKASM [ON | OFF]
Default: OFF.
If enabled, the interrupt mask bits of the CPU will be set during assembler single-step operations. The
interrupt routine is not executed during single-step operations. After single step the interrupt mask bits are
restored to the value before the step.
On AUDO-Future devices, IMASKASM might not always work due to chip bug CPU_TC.115 (see the
corresponding Infineon Errata sheets). Enable SYStem.Option STEPONCHIP concurrently as a
workaround.

SYStem.Option IMASKHLL Disable interrupts while HLL single stepping
Format: SYStem.Option IMASKHLL [ON | OFF]
Default: OFF.
If enabled, the interrupt mask bits of the CPU will be set during HLL single-step operations. The interrupt
routine is not executed during single-step operations. After single step the interrupt mask bits are restored to
the value before the step.
On AUDO-Future devices, IMASKHLL might not always work due to chip bug CPU_TC.115 (see the
corresponding Infineon Errata sheets). Enable SYStem.Option STEPONCHIP concurrently as a
workaround.
SYStem.Option INTSTART Start address of interrupt routines
Format: SYStem.Option INTSTART <address> (deprecated)

Use the MCDS.Option eXception command group instead.
Sets the start address of the interrupt routines. The on-chip trace uses this together with SYStem.Option
INTUSE to determine if an interrupt occurred.
SYStem.Option INTUSE Number of implemented interrupts
Format: SYStem.Option INTUSE <value> (deprecated)

Sets the number of implemented interrupts. The on-chip trace uses this together with SYStem.Option
INTSTART to determine if an interrupt occurred.

SYStem.Option JTAGENSEQ Use JTAG initialization sequence
Format: SYStem.Option JTAGENSEQ [NONE | JTAG | <signature>]
When JTAG is selected as type of the debug port (see SYStem.CONFIG.DEBUGPORTTYPE JTAG), the
debugger must switch the debug port of the CPU to JTAG. This can either be done using TRST or a
dedicated JTAG enable sequence.
NONE (default) Do not send a sequence on SYStem.Mode Up and SYStem.Mode Go

but use TRST. Use standard sequence on SYStem.Mode Attach.
JTAG Send standard JTAG enable sequence in all cases.
<signature> Specify custom upper word for the DAP turn-off command on which the
enable sequence is based. Not required for normal operation.
SYStem.Option KEYCODE Set debug interface password
Format: SYStem.Option KEYCODE [<pwd0> <pwd1> … <pwd7>]
Set debug interface password for AURIX devices in case the debug interface was locked by programming
UCB_DBG. The password will be sent automatically on SYStem.Mode Up, SYStem.Mode Go and
SYStem.DETECT CPU as well as on reconnects during SYStem.Mode STANDBY and after resets.
Each parameter <pwd0> to <pwd7> is a 32-bit number. Omitting all parameters will clear the password.
SYStem.Option KEYCODEWarnNotAccepted Set warning level
Format: SYStem.Option KEYCODEWarnNotAccepted [ON | OFF]
Default: ON.
In some cases, the chip will not respond to the password exchange sequence enabled by SYStem.Option
KEYCODE. This option configures if a warning is emitted in these cases.

SYStem.Option LBIST LBIST gap handling
Format: SYStem.Option LBIST [ON | OFF | AUTO]
Default: OFF.
If LBIST is activated for TC3xx, there is an interruption of the debug connection during device start-up
(LBIST gap). This option automatically manages this gap after resets, on reconnects during SYStem.Mode
StandBy, and when the following commands are executed:
• SYStem.Mode Up
• SYStem.Mode Go
• SYStem.DETECT CPU
OFF No LBIST expected. Occurrence of an LBIST gap will lead to an error.
ON LBIST expected. TRACE32 waits for the end of the LBIST gap and
reconfigures the debug connection automatically.
If no LBIST gap occurs, a warning is displayed.
AUTO Automatic LBIST handling. TRACE32 waits for the end of the LBIST gap
and reconfigures the debug connection automatically.
If no LBIST gap occurs, then no warning is displayed.

SYStem.Option MACHINESPACES Address extension for guest OSes
Format: SYStem.Option MACHINESPACES [ON | OFF]
Default: OFF
Enables the TRACE32 support for debugging virtualized systems. Virtualized systems are systems running
under the control of a hypervisor.
After loading a Hypervisor Awareness, TRACE32 is able to access the context of each guest machine. Both
currently active and currently inactive guest machines can be debugged.
If SYStem.Option.MACHINESPACES is set to ON:
• Addresses are extended with an identifier called machine ID. The machine ID clearly specifies to
which host or guest machine the address belongs.
The host machine always uses machine ID 0. Guests have a machine ID larger than 0.
TRACE32 currently supports machine IDs up to 30.
• The debugger address translation (MMU and TRANSlation command groups) can be individually
configured for each virtual machine.
• Individual symbol sets can be loaded for each virtual machine.
SYStem.Option MAPCACHE Map cache automatically
Format: SYStem.Option MAPCACHE [ON | OFF | Ponly]
Default: ON / Ponly for TC2xx.
For the cache analysis in the CACHE command group and SYStem.Option DCREAD, TC2xx and TC3xx
require to map the cache via MTU. This operations is potentially intrusive, i.e., it modifies status bits of the
MTU.
OFF Do not map cache.
ON Map cache if appropriate, e.g., on SYStem.Up.
Ponly Map cache of TC1.6P cores only if appropriate, e.g., on SYStem.Up.

This is the default for TC2xx CPUs to avoid problems with flushing the
TC1.6E cores.
For details, see “CPU Constraints for Cache Evaluation and Cache Inspection”, page 42.

SYStem.Option OCDSELOW Set OCDS line to low
Format: SYStem.Option OCDSELOW [ON | OFF]
Default: OFF.
If enabled the nOCDSE line of the Debug Cable is driven low, otherwise it is:
• High in case of the Automotive Debug Cable.
• Tri-stated in case of Uni- and Bi-directional Debug Cables.
See “Debug Cables” (app_tricore_ocds.pdf) for more information on Debug Cables.
This option is ignored on TriCore devices where the nOCDSE line is needed for enabling the OCDS, or when
SYStem.Option ETK is not OFF.
SYStem.Option OVC Enable OVERLAY memory access
Format: SYStem.Option OVC [ON | OFF]

SYStem.Option OVERLAY (deprecated)
Default: OFF.
Enables evaluation of Data Access Overlay (OVC) configuration during memory accesses.
Only supported for AURIX devices.
ON Memory will be seen as from the CPU’s point of view.

The debugger reads the OVC configuration from the target on each access.
For flash regions with configured overlay, the overlay memory content will be
shown instead of the original flash content.
OFF Debugger displays the original Flash content only.

SYStem.Option OVERLAY Enable overlay support
Format: SYStem.Option OVERLAY [ON | OFF | WithOVS]
Default: OFF.
ON Activates the overlay extension and extends the address scheme of the
debugger with a 16 bit virtual overlay ID. Addresses therefore have the
format <overlay_id>:<address>. This enables the debugger to handle
overlaid program memory.
OFF Disables support for code overlays.
WithOVS Like option ON, but also enables support for software breakpoints. This
means that TRACE32 writes software breakpoint opcodes to both, the
execution area (for active overlays) and the storage area. This way, it is
possible to set breakpoints into inactive overlays. Upon activation of the
overlay, the target’s runtime mechanisms copies the breakpoint opcodes
to the execution area. For using this option, the storage area must be
readable and writable for the debugger.
Example:
SYStem.Option OVERLAY ON
Data.List 0x2:0x11c4 ; Data.List <overlay_id>:<address>

SYStem.Option PERSTOP Enable global peripheral suspend
Format: SYStem.Option PERSTOP [ON | OFF]
Default: ON.
This controls the operation mode of the peripherals (e.g. timer), when a debug event is raised, e.g. when the
target is halted or when a breakpoint is hit. A debug event causes the peripherals to suspend if this option is
activated and the suspend enable bit in the peripheral module is set. Usually this is done in its Clock
Register <module>_CLC on AUDO devices, or in the OCDS Control and Status Register <module>_OCS
on AURIX devices.
If enabled, TRACE32 will only set the suspend signal. The user has to activate the enable suspend bit in the
desired peripheral modules either manually or by his application.
See Trigger Onchip Commands for the Suspend Switch for advanced programming features.

SYStem.Option PMILBFIX Enable PMI line buffer invalidation workaround
Format: SYStem.Option PMILBFIX [ON | OFF]
Default: ON.
This option is implemented for AUDO-NG devices only.
This is a workaround for a silicon bug (CPU_TC.053), where the PMI Line Buffer is not invalidated during
CPU halt. The bug comes into effect, when the debugger sets software breakpoints, replacing the original
instruction at the breakpoint address with a debug instruction and thereby halting the CPU. When execution
is resumed, the obsolete debug instruction is still present in the PMI Line Buffer, preventing the CPU to
resume execution. Therefore, the PMI Line Buffer needs to be invalidated before the execution is resumed.
If this option is turned on, the PMI Line Buffer will be invalidated when program execution is resumed.
When using software breakpoints in FLASH memory this bugfix is not applicable. The following procedure in
your start-up script can be used as a workaround.
Data.Assemble <code_address> debug16 nop nop nop nop nop nop nop nop
Data.PROLOG.TARGET <code_address>++0x1F (<code_address>+0x20)++0x1F
Data.PROLOG.ON
Register.Set PC <code_address>+0x02
Step
These commands define a simple target program, that is automatically started by the TRACE32 software
directly before program execution, fetching the stated instructions at <code_address> and thereby
invalidating the PMI Line Buffer. Replace <code_address> with an address in unused and valid memory.

SYStem.Option PostResetDELAY Delay after RESET is released
Format: SYStem.Option PostResetDELAY <time>
Default: 100.us
This option affects the behavior of the commands SYStem.Mode Up, SYStem.Mode Attach and
SYStem.Mode Go, as depicted below.
RESET detection of
released RESET de-assertion
RESET
JTAG /
DAP active
SYStem.Option PostResetDELAY
It configures the delay that is inserted after the RESET line was released by the debugger and the RESET
line is detected as de-asserted, but before accessing the debug port via DAP or JTAG.
NOTE: • Too short delays may result in debug port errors.

• Too long delays may result in failure to stop at the reset vector.
SYStem.Option ReadOnly Block all write accesses
Format: SYStem.Option ReadOnly [ON | OFF]
Default: OFF
This option blocks all write accesses to the target. This includes accesses from the debugger itself.
Commands like Go.direct and Break.direct will not work while this option is active.

SYStem.Option RESetBehavior Set behavior when a reset occurs
Format: SYStem.Option RESetBehavior <mode>
<mode>: Halt
RestoreGo
RunRestore
Sets the behavior in case of a reset. For a detailed explanation, see Debugging through Resets.
Halt Halt after reset.
RestoreGo Halt after power-on reset, restore the debugging resources (e.g.,
breakpoints), and then go. After a soft reset, the debugger does not stop
the CPU. The debugging resources remain in place.
RunRestore Restore debugging resources after power-on reset while CPU is running.
Breakpoints shortly after a reset will be missed. After a soft reset, the
debugger does not stop the CPU. The debugging resources remain in
place.
SYStem.Option ResetDetection Set how hard resets are detected
Format: SYStem.Option ResetDetection <mode>
<mode>: DEFault
TIMEOUT
Configure which of the following methods TRACE32 uses to detect hard resets.
DEFault A hard reset is detected on a low pulse of the RESET line or a time out of
the debug connection.
TIMEOUT A hard reset is detected on a time out of the debug connection only.

SYStem.Option ResetMode Select reset method
Format: SYStem.Option ResetMode <method>
<method>: PORST | EPORST | SYS | APP
Configures the reset method used by SYStem.Up and SYStem.Mode Go.
PORST Power on Reset by asserting the RESET line on the debug

connector.
EPORST Emulated Power on Reset using the Cerberus module.
SYS System reset using the Cerberus module.
APP Application reset using the Cerberus module.
SYStem.Option RESetTMS State of TMS line at reset
Format: SYStem.Option RESetTMS [ON | OFF]
Default: OFF.
Configures the state of the TMS line at the time the RESET line is released by commands SYStem.Mode
Up and SYStem.Mode Go. This option is only required when chaining a TriCore with other devices, e.g., an
XC800.
SYStem.Option SLOWRESET Long timeout for resets
Format: SYStem.Option SLOWRESET [ON | OFF]
Default: OFF.
If enabled, TRACE32 waits up to 25s for the end of a reset.

SYStem.Option SOFTLONG Set 32 bit software breakpoints
Format: SYStem.Option SOFTLONG [ON | OFF]
Default: OFF.
This option must be used if the program RAM allows only 32-bit accesses. When enabled the debugger
uses always 32-bit accesses to write the software breakpoints.
SYStem.Option STEPONCHIP Step with onchip breakpoints
Format: SYStem.Option STEPONCHIP [ON | OFF]
Default: OFF.
If turned on, single stepping is implemented by using a single on-chip breakpoint with Break-After-Make.
This is mainly used as workaround for the silicon bug CPU_TC.115 where an already accepted interrupt is
not suspended. See chapter Single Stepping for details.
Note that in case interrupts are not disabled, the interrupt handler will run silently in the background without
the user noticing. This leads to data modification which may affect the behavior of the stepped function.
This option has no effect if SYStem.Option STEPSOFT is ON.
SYStem.Option STEPSOFT Step with software breakpoints
Format: SYStem.Option STEPSOFT [ON | OFF]
Default: OFF.
If turned off, single stepping is performed by using on-chip breakpoints. For an overview, see “Single
stepping”.
If turned on, single stepping is implemented by using software breakpoints only. This is necessary for
AUDO-NG an earlier cores if the Memory Protection Registers are used by the target application for Memory
Protection. For single stepping in flash memory, set up flash configuration and enable FLASH.AUTO ALL.
Note that in case interrupts are not disabled, the interrupt handler will run silently in the background without
the user noticing. This leads to data modification which may affect the behavior of the stepped function.

SYStem.Option TB1766FIX Bug fix for some TC1766 TriBoards
Format: SYStem.Option TB1766FIX [ON | OFF]
Default: OFF.
Bug fix only required for some TriBoards TC1766. On those, two trace pins are swapped. Therefore the
debugger switches the signals, so that the trace is working correctly.
SYStem.Option TRAPSTART Start address of trap vectors
Format: SYStem.Option TRAPSTART <address> (deprecated)

Sets the start address of the trap vectors. The on-chip trace uses this if a trap occurred.
SYStem.Option WDTFIX Disables the watchdog on SYStem.Up
Format: SYStem.Option WDTFIX [ON | OFF]

SYStem.Option WATCHDOGFIX [ON | OFF] (deprecated)
SYStem.Option TC1796FIX [ON | OFF] (deprecated)
SYStem.Option TC19XXFIX [ON | OFF] (deprecated)
Default: OFF.
Some early TriCore AUDO derivatives, e.g. TC1130, TC1796, TC19xx, …, have a silicon bug where the
watchdog is not suspended when the CPU is halted. As a workaround, this options disables the watchdog
on SYStem.Mode Up and SYStem.Mode Go.
To find out if your derivative is affected by this bug, have a look at the “Example Scripts” and at the Errata
Sheets available from Infineon.
Do not use too low a JTAG clock frequency otherwise the debugger might be too slow to disable the
watchdog in time. The default frequency should be fine.

SYStem.Option WDTSUS Link the watchdog timer to the suspend bus
Format: SYStem.Option WDTSUS [ON | OFF]
Default: OFF.
By default the TriCore watchdog timer is disabled when OCDS is enabled, i.e. when the debugger is
attached.
Setting this option to ON will link the watchdog timer to the suspend bus, i.e. the watchdog timer will be
running only if the suspend bus is inactive. In other words: The watchdog timer will run concurrently with the
CPU and halt concurrently with the CPU. TRACE32 will concurrently set SYStem.Option PERSTOP ON to
automatically pull the suspend bus when breaking. This allows debugging the watchdog timer.
Consult the Infineon documentation for details.
SYStem.RESetOut In-target reset
Format: SYStem.RESetOut
When issuing this command, the debugger will drive the nRESET line low for 2 ms. This will reset the target
including the CPU but not the debug port. The debugger might report one or more bus errors during the
reset.
SYStem.state Open SYStem.state window
Format: SYStem.state
Opens the SYStem.state window with settings of CPU specific system commands. Settings can also be
changed here.

CPU specific TrOnchip Commands
TriCore derivatives such as the TC1100 and devices of the AUDO family have a Multi-Core Break Switch
(MCBS) providing two internal Break Buses and a Suspend Switch.
TrOnchip.BreakBusN.BreakIN Configure break pin of "BreakBus N"
Format: TrOnchip.BreakBus0.BreakIN [ENable | DISable]

TrOnchip.BreakBus1.BreakIN [ENable | DISable]
Default: DISable.
When enabled, the nBRKIN pin (nBRKOUT pin) of the JTAG connector acts as input for BreakBus 0
(BreakBus 1). Available for devices with an MCBS (up to AUDO-MAX family).
For TC1100, TC1115 and TC1130 only Break Bus 0 (nBRKIN pin) can be configured as input.
NOTE: Configuring a BreakBus as BreakIN and BreakOUT at the same time will
result in undefined behavior.
TrOnchip.BreakBusN.BreakOUT Configure break pin of "BreakBus N"
Format: TrOnchip.BreakBus0.BreakOUT [ENable | DISable]

TrOnchip.BreakBus1.BreakOUT [ENable | DISable]
Default: DISable.
When enabled, the nBRKOUT pin (nBRKIN pin) of the JTAG connector acts as output for BreakBus 1
(BreakBus 0). Available for devices with an MCBS (up to AUDO-MAX family).
For TC1100, TC1115 and TC1130 only Break Bus 1 (nBRKOUT pin) can be configured as output.

TrOnchip.BreakIN.<target> Connect break <target> to BreakBus
Format: TrOnchip.BreakIN.<target> [BreakBus0 | BreakBus1]
<target>: TriCore
MCDS
SusSWitch
Default: BreakBus0.
Connects the break <target> with the specified BreakBus. A break target must always be connected to a
BreakBus. Available for devices with an MCBS (up to AUDO-MAX family). Not all targets are available on
each derivative.
TriCore Sets the TriCore as target.
MCDS MCDS is only available on an Emulation Device.
SusSWitch SusSWitch is the break to Suspend Switch.
TrOnchip.BreakOUT.<source> Connect break <source> to BreakBus
Format: TrOnchip.BreakOUT.<source> [BreakBus0 | BreakBus1]

TrOnchip.BreakOUT.HaLTEN [ENable | DISable]
<source>: TriCore
MCDS
DMA
SBCU
RBCU
MLI0
MLI1
Default: BreakBus0.

<source>
Connect the break <source> with the specified BreakBus. A break source must always be connected to a
BreakBus. Available for devices with an MCBS (up to AUDO-MAX family). Not all sources are available on
each derivative.
Depending on the derivative, not all trace sources are available. The break source MCDS is only available
on an Emulation Device. The following table shows which sources are available on which device. Sources
separated by a / are shared and can be disabled in the corresponding chip modules separately. For
information on how to program the module correctly, refer to the Infineon User’s Manual of your device.
TC11xx AUDO-NG AUDO-Future
TriCore TriCore TriCore
DMA DMA DMA
BCU / MLI0 S-BCU / MLI0 S-BCU / (MCDS)
MLI1 R-BCU / MLI1 MLI0
(MCDS) MLI1
NOTE: Note that the R-BCU is only available on TC1792, TC1796 and TC1796ED.
Note that the TrOnchip.view window summarizes shared sources within
the same box.
HaLTEN
Default: DISable.
This special target is only available for the AUDO-Future family. When enabled, the CPU HALT state is
broadcast as a level signal on the connected break bus.
NOTE: Do not enable the break target PCP in case HaLTEN is enabled for
TriCore and TriCore is the break source to the same break bus where
PCP is break target. In this case the synchronous multicore start will fail.

TrOnchip.CONVert Adjust range breakpoint in on-chip resource
Format: TrOnchip.CONVert [ON | OFF]
Converts on-chip breakpoints, freeing on-chip breakpoint resources.
ON On cores up to core version 1.3.1, breakpoint ranges will be reduced to

single address breakpoints.
As of core version 1.6, breakpoint ranges from and to the same address will
be converted to a single address breakpoint.
OFF No conversion.
TrOnchip.CountX Event X counter value
Format: TrOnchip.CountX <value>
This feature is only available for the 5 V trace preprocessor (LA-7879).
The counter <value> is incremented each time the event X has occurred. When the value is equal to 0, the
assigned status (TR[1..0] CR or EXT) is sampled.
On 3.3 V preprocessors (LA-7928), this counter is not active, the status will be sampled every time the event
X occurred.
TrOnchip.CountY Event Y counter value
Format: TrOnchip.CountY <value>
See TrOnchip.CountX.

TrOnchip.EXTernal Configure TriCore break on BreakBus event
Format: TrOnchip.EXTernal [ON | OFF]
Default: OFF.
When enabled, TriCore will break on an break signal distributed via the BreakBus which TriCore listens to.
For AURIX devices, this option is always on.
NOTE: Enabling this feature will disturb the OCDS-L2 break actions TraceON,
TraceOFF, TraceEnable and TraceTrigger. Instead TriCore will stop when
hitting such a break action.
Unconditional tracing is still possible, OCDS-L3 (On-chip trace) is not
affected.
TrOnchip.PERSTOPOUT Route suspend signal to pin
Format: TrOnchip.PERSTOPOUT OFF | <pin>
<pin> Pin0 | Pin1 | ... | Pin7
This command configures the OTGS of TC2xx and later devices to route the peripheral suspend signal (see
Suspending Peripherals) to a pin. For the exact pins, please refer to the chip data sheet. Pin0 corresponds
to /TGO0, Pin1 corresponds to /TGO1, etc.
TrOnchip.RESet Reset settings for the on-chip trigger unit
Format: TrOnchip.RESet
Resets the settings for the trigger on-chip unit to default.

TrOnchip.SoftWare Configure "TriCore" break on debug instruction
Format: TrOnchip.SoftWare [ON | OFF]
Default: ON.
When enabled, TriCore will break when executing a debug instruction.
NOTE: When this feature is disabled, the TriCore CPU will treat all debug
instructions as nop instructions. This will silently disable all software
breakpoints.
TrOnchip.SusSWitch Enable or disable suspend switch
Format: TrOnchip.SusSwitch [ENable | DISable]
Default: DISable.
Enables or disables forwarding of a break signal to the suspend bus.
Available for devices with an MCBS (up to AUDO-MAX family).
TrOnchip.SusSWitch.FORCE Force generation of suspend signal
Format: TrOnchip.SusSwitch.FORCE [ENable | DISable]
Default: DISable.
When enabled, the suspend switch generates a suspend signal independent of any state or mode.
Available for devices with an MCBS (up to AUDO-MAX family).

TrOnchip.SusSWitch.Mode Set suspend switch mode
Format: TrOnchip.SusSwitch.Mode [CAPTURE | DIRECT | CLEAR]
Default: CAPTURE.
In DIRECT mode, the suspend switch forwards the signal coming from the break bus directly to the suspend
bus.
In CAPTURE mode, a high-low transition on the break bus is stored in a flip-flop. Its state is used to drive the
suspend bus. The flip-flop is reset with the CLEAR option. Available for devices with an MCBS (up to AUDO-
MAX family).
TrOnchip.SusTarget Connect special targets to the suspend bus
Format: TrOnchip.SusTarget.<target>
<target>: TriCore [ON | OFF]

PMU [ON | OFF]
FORCE [ENable | DISable]
Default: DISable / OFF.
Normally each peripheral has a Clock Register mod_CLC where it can be connected to the suspend bus.
Some modules do not have such a register and can be programmed here.
If FORCE is selected, all special targets enabled for suspend are suspended immediately, independent of
the current suspend bus state. This is also true for PCP if enabled in ICD PCP. Available for devices with an
MCBS (up to AUDO-MAX family).
TrOnchip.SYNCHRONOUS Switches mode for data breakpoints
Format: TrOnchip.SYNCHRONOUS [ON | OFF]
Default: OFF.
Switches the Break Before Make flag in TRxEVT registers of AURIX cores. This flag is only effective for data
breakpoints.

If the flag is ON the processor stops on a breakpoint hit before the new value is written to the respective
destination/address. If the flag is set OFF the processor stops after the new value is written.
TrOnchip.TDelay Trace trigger delay
Format: TrOnchip.TDelay <value> (deprecated)

Use Break.Set instead.
The trace will not stop immediately after trigger if a trigger delay is programmed.
TrOnchip.TExtMode Mode for external trigger input
Format: TrOnchip.TExtMode [COMP | EDGE]
Default: EDGE.
This defines if the external trigger pin on the preprocessor (only LA-7879) reacts on level (COMP) or edge
(EDGE).
TrOnchip.TExtPol Polarity of external trigger input
Format: TrOnchip.TExtPol [+ | -]
Default: -.
This defines if the external trigger pin on the preprocessor (only LA-7879) reacts on active high/positive edge
(+) or active low/negative edge (-).
TrOnchip.TMode Trace mode
Format: TrOnchip.TMode <mode> (deprecated)

Use Break.Set instead.
This command is obsolete and only left for compatibility reasons.

TrOnchip.TR0 Specify trigger event 0
Format: TrOnchip.TR0 <source> <event>
<source>: Code <breakpoint>

Address <breakpoint>
CYcle OFF | Read | Write | Access
<event>: WATCH [ON | OFF]
Specifies the source for the trigger event 0 and the action associated with the trigger event. Available for
devices with an MCBS (up to AUDO-MAX family).
Code Code range for the debug event generation, the code range has to be
<breakpoint> marked by an Alpha | Beta | Charly | Delta | Echo breakpoint.
Address Data range for the debug event generation, the data range has to be
<breakpoint> marked by an Alpha | Beta | Charly | Delta | Echo breakpoint.
CYcle Cycle type for the data range: OFF | Read | Write | Access
Specify the event for trigger source 0
WATCH Default: OFF.

[ON | OFF] When WATCH is ON and the event X or Y occurs, program execution will
stop and the status will be output. If switched to OFF, only the status will
be output.
NOTE: This way of setting Trace Triggers is obsolete.

The correct way is to use Breakpoints.
Example 1: Stop the program execution when the function sieve is entered.
Break.Set sieve /Alpha ; Set a breakpoint of the type Alpha to sieve
TrOnchip.TR0.Code ; Select the code range as source for the

Alpha ; trigger event 0 generation and assign the
; breakpoint type Alpha
TrOnchip.TR0.WATCH OFF ; The program execution will be stopped if the

; trigger event 0 occurs

Example 2: Stop the program execution when a write access to flags[3] occurs.
; Set a breakpoint of the type Alpha to flags[3]
Var.Break.Set \\demo\taskc\flags[3]; /Alpha
; Select the data range as source for the trigger event 0 generation and
; assign the breakpoint type Alpha
TrOnchip.TR0.Address Alpha
; Select Write as cycle type for the data access
TrOnchip.TR0.CYcle Write
; The program execution will be stopped if the trigger event 0 occurs
TrOnchip.TR0.WATCH OFF
TrOnchip.TR1 Specify trigger event 1
See TrOnchip.TR0 for further information.
TrOnchip.state Show on-chip trigger window
Format: TrOnchip.state
Shows the trigger on-chip window.

TrOnchip.WatchPin Route core trigger to pin
Format: TrOnchip.WatchPin OFF | <pin>
<trigger> WATCH | Alpha | Beta | Charly | Delta | Echo
<pin> Pin0 | Pin1 | ... | Pin7
This command configures the OTGS of TC2xx and later devices to route a core trigger to a pin. This can be
used to correlate program events with external signals. For the exact pins, please refer to the chip data
sheet. Pin0 corresponds to /TGO0, Pin1 corresponds to /TGO1, etc.
Additional configuration for the pins, e.g., speed grade, might be required.
Example:
This example shows how to route a range breakpoint on "func1" to pin "/TGO0". The pin will be active (low)
while the program counter is inside func1 but not inside a called function.
Break.Set sYmbol.RANGE(func1) /Alpha

TrOnchip.WatchPin.Alpha Pin0
An extended example can be found at ~~/demo/tricore/etc/watchpins/aurix_watchpin.cmm.
TrOnchip.X Select trigger source X
Format: TrOnchip.X <source>
<source>: TR0
TR1
CR
EXT
The on-chip comparator unit can react on different sources. Available for devices with an MCBS (up to
AUDO-MAX family).
TR0 On-chip address comparator TR0
TR1 On-chip address comparator TR1

CR Core Event: MTCR/ MFCR instruction is executed or a core SFR is
modified.
EXT External Break In pin is asserted.
TrOnchip.Y Select trigger source Y
See TrOnchip.X for further information.

Technical Data
JTAG Connector
Signal Pin Pin Signal

TMS/DAP1 1 2 VTREF
TDO/DAP2/USER0 3 4 GND
CPUCLOCK 5 6 GND
TDI/DAPEN 7 8 RESET-
TRST-/DAPDIR 9 10 BRKOUT-
TCK/DAP0 11 12 GND
BRKIN- 13 14 OCDSE-/BREQ-
RESERVED/BGRNT- 15 16 GND
A standard 2 x 8 pin header (pin-to-pin spacing: 0.1 inch = 2.54 mm.) is required on the target.
• Do not connect the “reserved” pin.
• Do connect all GND pins and the N/C pin for shielding purpose, though they are connected on
the debugger.
• VCCS is the processor power supply voltage. It is used to detect if target power is on and it is
used to supply the output buffers of the debugger. That means the output voltage of the debugger
signals (TMS, TDI, TCLK, /TRST, /BRKIN) depends directly on VCCS. VCCS can be
2.25 … 5.5 V. The output buffer takes about 2 mA.
• /RESET and /OCDS_E are controlled by an open drain driver. An external watchdog must be
switched off if the In-Circuit Debugger is used.
• /BRKIN and /BRKOUT must be configured in MCBS (Multi Core Break Switch) for before they
can be used.
• CPUCLOCK is optional. The CPU clock output has to be enabled by setting the appropriate
register.
For an example design see the Infineon TriBoard schematics.
VIHmin = 2.0 V, VILmax = 0.8 V for the input pins TDO, CPUCLOCK, /BRKOUT.
When having multiple JTAG TAP controllers in the chain, make sure that the TriCore is the first device in the
chain. It is not possible to have another TriCore, XC16x or XC2000 in the same chain.

See “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf) for a description of
• The TriCore Debug Cables and their features
• The JTAG and DAP connectors
• Availably accessories: adapters, converters and cables
Pins Connection Description Recommendations
1 TMS Test Mode None.

Select
2 VCCS VCC Sense Connect to Chip I/O voltage VCC.
3 TDO Test Data Out If there are multiple devices on the JTAG chain,
connect TDO to the TDI signal of the next
device in the chain.
4, 6, 12 GND System Connect to digital ground.

Ground Plan
5 CPUCLOCK CPU clock Optional.
7 TDI Test Data In No other devices in the JTAG chain are allowed
between the Debug Cable and the TriCore.
8 RESET Reset Connect to /PORST and connect /PORST to

VCC via a 10 k pull-up resistor.
Do not connect to /TRST.
9 TRST Test Reset Connect to /TRST. Do not connect to /PORST.
10 BRKOUT Break output None.
11 TCLK Test clock None.
13 BRKIN Break input None.
14 OCDSE OCDS enable Required for older TriCore devices only, e.g.
TC1765, TC1775 and TC19xx. Connect to
VCC via a 10 k pull-up resistor.
15 NC Not Connect to Ground.

Connected
16 GND KEY pin. Connect to Ground.

Trace Connector
For more information on connectors, adapters, converters, and cables, see “Application Note Debug
Cable TriCore” (app_tricore_ocds.pdf).
AMP 40 Connector
• 2x20 connector
• Pin-to-pin spacing: 50 mil = 0.05 inch = 1.27 mm
• Connector example:
AMP/ Tyco 104550-5 standard
Signal description:

CPUCLK 1 2 GND
N/C 3 4 EMUSTAT0
EMUSTAT1 5 6 EMUSTAT2
EMUSTAT3 7 8 EMUSTAT4
N/C 9 10 N/C
N/C 11 12 GND
N/C 13 14 EMUPC0
EMUPC1 15 16 EMUPC2
EMUPC3 17 18 EMUPC4
EMUPC5 19 20 EMUPC6
EMUPC7 21 22 N/C
N/C 23 24 N/C
N/C 25 26 GND
N/C 27 28 EMUBREAK0
EMUBREAK1 29 30 EMUBREAK2
N/C 31 32 N/C
N/C 33 34 N/C
N/C 35 36 VCC
N/C 37 38 N/C
N/C 39 40 GND

ERF8 22-pin Power.org Connector
• 2x11 edge rate socket strip connector
• Pin-to-pin spacing: 31.5 mil = 0.031 inch = 0.8 mm
• Connector example:
Samtec ASP-137969-01 ASP for Power.org connector (base type is ERF8-DV)
See https://www.lauterbach.com/erf822_asp_137969_01.pdf for dimensioning details.
Signal description:

RXP0 1 2 VREF
RXN0 3 4 TCK
GND 5 6 TMS
RXP1 7 8 TDI
RXN1 9 10 TDO
GND 11 12 TRST-
RXP2 13 14 CLKP
RXN2 15 16 CLKN
GND 17 18 TRIG
RXP3 19 20 CRCERR
RXN3 21 22 RESET-
Samtec 60 Connector
• 2x30 high-speed socket strip connector
• Pin-to-pin spacing: 19.7 mil = 0.0197 inch = 0.5 mm

• Connector examples:
Samtec QSH-030-01-L-D-A standard
Samtec QSH-030-01-L-D-A-K with pick & place pad
Samtec QSH-030-01-L-D-A-K-TR with pick & place pad, tape & reel
Signal description:

RESET- 1 2 BREAK2
BRKIN- 3 4 BREAK1
TRST- 5 6 N/C
N/C 7 8 VCCIO/OCDS1
N/C 9 10 BREAK0
OCDS1EN- 11 12 STAT4
TDI 13 14 STAT3
TCK 15 16 STAT2
N/C 17 18 STAT1
N/C 19 20 STAT0
N/C 21 22 N/C
N/C 23 24 N/C
N/C 25 26 N/C
BRKOUT- 27 28 TDO
N/C 29 30 N/C
N/C 31 32 N/C
N/C 33 34 N/C
N/C 35 36 EMUPC7
N/C 37 38 EMUPC6
N/C 39 40 EMUPC5
N/C 41 42 EMUPC4
N/C 43 44 TMS
N/C 45 46 N/C
N/C 47 48 EMUPC3
N/C 49 50 EMUPC2
N/C 51 52 EMUPC1
N/C 53 54 EMUPC0
N/C 55 56 VCCIO/OCDS2
N/C 57 58 OCDS2EN-
N/C 59 60 EMUCLK

Technical Data for Debugger
Operation Voltage
Adapter OrderNo Voltage Range

Debugger for TriCore Automotive PRO LA-2707 0.9 .. 5.5 V
Debug-Bundle MPC5xxx/TriCore Automotive PRO LA-2713 1.6 .. 5.5 V
Debug-Bundle TriCore/RH850 Automotive PRO LA-2714 1.6 .. 5.5 V
Debugger for TriCore Automotive LA-3737 1.6 .. 5.5 V
Debugger-Bundle MPC5xxx/TriCore Automotive LA-3738 1.6 .. 5.5 V
Debugger-Bundle TriCore/RH850 Automotive LA-3753 1.6 .. 5.5 V
Mechanical Dimensions
OCDS Uni-Dir Debug Cable Bidirectional Cables and Auto-

V0 motive Debug Cables
Length: 4.2 cm 5.5 cm
Width: 5.2 cm 6.25 cm
Height: 1.6 cm 1.7 cm
Length of cable: approx. 37.5 cm approx. 37.8 cm
The Debug Cables with new housings are shipped within Europe since March 2006. They have a removable
cable and are RoHS compliant. The electrical components and the schematics are identical to ones in the
old housing.
Further details are available in “Application Note Debug Cable TriCore” (app_tricore_ocds.pdf).

Technical Data for Trace
Operation Frequency
Module CPU TRACE

LA-7928 PXB4260 130.0 MHz
LA-7928 TC10GP 180.0 MHz
LA-7928 TC1100 180.0 MHz
LA-7928 TC1115 180.0 MHz
LA-7928 TC1130 180.0 MHz
LA-7928 TC1161 180.0 MHz
LA-7928 TC1162 180.0 MHz
LA-7928 TC1163 180.0 MHz
LA-7928 TC1164 180.0 MHz
LA-7928 TC1165 180.0 MHz
LA-7928 TC1166 180.0 MHz
LA-7928 TC11IA 180.0 MHz
LA-7928 TC11IB 180.0 MHz
LA-7928 TC11IC 180.0 MHz
LA-7928 TC1762
LA-7928 TC1764
LA-7928 TC1765 180.0 MHz
LA-7928 TC1766
LA-7928 TC1766ED 180.0 MHz
LA-7928 TC1775 180.0 MHz
LA-7928 TC1792 180.0 MHz
LA-7928 TC1796 180.0 MHz
LA-7928 TC1796ED 180.0 MHz
LA-7928 TC1796L 180.0 MHz
LA-7928 TC1910 180.0 MHz
LA-7928 TC1912 180.0 MHz
LA-7928 TC1920 180.0 MHz
Operation Voltage
Adapter OrderNo Voltage Range

Preprocessor TriCore OCDS-L2 5V Samtec 60 LA-7879 3.0 .. 5.5 V
Converter AMP 40 to Samtec 60 LA-7919 3.0 .. 5.5 V
Preprocessor TriCore OCDS-L2 3.3V Samtec 60 LA-7928 1.8 .. 3.3 V

Mechanical Dimensions
Dimension
LA-7928 PP-TRICORE-3.3V
TOP VIEW CABLE

2475 / 100
DRILL O
1988
PIN1
/ 100
DRILL O
937
488
200
362
3500
SIDE VIEW
675
413
ALL DIMENSIONS IN 1/1000 INCH
LA-7879 PP-TRICORE-5V
TOP VIEW
1400
100
450
1
2350
1450
1925
650
100
450
425
1488
1250 400
SIDE VIEW
550
CABLE
375
ALL DIMENSIONS IN 1/1000 INCH

Appendix
• “Parallel Off-chip Trace - OCDS-L2 Flow Trace (Analyzer)”, page 134
Parallel Off-chip Trace - OCDS-L2 Flow Trace (Analyzer)
Use Trace.METHOD Analyzer for selecting the Analyzer.
Overview
This chapter describes the OCDS-L2 Flow Trace, which is available on some devices of the AUDO-NG
family, e.g. the TC1796.
For all other traces, please refer to chapter “Tracing”, page 58.
Quick Start for Tracing with OCDS-L2 Trace (Analyzer)
It is assumed that you are tracing a TC1766 B-Step on an Infineon TriBoard-TC1766.300 or above.
1. Prepare the Debugger
Load your application and prepare for debug. See “Quick Start for OCDS-L1 Debugger” for more details.
2. Connect the PreProcessor to the Trace Connector on the Target
Plug the preprocessor into the trace connector on the target board. In case of an AMP40 connector you
need to care for the correct orientation of the connector. Check for Pin 1.
3. Configure the Trace Port on Your Target
Data.Set 0xF0001110 %Long 0xA0A0A0A0 ; enable Port 5 for OCDS-L2 output
Data.Set 0xF0001114 %Long 0xA0A0A0A0
Data.Set 0xF0001118 %Long 0xA0A0A0A0
Data.Set 0xF000111C %Long 0xA0A0A0A0
On TriBoard-TC1766.300 the trace connector is connected to GPIO port 5 which needs to be set up for
tracing.

4. Fine Tuning
Analyzer.Clock 20.0MHz ; specify CPU clock
The preprocessor uses a compression algorithm which affects the accuracy of the timestamp information.
For improving the accuracy by the factor 4, specify the CPU clock frequency.
The trace is now configured.
5. Start and Stop Tracing
Go ; start tracing
Break ; stop tracing
Recording is stopped when the TriCore halts, e.g. when a breakpoint was hit.
6. View the Results
Analyzer.List ; view recorded trace data
Supported Features
• Program Flow Trace for TriCore
• Program Flow Trace for PCP
• Timestamp
• Simple Trace Control
NOTE: Note that OCDS-L2 does not allow to trace TriCore and PCP at the same
time.

Version History
The trace hardware is under constant development. So it is possible that you have different trace hardware
versions. Only the latest trace hardware versions are housed (see Mechanical Dimensions).
Order number LA-7879 LA-7879 LA-7928
Housing no no yes
PCB version MERF1-4 MERF5-6 MERF7-
Connector AMP40 SAMTEC60 SAMTEC60
Counter yes yes no
Frequency 80 MHz 133 MHz 180 MHz
Termination passive (clock) passive (clock) active

50Ohm Thevenin
Threshold no no yes
Trace control yes yes yes
JTAG on board no no yes
Trace depth x2 x2 x4
Number of cable 1 1 2
Timestamp Accuracy
The TriCore does not generate any timestamps for OCDS-L2 trace.
The trace preprocessor demultiplexes multiple OCDS-L2 trace samples (2 in case of LA-7879, 4 in case of
LA-7928) into a single trace package which is stored in one trace memory frame and marked with a
timestamp generated by the trace hardware. The accuracy is trace hardware dependent, see “Trace
Method Analyzer” (general_ref_a.pdf) for details.
This results in inaccurate execution times. Especially when Trace.PortFilter is used, you can get extremely
high time values or even durations below the resolution of the trace hardware - shown as e.g. "< 20 ns".
PowerView is able to compensate for the inaccuracy by setting Analyzer.CLOCK <cpufreq> according to
the CPU frequency.
Note that in case of high CPU frequencies and Analyzer.CLOCK <cpufreq> is set, negative cycles may be
displayed. In case of negative timestamps, it is recommended to adjust the <cpufreq>. Sightly higher values
may already eliminate all or most of the negative timestamps.
OCDS-L2 trace is a Program Flow Trace and so timestamps will never be instruction accurate.

Concurrent Usage of OCDS-L2 Off-chip Trace and OCDS-L3 On-chip Trace
The parallel OCDS-L2 off-chip trace and the OCDS-L3 on-chip trace can be used in parallel with restrictions.
For details, see “Concurrent Usage of Different Trace Methods” (mcds_user.pdf).
This use case is not recommended.
Simple Trace Control
TriCore OCDS-L2 trace supports the same features:
• Trace all
• Trace to
• Trace from
• Trace from to
• Trigger
• Enable
OCDS level 2 is a flow trace. That means only relative program flow
information is given out by the CPU.
TRACE32 needs synchronization points for starting trace disassembling.
The trace cannot be shown correctly until such a synchronization point is
reached.
Trace Break Signals (OCDS-L2)
The trace connector has three break lines (see Trace Connector) which will output a defined status when
certain events occurred a definable number of times:
event TR0 TR1
[EMU]BREAK0 1 1
[EMU]BREAK1 0 0
[EMU]BREAK2 0 1
BREAK[2..0] corresponds to EMUSTAT[7..5] in the trace.
TR[1..0], CR and EXT can be assigned to events X and Y.

Trace Examples
A successfully loaded target application is needed for the following examples.
Trace is just a pointer to the currently selected trace method (see

Trace.METHOD).
Example 1: Trace from
Start recording at address 0xA0001000.
Analyzer.view ; show trace setup window
Analyzer.Mode STACK ; set trace to stack mode
Analyzer.List ; show trace list window
Break.Set 0xA0001000 /TraceON ; set start address
Example 2: Trace to
Stop recording at address 0xA0001100, but do not halt the CPU.
Break.Set 0xA0001100 /TraceOFF ; set end address
Example 3: Trace from to
Start recording at address 0xA0001000 and stop recording at address 0xA0001100, but do not halt the
CPU. If recording was stopped once it will restart when the start address is reached once more.
Break.Set 0xA0001000 /TraceON ; set start address
Break.Set 0xA0001100 /TraceOFF ; set end address

Example 4: Trace Trigger
Trigger recording at address 0xA0001200. The trace will stop recording after a programmable period, see
Trace.Trigger for more information.
Break.Set /TraceTrigger ; set trigger address
Example 5: Trace Enable
When address 0xA0001400 is reached, write a sample into the trace memory.
Break.Set 0xA0001400 /TraceEnable ; set enable address

Troubleshooting for OCDS-L2 Trace
No Data in Trace.List Visible
Different reasons are possible:
• CPU trace port not mapped.

Mostly the trace port shares its functionality with another peripheral. In this case, one or more
dedicated registers have to be set correctly. See also the demo scripts within the TRACE32
installation directory: ~~/demo/tricore/hardware/*.
• Reference voltage not set up correctly (LA-7928 only).

Reference voltage pin on trace connector connected? If not, the threshold value must be set to
the middle of the trace signal manually (half of target I/O voltage level).
• Poor trace/clock signal.

Change termination setting (LA-7928 only) and threshold value. If a change of the setup does not
help, further target hardware modifications are required. Please ask the technical support for
details ([email protected]).
Error Diagnosis
NOTE: Advanced trace analysis commands like Trace.STATistic.Func,

Trace.STATistic.TASK display accurate results only if the trace recording
works error-free.
Error messages are displayed in the upper left corner of the Trace.List window:

Searching for Errors
TRACE32 uploads only the requested trace information to the host to provide a quick display of the trace
information. Consequently, potential errors outside the uploaded range are not immediately visible.
There are several ways to search for errors within the trace, all of them will force TRACE32 to upload the
complete trace information to the host:
1. The Trace Find window
Pushing the Find … button of the Trace.List window opens a special search window:
Select Expert and enter “flowerror” in the item field. The item entry is not case sensitive. Use the Find
First/Find Next button to jump to the next flowerror within the trace. Find All will open a separate
window with a list of all flowerrors.
2. Using command Trace.FindAll , FLOWERROR
This command will search for errors within the entire trace buffer. The records will be listed within a
separate window. This command corresponds to the FindAll option described above.

3. Using command Trace.Chart.sYmbol
This command will start a statistical analysis. An additional symbol (ERROR) is shown if errors where
found.
The search could take a long time depending on the used memory size of
the trace module and the type of host interface. Check the status to estimate
the time.
Error Messages
One of the following 2 errors may occur:
1. HARDERROR
There are no valid trace data. Possible reasons are:
• Traceport multiplexed with other IO functions (no valid trace data)
• Trace signal capturing failed (setup/hold time violations)
• Wrong version of PowerTrace module
• Target frequency too high
2. FLOWERROR
The traced data are not consistent with the code in the target memory. Possible reasons are:
• Memory contents has changed.

Self modifying code is not supported.
• Wrong trace data (as result of HARDERRORS)
• CPU trace port not mapped.

Mostly the trace port shares its functionality with another peripheral. In this case, one or more
dedicated registers have to be set correctly. See also the demo scripts within the TRACE32
installation directory: ~~/demo/tricore/hardware/*.
• Reference voltage not set up correctly (LA-7928 only).

Reference voltage pin on trace connector connected? If not, the threshold value must be set to
the middle of the trace signal manually (half of target I/O voltage level).
• Poor trace/clock signal.

Change termination setting (LA-7928 only) and threshold value. If a change of the setup does not
help, further target hardware modifications are required. Please ask the technical support for
details ([email protected]).
• Setup/hold time violation.

- 3 ns setup / 1 ns hold time needed.
- sample point: falling edge.


Debugger Tricore

Uploaded by

Copyright:

Available Formats

Debugger Tricore

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Debugger Tricore

Uploaded by

Copyright:

Available Formats

TriCore Debugger and Trace

TRACE32 Online Help

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

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

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

TriCore Debugger and Trace ............................................................................................... 1

Safety Precautions ............................................................................................................ 8

©1989-2021 Lauterbach GmbH

CPU specific Commands .................................................................................................. 65

©1989-2021 Lauterbach GmbH

©1989-2021 Lauterbach GmbH

CPU specific TrOnchip Commands ................................................................................. 114

Technical Data ................................................................................................................... 126

Appendix ............................................................................................................................ 134

©1989-2021 Lauterbach GmbH

27-Jul-20 Update description of command: SYStem.Option MAPCACHE.

20-Dec-19 New commands: SYStem.Option DSYNC, SYStem.Option HoldReset.

17-Jul-19 New commands: SYStem.Option MAPCACHE, SYStem.Option SLOWRESET.

28-Jan-19 New command: SYStem.Option EndInitProtectionOverride.

©1989-2021 Lauterbach GmbH

Caution: To prevent debugger and target from damage it is recommended to

Recommendation for the software start:

©1989-2021 Lauterbach GmbH

Brief Overview of Documents for New Users

• “T32Start” (app_t32start.pdf): T32Start assists you in starting TRACE32 PowerView instances

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

- Choose Help menu > Processor Architecture Manual.

©1989-2021 Lauterbach GmbH

Debugging an Infineon TriCore device requires a

To connect to the target the following Debug Cables can be

• Debugger for TriCore Automotive

• Debugger for TriCore (Standard)

• POWER DEBUG INTERFACE / USB 3

• POWER DEBUG INTERFACE / USB 2

• POWER DEBUG PRO

• POWER TRACE / ETHERNET

The DEBUG INTERFACE (LA-7701) cannot be used for debugging TriCore.

Software-only Debugger for XCP

©1989-2021 Lauterbach GmbH

Lauterbach offers an off-chip trace solutions for AURIX

Tracing requires either the PREPROCESSOR SERIAL

or a POWER TRACE SERIAL licensed for the TriCore

Parallel Off-chip Trace

Co-Processor Debugging (PCP/GTM)

Multicore Debugging and Tracing

• An installer is available for a complete TRACE32 installation under Windows.

POWER DEBUG USB INTERFACE / USB 3

POWER DEBUG INTERFACE / USB 3

©1989-2021 Lauterbach GmbH

• “Debugger Basics - SMP Training” (training_debugger_smp.pdf): SMP debugging.

• “AURIX Trace Training” (training_aurix_trace.pdf): Training for AURIX devices.

Demo and Start-up Scripts

hardware/ Ready-to-run debugging and flash programming demos for evaluation

Recommended for getting started!

kernel/ Various OS Awareness examples.

compiler/ Compiler examples.

fdx/ Example applications for the FDX feature.

©1989-2021 Lauterbach GmbH

©1989-2021 Lauterbach GmbH