Debugger User

ICD Debugger Users Guide
TRACE32 Online Help

TRACE32 Directory
TRACE32 Index
TRACE32 Documents ......................................................................................................................
ICD In-Circuit Debugger ................................................................................................................
ICD Debugger User's Guide ......................................................................................................
Warning ....................................................................................................................................
Basics .......................................................................................................................................
Restrictions ..............................................................................................................................
Debugger Licenses .................................................................................................................
Configuration ...........................................................................................................................
Configuration Overview
PODBUS Interface Card
Parallel - PODBUS Converter
SCU -PODBUS Converter
ICD Configuration for JTAG/BDM Debugger
10
ICD Configuration for ROM Monitor
11
Expanded Configurations
13
Installation ...............................................................................................................................
14
Software Installation
14
Command Line Arguments for Starting TRACE32
15
20
Parallel PODBUS Converter
21
Serial Line Configuration
22
Using Multiple Devices on one PODBUS
22
Multicore Debugging
23
General Information
23
Tool Configuration for Single Device Solution
23
Tool Configuration for Multi Device Solution
24
Hardware Configuration for Multicore-Debugging
25
Multicore Licenses
30
Install Debugger Software for Multicore Debugging
31
Setup and Start of TRACE32 Software
32
General
32
TRACE32 Multicore Configuration
41
Daisy Chain Settings
42
1989-2016 Lauterbach GmbH
Multiplex Settings
45
Start Stop Synchronisation
46
Settings
46
Result of start/stop synchronization
49
Synchronisation Time Delay
51
Multicore Debugging Summary
52
Multiprocessor Debugging
53
Program Start and End
54
Installation as TRACE32-ICE Extension ................................................................................
55
55
58
Working with the ICD Debug System ....................................................................................

Available Device Prompts
59
59
ICD Commands and Procedures ...........................................................................................
60
Mapping the EPROM Simulator
61
Break
63
eXception
64
eXception.NMIBREAK
65
eXception.NMIPOL
65
eXception.RESetPOL
65
RESet
66
SYStem
67
SYStem.BdmClock (BDM only)
67
SYStem.Mode
68
SYStem.Option
69
Trigger
70
Trigger.Set (BDM only)
70
Trigger.Out (BDM only)
70
Trace Methods .........................................................................................................................

ART - Advanced Register Trace
71
72
Debugging on Mixed Level
72
Debugging on HLL Level
74
SNOOPer
75
Applications for the SNOOPer
75
Technical Data of the SNOOPer
76
SNOOPer via Real-Time Memory Access
77
SNOOPer via Debug Communication Channel
80
Snooping the Program Counter
83
Software Trace .........................................................................................................................
85
The Trace Format
87
Operation Modes
88
Address and Data Trace
88
Program Flow Trace
89
Software Trace Configuration
90
Software Trace Configuration in Code
91
Software Trace Configuration in the TRACE32 Software
95
Display the Software Trace
98
Software Trace as a Flow Trace for the SH4
99
Background
99
Display the On-chip Trace
100
Software Trace Format
101
How to use the Software Trace
102
Software Trace as a Flow Trace for the MPC860
106
Background
106
106
107

Version 24-May-2016
29-Jan-15
Extended Command Line Arguments for Starting TRACE32 with a fourth example showing
how to handle white spaces and quotation marks.
Warning
NOTE:
To run the ICD Debugger a target system is required

Do not connect or disconnect PODBUS devices from target while target power
is ON
Warning
Basics
ROM Monitor and JTAG/BDM Debuggers are low cost microprocessor development systems working for
numerous CPUs. A number of devices is available which can be combined very flexible to the developer's
needs.
In Circuit Debugger Module (supports BDM, ONCE, JTAG, COP ports)
ROM Monitor Interface with EPROM Simulator
Serial Linked ROM Monitor
Custom Linked ROM Monitor
Special Debugger Variants (e.g. public domain hardware or EVA boards)
ICD State Analyzer Module with Performance and Code Coverage functions
Serial Line Remote Debugger
Stimuli-Generator
Clock-Generator
Evaluation Boards
These devices are connected to the PC via the PODBUS Interface Card, USB2.0/1.1 or Ethernet. The
corresponding software on PC runs with Windows-95/98/ME/NT/2000/XP or Linux and is compatible to the
TRACE32-ICE in-circuit emulator system.
In addition to the high speed interface the PODBUS Interface Card contains a universal counter system and
a trigger input/output.
You can also use the ICD Debugger as an extension for the TRACE32-ICE system e. g. to control additional
CPUs on the target system. The devices are connected to the PODBUS connector of the emulation
controller unit. In this configuration the software is available for the same operating systems as the
TRACE32-ICE system.
Restrictions
If the stimuli generator is used, it must be the first device connected to the PODBUS interface.
There is a maximum of five devices which can be connected to the PODBUS.
Basics
Debugger Licenses
For debugging it is necessary to obtain the licenses for the particular processors. The license is saved within
debug cable. For some processors, it is possible to save more than one license into the same cable. Those
licenses are available as so-called extension licenses (X-licenses, in case of processors belonging to the
same family) or additional licenses (A-licenses).
The licenses are dropped within debug cable into a so-called license matrix, consisting of 3 rows and 4
columns (example):
ARM Family
ARM7
LA-7746
ARM9
LA-7742X
ARM11
LA-7765X
C55x Family
TMS320C55x
LA-7830A
TMS320C54x
LA-7831X
TI DSP Trace
Support
LA-3802X
C6400 Family
TMS320C6400
LA-7838A
The entries in each row within the table shown above are associated to
Same TRACE32 executable
Same serial number
Same maintenance contract
Debugger Licenses
The licenses located in the currently used debug cable can be viewed by typing the VERSION command at
the TRACE32 command line or by choosing Help menu > About TRACE32:
X-Licenses are possible for processors of the same family as the base license or associated A-License. To
learn which license combinations are possible please contact LAUTERBACH sales department or
distributor.
Debugger Licenses
Configuration
Configuration Overview
Regarding the PODBUS interface there are three possible configurations:
PODBUS Interface Card (PODPC)
Parallel - PODBUS Converter (PODPAR)
SCU - PODBUS Conveter (PODSCU)

Direct connection
or
Extension Cable
for PODBUS 0.5m
Interface Cable
for PODBUS 1.5m
PODBUS
Interface
Card
Addr.
Select
Jumper
Dev.1
Dev.2
Trigger In/Out
MESS Out
Basic configuration
The PODBUS Interface Card requires no extra power supply. The counter system on the PODPC card
provides measurement functions as described in the Count command group. The BNC connector is used
to in- or output the triggers from the debug module.
Configuration
Parallel - PODBUS Converter
PC
Standard parallel cable

(PC male,
PODPAR female)
Direct connection or
extension cable for PODBus
Dev. 1
Direct connection or
extension cable for PODBus
Dev. 2
PODPAR
Power
7-9V
Trigger
In/Out
Please use only the standard power supply unit, which you will receive together with the PODPAR interface
box. The trigger connector is used to in- or output the triggers from the debug module.
SCU -PODBUS Converter

The PODSCU is used together with the SCU of the standard TRACE32 emulator. The intention of this
solution is to provide an Ethernet interface for the PODBUS based debug system.
No extra power supply is required. The trigger connector is used to in- or output the triggers from the debug
module. The PODSCU contains the same counter system as the PODPC card.
Configuration
ICD Configuration for JTAG/BDM Debugger

Interface Cable
PODPC or
PODPAR or
PODSCU
(Power)
Debug
Module
EPROM
Simulator
(optional)
...
or direct
connection if
PODPAR
Target
Cable
CPU CLK
JTAG/BDM Connector
EPROM
Target
Basic configuration for JTAG/BDM Debuggers
Together with the debug module you receive a single cable to connect the CPU clock to the target cable
plug. This way you can use the divided CPU clock as BDM clock. This option is not available at all ICD
Debuggers.
Optionally an EPROM simulator can be used to load and debug programs in the ROM area. One EPROM
simulator is used to simulate two 8 bit or one 16 bit EPROM. For that you get 3 adapters together with the
EPROM simulator, one for 16 bit EPROMs, one for 8 bit high and one for 8 bit low. To simulate EPROMs with
a wider bus size, two or more EPROM simulators can be put together.
10
Configuration
ICD Configuration for ROM Monitor

Interface Cable
PODBUS or
PODPAR or
PODSCU
EPROM
Simulator
(ROM Monitor
Interface)
or direct
connection if
PODPAR
Other
Device
(optional)
...
Target
Basic configuration for the ROM Monitor Interface

One EPROM simulator is used to simulate two 8 bit or one 16 bit EPROM. To simulate EPROMs with a
wider bus size, two or more EPROM simulators can be chained together. NOTE: The address lines of both
adapters of an EPROM simulator are directly connected. If the address lines on the target are not the same
(e.g. write enable lines for FLASH), they must be isolated from the target on one adapter.
Together with the EPROM simulator you get 3 adapters. One for 16 Bit EPROMs, one for 8 Bit High and one
for 8 Bit Low.
11
Configuration
On each adapter there are three extra pins for GND, NMI and RES. NMI and RES are outputs from a HTC
Schmitt trigger.
1
Male connector to EPROM Simulator
GND
NMI
RES
Adapter for the EPROM Simulator

The RESet pin of one adapter can be connected to the reset pin of the CPU to give the ROM Monitor
program the possibility to control the RESET of the CPU.
The NMI pin of one adapter can be connected to the NMI pin of the CPU to manually stop a program
running on the target system.
ROM Monitors are provided for CPUs without a debugging interface. To run the ROM Monitor a 8KB monitor
program ((ROM<CPUtype>.HEX) has to be loaded to the target system together with the application
program. This monitor program provides the debugging interface.
12
Configuration
Expanded Configurations
The base systems can be expanded very flexible. The following examples should give you an impression of
possible configurations.
32 Bit ROM Monitor
with Evaluation Board
PODPC
ESI
ESI
BDM Debugger
with I/O Test System
PODPC
STG
BDM
PODPAR
ESI
ESI
BDM Debugger with

32 Bit EPROM Simulator
and Evaluation Board
EVAL-166
BDM
EVAL-505
13
Configuration
Installation
In this section the installation for the ICD Debugger connected to the PC is described. The configuration of
the ICD debug system is done in the file CONFIG.T32 which must reside in the TRACE32 system directory.
See TRACE32 Installation Guide (installation.pdf).
14
Installation
Command Line Arguments for Starting TRACE32

TRACE32 can be started with and without command line arguments. If you do not pass any command line
arguments, TRACE32 starts by calling the PRACTICE start-up script t32.cmm from the TRACE32 system
directory (by default c:\t32) and expects to find the configuration file config.t32 in the same folder as
the TRACE32 executable.
If you pass command line arguments, you can adapt the start and the environment of TRACE32 to your
project-specific needs. You can define a user-specific name and location for the configuration file and your
own PRACTICE start-up script. In addition, you can pass user-defined parameters to your configuration file
and to your start-up script.
The command line syntax for Windows, Linux, and Unix is as follows:
Format:
t32m<arch>[.<x>] [-c <configfile> [<c_args>]] [-s <startup_script> [<s_args>]]
<x>
Optional for Windows and Linux, but not for Unix: file name extension of the
executable.
<arch>
Architecture, e.g. ARM in t32marm.exe stands for the ARM architecture.
-c <configfile>
By default, TRACE32 expects to find the configuration file config.t32 in the

same folder as the TRACE32 executable. An error message is displayed if the
configuration file config.t32 does not exist.
The option -c <configfile> allows you to define a user-specific name and location
for the TRACE32 configuration file.
For information about the configuration options in the configuration file, type at
the TRACE32 command line: HELP.Index "config.t32"
<c_args>
Sequence of white-space separated arguments passed to the configuration file.

The individual command line arguments are assigned to the configuration
options in the configuration file using ${n} where n is the number of the
command line argument. The numbering starts at 1
Example: HEADER=${2} means that the second <c_arg> is assigned to the
configuration option HEADER=
15
Installation
-s <startup_
script>
The option -s <startup_script> allows you to define a user-specific name and

location for your PRACTICE start-up script (*.cmm).
NOTE: If you do not pass your own start-up script, then TRACE32 starts with its
default PRACTICE start-up script t32.cmm. However, if the t32.cmm can neither
be found in the TRACE32 system directory (by default C:\t32) nor in the current
working directory, then TRACE32 starts without the t32.cmm
NOTE: If your <startup_script> contains a blank, then enclose path and *.cmm
file name with the following quotation mark types:
<single_quote><double_quote><startup_script><double-quote><single-quote>
<s_args>
Sequence of white-space separated arguments passed to the PRACTICE startup script (*.cmm).
Next:
Example 1: Passing command line arguments via a Windows shortcut to TRACE32
Example 2: Passing command line arguments to a TRACE32 configuration file (*.t32)
Example 3: Passing command line arguments to a PRACTICE start-up script (*.cmm)
Example 4: Sequence of quotation mark types if <startup_script> contains a blank
16
Installation
Example 1: Passing command line arguments via a Windows shortcut to TRACE32

This example shows how to pass TRACE32 command line arguments via a Windows shortcut to TRACE32.
The command line arguments are:
A user-defined configuration file called config_usb.t32
A user-defined PRACTICE start-up script called start.cmm

Operating System side
TRACE32 side
E
D
A
C
A
A Path and name of a TRACE32 executable.

In a default installation, all TRACE32 executables are located in C:\t32\bin\<os>\
B The option -c <configfile> allows you to define a user-specific name and location for the TRACE32
configuration file (*.t32).
C The option -s <startup_script> allows you to define a user-specific name and location for your
PRACTICE start-up script (*.cmm).
D User-defined working directory.
In the above Properties dialog box, the Start in text box sets the path for the Target text box unless different paths are specified in the Target text box.
This means for our example that the t32marm.exe searches for the files config_usb.t32 and
start.cmm in C:\t32\project_x.
E TRACE32 system directory (by default c:\t32). It is specified during the installation of TRACE32.
Normally, you do not need to change anything here.
17
Installation
Example 2: Passing command line arguments to a TRACE32 configuration file (*.t32)

The following example shows how to pass TRACE32 command line arguments from a batch file (*.bat) to
the configuration file (*.t32). The command line arguments are:
<c_arg1>: A user-defined window title for TRACE32
<c_arg2>: A network folder path containing the pdf files of the TRACE32 online help
Batch file start2_usb.bat:

rem
<c_arg1>
<c_arg2>
start C:\T32\t32marm.exe -c config2_usb.t32 " Project X" "g:\TRACE32_pdf"
TRACE32 configuration file config2_usb.t32:

// Example of a TRACE32 configuration file
OS=
ID=T32002
TMP=C:\temp
; temporary directory for TRACE32
SYS=C:\T32
; system directory for TRACE32
HELP=${2}
; help directory for TRACE32
PBI=
USB
PRINTER=WINDOWS
SCREEN=
HEADER=TRACE32 ${1}
The values passed as command line arguments to the user-defined configuration file are now used by
TRACE32:
Value of argument ${1}
Value of argument ${2}

TRACE32 now retrieves the pdfs
of the help system from this
network folder.
NOTE:
The help.t32 file of the online help must reside in the TRACE32 system
directory (by default C:\t32).
18
Installation
Example 3: Passing command line arguments to a PRACTICE start-up script (*.cmm)

The following example shows how to pass TRACE32 command line arguments from an MS batch file (*.bat)
to a PRACTICE start-up script (*.cmm). The command line arguments are:
<start_up_script>: A user-defined PRACTICE start-up script (*.cmm)
<s_args>: These hex values - 0x1 and 0x2 - are passed to the PRACTICE start-up script
Batch file start3.bat:

rem
start C:\T32\t32marm.exe
-c config3_usb.t32
<start_up_script> <s_args>
-s start3.cmm
0x1 0x2
PRACTICE start-up script start3.cmm:

LOCAL &arg1 &arg2
ENTRY &arg1 &arg2
;Declare local PRACTICE macro

;Assign value of command line arguments
;to the macros
AREA.view
;Open an AREA.view window
PRINT "Arguments passed to the start-up script: " OS.PPF()
PRINT "Value 1: &arg1"
PRINT "Value 2: &arg2"
The values passed as command line arguments to the PRACTICE start-up script are printed to the
AREA.view window.
Example 4: Sequence of quotation mark types if <startup_script> contains a blank

Batch file start4.bat:
start C:\T32\t32marm.exe
^
-c config4_sim.t32
^
-s '"C:\t32\my project\start4.cmm"' ^
0x3 0x5
The caret sign ^ serves as a line continuation character in Windows batch files (*.bat). White space
characters after ^ are NOT permissible.
19
Installation

The default address of the PODBUS Interface Card is set to 350h. To change this address the jumpers and
the file CONFIG.T32 have to be modified.
Address Select Jumpers:
JP0
JP1
JP2
Address (hex)
Address (dec)
on
on
on
350
848
off
on
on
250
592
on
off
on
260
608
off
off
on
280
640
on
on
off
300
768
off
on
off
330
816
on
off
off
340
832
off
off
off
390
912
JP3 must always be on.

The file CONFIG.T32 must have the following content:
PBI=
ADDRESS=816
; the address must be entered in decimal format
20
Installation
Parallel PODBUS Converter

The Parallel PODBUS converter supports standard and EPP parallel ports. For standard configuration the
file CONFIG.T32 must have the following content:
PBI=
LPT1
; or optional LPT2
NOTE: The relation between the LPTx names in the config.t32 file and port addresses is fixed. LPT1 is at
378, LPT2 at 278 and LPT3 at 3BC. This may not be the same as the names used in Windows. If you have
a parallel port on your motherboard or graphics card it may be address 3BC, Windows may call it LPT1, but
in the config file you must specfiy LPT3.
If the PC supports EPP mode the following CONFIG.T32 file is required:
PBI=
LPT1
EPP
; or optional LPT2
EPP mode is the fastest operation mode for the PODBUS interface. It should be used wherever possible.
At common PCs the parallel port mode can be selected in the BIOS. The BIOS must be switched to EPP,
EPP V1.7 or EPP V1.9. Some PCs require special tools to modify the parallel port mode. Please ask your
PC manufacturer.
21
Installation
Serial Line Configuration

Modifications to the CONFIG.T32 configuration file:
PBI=COM2 baudrate=38400

One PODBUS can control multiple independent devices. Each device or group can be controlled by a
different user interface. The definition is made in the config.t32 file:
PBI=
USE=1001
The bitmask defines which devices (PowerDebug, PowerTrace, PowerProbe, ... ) are controlled by the host
application program. A '1' means control the device, a '0' means skip the device. The leftmost bit controls the
first device on the bus i.e. the device with the host connection (USB, ETH).
Normally a use mask will contain a single set bit e.g. 1000, indicating that only one of the devices in the
PODBUS is used by the respective program (e.g. PowerView ARM frontend software uses a PowerTrace
device to access the target).
When using PowerView to control two devices the use mask will contain two 1 bits. An example for this is a
PowerDebug device and a PowerProbe device which are used to record signals corresponding to a debug
session of PowerDebug. Using this mechanism it is possible to combine a debugger and a PowerProbe
device, independently of their position in the PODBUS chain.
NOTE: PowerDebug modules without USB or with USB 1.1 only are special in the sense that it must be
considered as TWO devices (internally it combines multiple functions that were historically located in
separate boxes). Therefore the PowerDebug device is represented by either 00 or 11 in the use mask.
22
Installation
Multicore Debugging
General Information
Multicore debugging in general means that there are multiple cores on one chip which use the same JTAG
interface. In contrary, if there is more than one chip with different JTAG interfaces to be debugged
simultaneously, we use the term multiprocessor debugging.
The following chapters describe which hardware and licenses are needed and how to set up the TRACE32
software for multicore debugging. For detailed core specific settings, please refer to the particular Processor
Architecture Manuals. In addition, there is a number of PRACTICE sample scripts for different multicore
systems available on the software CD or can be received from LAUTERBACH support (for contact
possibilities, see www.lauterbach.com).
There are two general ways for multicore debugging:
single device solution: one debug module (debug box) for several cores
multi device solution: several debug modules (debug boxes), one for each core
In any case, each core has its own application software on the host PC, but those applications use different
ways to access the LAUTERBACH Debug Hardware, and, in the end, their particular core.
Tool Configuration for Single Device Solution

Host PC
Application 1
(e.g. t32marm)
Application 2
(e.g. t32m320)
USB
or
Ethernet
Interface
Power
Debug
Module
JTAG
Handler
Target
Joint
JTAG
Interface
Core A
Core B
When using single device solution, the applications do not care about availability of the joint JTAG interface,
the different accesses are arranged by a JTAG handler. The application executables (t32marm and t32m320
in the diagram above) register themselves at the JTAG handler of the common Power Debug Module.
Therefore, the configuration files (default file name: config.t32) of the applications have to contain core=
settings (as specified below).
The master application (those belonging to the base license of the debug cable) has
to be started first to install the proper JTAG handler. Nevertheless, the setting to
define which core is addressed actually is done later on.
23
Installation
Tool Configuration for Multi Device Solution

Power Debug
Module
Host PC
Application 1
(e.g. t32marm)
Application 2
(e.g. t32m320)
USB
or
Ethernet
Interface
JTAG Handler
Podbus
Power Debug
Module
Target
Joint
JTAG
Interface
Core A
Core B
JTAG Handler
The multi device alternative demands self-administration of the access to the joint JTAG interface for each
application. The application reserves the JTAG port for usage, and releases it afterwards transferring its
Debug Module into tristate mode. The applications (t32marm and t32m320 in diagram above) have to be
configured to use their own separate debug box. Therefore, the configuration files (default file name:
config.t32) of the applications have to contain use= settings (as specified below).
In this case it does not matter which application is started first.
As well as in single device solution, the setting to define which core is
addressed at the end is done later on.
24
Installation
Hardware Configuration for Multicore-Debugging

The following configuration examples provide an overview on usable LAUTERBACH debugging hardware
for multicore debugging. To see which multicore processor ICs are supported by specific configurations,
please contact LAUTERBACH sales department or local distributor.
Configuration 1: Single PowerDebug-Module
Target with
Multicore-IC
Joint JTAG Interface
clock
cable
Multicore
Debug Interface Cable
PC
trigger
in/out
DEBUG
MODULE
PODBUS
USB
interface
power
supply
AC/DC-adapter
Description: The TRACE32 debugging software running on the Host-PC uses a joint JTAG interface to
communicate with the cores on the multicore-IC. With Power Debug Ethernet Module the configuration looks
likewise, except of interposed hub and ethernet connection at the host PC.
25
Installation
Configuration 2: Single Power Trace Ethernet
Multicore
Target
Ethernet 100 BaseT,
Twisted Pair Ethernet
HUB
Preprocessor
to Trace Connector
Joint JTAG
Interface
Multicore
Debug Interface
Cable
PC or
Workstation
POWER
TRACE
ETHERNET
USB connector
AC/DC-adapter
Description: The TRACE32 debugging software running on the Host-PC uses a joint JTAG interface to
communicate with the cores on the multicore-IC. If several cores on the target provide trace information it is
possible to select which core is accessed by the Trace Preprocessor. If there are several trace ports on the
target, refer to configuration 5.
Using the USB connector of the Power Trace Ethernet module, the configuration looks likewise (without the
Ethenet hub of course).
26
Installation
Configuration 3: Two (or more) Power Debug Modules
Multicore Target
Processor
Core 1
Core 2
...
Core n
Joint JTAG
Interface
Y-Adapter
JTAG Connectors
PC
POWER
DEBUG
MODULE
POWER
DEBUG
MODULE
up to 4 Power Debug Modules

possible
USB
interface
AC/DC-adapter
Description: The TRACE32 debugging software running on the host-PC uses separate debug boxes to
communicate with the cores on the multicore-IC. To do this, one debug cable for each core is necessary.
Some target boards already provide several JTAG connectors that represent a single one actually, in that
case the y-adapter is not needed.
The number of Power Debug Modules needed depends on the number of cores to be debugged.
27
Installation
Configuration 4: One PowerTrace- and one or more Power Debug Modules
Multicore Target
Joint JTAG
Interface
Processor
Core 1
Core 2
JTAG Y-Adapter
Preprocessor
to Trace Connector
PC
POWER
TRACE
ETHERNET
POWER
DEBUG
MODULE
up to 3 Power Debug Modules
possible
USB
interface
AC/DC-adapter
Description: The TRACE32 debugging software running on the Host-PC uses separate JTAG interfaces to
communicate with the cores on the multicore-IC. To do this, one debug cable for each core is necessary. If
several cores on the target provide trace information it is possible to select which core is accessed by the
Trace Preprocessor. If there are several trace ports on the target, refer to configuration 5.
case the y-adapter is not needed.
The number of Power Debug Modules needed depends on the number of cores to be debugged.
28
Installation
Configuration 5: Two PowerTrace- and optionally one or more Power Debug Modules
Multicore Target
Processor
Joint JTAG
Interface
JTAG Y-Adapter
Preprocessor
to Trace Connector
PC
Core 1
Core 2
...
Core n
POWER
POWER
TRACE
TRACE
ETHERNET ETHERNET
up to 2 additional
Power Debug Modules
possbible
USB
interface
AC/DC-adapter
Description: The TRACE32 debugging software running on the Host-PC uses separate debug boxes to
communicate with the cores on the multicore-IC. To do this, one debug cable for each core is necessary.
case the y-adapter is not necessary.
The number of additional Power Debug Modules needed depends on the number of cores to be debugged.
29
Installation
Multicore Licenses
For multicore debugging, it is necessary to obtain the licenses for the particular cores. In case of
configurations 3,4 and 5 (see chapter Hardware Configuration for Multicore Debugging), the licenses
are present in the respective debug cables (e.g. base licenses for each core). In contrast, the configurations
1 and 2 require all necessary licenses to be present in one debug cable. Those multicore debug cables
always consist of the so-called base license and additional A- or X-license(s) according to the further
core(s). In case there are only several equal cores of the same type on the chip, the so-called multicore
license has to be added to the base license. If there are already several different core license within one
cable, this namely permits multicore debugging (if supported by software).
The on-chip-trace licenses like ARM-ETB license do not count as a core license,
to debug several same ARM cores the multicore license LA-7960X is required.
To learn which license combinations are possible please contact LAUTERBACH sales department or
distributor.
30
Installation
Install Debugger Software for Multicore Debugging

The basic way to install the software on the different operating systems is described in TRACE32
Installation Guide (installation.pdf) (installation.pdf).
For multicore debugging, all the debuggers for the different cores have to be installed.
selection of several debuggers by

left-click
31
Installation
Setup and Start of TRACE32 Software

General
At multicore debugging, each core belongs to one instance of the TRACE32 software, i.e., there are as
many TRACE32 instances resp. executables running as cores are to be debugged simutaneously.The
appropriate executable to be started is titled according to the name of the core family, and can be checked in
the properties of the installed debugger shortcuts.
t32m<corefamily>.exe
; on Windows
t32m<corefamily>
; on Linux or workstations
After installation, the particular predefined config files (config.t32) are for single core debugging only.
Therefore it is necessary to add certain settings as described in the following. It is recommended to copy the
existing config.t32 into a new file, the filename is freely choseable, and can be provided when starting the
executable.
Config file settings for single device solution
At single device solution, all TRACE32 applications use the same debug box:
Host PC
Application 1
(e.g. t32marm)
Application 2
(e.g. t32m320)
USB
or
Ethernet
Interface
Power
Debug
Module
Target
Joint
JTAG
Interface
JTAG
Handler
Core A
Core B
To specify this, we use core= setting within PBI section:

PBI=
CORE=1
; within config file of first core
PBI=
CORE=2
; within config file of 2nd core
; possibly more config files
32
Installation
Config file settings for multi device solution
At multi device solution, each TRACE32 application uses its own debug box:
Power Debug
Module
Host PC
Application 1
(e.g. t32marm)
Application 2
(e.g. t32m320)
USB
or
Ethernet
Interface
Target
JTAG Handler
Podbus
Power Debug
Module
Joint
JTAG
Interface
Core A
Core B
JTAG Handler
To specify this, we use the use= setting within PBI section:

PBI=
USE=10
PBI=
USE=01
(see also chapter Using Multiple Devices on one PODBUS). In addition, it is necessary to specify the ID=
setting within OS section (the ID is used to store PRACTICE command history and associated source code
files within TMP directory, therefore it is alternatively possible to use same ID and assign separate TMP
directories to each TRACE32 instance):
OS=
ID=T32_CORE1
OS=
ID=T32_CORE2
33
Installation
Config file settings for both single and multi device solutions
To use the start/stop synchronization between the different core debuggers, the intercom port settings are
necessary (PORT= setting within IC section, see also chapter Start Stop Synchronisation):
IC=NETASSIST
PORT=20001
IC=NETASSIST
PORT=20002
Example: Static config files for each TRACE32 instance
First TRACE32 instance:

; The configuration file for the ARM9 core
; ========================================
; 1. Specify the ARM9 core as the first core.
PBI=
CORE=1
USB
; 2. Specify an ID for the ARM9 debugger.
OS=
SYS=.\
TMP=C:\temp
ID=T32ARM9
HELP=H:\T32NEW\pdf
; 3. Specify a better core identification for the TRACE32 window.
SCREEN=
HEADER=TRACE32-ARM Multicore
; Header for the

TRACE32 window
; T32 Intercom for Start/Stop synchronisation

IC=NETASSIST
PORT=20002
In the example above the call syntax would be (assuming the config filename is config_core1.t32:
t32marm -c config_core1.t32
34
Installation
Second TRACE32 instance:

; The configuration file for the TMS320C55X core
;===================================================
; 1. Specify the TMS320C55X core as the second core.
PBI=
CORE=2
USB
; 2. Specify an ID for the TMS320C55X debugger.
OS=
SYS=.\
TMP=C:\temp
HELP=H:\T32NEW\pdf
ID=T32C55x
; Each debugger creates copies of source file into the TMP directory. The
; specified ID allows each
; debugger to identify its source files.
; 3. Specify a better core identification for the TRACE32 window.
SCREEN=
HEADER=TRACE32-C55x Multicore
PALETTE 1 = 255 255 223
; Header for the TRACE32 window

; Yellow background color
; T32 Intercom for Start/Stop synchronisation

IC=NETASSIST
PORT=20001
In the example above, the call syntax would be (assuming the config filename is config_core2.t32:
t32m320 -c config_core2.t32
35
Installation
Example: Generic config file for each TRACE32 instance
Besides, there is the possibility to use just one generic template config file for all cores. The particular
settings are passed as parameter. Example for generic config file:
IC=NETASSIST
PORT=${1}
; Environment variables
OS=
ID=T32${1}
TMP=C:\temp
SYS=.\
HELP=h:\t32new\pdf
PBI=
${3}
${4}
${5}
${6}
; Printer settings
PRINTER=WINDOWS
; Screen fonts
SCREEN=
FONT=SMALL
HEADER=TRACE32 ${2} Multicore @${3} ${4} ${5}
${6}
The template variables ${1} to ${6} are replaced textually by corresponding calling parameters. In that way, it
is possible to select even the connection method (Parallel, USB or Ethernet) by parameters.
In this generic example the call syntax could be (assuming the config filename is config_mc.t32:
; Start ARM executable as 1st core via USB and intercom port 20001
t32marm -c config_mc.t32 20001 ARM USB CORE=1
; Start TMS320 executable as 2nd core via USB and intercom port 20002
t32m320 -c config_mc.t32 20002 C55x USB CORE=2
36
Installation
Those calls are also possible through shortcut:
Examples for Ethernet connection:

; Start ARM executable as 1st core via ETH and intercom port 20001
t32marm -c config_mc.t32 20001 ARM NET NODE=10.2.2.234 CORE=1
; Start TMS320 executable as 2nd core via ETH and intercom port 20002
t32m320 -c config_mc.t32 20002 C55x NET NODE=10.2.2.234 CORE=2
37
Installation
Example: start of further TRACE32 instances by first instance (with generic config file)
Using the OS command of TRACE32 PRACTICE language, it its possible to start further instances of
TRACE32 (see also IDE Reference Guide). This way offers the possibility to start multiple core debuggers
from one PRACTICE script file. In combination with a generic config file, this is a very smart way to set up
multicore debugging.
; start tpu executable as 2nd core via USB and intercom port 20002
os t32mtpu -c config_mc.t32 20002 eTPU_A USB CORE=2
For a description of the parameters refer to chapter Generic config file for each TRACE32 instance, see
above.
The very first instance, however, has to be started in common way (by batch file or shortcut), as described in
chapter Generic config file for each TRACE32 instance, see above:
; start PPC executable as 1st core via USB and intercom port 20001
t32mppc -c config_mc.t32 20001 PowerPC USB CORE=1
; start PPC executable as 1st core via ETH and intercom port 20001
t32mppc -c config_mc.t32 20001 PowerPC NET NODE=10.2.2.234 CORE=1
38
Installation
Complete example PRACTICE script for generic starting of multiple instances on Windows, using MPC5554
(with E200 and two eTPU cores), in which it is dynamically selectable to use USB or Ethernet connection:
; Sample eTPU setup script
; start eTPU debugger software and check intercom
=============================
&nodename=NODENAME()
&etpu1="intercom localhost:20002"
&etpu2="intercom localhost:20003"
; Test is etpu software is already running or not
if !intercom.ping(localhost:20003)
(
if "&nodename"==""
(
print "assuming connection is USB"
os t32mtpu -c config_mc.t32 20002 eTPU_A USB CORE=2
; wait until software is started
intercom.wait localhost:20002
os t32mtpu -c config_mc.t32 20003 eTPU_B USB CORE=3
)
else
(
print "connection is ETH"
os t32mtpu -c config_mc.t32 20002 eTPU_A NET NODE=&nodename
PACKLEN=1024 CORE=2
; wait until software is started
os t32mtpu -c config_mc.t32 20003 eTPU_B NET NODE=&nodename
PACKLEN=1024 CORE=3
)
; wait some time until the software finished booting
; if you get and intercom timeout error on the following framepos
; commands
; increase time
wait 3.s
; multicore settings
==========================================================
&etpu1 SYStem.CONFIG.CORE 2.
&etpu2 SYStem.CONFIG.CORE 3.
)
39
Installation
; arrange debugger windows

framepos
0.
0. 88.
&etpu1 framepos
0. 38. 181.
&etpu2 framepos 94.
0. 88.
25.
26.
20.
; attach debugger to cores

====================================================
sys.u
&etpu1 sys.m.attach
&etpu2 sys.m.attach
enddo
In the example above, the other TRACE32 instances are accessed from first instance by
intercom localhost:<port no>
command, which is stored into local PRACTICE variables (&etpu1 and &etpu2).
Automatic setup of config files
(for Windows only)

The usage of the LAUTERBACH add-on T32Start is described in T32Start Reference Guide.
40
Installation
TRACE32 Multicore Configuration

The installation of the TRACE32 software and the config files is finished now. All TRACE32 applications
access the same JTAG port, either by single device or by multi device solution. Now we have to tell the
TRACE32 applications which of the cores they should debug.
Host PC
Application 1
(e.g. t32marm)
Application 2
(e.g. t32m320)
USB
or
Ethernet
Interface
Application 2
(e.g. t32m320)
JTAG
Handler
Target
Joint
JTAG
Interface
Power Debug
Module
Host PC
Application 1
(e.g. t32marm)
Power
Debug
Module
USB
or
Ethernet
Interface
JTAG Handler
Podbus
Power Debug
Module
Core A
Core B
Target
Joint
JTAG
Interface
Core A
Core B
JTAG Handler
The communication to the specified core is done not until the SYStem.Up command, and for preparation
(besides the proper processor selection) there might be some additional multicore settings to be done.
There is a number of PRACTICE sample scripts for different processors available on LAUTERBACH
software CD or directly from LAUTERBACH support (for contact possibilities, see www.lauterbach.com),
which may assist you in setting up multicore debugging.
Basically, there are two different ways to address the particular core:
daisy chaining
multiplexing
41
Installation
Daisy Chain Settings
For those processors that have multiple so-called TAP (=Test Access Port) controllers, eg. one for each core,
it is necessary to provide the TRACE32 applications with daisy chain settings.
The JTAG port of the individual cores are arranged serially (daisy chained). The TAP controller controls the
scanning of data in the instruction register and the data register of the JTAG architecture.
The instruction register has a specific width for each architecture
The width of the data register depends on the instruction used (always 1 bit if the instruction
register contains the BYPASS instruction)
According to the JTAG convention there is an option to generate sequences for the scan chain, that ensure,
that individual TAP controllers behave neutrally (BYPASS). To address a specific core the debugger must
therefore be configured in such a way that, when generating the scan chain, BYPASS sequences are
created for all TAP controllers before and after this core. The associated settings are either determined by
selection of the processor (if fixed) and/or can be modified in the SYStem.CONFIG.state window.
To access the SYStem.CONFIG.state window, do one of the following:
Choose CPU menu > System Settings, and then click the CONFIG button.
At the TRACE32 command line, type:

SYStem.CONFIG.state
Shows the state of the MULTICORE setting.
42
Installation
IRPRE
<number> of instruction register bits of all cores in the JTAG chain between the
current core and the TDO signal.
IRPOST
<number> of instruction register bits of all cores in the JTAG chain between TDI
signal and the current core.
DRPRE
<number> of cores resp. TAP controllers in the JTAG chain between the current
core and the TDO signal (one data register bit per TAP controller which is in
BYPASS mode).
DRPOST
<number> of cores resp. TAP controllers in the JTAG chain between the TDI signal
and the current core (one data register bit per TAP controller which is in BYPASS
mode).
Slave
All debuggers except one must have this option active. Only one debugger - the
master - is allowed to control the signals nTRST and nSRST (nRESET).
43
Installation
In case of multi device solution, the following additional settings have to be made:
TriState
If more than one debug box shares the same JTAG port, this option is required.
The debugger switches after each JTAG access to tristate mode. Then other
debuggers can access the port.
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. The default value is recommended.
TCKLevel
Level of TCK signal when all debuggers are tristated (0 in case of pull-down on
target, 1 if pull-up).
In case the daisy chain settings are preconfigured by processor selection, they are displayed within
SYStem.CONFIG.state window:
automatic daisy chain

settings by processor selection
The example above shows both core and ARM-ETB daisy chain settings, at which they both are located
within same daisy chain sequentially. If there are additional TAP controllers beyond the selected multicore
processor located on the target board (e.g. several daisy-chained multicore chips together on one target
board), the necessary values have to be entered into edit controls.
44
Installation
Multiplex Settings
For some processors (like STARCORE or NIOS-II) it is necessary to specify individually which core the
current TRACE32 instance should debug.
SYStem.CPU <multicore processor>
SYStem.CONFIG.CORE 1
; select multicore processor type

; specify current TRACE32 instance
; as core 1 debugger
SYStem.CPU <multicore processor>

SYStem.CONFIG.CORE 2
; select multicore processor type

; specify current TRACE32 instance
; as core 2 debugger
The SYStem.CONFIG.CORE setting does technically NOT refer to CORE= setting

within config file. Of course, it is recommended to use same core number.
45
Installation
Start Stop Synchronisation

Settings
To use the Start/Stop Synchronisation, the intercom port settings within config file(s) are required (refer to
chapter Setup and Start of TRACE32 Software.
The synchronisation itself is done by SYnch commands, according to the following steps:
1.
Set up the SYnch command for first core as master core

SYnch.state
;Display the current settings of the SYnch command
SYnch.Connect Localhost:20001 [<further ports>]
SYnch Settings
Connect
Establish a connection to the debugger attached to the defined

communication port(s). Several debuggers resp. ports can be
specified, separated by space.
MasterGo ON
If the program execution is started, the program execution for all other
processors which have SlaveGo ON is also started.
MasterBrk ON
If the program execution is stopped, the program execution for all

other debuggers which have SlaveBrk ON is also stopped.
MasterStep ON
If an asm single step is executed, all processors which have

SlaveStep ON will also asm single step.
46
Installation
It is optionally possible to set both master and slave settings ON, to let this core react on other core
events, too.
The PORT= value within IC section of the config file of the current core has
to match the value(s) of the SYnch.Connect command(s) of the
coressponding debugger(s), while the SYnch.Connect value(s) of the
current core has(have) to match those values from the config files of the
other core debugger(s).
In other words, the PORT= value(s) within config file(s) are server port
numbers, while the SYnch.Connect values are client port numbers (see
also chapter Setup and Start of TRACE32 Software).
2.
Set-Up the SYnch command for the further cores.
SYnch.Connect Localhost:20000 [<further ports>]
SYnch Settings
Connect
Establish a connection to the debugger attached to the defined

communication port
SlaveGo ON
The program execution is started, if a processor with MasterGo ON starts

its program execution.
SlaveBrk ON
The program execution is stopped, if a processor with MasterBrk ON

stops its program execution.
SlaveStep ON
A asm single step is performed, if a processor with MasterStep On

performs an asm single step.
It is optionally possible to set both master and slave settings ON, to let other cores react on current
core events, too.
47
Installation
Summary (Example with one master and two slave core debuggers):
; Complete script has to be run on TRACE32 instance of first core
; SYNCH commands for 1st core
SYNCH.RESet
SYNCH.Connect Localhost:20001 Localhost:20002
SYNCH.MasterGo ON
SYNCH.MasterBRK ON
SYNCH.MasterStep ON
; SYNCH commands
INTERCOM.execute
INTERCOM.execute
Localhost:20002
INTERCOM.execute
INTERCOM.execute
INTERCOM.execute
for 2nd core

Localhost:20001 SYNCH.RESet
Localhost:20001 SYNCH.Connect Localhost:20000
; SYNCH commands
INTERCOM.execute
INTERCOM.execute
Localhost:20001
INTERCOM.execute
INTERCOM.execute
INTERCOM.execute
for 3rd core

Localhost:20002 SYNCH.RESet
Localhost:20002 SYNCH.Connect Localhost:20000
Localhost:20001 SYNCH.SlaveGo ON
Localhost:20001 SYNCH.SlaveBRK ON
Localhost:20001 SYNCH.SlaveStep ON
Localhost:20002 SYNCH.SlaveGo ON
Localhost:20002 SYNCH.SlaveBRK ON
Localhost:20002 SYNCH.SlaveStep ON
ENDDO
48
Installation
Result of start/stop synchronization
The master starts the

program execution
Both slaves are started
49
Installation
The master stops the program

execution
Both slaves are stopped
50
Installation
Synchronisation Time Delay
There is a time delay between reaction of different cores. The reaction time of the appended slave core(s)
depends on the technical realization of the synchronization. In worst case, this is done by software, i.e. the
master debugger informs the slave debugger(s) via socket communication on the host about specified
events. In best case, the synchronization takes place directly on the processor, and the in between solutions
are PODBUS trigger signal or to connect certain PINs, if available, on the JTAG connector or the board.
Which solution is offered by the particular multicore debugging environment is depending on the chip and/or
board hardware. The LAUTERBACH Debuggers always use the fastest available possibility. The software
synch mechanism starts all cores simultaneously by TRACE32 software, either by socked communication
(slow) or internal synchronized within TRACE32 (fast). The fast method is only implemented for some
processors, while the software method by socket is always available.
Special on STEP-Signal: By selecting MasterStep/SlaveStep ON, only the asm single steps are
synchronized. The HLL steps are published by master debugger as a sequence of (asm)step-go-break (or
just go-break), which means the slave debugger(s) do(es) not really perform an own HLL single step.
Solution:
Software
(slow)
Software
(fast)
PODBUS
Trigger
Hardware (JTAG
or Board)
Chip
Hardware
Delay time:
1-5 ms
~10 s
100-300 ns
~10 ns
0-10 ns
51
Installation
Multicore Debugging Summary

Here is a list of steps to set up and start the LAUTERBACH debugger for multicore debugging:
Choose debug hardware (see Hardware Configuration for Multicore Debugging)
Install suitable debugger software (see Install Debugger Software for Multicore Debugging).
Setup config files (see Setup and Start of TRACE32 Software)
Start executables with particular config files (see Setup and Start of TRACE32 Software)
Run core specific script (see TRACE32 Multicore Configuration).
52
Installation
Multiprocessor Debugging
Multiple ICD Debuggers can be started and stopped synchronously. The time delay depends on the
implementation of the debug port. On a 68332 the start time delay is about 10us and the stop delay about
5us. The coupling of the different systems is made by the SYnch command.
NOTE:
This command requires that the InterCom system is configured in the host. The
synchronous break can be made with the Trigger command. The following
example shows the configuration files and commands required for a system where
one master controls two slaves:
Configuration file for master:

PBI=
USE=100
IC=NETASSIST
PORT=20000
Configuration file for slave 1:

PBI=
USE=010
IC=NETASSIST
PORT=20001
Configuration file for slave 2:

PBI=
USE=001
IC=NETASSIST
PORT=20002
Startup commands for master:

sy.connect localhost:20001 localhost:20002
sy.mastergo on
sy.on
trigger.out busa on
Startup commands for slaves:

sy.slavego on
sy.on
trigger.set busa on
53
Installation
Program Start and End

To start TRACE32, do one of the following:
Click the Windows Start button, and then select TRACE32 ... .
Navigate to c:\t32\bin\<OS_name>\<32_or_64_bit_version>, and then double-click

the required executable file.
The executable file which has to be started is named T32M<CPU type>.exe (e.g. T32M68.EXE,
T32MPPC.EXE, T32MARM.EXE).
To exit from TRACE32, do one of the following:
At the TRACE32 command line, type: QUIT
Choose File menu > exit.
54
Installation
Installation as TRACE32-ICE Extension
To install the ICD Debugger together with the TRACE32-ICE see the Installation Guide of the TRACE32
System. In addition to the normal TRACE32 emulator software the following files may be required.:
mccm<CPU type>.t32
mcpm<CPU type>.t32
; Driver for JTAG/BDM Debugger or ROM Monitor,

; CPU specific (for old and new controller)
mccesi.t32
mcpesi.t32
; Driver for the EPROM Simulator
mccitim.t32
mcpitim.t32
; Driver for the PowerProbe
mccstg.t32
mcpstg.t32
; Driver for the Stimuli Generator
mcctim.t32
mcptim.t32
; Driver for the Timing Analyzer (TA32)
A configuration file software.t32 must be created for special configurations (e.g. when multiple BDMs and
ESIs are connected). This file is not required for standard configurations.
Format:
<driver>=<cpu_type> [<usemask>]
<driver>:
GROUP
SIM
<cpu_type>
Description
08
for 68HC0x
11
for M68HC11
12
for M68HC12
166
for C166
16
for M68HC16
186
for I86
M32R
for M32R
51
for i8051
55
<cpu_type>
Description
56
for DSP56k
68
for M68k / ColdFire
78K
for 78K
96
for i196
2000
for TMS320C2xxx
5000
for TMS320C5xxx
6000
for TMS320C6xxx
ADRO
for Adreno
ANDE
for AndeStar
APEX
for APEX
APS
for APS3
ARC
for ARC
ARM64
for ARM (64-bit)
ARM
for ARM (32-bit)
AVR
for AVR32
BA
for Beyond
BF
for Blackfin
CEVA
for CEVA-X
CORE
for M.CORE
GTM
for GTM
H83
for Renesas-H8
MIPS64
for MIPS (64-bit)
MIPS
for MIPS (32-bit)
MB
for MicroBlaze
MDSP
for MMDSP+
NDSP
for NanoDSP
NIOS
for Nios-II
PPC64
for PowerPC (64-bit)
PPC
for PowerPC (32-bit)
QDSP6
for Hexagon
RX
for Renesas-RX
56
<cpu_type>
Description
SC
for StarCore
SH
for SH
M430
for MSP430
SPT
for SPT
TC
for TriCore
TEAK
for CEVA-Teak
TPU
for eTPU
UBI
for Ubicom32
V800
for V850/RH850
VSPA
for VSPA
X86
for Intel Arch. (32-bit)
X64
for Intel Arch. (64-bit)
XA
for XA51
XTEN
for Xtensa
Z80
for Z80
ZSP
for ZSP
57

One PODBUS can control multiple independent devices. Each device or group can be controlled by a
different prompt (e.g. B:, B2:, B3:). The definition is made in the file software.t32 by specifying a bitmask after
the BDM=xx command. The bitmask defines which devices are controlled by the prompt. A '1' means control
the device, a '0' means skip the device. The leftmost bit controls the first device on the bus.
Example for software.t32:
GROUP=68 100
GROUP=68 010
GROUP=68 001
In this example the first debug module connected to the PODBUS is controlled by prompt b:, the second
device by prompt b2: and so on. The prompt name can be changed after boot with the SETUP.DEVNAME
command. The command MENU.AUTODEV can be used to automatically change the main menu and
toolbar device dependend on the currently selected prompt or active window.
58
Working with the ICD Debug System
Available Device Prompts

The TRACE32 system includes a number of devices, e.g. in circuit emulator, timing analyzer, ICD Debugger.
Each device has its own command set.
To work with the device specific command set, the device must be selected by entering the device identifier
ending with a double colon in the command line. The currently selected device is displayed by the prompt of
the command line. At the ICD debug system the following prompts are available.
B:
JTAG/BDM Debugger or ROM Monitor. This is the prompt which will typically be used for
debugging. Please note that if you use the ESI as ROM Monitor or as emulation memory
together with an ICD module, all mapping must be done on the B: prompt.
ESI:
This prompt is only required if you want to use the ESI as pure EPROM simulator, without
any debug capabilities.
PP:
Used to control the PowerProbe
STG:
Used to control the Stimuli Generator
T:
Used to control the Timing Analyzer (TA32)
59
Working with the ICD Debug System
ICD Commands and Procedures

The start-up procedures and CPU specific commands for the ICD Debugger are described in the CPUspecific documentation section.
You can look up the function and syntax for all general commands in the Emulator Reference for the
TRACE32 system.
Specific commands and procedures for the ICD debug system are described in the following chapters.
60
Mapping the EPROM Simulator

One EPROM simulator is used to simulate two 8 bit or one 16 bit EPROM. To simulate EPROMs with a
bigger bus size, two or more EPROM simulator can be put together.
Whenever the EPROM simulator is used the configuration of the target EPROMs must be specified in the
ICD Debugger software with the MAP command.
The reproduction of the EPROM configuration is done as follows:
1.
Reset the mapping system (MAP.RESet command).
2.
Map the EPROM simulator within the specified range (MAP.ROM command).
3.
Set the EPROM bus size (MAP.BUSXX command). The default bus size is 8 bit.
4.
Set the EPROM width (MAP.BYTE or MAP.WORD command).
5.
Verify your configuration with the MAP.List command.

; maps one 8K x 8 EPROM
; 8 bit adapter low
b:
map.res
map.rom 0x0--0x01fff
; maps two 8K x 8 EPROMS in parallel

; 8 bit adapter low and high
b:
map.res
map.bus16 0x0--0x03fff
; maps one 4K x 16 EPROM

; 16 bit adapter
b:
map.res
map.bus16 0x0--0x01fff
map.word 0x0--0x01fff
61
; maps one paged addressed EPROM with 4 pages (4 x 16K x 8)

; 8 bit adapter low
b:
map.res
map.rom
map.rom
map.rom
map.rom
map.page
map.page
map.page
map.page
0x00000--0x03fff
0x04000--0x07fff
0x08000--0x0bfff
0x0c000--0x0ffff
0
1
2
3
0x00000--0x03fff
0x04000--0x07fff
0x08000--0x0bfff
0x0c000--0x0ffff
; maps two fragments in one 8 bit EPROM

; 8 bit adapter low
b:
map.rom 0x0--0x7fff
map.frag 1 0 0x0--0x7fff
map.frag 1 0x8000 0x10000--0x17fff
; relocates one 128K x 8 EPROM mapped from 0--1ffff to 40000

; while the system is up
b:
map.relocate 0x40000 0x0--0x1ffff
; maps four 64K x 8 EPROMs for a bus size of 32 bit

; two EPROM simulators
; for each 8 bit adapter high and low
map.rom 0x0--0x3ffff
map.bus32 0x0--0x3ffff
; maps two 64K x 16 EPROMs for a bus size of 32 bit

; two EPROM simulators
; for each 16 bit adapter
map.rom 0x0--0x3ffff
map.bus32 0x0--0x3ffff
map.word
62
Break
The ICD Debugger uses software breakpoints. For that reason only Program, HLL and Spot Breakpoints are
available.
If the CPU provides hardware breakpoints, read and write breakpoints can be used. For more information
see the CPU specific section.
If the CPU provides hardware execution breakpoints, they will be used when a breakpoint is set in an area
marked with MAP.ReadOnly.
Manual break for ROM Monitors can be accomplished in different ways:
Use of the NMI line
Use of the Serial Line Interrupt (Serial Monitors)
Polling of serial line or ESI by target
NIL character send by virtual terminal
See the Processor Architecture Manual and monitor source code for your target for more details.
63
eXception
The eXeption commands are used to adapt and connect the RES and NMI signals generated by the ROM
Monitor software to the target CPU.
On each adapter for the EPROM simulator there are three extra pins for GND, NMI and RES. NMI and RES
are outputs from a HTC Schmitt trigger.
1
Male connector to EPROM Simulator
GND
NMI
RES
Adapter for the EPROM Simulator

The RESet pin of one adapter can be connected to the reset pin of the CPU to give the ROM Monitor
program the possibility to control the CPU reset. The polarity of the reset can be adapted to the CPU type by
the eXception.RESetPOL command.
If the RESet pin is connected to the CPU, the CPU held in reset, while the system is down.
The NMI pin of one adapter can be connected to the NMI pin of the CPU to manually break a program
running on the target system. The polarity of the NMI can be adapted to the CPU type by the
eXeption.NMIPOL command. The connection is enabled by eXception.NMIBREAK ON.
; defines the NMI as a acitve-low signal and enables the NMI connection
x.nmipol x.nmibreak on
No connection for the RES and NMI pins of the EPROM simulator are needed, if a LAUTERBACH
evaluation board is used. On these boards the target CPU gets this signals from the PODBUS interface.
64
eXception.NMIBREAK
Format:
eXception.NMIBREAK ON | OFF
The connection of the NMI signal to the target CPU is enabled or disabled.
eXception.NMIPOL
Format:
eXception.NMIPOL <polarity>
<polarity>:
+|-
Sets the polarity for the NMI.
eXception.RESetPOL
Format:
eXception.RESetPOL <polarity>
<polarity>:
+|-
Sets the polarity for the Reset.
65
RESet
Format:
RESet
(ROM Monitor) Switches off the EPROM simulator and resets the mapping system to its default state.
The target CPU is reset only if the RES pin of one adapter is connected and adapted to the target CPU.
66
SYStem
SYStem.BdmClock (BDM only)
Format:
SYStem.BdmClock
<rate>:
2 | 4 | 8 | 16 | <fixed>
<fixed>:
1000. .. 5000000.
<rate>
Either the divided CPU frequency is used as the BDM clock or a fixed clock rate. The fixed clock rate must
be used when the operation frequency is very slow clock line is not available.
The default is a fixed rate of 1 MHz.
67
SYStem.Mode
Format:
SYStem.Mode <mode>
<mode>:
Down
NoDebug
Go
Up
Down (BDM)
Disables the debug mode. The state of the CPU remains unchanged.
Down (ROM
Monitor)
Switches of the EPROM Simulator. Asserts the Reset Port.
Go (BDM)
Resets the system with debug mode enabled. The system runs until any
break condition occurs.
Go (Serial)
Attaches the debugger to a running target.
ATTACH
(BDM)
Attaches the debugger to a running target without reset.
ATTACH
(Serial)
Attaches the debugger to a stopped target.
NoDebug
(BDM only)
Resets the system with debug mode disabled.
Up (BDM)
Resets the system with debug mode enabled and breaks before the first
Op-Fetch.
Up (ROM
Monitor)
Activates the EPROM Simulator, then the Reset Port is negated.
Up (Serial)
Removes the RESET lines (if attached) and waits the for monitor entry.
68
SYStem.Option
Format:
SYStem.Option <option>
<option>:
BASE
BASE
Defines the base address of the internal peripherals. This value is used by the
PER command to display the internal registers.
69
Trigger
Trigger.Set (BDM only)
Format:
Trigger.Set
<source>:
BUSA
<source> [ON | OFF]
Enables the external Trigger input. The emulation is breaked when a high pulse is active for more then
300 ns.
b:
Trigger.Set BUSA ON
The TRACE32-ICE system can generate the trigger pulse to break the emulation using the trigger bus line
A. The trigger pulse is controlled by an analyzer program.
bus.a if ab
; the trigger pulse to break the emulation is

; generated at an alpha breakpoint
Trigger.Out (BDM only)
Format:
Trigger.Out
Outputs a high pulse of 200 ns.

An analyzer trigger program of the TRACE32-ICE system controls the reaction to a trigger pulse of the BDM
Debugger.
trigger.a if busa
; asserts trigger A of the TRACE32-ICE system,

; when the BDM Debugger outputs a trigger pulse
70
Trace Methods
This section describes which methods are provided by TRACE32 to record run-time information even if only
a debugger is used.
Debugging is handled mostly via on-chip debugging interfaces e.g. JTAG, BDM, OCDS. The main tasks of a
debugger are: to start the program and to stop it at a more or less complex breakpoint. With a halted
program the current state of the CPU/target can be read out and modified respectively.
Debugging comes to its limits when run-time errors occur. Run-time errors are errors whose causes, either
time-related or in the program hierarchy, are so far apart that the correlation between cause and effect can
no longer be detected by a debugger. Moreover no analysis of the runtime behavior is possible by using
debugger.
In the following ancillary trace methods are presented. These trace methods allow to record run-time
information even with a debugger.
ART:
LOGGER:
Snooper: Snooping allows a periodic sampling of up to 16 data items or the program counter.
FDX: FDX (Fast Data eXchange) allows to transfer arbitrary data between the target and the host. It is
implemented by using a specialized communication protocol, supplied by LAUTERBACH.
OnChip:
71
Trace Methods
ART - Advanced Register Trace

Debugging on Mixed Level
ART logs all CPU registers when single stepping on assembler level. This information is used to provide a
single step trace.
Assembler steps that only changed the contents of CPU registers can be undone by pushing the Undo
button.
Mode.Mix
Select mixed mode debugging
ART.List
List the contents of the ART trace
Frame.UNDO
Undo the register changes performed by the last assembler step
Frame.REDO
Reverse Frame.UNDO
If complex single step commands are performed e.g.

Var.Step.Till flags[3]==0&&i>8
ART shows which program steps were performed by the CPU to get into the specified state of the system.
72
Trace Methods
The default size of the ART is 256 single steps (records). The max. size is 65536.
ART.state
Display ART configuration window
ART.SIZE <records>
Specify size for ART trace
73
Trace Methods
Debugging on HLL Level

Mode.HLL
Select hll debugging
In order to realize a fast debugging a hllstep is realized by starting the program execution and stop it at the
next hll line. Due to this proceeding ART cant log the CPU registers for each instruction executed. As a
result part of the assembler program flow is lost for ART.
In many cases TRACE32 can reconstruct the assembler program flow (hllseq).
74
Trace Methods
SNOOPer
Applications for the SNOOPer
Basic concept: The debugger reads out information from the target in a pre-defined time interval. This
information is written to a trace buffer. The trace memory for the SNOOPer trace is allocated on the host.
Snooping can only be used, if the on-chip debugging interface provides specific characteristics. Depending
on the characteristics the SNOOPer can monitor either data items or the program counter.
Characteristic required by the
On-chip Debugging Interface
Monitoring of
Possible for (e.g.)
Real-time memory access
Up to 16 data items
TriCore, S12X, C166CBC
Debug Communication Channel
User-defined 32 bit value
All ARMs, DSP56800
Memory-mapped program counter

plus real-time memory access
Program counter
TriCore, TMS320C55x
Possibility to check the program

counter while the program is
running
Program counter
ARM11, V850
The SNOOPer can be configured and controlled by the command group SNOOPer:
SNOOPer.state
; Display the SNOOPer configuration windows
Another way to configure and control the SNOOPer is the generic Trace command group:
Trace.METHOD SNOOPer
; Pre-select the trace method SNOOPer
Trace.state
; Display the trace configuration windows

; for the pre-selected trace method
75
Trace Methods
Technical Data of the SNOOPer
Real-time
Memory
Access
DCC
Memorymapped
PC
Check PC
while Program runs
Shortest sampling rate
20 s
50 s
50 s
50 s
Sampled data items [max]
Up to 16
32 bit value
Application code change required
No
Yes
No
No
Using the SNOOPer doesnt require any changes in the application (beside of the mode DCC). Therefore
the whole setup process is easy.
76
Trace Methods
SNOOPer via Real-Time Memory Access

For some CPUs the real-time memory access can only access memory but not
the data cache. Please refer to your Processor Architecture Manual or to your
CPU manual for details.
If the real-time memory access can not access the data cache the SNOOPer
can only be used if the data cache is off or if the data cache works in writethrough mode.
If the on-chip debugging interface provides real-time memory access the SNOOPer can monitor up to 16
data items.
To check if your CPU provides real-time memory access enter the following command:
SYStem.MemAccess CPU
; If your debugger accepts this

; command, real-time memory access
; is possible for your CPU
Via the real-time memory access the SNOOPer can monitor the contents of up to 16 memory address. For
this reason the SNOOPer.Mode Memory has to be configured. Here a full example:
SNOOPer.RESet
; Reset the SNOOPer
SNOOPer.Mode Memory
; Choose the recording

; mode Memory
SNOOPer.SIZE 10000.
; Set the size for the

; SNOOPer trace buffer
; to 10000.
SNOOPer.Rate 200.
; Set the sampling rate

; to 200. samples/s
SNOOPer.SELect %Byte 0x1234 %Long 0x5678
; Specify the memory

; addresses that the
; SNOOPer monitors
77
Trace Methods
It is also possible to define the addresses monitored by the SNOOPer as hll language expression. Please be
aware that no composite variable can be used.
SNOOPer.SELect V.RANGE(flags[3])
; The data type of flags[3] is

; char, so a byte is monitored
SNOOPer.SELect V.RANGE(ast.count)
; The data type of ast.count is 32

; bit integer, so a long is
; monitored
The screenshot below displays the SNOOPer.state window.
78
Trace Methods
The monitored data items can be displayed with the command SNOOPer.List.
Shortest sampling
rate for the SNOOPer
The shortest sampling rate for the SNOOPer is approx. 20 s. If more the one data item is sampled, then the
time distance between the first data item (sampled in the SNOOPer.Rate) and the second data item shows
the shortest sampling rate possible for your CPU.
Since the shortest sampling rate is approx. 20 s data losses are inevitable if the
monitored data items are changed at a higher rate by the application program.
Since neither the host nor the debugger are real-time systems the defined
snooping rate is not guaranteed. The longest snooping interval for the current
trace contents is displayed in the max field of the SNOOPer.state window.
The influence on the real-time behavior caused by the SNOOPer depends on
the realization of the real-time memory access by the CPU. It is very small for
nearly all CPUs.
79
Trace Methods
SNOOPer via Debug Communication Channel

The Debug Communication Channel - short DCC - is a characteristic of the on-chip debugging support. It
allows to pass information between the application program on the target and the debugger. For details refer
to your CPU manual.
If the SNOOPer uses the DCC, the following basic steps are required:
The application program on the target writes a 32 bit information to the corresponding registers of
the DCC.
The debugger on the other side checks the DCC registers in a defined sampling rate and enters
the recieved information into the SNOOPer trace buffer.
Application
Debugger
DCC
Read periodically
information from DCC
Write 32 bit data

of interest to DCC
In order to check, whether your CPU provides a DCC enter the following command:
SNOOPer.Mode DCC
; If your debugger accepts this command, DCC

; is provided by your CPU
The application program has to provide the data of interest. This requires that special code is added to the
application program.The low level code to handle the DCC is provided by Lauterbach. Please send an email
to [email protected] to get this code.
The interface to the low level code has to be written by the user. Here an example:
while ( k <= SIZE )

{
flags[ k ] = FALSE;
SnoopData(k*2+3);
k += primz;
}
anzahl++;
80
Trace Methods
The integer (k*2+3) is passed to the function SnoopData.

/* SnoopData may be called by the application */
void SnoopData(unsigned int data) {
Snoop = data_to_snoop;
//Snoop is passed to the debugger
while (T32_TsMon_SendStatus()); //get status of the com-channel
T32_TsMon_SendWord(Snoop); //if its free, send data to channel
}
If you plan to use the SNOOPer via DCC, you have to be aware of the following:
1.
New information can only be passed by the application program to the DCC, if the debugger has
already read the previous written information. The function T32_TsMon_SendStatus() in the
above example checks the status of the DCC. This behavior allows the user to select one of the
following strategies:
If DCC is not ready for the next 32 bit information, the application program can wait until DCC is
ready and pass the information then. This way no information is lost, but waiting will consume
CPU time.
If DCC is not ready for the next 32 bit information, the application program can ignore the current
32 bit information and continue the program execution. This way information might be lost, but
the CPU doesnt spend CPU time to wait until DCC is ready.
The fastest possible sampling rate by the debugger is approx. 50 s.
2.
The application program sends a 32 bit information to the debugger, but no information about the
meaning of this 32 bit information is exchanged between the application program and the
debugger. For this reason the debugger has to define the meaning of the 32 bit information
independent of the application program.
If the contents of a memory address or primitive variable is send by the application, the debugger
can specify this address/variable as the meaning of the 32 bit information.
For all other information the application has to declare an extra variable that can be used by the
debugger to specify the meaning of the 32 bit information.
Here a full configuration for the SNOOPer via DCC:

SNOOPer.RESet
; Reset the SNOOPer
SNOOPer.Mode DCC
; Choose the recording mode DCC
SNOOPer.SIZE 12000.
; Set the size of the SNOOPer trace

; buffer to 12000.
SNOOPer.Rate 1000.
; Set the sampling rate to 1000 sample/s
SNOOPer.SELECT V.RANGE(vint)
;
;
;
;
The contents of the variable vint is

sent by the application program
The variable vint is a 32 bit
integer
81
Trace Methods
If the application program passes e.g. the contents of a register via DCC, the application program has to
declare an extra variable.
volatile int Snoop;
This variable can the be used by the debugger to display the information passed via the DCC.
SNOOPer.SELECT V.RANGE(Snoop)
82
Trace Methods
Snooping the Program Counter

The program counter can be monitored if the on-chip debugging interface provides one of the following
characteristics:
The program counter is memory-mapped and the on-chip debugging interface provides real-time
memory access (e.g. TriCore, TMS320C5x).
The on-chip debugging interface provides the possibility to check the program counter (e.g.
Program Counter Sample Register for the ARM11, Quick Access for V850).
To check if your CPU can monitor the program counter enter the following command:
SNOOPer.Mode PC
; If your debugger accepts this command,

; monitoring the PC is supported by your CPU
Here a full configuration:

SNOOPer.RESet
; Reset the SNOOPer
SNOOPer.Mode PC
; Choose the recording mode PC
SNOOPer.SIZE 10000.
; Set the size of the SNOOPer trace buffer

; to 10000.
SNOOPer.Rate 5000.
; Set the sampling rate to 5000. sample/s
83
Trace Methods
The monitored PC can be displayed with the command SNOOPer.List.
Complementary commands:
SNOOPer.Chart.sYmbol
Displays the result of SNOOPer.List graphically.
PERF.state
Monitoring the PC while the program in running allows to make a

non-intrusive function performance analysis with the debugger.
84
Trace Methods
Software Trace
Problem description: A TRACE32-ICD debugger is used to test and integrate an application program on
the target. Now a problem occurs, that could easily be solved if more information about the program history
would be available.
Usually a TRACE32-ICD hardware trace extension can be used to get more information about the program
history. But not all targets allow the operation of such a hardware trace.
For these targets Lauterbach is offering a software trace. The software trace however needs RAM from the
target and is influencing the real-time behavior.
To operate a software trace, Lauterbach provides:
A general trace format for a software trace located in the target RAM
Configuration and display commands for the software trace in the TRACE32 software
(command: LOGGER)
Predefined algorithms to operate the software trace from the target program
To use the software trace basic knowledge of the target hardware and the processor architecture is required.
I
Trace METHOD LOGGER
85
Software Trace
Implementation of the
trace memory
The user reserves a part of the target RAM, that can be used by
TRACE32 as trace memory.
Max. trace size
Any desired.
Sampling
The trace memory is filled either by an algorithm predefined by

Lauterbach or by a user-defined algorithm.
The algorithm can either be called by an interrupt or the code has
to be instrumented.
Influence on the real-time

behavior
Yes, depends on the implementation of the sampling algorithm.
Selective tracing
Possible by the sampling algorithm.
Fastest sampling rate
Depends on the sampling algorithm.
86
Software Trace
The Trace Format

8 x 32-bit LOGGER
description block
LOGGER
address
16-bit
flags
48-bit
time stamp
32-bit
address
32-bit
data
Start address
Size
Index
Trigger counter
Flags from the host
Flags to the host
(currently not used)
TRACE32Software
Target RAM
LOGGER Description Block

Start address (32-bit)
Start address of the software trace in the target RAM.
Size (32-bit)
Number of trace records.
Index (32-bit)
Record number for the next entry.
Trigger counter (32-bit)

Flags from the host (32bit)
Bit 0: ARM (high active)

Bit 8: FIFO mode (low active), Stack mode (high active)
Flags to the host (32-bit)
Bit 0: Overrun (high active)

Bit 8: Trigger (high active)
Bit 9: Break (high active)
87
Software Trace
Operation Modes
The software trace can work in 2 operation modes:
Address/data trace
Address and data information is sampled.
Flow trace
A flow trace is available on architectures which provide a branch trace capability like all
PowerPC families and the SuperH SH4. For a flow trace all changes in the program flow are
sampled. The TRACE32 software reconstructs and displays the complete program flow out of
this information.
Address and Data Trace
Software Trace Record Description

Flags (16-bit)
Fetch (0x10)
Data Read (0x20)
Data Write (0x30)
Time stamp (48-bit)
Time stamp from a timer, counter etc. from the target
Address (32-bit)
32-bit address
Data (32-bit)
32-bit data
If a normal software trace is used, the software trace listing displays the address and data, the cycle type
and a time stamp.
88
Software Trace
Program Flow Trace
SoftwAre Trace Record Description FlowTrace (e.g. PowerPC, SH4)

Flags (16-bit)
0xF00x: Flow trace record
Time stamp (48-bit)
Time stamp from a timer, counter etc. from the target
Address (32-bit)
Address 1
Address (32-bit)
Address 2
If the software trace is used to sample the program flow, the software trace listing reconstructs the program
flow based on the sampled information about the changes in the program flow.
Reconstructed
program flow
Sampled change in
the program flow
89
Software Trace
Software Trace Configuration
TRACE32 Software
LOGGER configuration commands
LOGGER description block
Predefined algorithm
in debug monitor (not visible) e.g SH4
in code linked to the application e.g. PPC
User-defined algorithm
Software trace in target RAM
90
Software Trace
Software Trace Configuration in Code

1.
Definition of the LOGGER description block and the software trace

Example:
typedef struct
{
unsigned long tshigh;
/* high part of timestamp and cycle info */
unsigned long tslow;
/* low part of timestamp
*/
unsigned long address;

unsigned long data;
}
T32_loggerData;
#define T32_LOGGER_SIZE1024
int T32_LoggerFast = TRUE;
extern T32_loggerData T32_LoggerBuffer[];
struct
{
T32_loggerData * ptr;
long size;
/* pointer to trace data
*/
/* size of trace buffer
*/
volatile long index;
long tindex;
long iflags;
long oflags;
/* current write pointer
*/
/*
/*
/*
/*
/*
*/
*/
index of trigger record

incoming flags, Bit 0: ARM,
Bit 8: Stack Mode */
outgoing flags, Bit 0: Overflow,
Bit 8: Trigger, Bit 9:
*/
*/
Break */
long reserved1;
long reserved2;
T32_loggerData buffer[T32_LOGGER_SIZE];
}
T32_LoggerStruct;
91
Software Trace
2.
Instrument your program to fill the software trace.

Add commands to fill the software trace at the appropriate location in your application.
Example:
T32_LoggerWrite(<cycle type>, <address>, <data>)
Use an interrupt to fill the software trace.

Example:
__interrupt__ void T32_LoggerInterrupt()
{
T32_LoggerWrite(<cycle type>, <address>, <data>);
}
The main tasks of the T32_LoggerWrite algorithm are:

-
to handle the flags in the software trace
to enter the time stamp (optional)
to enter the trace data
to maintain the software trace by the logger description block
An example for a T32_LoggerWrite algorithm can be found on the TRACE32 software CD:
\Dos\Demo\Powerpc\etc\Logger\logdemo.c
92
Software Trace
3.
Configure the software trace in the TRACE32 software.
LOGGER.state
Display the LOGGER configuration window
Time stamp configuration
LOGGER address
Define the usage of the software trace
LOGGER address
Enter the start address of the logger description block
OFF: no time stamp is used

Up: time stamp counts up
Down: time stamp counts down
Rate: Frequency of the time stamp in Hz
Usage of the software

trace
Flow Trace OFF: software trace is used to sample address

and data information
Flow Trace ON: software trace is used to sample program
flow
93
Software Trace
4.
Initialize the software trace.
Push Init to initialize the software trace
Push the Init button in the commands field to initialize the software trace. Prior to the initialization the
chip selects have to be configured in order to get access to the target RAM.
After the initialization the SIZE field contains the size of the software trace.
5.
Switch on the software trace in the TRace configuration window.
LOGGER ON:
Use software trace
94
Software Trace
Software Trace Configuration in the TRACE32 Software

1.
Definition of the LOGGER description block

Command: LOGGER.state
LOGGER.state
Display the LOGGER configuration window
Enter the start ADDRESS of the LOGGER

description block
Switch ON the Create check box to inform the
TRACE32 software, that you want to create the
LOGGER Description block and the software trace
from the TRACE32 software
SIZE of the software trace

Size
Define the size of the software trace

Up: time stamp counts up
Down: time stamp counts down
Rate: Frequency of the time stamp in Hz
Usage of the software trace
Flow Trace OFF: software trace is used to sample address and

data information
Flow Trace ON: software trace is used to sample program flow
95
Software Trace
The required target memory size can by calculated as follows:

Memory required for the LOGGER Description block: 32 byte
Memory required for the Software Trace: Number of records x 16 byte
Logger_Memory_Size = 32 byte + (Number of records x 16 byte)
2.
Instrument your program to fill the software trace.

Add commands to fill the software trace at the appropriate location in your application
Example:
T32_LoggerWrite(<cycle type>, <address>, <data>)
Use an interrupt to fill the software trace.

Example:
__interrupt__ void T32_LoggerInterrupt()
{
T32_LoggerWrite(<cycle type>, <address>, <data>);
}
The main tasks of the T32_LoggerWrite algorithm are:

-
to handle the flags in the software trace
to enter the time stamp (optional)
to enter the trace data
to maintain the software trace by the logger description block
An example for a T32_LoggerWrite algorithm can be found on the TRACE32 software CD:
For the SH4 family a hidden monitor is provided by the TRACE32 software to fill the software trace.
So if a software trace is used to sample the program flow for the SH4, no instrumentation of the code
is necessary.
96
Software Trace
3.
After the initialization the hidden monitor for the SH4 family is automatically activated.
4.
Switch on the software trace in the TRace configuration window.
LOGGER ON:
Use software trace
97
Software Trace
Display the Software Trace
TRACE32 Software
LOGGER display commands
LOGGER description block
Software trace in target RAM
Click here to
get a trace
listing
98
Software Trace
Software Trace as a Flow Trace for the SH4

This section shows you, how to set up a flow trace for the SH4 by using the TRACE32-ICD software trace.
Background
The SH4 core includes a 8-stage on-chip branch trace. This trace holds the source and destination address
of the last eight changes in the program flow. Sampling to the on-chip branch trace in non-intrusive.
3 classes of branch operations can be traced by the on-chip branch trace of the SH4:
Exception branches
All exceptions other than ASE exception, as well as all interrupt operation and RTE instruction
Subroutine branches
BSR, BSRF, JSR and RTS instructions
General branches
BF, BT, BF/S, BT/S, BRA, BRAF, and JMP instructions
The user program can be stopped by a TRACE exception, when the buffer contains 1 or 6 records.
This on-chip trace buffer is used as the basis for the software trace. At the moment only General branches
are supported for the use in the software trace.
99
Software Trace
Display the On-chip Trace
Select what should be sampled

into on-chip branch trace (FIFO)
Command: FIFO
Branch source
Branch destination
FIFO Modes
OFF
The on-chip branch trace is disabled.
eXception
The on-chip branch trace samples exceptions, interrupts and RTE

instructions.
Subroutine
The on-chip branch trace samples exceptions, interrupts and RTE,

BSR, BSRF, JSR and RTS instructions.
ALL
The on-chip branch trace samples all changes in the program flow.
100
Software Trace
SoftwAre Trace Record Description FlowTrace for SH4

Flags (16-bit)
0xF00n: 1st flow trace record that was copied from the on-chip
branch trace, n records with the same time stamp will follow
0xF00E: following flow trace record
0xF00F: last flow trace record in memory, all records until record
SIZE-1 are empty, next valid entry starts at record number 1.
This flag is used, if there are not enough empty records left in the
software trace to store the next 6 entries from the on-chip branch
trace.
Time stamp (48-bit)
Time stamp from performance counter (elapsed time)
Address (32-bit)
Branch source address
Address (32-bit)
Branch destination address
101
Software Trace

1.
Allocate memory space for the logger description block and the software trace.
Command: LOGGER
Start ADDRESS of the target memory block
Create check box
The required target memory size can by calculated as follows:

Memory required for the LOGGER Description block: 32 byte
Memory required for the Software Trace: Number of records x 16 byte
Logger_Memory_Size = 32 byte + (Number of records x 16 byte)
Enter the start address of the available target memory block into the ADDRESS field of the LOGGER
Window and switch ON the Create check box in the Mode field to inform the TRACE32 software,
that you want to create the LOGGER Description block and the software trace from the
TRACE32 software.
SIZE field
Select ALL to sample all changes in the program flow
Enter the number of records used for the Software Trace to the SIZE field.
Select ALL in the Flow Trace field. Then all changes in the program flow are sampled into the
software trace.
TRACE32 now allocates the memory for the software trace subsequently to the logger description
block.
102
Software Trace
2.
Define the method in which the Software Trace is filled.

By default a TRACE exception is generated after 6 valid entries to the on-chip branch trace. The user
program is stopped by this TRACE exception and a hidden monitor program is started. This monitor
program copies the contents of the on-chip branch trace into the software trace and then restarts the
program execution.
The influence on the run-time depends on the target program. With the estimation that the program
flow changes every 5 cycles, the program runtime will be 5 times slower.
AllCycles ON
If the check box AllCycles is switched ON, a TRACE exception is generated after each valid entry to
the on-chip branch trace.
103
Software Trace
3.
Define the usage of the TimeStamp.

TRACE32 provides the possibility to mark the entries to the software trace with a time stamp. One of
the Performance counters of the SH4 is used as timer here. The used performance counter is
counting upwards.
When the hidden monitor program copies the entries from the on-chip branch trace to the software
trace, the entries are marked with the time stamp. That means when 6 entries are copied at a time, all
6 entries have the same time stamp.
The Performance Counter is stopped, when the hidden monitor is active.
Click Up to use a time stamp together with
the software trace
Enter the CPU clock in Hz as frequency
of the performance counter
Here the performance counter PMCTR1 is

used as timer for the time stamp of the
104
Software Trace
4.
Initialize the software trace
After the initialization the hidden monitor for the SH4 family is automatically activated.
5.
Start the user program by Go and stop it again. Display the software trace.
105
Software Trace
Software Trace as a Flow Trace for the MPC860

This section shows you, how to set up a flow trace for the MPC860 by using the TRACE32-ICD software
trace.
Background
The MPC860 has a Trace Exception. The Trace Exception occurs:
if MSR[SE]=1 and any instruction other then rfi is successfully completed
if MSR[BE]=1 and a branch is completed
If the Trace Exception causes the processor to enter into the debug mode or if the Trace Exception is
handled by an interrupt service routine, can be decided by setting the TRE (Trace interrupt enable bit) bit in
the DER (Debug Enable Register).
To configure the MPC860 to support a software trace as flow trace:
MSR[BE]=1 and MSR[SE]=0 has to be set
DER[TRE]=0 has to be set
In consequence of this single stepping is not possible while a software trace as flow trace is used.
The time base facility (TB) of the MPC860 can be used as source for the time stamp unit.
SoftwAre Trace Record Description FlowTrace for MPC860

Flags (16-bit)
0xF000: Flow trace record
Time stamp (48-bit)
Time stamp from Time Base
Address (32-bit)
Branch destination address
Address (32-bit)
0x0000
106
Software Trace

1.
Add a definition for the LOGGER Description Block and the Software Trace to your application.
2.
Add a interrupt service routine for the Trace Exception to your application.
The main tasks of the interrupt service routine are:
-
handle the flags in the software trace
read the Time Base and enter it as time stamp (optional)
enter the branch destination address
maintain the software trace by the logger description block
An example can be found on the TRACE32 software CD:

3.
Set the MSR register.

Register.Set MSR 0x0202
4.
Disable the Trace Exception in DER.

TrOnchip.Set TRE OFF
107
Software Trace
5.
Configure the software trace in the TRACE32 software.

Command: LOGGER.state
LOGGER.state
Display LOGGER configuration window
LOGGER address
6.
LOGGER address
Enter the start address of the logger description block

Up: Time Base counts upwards
Rate: Frequency of the Time Base in Hz
Usage of the software

trace
Flow Trace ON: software trace is used to sample program

flow
108
Software Trace
7.
Switch on the software trace in the Trace configuration window.
LOGGER ON:
Use software trace
8.
Start the user program by Go and stop it again. Display the software trace.
109
Software Trace

Debugger User

Uploaded by

Copyright:

Available Formats

Debugger User

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Debugger User

Uploaded by

Copyright:

Available Formats

ICD Debugger Users Guide

TRACE32 Online Help

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

ICD Debugger User's Guide ......................................................................................................

Debugger Licenses .................................................................................................................

PODBUS Interface Card

Parallel - PODBUS Converter

SCU -PODBUS Converter

ICD Configuration for JTAG/BDM Debugger

ICD Configuration for ROM Monitor

Command Line Arguments for Starting TRACE32

PODBUS Interface Card

Parallel PODBUS Converter

Serial Line Configuration

Using Multiple Devices on one PODBUS

Tool Configuration for Single Device Solution

Tool Configuration for Multi Device Solution

Hardware Configuration for Multicore-Debugging

Install Debugger Software for Multicore Debugging

Setup and Start of TRACE32 Software

TRACE32 Multicore Configuration

Daisy Chain Settings

ICD Debugger Users Guide

Start Stop Synchronisation

Result of start/stop synchronization

Synchronisation Time Delay

Multicore Debugging Summary

Program Start and End

Installation as TRACE32-ICE Extension ................................................................................

Using Multiple Devices on one PODBUS

Working with the ICD Debug System ....................................................................................

ICD Commands and Procedures ...........................................................................................

Mapping the EPROM Simulator

SYStem.BdmClock (BDM only)

Trigger.Set (BDM only)

Trigger.Out (BDM only)

Trace Methods .........................................................................................................................

Debugging on Mixed Level

Debugging on HLL Level

Applications for the SNOOPer

Technical Data of the SNOOPer

SNOOPer via Real-Time Memory Access

SNOOPer via Debug Communication Channel

Snooping the Program Counter

Software Trace .........................................................................................................................

The Trace Format

Address and Data Trace

ICD Debugger Users Guide

Program Flow Trace

Software Trace Configuration

Software Trace Configuration in Code

Software Trace Configuration in the TRACE32 Software

Display the Software Trace

Software Trace as a Flow Trace for the SH4

Display the On-chip Trace

Software Trace Format

How to use the Software Trace

Software Trace as a Flow Trace for the MPC860

Software Trace Format

How to use the Software Trace