Training Debugger
Training Debugger
TRACE32 Directory
TRACE32 Index
History ...................................................................................................................................... 4
Registers .................................................................................................................................. 39
Breakpoints .............................................................................................................................. 69
Breakpoint Implementations 69
Software Breakpoints in RAM 69
Software Breakpoints in FLASH 70
Onchip Breakpoints in NOR Flash 71
Onchip Breakpoints on Read/Write Accesses 74
Onchip Breakpoints by Processor Architecture 75
ETM Breakpoints for ARM or Cortex-A/-R 87
Breakpoint Types 89
Program Breakpoints 90
Read/Write Breakpoints 92
Version 06-Nov-2017
History
Depending on the debug resources different debug features can be provided and different TRACE32 tools
are offered.
The TRACE32 debugger allows you to test your embedded hardware and software by using the on-chip
debug interface. The most common on-chip debug interface is JTAG.
A single on-chip debug interface can be used to debug all cores of a multi-core chip.
Debug Features
PC
Windows / Linux / Mac OS
Target
Debug Cable
PODBUS IN
POWER DEBUG USB INTERFACE / USB 3
USB LAUTERBACH
Connector
POWER
SELECT
Cable TRIG
EMULATE
JTAG
DEBUG CABLE
DEBUG CABLE
USB
LAUTERBACH
POWER
7-9V
PODBUS OUT
AC/DC Adapter
Current module:
Deprecated module:
HUB PC or
Workstation
1 Gbit Ethernet
Target
Debug Cable
Ethernet TRIGGER
PODBUS SYNC
POWER DEBUG PRO
Cable
Connector
POWER
ETHERNET
SELECT
RUNNING
JTAG
DEBUG CABLE
DEBUG CABLE
USB
LAUTERBACH
POWER
7-9V
AC/DC Adapter
Current module:
Deprecated modules:
A number of single-core processors/multi-core chips offer in addition to the on-chip debug interface an on-
chip trace buffer.
• On task/process switches.
In order to analyze and display the trace information the debug cable needs to provide a Trace License. The
Trace Licenses use the following name convention:
A number of single-core processors/multi-core chips offer in addition to the on-chip debug interface a so-
called trace port. The most common trace port is the TPIU for the ARM/Cortex architecture.
• On task/process switches.
The display and the evaluation of the trace information is described in the following training manuals:
NEXUS is a standardized interface for on-chip debugging and real-time trace especially for the automotive
industry.
NEXUS Features
The display and the evaluation of the trace information is described in “Nexus Training”
(training_nexus.pdf).
This chapter describes the basic parameters required to start a TRACE32 PowerView instance.
The parameters are defined in the configuration file. By default the configuration file is named config.t32. It
is located in the TRACE32 system directory (parameter SYS).
Configuration File
Open the file config.t32 from the system directory (default c:\T32\config.t32) with any ASCII editor.
Environment OS=
variables ID=<identifier> (ID) Prefix for all files which are saved by
TMP=<temp_directory> the TRACE32 PowerView instance into the
SYS=<system_directory> TMP directory
HELP=<help_directory>
(TMP) Temporary directory used by the
TRACE32 PowerView instance (*)
; Host interface
PBI=
USB
; Environment variables
OS=
ID=T32
TMP=C:\temp ; temporary directory for TRACE32
SYS=C:\t32 ; system directory for TRACE32
HELP=C:\t32\pdf ; help directory for TRACE32
; Printer settings
PRINTER=WINDOWS ; all standard windows printer can be
; used from the TRACE32 user interface
; Host interface
PBI=
USB
NODE=training1 ; NODE name of TRACE32
; Environment variables
OS=
ID=T32_training1
TMP=C:\temp ; temporary directory for TRACE32
SYS=C:\t32 ; system directory for TRACE32
HELP=C:\t32\pdf ; help directory for TRACE32
; Printer settings
PRINTER=WINDOWS ; all standard windows printer can be
; used from TRACE32 PowerView
TRACE32 allows to communicate with a POWER DEBUG INTERFACE USB from a remote PC. For an
example, see “Example: Remote Control for POWER DEBUG INTERFACE / USB” in TRACE32
Installation Guide, page 58 (installation.pdf).
; Host interface
PBI=
NET
NODE=training1
; Environment variables
OS=
ID=T32 ; temp directory for TRACE32
SYS=C:\t32 ; system directory for TRACE32
HELP=C:\t32\pdf ; help directory for TRACE32
; Printer settings
PRINTER=WINDOWS ; all standard windows printer can be
; used from the TRACE32 user interface
IFCONFIG Dialog to display and change information for the Ethernet interface
Changing the font size can be helpful for a more comfortable display of TRACE32 windows.
; Screen settings
SCREEN=
FONT=SMALL ; Use small fonts
The properties window allows you to configure some basic settings for the TRACE32 software.
Configuration File
Working Directory
Window Size
By default the configuration file config.t32 in the TRACE32 system directory (parameter SYS) is used. The
option -c allows you to define your own location and name for the configuration file.
C:\T32_ARM\bin\windows\t32marm.exe -c j:\and\config.t32
After its start TRACE32 PowerView is using the specified working directory. It is recommended not to work in
the system directory.
The basic parameters can also be set up in an intuitive way via T32Start.
A detailed online help for t32start.exe is available via the Help button or in “T32Start” (app_t32start.pdf).
Parameters
If you want to contact your local Lauterbach support, it might be helpful to provide some basis information
about your TRACE32 tool.
Version Information
2. The debug licenses programmed into the debug cable and the expiration date of your software
warranty respectively the expiration date of your software maintenance.
1. To generate a system information report, choose Help > Support > Systeminfo.
2. Preferred: click Save to File, and send the system information as an attachment to your e-mail.
3. Click Save to Clipboard, and then paste the system information into your e-mail.
Before you can start debugging, the debug environment has to be set up. An overview on the most common
setups is given in “Establish Your Debug Session” (tutor_setup.pdf).
Local Buttons
Window Area
Context Menu
Command Line
Message Line
SoftkeyLine
State Line
The structure of the menu bar and the tool bar are defined by the file t32.men
which is located in the TRACE32 system directory.
TRACE32 allows you to modify the menu bar and the tool bar so they will better
fit your requirements. Refer to “Training Menu” (training_menu.pdf) for details.
The main menu bar provides all important TRACE32 functions sorted by groups.
Accelerators
; user menu
MENU.AddMenu "Set PC to main" "Register.Set pc main"
User Menu
For more complex changes to the main menu bar refer to “Training Menu”
(training_menu.pdf).
The main tool bar provides fast access to often used commands.
User specific
button
TRACE32 Documents -> IDE User Interface -> IDE Reference Guide -> MENU -> Programming
Commands -> TOOLITEM.
ChDir.DO ~~/demo/menu/internal_icons.cmm
For more complex changes to the main tool bar refer to “Training Menu”
(training_menu.pdf).
No information about the window layout is saved when you exit TRACE32 PowerView. To save the window
layout use the Store Windows to … command in the Window menu.
Script example:
B::
TOOLBAR ON
STATUSBAR ON
FRAMEPOS 68.0 5.2857 107. 45.
WINPAGE.RESET
WINCLEAR
WINPOS 0.0 0.0 80. 16. 15. 1. W000
WINTABS 10. 10. 25. 62.
List
WINPAGE.SELECT P000
ENDDO
Command line
Command Structure
Device prompt: the default device prompt is B::. It stands for BDM which was the first on-chip debug
interface supported by Lauterbach.
Option(s)
Parameter(s)
Subcommand
Command group
Each command can be abbreviated. The significant letters are always written in upper case letters.
Examples for the parameter syntax and the use of options will be presented throughout this training.
Message Area
Message Line
• Message Area window for the display of the last system and error messages
The softkey line allows to enter a specific command step by step. Here an example:
The display of the hex. dump can be adjusted to your needs by an option.
• Information on the state of the debugger (running, stopped, stopped at breakpoint etc.)
The Mode field of the state line indicates the debug mode. The debug mode defines how source code
information is displayed.
Core Registers
Register.view
TRACE32 supports a free configurable window to display/manipulate configuration registers and the on-chip
peripheral registers at a logical level. Predefined peripheral files are available for most standard
processors/chips.
Tree Display
The individual configuration registers/on-chip peripherals are organized by TRACE32 PowerView in a tree
structure. On demand, details about a selected register can be displayed.
Please be aware, that TRACE32 permanently updates all windows. The default
update rate is 10 times per second.
Sometimes it might be useful to expand the tree structure from the start.
Commands:
The following command sequence can be used to save the contents of all configuration registers/on-chip
peripheral registers to a file.
The access class, address, bit position and the full name of the selected item are
displayed in the state line; the full name of the selected item is taken from the
processor/chip manual.
• By pressing the right mouse button and selecting one of the predefined values from the pull-
down menu.
The definition can be changed to fit to your requirements using the PER command group.
The path and the version of the actual PER definition file can be displayed by using:
VERSION.SOFTWARE
PER.view C:\T32_ARM\percortexa9mpcore.per
This training section introduces the most often used methods to display and modify memory:
• The Data.dump command, that displays a hex dump of a memory area, and
the Data.Set command that allows to modify the contents of a memory address.
• The List (former Data.List) command, that displays the memory contents as source code listing.
A so-called access class is always displayed together with a memory address. The following access
classes are available for all processor architectures:
For additional access classes provided by your processor architecture refer to your “Processor
Architecture Manuals”.
Please be aware, that TRACE32 permanently updates all windows. The default
update rate is 10 times per second.
If you enter an address range, only data for the specified address range are displayed. This is useful if a
memory area close to memory-mapped I/O registers should be displayed and you do not want TRACE32
PowerView to generate read cycles for the I/O registers.
• <start_address>--<end_address>
• <start_address>..<end_address>
• <start_address>++<offset_in_byte>
TRACE32 PowerView updates the displayed memory contents by default only if the core is stopped.
Various cores allow a debugger to read and write physical memory (not cache) while the core is executing
the program. The debugger has in most cases direct access to the processor/chip internal bus, so no extra
load for the core is generated by this feature.
Open the SYStem window in order to check if your processor architecture allows a debugger to read/write
memory while the core is executing the program:
MemAccess CPU/NEXUS/DAP
indicates, that the core allows
the debugger to read/write the
memory while the core is
executing the program.
Please be aware that caches, MMUs, tightly-coupled memories and suchlike add conditions to the run-time
memory access or at worst make its use impossible.
Restrictions
The following description is only a rough overview on the restrictions. Details about your core can be found in
the Processor Architecture Manual.
If run-time memory access for a cached memory location is enabled the debugger acts as follows:
MMU
Debuggers have no access to the TLBs while the program execution is running. As a consequence run-time
memory access can not be used, especially if the TLBs are dynamically changed by the program.
In the exceptional case of static TLBs, the TLBs can be scanned into the debugger. This scanned copy of
the TLBs can be used by the debugger for the address translation while the program execution is running.
Tightly-coupled Memory
Tightly-coupled memory might not be accessible via the system memory bus.
Usage
The usage of the non-intrusive run-time memory access has to be configured explicitly. Two methods are
provided:
• Configure run-time memory access for all windows that display memory contents (not available
for all processor architectures).
If the E check box is enabled, the attribute E is added to the memory class:
If MemAccess CPU/NEXUS/DAP is
selected and DUALPORT is checked,
run-time memory is configured for
all windows that display memory
If your processor architecture doesn’t allow a debugger to read or write memory while the core is executing
the program, you can activate an intrusive run-time memory access if required.
If an intrusive run-time memory access is activated, TRACE32 stops the program execution periodically to
read/write the specified memory area. Each update takes at least 50 us.
• The time required by the debugger to start and stop the program execution on a processor/core
(main factor).
• Cache and MMU assesses that need to be performed to read the information of interest.
; Mark changes
Breakpoint Implementations
A debugger has two methods to realize breakpoints: Software breakpoints and Onchip breakpoints.
The default implementation for breakpoints on instructions is a Software breakpoint. If a Software breakpoint
is set the original instruction at the breakpoint address is patched by a special instruction (usually TRAP) to
stop the program and return the control to the debugger.
TRACE32 allows to set Software breakpoints to FLASH. Please be aware that the affected FLASH sector
has to be erased and programmed in order to patch the break instruction used by the Software breakpoint.
This usually takes some time and reduces the number of FLASH erase cycles. For details refer to
“Software Breakpoints in FLASH” (norflash.pdf).
Most core(s) provide a small number of Onchip breakpoints in form of breakpoint registers. These Onchip
breakpoints can be used to set breakpoints to instructions in read-only memory like NOR FLASH.
1. If the code is completely located in read-only memory, the default implementation for the
Program breakpoints can be changed.
MAP.BOnchip 0x0++0x1FFF
MAP.BOnchip 0xA0000000++0x1FFFFF
Onchip breakpoints can be used to stop the core at a read or write access to a memory location.
The list on page 4 gives an overview of the availability and the usage of the Onchip breakpoints. The
following notations are used:
• Program breakpoints: Number of Onchip breakpoints that can be used to set Program break-
points into onchip FLASH or NOR FLASH.
• Read/Write breakpoints: Number of Onchip breakpoints that stop the program when a read or
write to a certain address happens.
• Data value breakpoint: Number of Onchip data breakpoints that stop the program when a spe-
cific data value is written to an address or when a specific data value is read from an address.
Single address
For some processor architectures Onchip breakpoints can only mark single addresses (e.g Cortex-A9).
Address ranges
Most processor architectures allow to mark address ranges with Onchip breakpoints. It is very common
that one Onchip breakpoint marks the start address of the address range while the second Onchip
breakpoint marks the end address (e.g. MPC57xx).
The command TrOnchip.VarCONVert allows to control how range breakpoints are set for scalars (int, float,
double).
TrOnchip.VarCONVert OFF If a breakpoint is set to a scalar variable (int, float, double) breakpoints
are set to all memory addresses that store the variable value.
TrOnchip.VarCONVert OFF
Var.Break.Set vint /Write
Data.View vint
A number of processor architectures provide only bit masks or fixed range sizes to mark an address range
with Onchip breakpoints. In this case the address range is always enlarged to the smallest bit mask/next
allowed range that includes the address range.
It is recommended to control which addresses are actually marked with breakpoints by using the
Break.List /Onchip command:
Breakpoint setting:
Var.Break.Set flags
Break.List
Break.List /Onchip
1-4 by BU 1-4 by BU
(Breakpoint Unit) single addr. only
onchip flash only
Cortex-M1 1/2 by DW 1 or 2 by DW 1 or 2 by DW —
(Data Wachtpoint range as bit mask range as bit mask
unit)
6 by FPB 6 by FPB
(Flash Patch and single addr. only
Breakpoint unit) onchip flash only
break-before-make
Cortex-M4 1 or 4 by DWT 1 or 4 by DWT 1 or 4 by DWT 0 or 1
(Data Wachtpoint addr. range only range as bit mask needs two DWT
and Trace unit) break-after-make comparators
range as bit mask
2 or 6 by FPB 2 or 6 by FPB
(Flash Patch and single addr. only
Breakpoint unit) onchip flash only
break-before-make
Cortex-M7 2 or 4 by DWT 2 or 4 by DWT 2 or 4 by DWT 1
(Data Wachtpoint addr. range only range as bit mask
and Trace unit) break-after-make
range as bit mask
4 or 8 by FPB 4 or 8 by FPB
(Flash Patch and single addr. only
Breakpoint unit) onchip flash only
break-before-make
Cortex-R4 2-8 instruction 2-8 1-8 —
Cortex-R5 1-8 read/write range as bit mask range as bit mask,
break before make
MPC83xx
(PQ2 Pro)
MPC85xx 2 instruction 2/1 2 —
(PQ3) (reduced to 1 if soft- 2 single address or 2 single address or
ware breakpoints 1 breakpoint range 1 breakpoint range
are used) break before make
2 read/write
MSP430 2…8 2…8 2…8 2…8
ranges require ranges require
2 breakpoints 2 ...4 breakpoints
PPC401 2 instruction, 2 single address or 2 single address or —
PPC403 2 read/write 2 ranges 2 ranges
single address or
ranges of 2, 4 or
8 bytes (aligned)
XC2000/ 4 up to 4 up to 4 write up to 4 write
XE16x up to 1 read up to 1 read
XC800 4 up to 4 up to 1 single —
up to 1 range address read or
(2 single needed) address range
up to 1 single
address write or
address range
XSCALE 2 instruction/ 2 single address 2 single address or —
2 read/write 1 range as bit mask
Softcores
Configurable Cores
ETM breakpoints extend the number of available breakpoints. Some Onchip breakpoints offered by ARM
and Cortex-A/-R cores provide restricted functionality. ETM breakpoints can help you to overcome some of
these restrictions.
ETM breakpoints always show a break-after-make behavior with a rather large delay. Thus, use ETM
breakpoints only if necessary.
Please refer to the description of the ETM.StoppingBreakPoints command, if you want to use the ETM
breakpoints.
TRACE32 PowerView provides the following breakpoint types for standard debugging.
The red program breakpoint indicator marks all code lines for which a Program breakpoint is set.
The program stops before the instruction marked by the breakpoint is executed (break before make).
Break.Set <address> /Program [/DISable] Set a Program breakpoint to the specified address.
The Program breakpoint can be disabled if required.
Core stops at
a read access
to the variable
Core stops at
a write access
to the variable
On most core(s) the program stops after the read or write access (break after make).
Break.List
Software breakpoints
• If MemAccess CPU/NEXUS/DAP is enabled, Software breakpoints can be set while the core(s)
is executing the program. Please be aware that this is not possible if an instruction cache and an
MMU is used.
• If CpuAccess is enabled, Software breakpoints can be set while the core(s) is executing the
program. If the breakpoint is set via CpuAccess the realtime behavior is influenced.
• If MemAccess and CpuAccess is Denied Software breakpoints can only be set when the
program execution is stopped.
The behavior of Onchip breakpoints is core dependent. E.g. on all ARM/Cortex cores Onchip breakpoints
can be set while the program execution is running.
TRACE32 PowerView offers in addition to the basic breakpoints (Program/Read/Write) also complex
breakpoints. Whenever possible these breakpoints are implemented as real-time breakpoints.
Real-time breakpoints do not disturb the real-time program execution on the core(s), but they require a
complex on-chip break logic.
If the on-chip break logic of a core does not provide the required features or if Software breakpoints are
used, TRACE32 has to implement an intrusive breakpoint.
Program execution
Check not ok
Perform
required check
Check ok
Stay stopped
Each stop to perform the check suspends the program execution for at least 1 ms. For details refer to
“StopAndGo Mode” (glossary.pdf)
The (short-time) display of a red S in the state line indicates that an intrusive breakpoint was hit.
or
Program breakpoint is set to the function entry (first address of the function).
Break.Set func11
• If the on-chip break logic supports ranges for Program breakpoints, a Program breakpoint
implemented as Onchip is set to the full address range covered by the function.
• If the on-chip break logic provides only bitmasks to realizes breakpoints on instruction ranges, a
Program breakpoint implemented as Onchip is set by using the smallest bitmask that covers the
complete address range of the function.
Var.Break.Set func11
Program breakpoint is set to the first assembler instruction generated for the program line number.
Break.Set func11\7
Break.Set flags
• If the on-chip break logic supports ranges for Read/Write breakpoints, the specified breakpoint is
set to the complete range covered by the variable.
• If the on-chip break logic provides only bitmasks to realizes Read/Write breakpoints on address
ranges, the specified breakpoint is set by using the smallest bitmask that covers the address
range used by the variable.
Var.Break.Set flags
If you want to use an HLL expression to specify the address range for a Read/Write breakpoint, the HLL
check box has to be checked.
• If the on-chip break logic supports ranges for Read/Write breakpoints, the specified breakpoint is
set to the complete address range covered by the HLL expression.
• If the on-chip break logic provides only bitmasks to realizes Read/Write breakpoints on address
ranges, the specified breakpoint is set by using the smallest bitmask that covers the address
range used by the HLL expression.
Var.Break.Set flags[3]
Implementation
Implementation
By default the program execution is stopped when a breakpoint is hit (action stop). TRACE32 PowerView
provides the following additional reactions on a breakpoint hit:
Action (debugger)
Spot The program execution is stopped shortly at a breakpoint hit to update the
screen. As soon as the screen is updated, the program execution continues.
WATCH Trigger the debug pin at the specified event (not available for all processor
architectures).
Alpha, Beta, Charly, Delta and Echo breakpoint are only used in very special cases. For this reason no
description is given in the general part of the training material.
TraceEnable Advise on-chip trace logic to generate trace information on the specified event.
TraceON Advise on-chip trace logic to start with the generation of trace information at the
specified event.
TraceOFF Advise on-chip trace logic to stop with the generation of trace information at the
specified event.
TraceTrigger Advise on-chip trace logic to generate a trigger at the specified event.
TRACE32 PowerView stops the recording of trace information when a trigger is
detected.
A detailed description for the Actions (on-chip and off-chip trace) can be found in the following manuals:
The information displayed within TRACE32 PowerView is by default only updated, when the core(s) stops
the program execution.
The action Spot can be used to turn a breakpoint into a watchpoint. The core stops the program execution at
the watchpoint, updates the screen and restarts the program execution automatically. Each stop takes
50 … 100 ms depending on the speed of the debug interface and the amount of information displayed on
the screen.
Example: Update the screen whenever the program executes the instruction sieve\11.
Options
DISableHIT ON: Disable the breakpoint after the breakpoint was hit.
Temporary breakpoints are usually not set via the Break.Set dialog, but they are often used while debugging.
Examples:
• Go Till
Go <address> [ <address> …]
Go.Return
; first Go.Return
; set a temporary breakpoint to the start of the function epilogue
; and start the program execution
Go.Return
; second Go.Return
; set a temporary breakpoint to the function return
; and start the program execution
Go.Return
The DATA field offers the possibility to combine a Read/Write breakpoint with a specific data value.
• DATA breakpoints are implemented as real-time breakpoints if the core supports Data Value
Breakpoints (for details on your core refer to “Onchip Breakpoints by Processor Architecture”,
page 75).
TRACE32 PowerView allows inverted data values if this is supported by the on-chip break logic.
• DATA breakpoints are implemented as intrusive breakpoints if the core does not support Data
Value Breakpoints. For details on the intrusive DATA breakpoints refer to the description of the
Break.Set command.
TRACE32 PowerView allows inverted data values for intrusive DATA breakpoints.
If an address or symbol is used the user has to specify the access width, so that the correct number of bits is
compared.
TASK-aware breakpoints are implemented on most cores as intrusive breakpoints. A few cores support real-
time TASK-aware breakpoints (e.g. ARM/Cortex). For details on the real-time TASK-aware breakpoints refer
to the description of the Break.Set command.
Processing:
Specified No
task Continue with
running? program execution
Yes
Each stop at the TASK-aware breakpoint takes at least 1.ms. This is why the red S is displayed in the
TRACE32 PowerView state line whenever the breakpoint is hit.
Example for ARM9: Stop the program execution at the entry to the function Func_2 only if the taskF “main” is
running (Onchip breakpoint).
Software Counter
If the on-chip break logic of the core does not provide counters or if a Software breakpoint is used, counters
are implemented as software counters.
Processing:
Increment
counter
Counter No
reached final Continue with
program execution
value?
Yes
Each stop at a Counter breakpoint takes at least 1.ms. This is why the red S is displayed in the TRACE32
PowerView state line whenever the breakpoint is hit.
The on-chip break logic of some cores e.g. MPC8xx, MPC5xx, MPC55xx, StarCore provides counters. They
are used together with Onchip breakpoints.
Example: Stop the program execution after the function sieve was entered 1000. times.
The counters run completely in real-time. No current counter value can be displayed while the program
execution is running. As soon as the counter reached its final value, the program execution is stopped.
The program execution is stopped at the breakpoint only if the specified condition is true.
Processing:
AfterStep No
check box
ON?
Yes
Perform assembler
single step
Verify
condition
Condition No
is Continue with
true? program execution
Yes
Each stop at a CONDition breakpoint takes at least 1.ms. This is why the red S is displayed in the TRACE32
PowerView state line whenever the breakpoint is hit.
Stop the program execution at a write access to the variable mstatic1 only if flags[12] is equal to 0 and
mstatic1 is greater 0.
Perform an assembler single step because the processor architecture stops before the write access is
performed.
AfterStep checked
Examples: Stop the program executions on a write to the address flags if Register R11 is equal to 1.
The field CMD allows to specify one or more commands that are executed when the breakpoint is hit.
Example: Write the contents of flags[12] to a file whenever the write breakpoint at the variable flags[12] is
hit.
The on-chip break logic of some cores allows to combine data accesses and instructions to form a complex
breakpoint (e.g. ARM or PowerArchitecture).
Preconditions
• Harvard architecture.
• The on-chip break logic supports a logical AND between Program and Read/Write breakpoints.
Advantageous
2. Select MemoryWrite
If the on-chip breakpoint logic does not provide an inverting logic, the
core has to provide the facility to set the specified breakpoint type on
2 address ranges.
Stop the program execution when code outside of the function sieve writes 1 to the variable flags[3].
The following command allows to check how the option EXclude is implemented.
Break.List /Onchip
If your TRACE32 PowerView does not accept the option EXclude, delete all other Onchip breakpoints, to
make sure that enough resources are available.
data Data value that has to be read/written to stop the program execution by
the breakpoint
condition Condition that has to be true to stop the program execution by the
breakpoint
A (AfterStep) A ON: Perform an assembler single step before condition is evaluated
cmd (command) Commands that are executed after the breakpoint hit
R (resume) R ON: continue the program execution after the specified commands
were executed
Enable/Disable Breakpoints
B::
BREAK.RESET
B.S func4 /P /DISABLEHIT
B.S sieve /P
V.B.S \\diabp555\Global\flags[3]; /W /DATA.BYTE 0x1;
ENDDO
HLL mode and MIX mode debugging is simple, if the compiler generates a continuous block of assembler
code for each HLL code line.
If compiler optimization flags are turned on, it is highly likely that two or more detached blocks of assembler
code are generated for individual HLL code lines. This makes debugging laboriously.
TRACE32 PowerView displays a drill-down button, whenever two or more detached blocks of assembler
code are generated for an HLL code line.
Drill-down button
The following background information is fundamental if you want to debug optimized code:
• In HLL debug mode, the HLL code lines are displayed as written in the compiled program (source
line order).
• In MIX debug mode, the target code is disassembled and the HLL code lines are displayed
together with their assembler code blocks (target line order). This means if two or more detached
blocks of assembler code are generated for an HLL code line, this HLL code line is displayed
more than once in a MIX mode source listing.
The blue cursor in the MIX mode display follows the cursor movement
of the HLL mode display (Track option).
List.Hll
List.Mix
If a Program breakpoint is set to an HLL code line for which two or more detached blocks of assembler code
are generated, a Program breakpoint is set to the start address of each assembler block.
There are local buttons in the List window for all basic debug commands
Diverge Exit loops or fast forward to not yet stepped code lines. Step.Over is performed
repeatedly.
TRACE32 maintains a list of all assembler/HLL lines which were already reached by a Step. These reached
lines are marked with a slim grey line in the List window.
List.auto /DIVERGE
Column layout
state done: code line was reached by a Step and a Step was started from
this code line.
hit: code line was reached by a Step.
target: code line is a possible destination of an already started Step,
but was not reached yet (mostly caused by conditional branches).
When all reachable code lines are marked as done, the following message is displayed:
DIVERGE marking is
done whenever you
single step.
Up This command is used to return to the function that called the current function.
For this a temporary breakpoint is set to the instruction directly after the function
call. Afterwards the program execution is started.
Step 10.
Step.Change Register(R11)
Step.Till Register(R11)>0xAA
Var.Step.Change flags[3]
Var.Step.Till flags[3]==1
Measurement procedure: The Program Counter is sampled periodically. This is implemented in two ways.
• Snoop: Processor architecture allows to read the Program Counter while the program execution
is running.
• StopAndGo: The program execution is stopped shortly in order to read the Program Counter.
Steps to be taken:
The PERF METHOD Snoop is automatically selected, if the processor architecture supports reading
the Program Counter while the program execution is running.
StopAnd Go means that the core is stopped periodically in order to get the actual Program Counter.
STREAM OFF The software running on the host initiates the periodic stops.
The display of a red S in the TRACE32 state line indicates, that the program execution is periodically
interrupted by the sample-based profiling.
TRACE32 tunes the sampling rate so that more the 99% of the run-time is retained for the actual
program run (runtime). The smallest possible sampling rate is nevertheless 10 (snoops/s).
In-depth Result
Push the Detailed button, to get more detailed information on the result.
TRACE32 assigns all samples that can not be assigned to a high-level language function to (other).
Especially if the ratio for (other) is quite high, it might be interesting what code is running there. In this case
pushing the button ListLABEL is recommended.
Steps to be taken:
Since every OS has a variable that contains the information which task/process is currently running,
this variable has to be sampled while the program execution is running in order to perform TASK
sampling.
The PERF METHOD Snoop is automatically selected, if the processor architecture supports reading
physical memory while the program execution is running. For details refer to “Run-time Memory
Access” (glossary.pdf)).
PERF.Mode TASK