Debugger Tricore
Debugger Tricore
TRACE32 Directory
TRACE32 Index
TriCore ......................................................................................................................................
History ................................................................................................................................ 7
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
FAQ ..................................................................................................................................... 54
Tracing ............................................................................................................................... 55
On-chip Trace (OCDS-L3) 55
©1989-2020 Lauterbach GmbH
TriCore Debugger and Trace 2
Quick Start for Tracing with On-chip Trace (OCDS-L3) 55
Supported Features 56
Trace Control 57
Trace Evaluation 57
Impact of the Debugger on FPI Bus Tracing 57
Simple Trace Control 58
Examples 58
Version 21-Feb-2020
History
31-Aug-18 Picture and short description of PowerTrace Serial added. New command SYStem.Option
ResetMode.
Power down:
• Switch off the target power.
• Disconnect the debug cable from the target.
• Close the TRACE32 software.
• Power OFF the TRACE32 hardware.
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.
Architecture-independent information:
• “Debugger Basics - Training” (training_debugger.pdf): Get familiar with the basic features of a
TRACE32 debugger.
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:
• “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.
This chapter gives an overview of available Lauterbach tools for the TriCore architecture.
Debugger
The Debug Cable comes with a license for debugging. Detailed information is available in chapter “Debug
Cables” (tricore_app_ocds.pdf). Lauterbach also offers various “Adapter 16-pin 100 mil to 50 mil”
(tricore_app_ocds.pdf).
Furthermore it is required to use a Debug Module from the POWER series, e.g.
• POWER TRACE II
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.
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 137.
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.
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.
©1989-2020 Lauterbach GmbH
TriCore Debugger and Trace 11
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:
• 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
Windows / Linux / Mac OS
Target
Debug Cable
PODBUS SYNC
POWER DEBUG USB INTERFACE / USB 3
USB LAUTERBACH
Connector
POWER
SELECT
Cable
Debug
TRIG
EMULATE
DEBUG CABLE
DEBUG CABLE
USB
LAUTERBACH
POWER
7-9V
PODBUS OUT
• “Application Note Debug Cable TriCore” (tricore_app_ocds.pdf): All about the TriCore debug
cables and available accessories.
• “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.
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:
flash/ Binaries for target based programming and example declarations for
internal flash.
etc/ Various examples, e.g. data trace, terminal application, PCP debugging,
MCDS, …
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.
• Trace configuration
• “Flash”, page 29
• “Troubleshooting”, page 53
• “FAQ”, page 53
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.
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.
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.
Data.LOAD.Elf myprog.elf
The sub-command of the Data.LOAD command (here, Elf) depends on the file format generated by
the compiler. For information on the compiler sub-commands, refer to section 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.
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>.
SYStem.RESet
*) These commands open windows on the screen. The window position can be specified with the WinPOS
command.
SYStem.CPU TC275TE
Select the cores you want to debug. Do this with the CORE.ASSIGN command before running the
SYStem.Up command, e.g.:
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.:
PSTEP tc275te_smp_demo_multisieve.cmm
Copy the demo script and adjust it to your needs to get started with your own application in SMP
mode.
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.
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:
For details on “CORE=”, please refer to “Config file settings for single device solution” in ICD Debugger
User’s Guide, page 37 (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 39 (debugger_user.pdf).
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.:
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 51 (debugger_user.pdf).
4. Summary
All steps described above are included in the AMP multisieve demo scripts, e.g.:
Copy the demo script and adjust it to your needs to get started debugging your own application in AMP
mode.
For multicore debugging and tracing, TRACE32 supports two different setups:
The following table gives an overview of the differences between SMP and AMP:
SMP AMP
Recommended for Required for heterogenous systems, e.g. debugging TriCore concurrently
RTOS (esp. with with GTM core
dynamic core/thread
assignment)
To get started with a new AURIX target, we recommend to start with our “Demo and Start-up Scripts”,
page 13. (~~/demo/tricore/hardware/):
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.
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.
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:
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.
For background information about the term access class, see “TRACE32 Glossary” (glossary.pdf).
D Data
IC Instruction Cache
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:).
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.
(up to AUDO-FG)
(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.
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.
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.
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.
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.
©1989-2020 Lauterbach GmbH
TriCore Debugger and Trace 28
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.
• FLASH.Auto
• FLASH.ReProgram (recommended)
All these steps, including device-specific declarations, are provided in the flash demo scripts. Use
General help for flashing is available in chapter “FLASH” in General Commands Reference Guide F, page
39 (general_ref_f.pdf).
AURIX devices have several security features. Be careful not to lock yourself
out when flashing a device!
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.:
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:
Hint: Use the option /NoCODE of the Data.LOAD command to load only the symbols (without downloading
code), e.g.:
When flashing the HSM, use the same precautions as described in “Flashing and Debugging AURIX
Devices”, page 30.
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 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.
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.
• Performance counters in the core debug controller of each core. These counters are available in
AUDO MAX and AURIX CPUs.
- 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.
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
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
Beta breakpoint
Break.Set sYmbol.EXIT(sieve)-2
/Program /Beta
Runtime
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.
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
BMC.state
Result:
A complex example recording the results in BTrace can be found in the demo folder.
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.
Wait 1.s
The SNOOPer.List and SNOOPer.PROfileChart.COUNTER commands allow to specify the counters you
want to display. The benchmark counters of the TriCore are named as follows.
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.:
See the chapter “CPU specific TrOnchip Commands”, page 105 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
PSTEP ~~/demo/tricore/etc/watchpins/aurix_watchpin.cmm
The watch event can be routed to an output pin using the TrOnchip.WatchPin feature, e.g.:
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.:
For a sample pin mapping see chapter “Features and Restrictions”, page 39.
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.
; 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))
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.
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.
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.
Please see the CACHE command group to directly view the cache contents.
Cache contents can be displayed in various windows by changing the access class, e.g. with:
• Data.dump DC:0x80000000
instead of
• Data.dump D:0x80000000
Use SYStem.Option DCREAD ON to redirect all data memory accesses (D:) to cached data memory
accesses (DC:). 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. Please note that cache access is not
possible during CPU runtime.
AURIX Devices
• All early AURIX devices (TC27x-Astep, TC2Dx) do not need special handling for cache access.
• All later devices (TC27x-Bstep, TC29x, TC26x, …) implement the caches differently: As soon as
cache access is enabled, the devices follow a security requirement cleaning the cache contents.
Thus, access has to be enabled either at startup or manually.
- TRACE32 will automatically enable cache access when starting the device with SYStem.Up.
Due to the chip internal structure of the cache it may happen, that a cache line is already marked as valid
while its contents are not yet updated. Executing an isync or dsync instruction will guarantee
synchronicity.
Please note that TC1.6E (efficiency) cores implement a small data read buffer instead of a data cache. The
data read buffer is not accessible by TRACE32.
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.
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.
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 52.
• 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.
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.
For the most common CPUs and 3rd-party tools, PRACTICE start-up scripts (*.cmm) can be found under
~~/demo/tricore/etc/.
Details about electrical requirements and connector pin-outs can be found in “Application Note Debug
Cable TriCore” (tricore_app_ocds.pdf).
Debugging a TriCore device with the Memory Protection Unit enabled requires different device-dependent
strategies.
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 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.
The first step is to prevent the debugger from configuring any on-chip breakpoint:
1. Single-stepping
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
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:
FLASH.AUTO ALL
NOTE: Software breakpoints in FLASH drastically reduce the life-time of your FLASH.
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.
VTREF
soft reset
RESET
TRACE32 re-
up up
status attaching
VTREF
soft reset
RESET
TRACE32 re-
up up
status attaching
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”
(tricore_app_ocds.pdf).
• 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.
VTREF
RESET
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.
VTREF
RESET
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.
VTREF
RESET
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.
VTREF
RESET
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.
VTREF
RESET
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.
VTREF
RESET
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.
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.
• 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 52), the suspend signal will be kept active.
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
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.
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.
In certain situations TRACE32 will download and/or execute code to your target to achieve specific actions.
This includes but is not limited to:
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:
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.
In this section:
• SYStem.Up Errors
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.
For more information on pins, signals and daisy-chaining please refer to “Debug Interface Configuration”
(tricore_app_ocds.pdf).
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:
FAQ
Please refer to our Frequently Asked Questions page on the Lauterbach website.
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.
Only basic information will be given here, details and advanced tasks are described in separate documents,
see “Further Reading”, page 60.
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 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).
It is assumed that you are tracing a TC1766ED B-Step on an Infineon TriBoard-TC1766.300 or above.
Load your application and prepare for debug. For details, see “Single-Core Debugging - Quick Start”,
page 16.
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.
Go ; start tracing
Supported Features
• Program Flow Trace for TriCore and PCP
• FPI Bus Trace (independent of TriCore or PCP), both System Peripheral Bus (SPB) and Remote
Peripheral Bus (RPB, if available)
• Timestamps
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.
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.
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.
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
Enable the trace as long as the function sieve() is executed. Execution in sub-functions is not recorded.
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.
Trace all write accesses to variable flags with offset 0xC, program flow trace is disabled to save on-chip
trace memory.
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.
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.
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).
The Aurora Giga-Bit Trace (AGBT) is a high-speed serial trace for AURIX devices.
For more information, see chapter “Parallel Off-chip Trace - OCDS-L2 Flow Trace (Analyzer)”, page 137.
This chapter explains TriCore specific commands only. All other commands are documented in the
“General Commands” (general_ref_<x>.pdf) manuals.
Enables the OCDS-L2 PCP trace. The CPU trace port has to be switched manually to Peripheral Control
Processor output. See the demo scripts for processor specific settings.
The BMC (BenchMark Counter) commands provide control and usage of the on-chip benchmark and
performance counters if available on the chip.
For information about architecture-specific BMC commands, see command descriptions below.
Format: BMC.state
I
A
C D E F G H
1 For command descriptions, please refer to the commands in this chapter. For example, for the
AutoInit check box, see BMC.AutoInit. Note that some commands belong to the SNOOPer and the
MCDS command group.
A Clock cycle counter. The clock cycle counter is activated if at least one of the performance counters of
the core debug controller is activated.
C Event selection. The drop-down list shows the name of the event together with a short description
in parentheses. The available events are device-specific.
See BMC.<counter>.EVENT.
D 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.
E Size selection. The performance counters from the core debug controller have a fixed width of 31
bit. For the event counters from the MCDS sizes between 16 and 64 bit can be selected. These
sizes are implemented by cascading 16 bit counters.
See BMC.<counter>.SIZE.
F Ratio selection. Allows to calculate a relation between two counters. The result is displayed in the
column marked with H. See BMC.<counter>.RATIO.
G Counter value.
I Duration of the measurement. This value is calculated from the clock frequency and the clock
counter.
C
A B
A Event selection. The performance counters of all cores are programmed to count the same event.
Some events are not available on all cores or the implementation differs between cores. The
configuration window shows the event effectively programmed for each core below the drop-down
list. If an event is not available on a core, the description is shown in gray.
TRACE32 calculates and displays time information, if the core clock is known. For example, the clock is set
to 100 MHz as follows.
BMC.CLOCK 100.Mhz
This clock frequency will be set automatically in case automatic computation of clock frequencies is enabled
using command CLOCK.ON.
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.
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.
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.
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.
For descriptions of the commands on the XCP tab, see “XCP Debug
Back-End” (backend_xcp.pdf).
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.
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.
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).
Chip 0 Chip 1
• 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
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
<chip_index>: 1…i
<core_index>: 1…k
Default chipindex: 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 debuggers 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 none generic chip is created at the default chipindex.
None generic chips have a fixed amount of sub-cores with a fixed CPU type.
First all cores have successive chip numbers at their GUIs. Therefore you have to assign the coreindex and
the chipindex for every core. Usually the debugger does not need further information to access cores in
none 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 none
generic chip, two GUI are connected to the same coordinate or a GUI is not connected to a core. The initial
state of the system is value since every new GUI uses a new chipindex 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.
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:
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.
Default: PortPort.
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.
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.
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” (tricore_app_ocds.pdf) for details.
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).
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).
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” (tricore_app_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.
The abbreviation DXCPL stands for DAP over CAN Physical Layer by Infineon.
Default: AUTO.
• 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.
<option>: High
Low
HIGHWHENSTOPPED
LOWWHENSTOPPED
Default: High.
Controls the WDTDIS pin of the Automotive Debug Cable. This option is only available if an Automotive
Debug Cable is connected to the PowerDebug module.
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.
The current setting can be obtained by the PORTSHARING() function, immediate detection can be
performed using SYStem.DETECT PortSHaRing.
Default: TC1797.
<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.
Default: Denied.
This option declares if an intrusive memory access can take place while the CPU is executing code. To
perform this access, the debugger stops the CPU shortly, performs the access and then restarts the CPU.
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).
Enable Stop the CPU shortly to perform a memory read or write while the
program execution is running.
Each short stop takes 1 … 100 ms depending on the speed of the debug
interface and on the size of the read/write accesses required.
Denied No intrusive memory read or write is possible while the CPU is executing
the program.
Nonstop The program execution cannot be stopped and the real-time behavior of
the CPU is not affected.
Nonstop reduces the functionality of the debugger to:
• Run-time access to memory and variables
• Trace display
The debugger inhibits the following:
• To stop the program execution
• All features of the debugger that are intrusive (e.g. spot break-
points, performance analysis via StopAndGo, conditional break-
points etc.)
Default: Enable.
Denied Denies stopping the target. This includes manual stops and stop
breakpoints. However, short stops, such as spot breakpoints, may still be
allowed.
Example:
SYStem.CpuBreak Denied
Default: Enable.
Spotting is an intrusive way to transfer data periodically or on certain events from the target system to the
debugger. As a result, the program is not running in real-time anymore. For more information, see
SYStem.CpuBreak and SYStem.MemAccess.
Example:
SYStem.CpuSpot Denied
Break.Set main /Spot ; spot breakpoint results in an error message
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.
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.
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.
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.
CPU The debugger performs non-intrusive memory accesses via the CPU
internal buses (FPI Bus).
<mode>: Down
NoDebug
Prepare
Go
Attach
Up
StandBy
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 49.
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 save value for all CPUs.
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.
<x>: 0
Default: CerBeruS.
Handles the behavior of TRACE32 with respect to the CBS_ACCEN<x> registers of the Cerberus block.
<value> The value is written to the register when the core is started.
<mask> Arbitrary mask. For valid masks, refer to the TriCore User Manual.
Example 3: Enable access from the debugger and two more masters (described by <mask>) to the
Cerberus block. The two syntax examples are equivalent:
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.
Default: OFF.
If disabled, physical memory is accessed directly (as seen from the bus).
If enabled, memory accesses 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.
Default: OFF
Automatically executes a dsync instruction to make sure the CPU writes all data back to caches and
memory.
This system option uses target code execution (see “Target Code Execution”, page 52).
TriState (default) All drivers of the debug port are switched 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.
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).
Default: AUTO.
Handles the behavior of TRACE32 with respect to the ENIDIS bit of the CBS_OSTATE register.
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.
Configure the minimum time the debugger holds the RESET line active on SYStem.Up or SYStem.Mode
Go.
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.
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.
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.
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.
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.
Sets the number of implemented interrupts. The on-chip trace uses this together with SYStem.Option
INTSTART to determine if an interrupt occurred.
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.
<signature> Specify custom upper word for the DAP turn-off command on which the
enable sequence is based. Not required for normal operation.
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.
Default: OFF.
• SYStem.Mode Up
• SYStem.Mode Go
• SYStem.DETECT CPU
ON LBIST expected. TRACE32 waits for the end of the LBIST gap and
reconfigures the debug connection automatically.
AUTO Automatic LBIST handling. TRACE32 waits for the end of the LBIST gap
and reconfigures the debug connection automatically.
Default: ON.
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 intrusive, i.e., it modifies status bits of the MTU.
Default: OFF.
If enabled the nOCDSE line of the Debug Cable is driven low, otherwise it is:
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.
Default: OFF.
Enables evaluation of Data Access Overlay (OVC) configuration during memory accesses.
Only supported for AURIX devices.
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.
Default: ON.
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.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.
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.
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.
<mode>: Halt
RestoreGo
RunRestore
Sets the behavior in case of a reset. For a detailed explanation, see Debugging through Resets.
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.
<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.
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.
Default: 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.
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.
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.
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.
Sets the start address of the trap vectors. The on-chip trace uses this if a trap occurred.
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.
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.
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.
Format: SYStem.state
Opens the SYStem.state window with settings of CPU specific system commands. Settings can also be
changed here.
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.
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.
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.
NOTE: Configuring a BreakBus as BreakIN and BreakOUT at the same time will
result in undefined behavior.
<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.
<source>: TriCore
MCDS
DMA
SBCU
RBCU
MLI0
MLI1
Default: BreakBus0.
NOTE: Configuring a BreakBus as BreakIN and BreakOUT at the same time will
result in undefined behavior.
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.
(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.
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.
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.
See TrOnchip.CountX.
Default: OFF.
When enabled, TriCore will break on an break signal distributed via the BreakBus which TriCore listens to.
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.
Format: TrOnchip.RESet
Default: ON.
NOTE: When this feature is disabled, the TriCore CPU will treat all debug
instructions as nop instructions. This will silently disable all software
breakpoints.
Default: DISable.
Default: DISable.
When enabled, the suspend switch generates a suspend signal independent of any state or mode.
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).
Format: TrOnchip.SusTarget.<target>
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).
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.
Default: ON.
The trace hardware supports trace data compression. Redundant trace cycles will be not recorded and
displayed. For better trace memory usage it should be enabled.
The trace will not stop immediately after trigger if a trigger delay is programmed.
Default: EDGE.
This defines if the external trigger pin on the preprocessor (only LA-7879) reacts on level (COMP) or edge
(EDGE).
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 (-).
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
Example 1: Stop the program execution when the function sieve is entered.
; Select the data range as source for the trigger event 0 generation and
; assign the breakpoint type Alpha
TrOnchip.TR0.Address Alpha
TrOnchip.TR0.CYcle Write
TrOnchip.TR0.WATCH OFF
Format: TrOnchip.state
<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).
JTAG Connector
A standard 2 x 8 pin header (pin-to-pin spacing: 0.1 inch = 2.54 mm.) is required on the target.
• 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.
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.
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.
7 TDI Test Data In No other devices in the JTAG chain are allowed
between the Debug Cable and the TriCore.
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.
For more information on connectors, adapters, converters, and cables, see ”Application Note Debug
Cable TriCore” (tricore_app_ocds.pdf).
AMP 40 Connector
• 2x20 connector
• Connector example:
Signal description:
• Connector example:
Signal description:
Samtec 60 Connector
• 2x30 high-speed socket strip connector
Samtec QSH-030-01-L-D-A-K-TR with pick & place pad, tape & reel
Signal description:
Operation Voltage
Mechanical Dimensions
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” (tricore_app_ocds.pdf).
Operation Frequency
Operation Voltage
Dimension
LA-7928 PP-TRICORE-3.3V
PIN1
/ 100
DRILL O
937
488
200
362
3500
SIDE VIEW
675
413
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
Available Tools
INSTRUCTION
INTEGRATOR
SIMULATOR
MONITOR
POWER
DEBUG
TRACE
FIRE
CPU
ICD
ICD
ICD
ICE
PXB4260 YES YES YES
TC10GP YES YES YES
TC1100 YES YES YES
TC1115 YES YES YES
TC1124 YES YES
TC1128 YES YES
TC1130 YES YES YES
TC1161 YES YES YES
TC1162 YES YES YES
TC1163 YES YES YES
TC1164 YES YES YES
TC1165 YES YES YES
TC1166 YES YES YES
TC1167 YES YES
TC1182 YES YES
TC1184 YES YES
TC1191 YES YES
TC1193 YES YES
TC1197 YES YES
TC1198 YES YES
TC11IA YES YES YES
TC11IB YES YES YES
TC11IC YES YES YES
TC1337 YES YES
TC1367 YES YES
TC1387 YES YES
TC1387ED YES
TC1724 YES YES
TC1724ED YES YES
TC1728 YES YES
TC1728ED YES YES
SIMULATOR
MONITOR
POWER
DEBUG
TRACE
FIRE
CPU
ICD
ICD
ICD
ICE
TC1732 YES YES
TC1733 YES YES
TC1734 YES YES
TC1735 YES YES
TC1736 YES YES
TC1736ED YES YES
TC1738 YES YES
TC1746 YES YES
TC1762 YES YES YES
TC1764 YES YES YES
TC1765 YES YES YES
TC1766 YES YES YES
TC1766ED YES YES YES
TC1767 YES YES
TC1767ED YES YES
TC1768 YES YES
TC1775 YES YES YES
TC1782 YES YES
TC1782ED YES YES
TC1783 YES YES
TC1783ED YES YES
TC1784 YES YES
TC1784ED YES YES
TC1791 YES YES
TC1791ED YES YES
TC1792 YES YES YES
TC1793 YES YES
TC1793ED YES YES
TC1796 YES YES YES
TC1796ED YES YES YES
TC1796L YES YES YES
TC1797 YES YES
TC1797ED YES YES
TC1798 YES YES
TC1798ED YES YES
TC1910 YES YES YES
TC1912 YES YES YES
TC1920 YES YES YES
TC212L YES YES
TC213L YES YES
TC214L YES YES
SIMULATOR
MONITOR
POWER
DEBUG
TRACE
FIRE
CPU
ICD
ICD
ICD
ICE
TC222L YES YES
TC222S YES YES
TC223L YES YES
TC224L YES YES
TC233LF YES YES
TC233LP YES YES
TC234L YES YES
TC234LA YES YES
TC234LF YES YES
TC234LP YES YES
TC234LX YES YES
TC237LF YES YES
TC237LP YES YES
TC260D YES YES
TC260DU YES YES
TC264D YES YES
TC264DA YES YES YES
TC264DE YES YES YES
TC264DU YES YES
TC265D YES YES
TC265DE YES YES YES
TC265DU YES YES
TC267D YES YES
TC270T YES YES
TC270TP YES YES
TC270TU YES YES
TC274DE YES YES
TC275T YES YES
TC275TA YES YES
TC275TE YES YES
TC275TF YES YES
TC275TP YES YES
TC275TU YES YES
TC277T YES YES
TC277TE YES YES
TC277TF YES YES
TC277TP YES YES
TC277TU YES YES
TC290T YES YES
TC290TP YES YES
TC290TU YES YES
SIMULATOR
MONITOR
POWER
DEBUG
TRACE
FIRE
CPU
ICD
ICD
ICD
ICE
TC297T YES YES
TC297TA YES YES
TC297TE YES YES
TC297TF YES YES
TC297TP YES YES
TC297TU YES YES
TC298T YES YES
TC298TE YES YES
TC298TF YES YES
TC298TP YES YES
TC298TU YES YES
TC299T YES YES
TC299TE YES YES
TC299TF YES YES
TC299TP YES YES
TC299TU YES YES
TC2D5T YES YES
TC2D5TE YES YES
TC2D7T YES YES
TC2D7TE YES YES
TC336DT YES YES
TC337DA YES
TC337DT YES YES
TC357TT YES YES
TC364DP YES YES
TC367DP YES YES
TC377 YES YES
TC377TP YES
TC377TX YES
TC387 YES
TC387QP YES
TC389 YES
TC389QP YES
TC397 YES YES
TC397X YES YES
TC397XA YES YES YES
TC397XA_A-STEP YES YES YES
TC397XE YES YES YES
TC397XE_A-STEP YES YES YES
TC397XP YES
TC397XX YES YES YES
SIMULATOR
MONITOR
POWER
DEBUG
TRACE
FIRE
CPU
ICD
ICD
ICD
ICE
TC399 YES YES
TC399X YES YES
TC399XE YES YES YES
TC399XE_A-STEP YES YES YES
TC399XP YES
TC399XX YES YES YES
Compilers
Product Information
Additional Options
LA-2102 AD-HS-16 Adapter Half-Size 16 pin
LA-3873 CON-AUTO26-JTAG14 Conv. AUTO26 to JTAG14 OnCE
LA-3874 CON-AUTO26-MICTOR38 Conv. AUTO26 to MICTOR38 MPC5xxx
LA-3875 CON-AUTO26-SAMTEC50 Conv. AUTO26 to Samtec50 MPC5xxx
LA-3815 CON-JTAG16-DAP Conv. 16 Pin JTAG to DAP for TriCore/XC2000
LA-3829 CONV-SAM40/22-TC Conv. Samtec40 to Samtec22 TriCore AGBT
LA-3872 CONV-SAM40/AUTO- Conv. Sam40 HSTP+AUTO26+JTAG14 to Samtec22
SAM2
LA-3871 CONV-SAM40/AUTO26- Conv. Sam40 HSTP+AUTO26+JTAG14 to Samtec34
SA
LA-7753A DEBUG-MPC5500-A JTAG Debugger for MPC5xxx (ICD) Additional
LA-3719A DEBUG-RH850-A Debugger for RH850 Additional
LA-3739 DEBUG-RH850-AUTO Debugger for RH850/V850 Automotive
LA-3501 GALVANIC-ISOLATION Galvanic Isolation for Debug Cable
LA-7843A JTAG-ARMV7-A/R-A Debug Cortex-A/-R (ARMv7 32-bit) Add.
LA-3743A JTAG-ARMV8-A/R-A Debug Cortex-A/R (ARMv8 32/64-bit) Add.
LA-7844A JTAG-CORTEX_M-A Debug Cortex-M (ARMv6/7/8 32-bit) Add.
LA-7960X MULTICORE-LICENSE License for Multicore Debugging
LA-7759A OCDS-C166S-V2-A OCDS Debugger for XC2000/C166S V2 Additional
Additional Options
LA-1228 FLEXEXT-SAM-QTH-QSH Flex Ext. for SAM 60 pin QTH-QSH series 05.00
LA-1238 FLEXEXT-SAM-QTH- Flex Ext. for SAM 60 pin QTH-QSH series 12.00
QSHL
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 55.
It is assumed that you are tracing a TC1766 B-Step on an Infineon TriBoard-TC1766.300 or above.
Load your application and prepare for debug. See “Quick Start for OCDS-L1 Debugger” for more details.
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.
On TriBoard-TC1766.300 the trace connector is connected to GPIO port 5 which needs to be set up for
tracing.
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.
Go ; start tracing
Recording is stopped when the TriCore halts, e.g. when a breakpoint was hit.
Supported Features
• Program Flow Trace for TriCore
• Timestamp
NOTE: Note that OCDS-L2 does not allow to trace TriCore and PCP at the same
time.
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).
Housing no no yes
Threshold 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 TrOnchip.TCompress is enabled, 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.
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).
• 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.
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:
[EMU]BREAK0 1 1
[EMU]BREAK1 0 0
[EMU]BREAK2 0 1
Example 2: Trace 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.
Trigger recording at address 0xA0001200. The trace will stop recording after a programmable period, see
Trace.Trigger for more information.
When address 0xA0001400 is reached, write a sample into the trace memory.
Error Diagnosis
Error messages are displayed in the upper left corner of the Trace.List window:
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:
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.
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.
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
1. HARDERROR
2. FLOWERROR
The traced data are not consistent with the code in the target memory. Possible reasons are: