Debugger Ppcpq3

PQIII Debugger
TRACE32 Online Help

TRACE32 Directory
TRACE32 Index
TRACE32 Documents ......................................................................................................................
ICD In-Circuit Debugger ................................................................................................................
Processor Architecture Manuals ..............................................................................................
PQIII ..........................................................................................................................................
PQIII Debugger .....................................................................................................................
General Note ......................................................................................................................
Brief Overview of Documents for New Users .................................................................
Warning ..............................................................................................................................
Target Design Requirement/Recommendations ............................................................
General
Quick Start .........................................................................................................................
Troubleshooting ................................................................................................................
SYStem.Up Errors
FAQ
11
Configuration .....................................................................................................................
System Overview
16
16
PowerPC MPC85XX/QorIQ specific Implementations ....................................................

Breakpoints
17
17
Breakpoints on Program Addresses
18
Breakpoints on Data Addresses
18
Breakpoints on Data Access at Program Address
19
Breakpoints on Data Value
19
Access Classes
21
Access Classes to Memory and Memory Mapped Resources
21
Access Classes to Other Addressable Core and Peripheral Resources
22
Cache
22
MESI States and Cache Status Flags
24
Viewing Cache Contents
24
Debugging Information
25
Multicore Debugging e500 Cores
26
AMP Debugging
26
Synchronous stop of both e500 cores
27
1989-2016 Lauterbach GmbH
PQIII Debugger
Programming Flash on MPC85XX / QorIQ P10XX/P20XX, PSC93XX
27
On-chip Trace on MPC85XX/QorIQ
28
General SYStem Commands ............................................................................................

SYStem.CONFIG
30
Configure debugger according to target topology
31
Run-time CPU access (intrusive)
36
Lock and tristate the debug port
36
SYStem.CpuAccess
SYStem.LOCK
SYStem.MemAccess
Run-time memory access (non-intrusive)
37
Select operation mode
38
CPU specific SYStem Commands ...................................................................................
39
SYStem.Mode
SYStem.Option CoreStandBy
SYStem.Option DCFREEZE
On-the-fly breakpoint setup
39
Prevent data cache line load/flush in debug mode
39
SYStem.Option DCREAD
Read from data cache
40
SYStem.Option DUALPORT
Implicitly use run-time memory access
40
SYStem.Option FREEZE
Freeze system timers on debug events
41
Compare PC to hook address
41
SYStem.Option HOOK
SYStem.Option ICFLUSH
Invalidate instruction cache before go and step
41
Read from instruction cache
42
Disable interrupts while single stepping
42
Disable interrupts while HLL single stepping
42
SYStem.Option MMUSPACES
Enable multiple address spaces support
43
SYStem.Option.NoDebugStop
Disable JTAG stop on debug events
43
SYStem.Option OVERLAY
Enable overlay support
44
SYStem.Option PERSTOP
Stop on-chip peripherals in debug mode
44
SYStem.Option ICREAD
SYStem.Option IMASKASM
SYStem.Option IMASKHLL
SYStem.Option SLOWRESET
Relaxed reset timing
45
Use alternative method for ASM single step
45
CPU specific MMU Commands ........................................................................................
46
SYStem.Option STEPSOFT
MMU.List
Compact display of MMU translation table
47
Load MMU table from CPU
48
Set an MMU TLB entry
49
MMU.SCAN
MMU.Set
CPU specific BenchMarkCounter Commands ................................................................

BMC.FREEZE
50
Freeze counters while core halted
50
Assign event counter to TRACE32 SnooperTrace
51
CPU specific TrOnchip Commands .................................................................................
53
BMC.SnoopSet
TrOnchip.CONVert
Adjust range breakpoint in on-chip resource
TrOnchip.RESet
53
Reset on-chip trigger settings
53
Enable special on-chip breakpoints
54
Adjust HLL breakpoint in on-chip resource
55
View on-chip trigger setup window
56
MPC85XX/QorIQ Specific On-chip Trace Settings .........................................................
57
JTAG Connector ................................................................................................................
58
TrOnchip.Set
TrOnchip.VarCONVert
TrOnchip.view
Mechanical Description
58
PQIII Debugger
JTAG Connector MPC85XX (COP)
58
Support ...............................................................................................................................
58
Available Tools
58
Compilers
60
Realtime Operation Systems
61
3rd Party Tool Integrations
62
Products .............................................................................................................................
63
Product Information
63
Order Information
63
PQIII Debugger
PQIII Debugger
Version 24-May-2016
General Note
This documentation describes the processor specific settings and features for
TRACE32-ICD for the following CPU families:
Freescale PowerQuicc III Series MPC85XX
Freescale QorIQ P101x, P102x, P2010, P2020
Freescale Qonverge PSC91XX, PSC92XX series
If some of the described functions, options, signals or connections in this Processor Architecture Manual are
only valid for a single CPU or for specific families, the name(s) of the family(ies) is added in brackets.
Brief Overview of Documents for New Users

Architecture-independent information:
Debugger Basics - Training (training_debugger.pdf): Get familiar with the basic features of a
TRACE32 debugger.
T32Start (app_t32start.pdf): T32Start assists you in starting TRACE32 PowerView instances

for different configurations of the debugger. T32Start is only available for Windows.
General Commands (general_ref_<x>.pdf): Alphabetic list of debug commands.
Architecture-specific information:
Processor Architecture Manuals: These manuals describe commands that are specific for the
processor architecture supported by your debug cable. To access the manual for your processor
architecture, proceed as follows:
-
Choose Help menu > Processor Architecture Manual.
RTOS Debugger (rtos_<x>.pdf): TRACE32 PowerView can be extended for operating systemaware debugging. The appropriate RTOS manual informs you how to enable the OS-aware
debugging.
PQIII Debugger
General Note
Warning
Signal Level
NOTE:
The debugger drives the output pins of the BDM/JTAG/COP connector with the
same level as detected on the VCCS pin. If the debug/trace I/O pins of the
processor are operating at e.g. 3.3 V, then VCCS should be connected to 3.3 V as
well.
See also System.up Errors.
ESD Protection
NOTE:
To prevent debugger and target from damage it is recommended to connect or

disconnect the debug cable only while the target power is OFF.
Recommendation for the software start:
1.
Disconnect the debug cable from the target while the target power is
off.
2.
Connect the host system, the TRACE32 hardware and the debug
cable.
3.
Power ON the TRACE32 hardware.
4.
Start the TRACE32 software to load the debugger firmware.
5.
Connect the debug cable to the target.
6.
Switch the target power ON.
7.
Configure your debugger e.g. via a start-up script.
Power down:
1.
Switch off the target power.
2.
Disconnect the debug cable from the target.
3.
Close the TRACE32 software.
4.
Power OFF the TRACE32 hardware.
PQIII Debugger
Warning
Target Design Requirement/Recommendations
General
Locate the BDM/JTAG/COP connector as close as possible to the processor to minimize the
capacitive influence of the trace length and cross coupling of noise onto the JTAG signals. Dont
put any capacitors (or RC combinations) on the JTAG lines.
Connect TDI, TDO, TMS and TCK directly to the CPU. Buffers on the JTAG lines will add delays
and will reduce the maximum possible JTAG frequency. If you need to use buffers, select ones
with little delay. Most CPUs will support JTAG above 30 MHz, and you might want to use high
frequencies for optimized download performance.
Ensure that JTAG HRESET is connected directly to the HRESET of the processor. This will
provide the ability for the debugger to drive and sense the status of HRESET. The target design
should only drive HRESET with open collector/open drain.
For optimal operation, the debugger should be able to reset the target board completely
(processor external peripherals, e.g. memory controllers) with HRESET.
In order to start debugging right from reset, the debugger must be able to control CPU HRESET
and CPU TRST independently. There are board design recommendations to tie CPU TRST to
CPU HRESET, but this recommendation is not suitable for JTAG debuggers.
Debug cable
with blue
ribbon cable
The T32 internal buffer/level shifter will be supplied via the VCCS pin.
Therefore it is necessary to reduce the VCCS pull-up on the target board
to a value smaller 10 .
PQIII Debugger
Target Design Requirement/Recommendations
Quick Start
Starting up the Debugger is done as follows:
5.
Select the CPU to load the CPU specific settings. SYStem.DETECT CPU can set the appropriate
CPU automatically.
SYStem.CPU MPC85XX
SYStem.DETECT CPU
6.
Specify that on-chip breakpoints should be used by the debugger, e.g. for program in FLASH.
MAP.BOnchip 0xFF800000--0xFFFFFFFF
7.
Reset processor and enter debug mode

SYStem.Up
The core is now stopped at the reset address.
PQIII Debugger
Quick Start
8.
After SYStem.UP, only the boot page is visible for the CPU. Initialize MMU TLBs to configure
which memory is visible to the CPU at which address. See MMU.Set for details.
;set up TLB entry starting from address 0 for SDRAM
MMU.Set TLB1 1. 0x80000600 0x00000000 0x0000003f
9.
This step prepares the target memory for program loading. To configure the CPU for the access
to all memories either run the initialization code on your target or configure the CPU by using the
Data.Set command. See demo\powerpc\hardware for complete example scripts.
;set CCSR base address to 0xE0000000
Data.Set ANC:iobase() %LONG 0x000E0000
;local access window
Data.Set ANC:iobase()+0x0C08 %long 0x00000000
Data.Set ANC:iobase()+0x0C10 %long 0x80F0001C
...
10.
Load the program.

(ELF specifies the format,
demo.elf is the file name)
Data.LOAD.ELF demo.elf
The option of the Data.LOAD command depends on the file format generated by the compiler. For
information on the compiler options refer to the section Compiler. A detailed description of the Data.LOAD
command is given in the General Commands Reference.
PQIII Debugger
Quick Start
Troubleshooting
SYStem.Up Errors
The SYStem.Up command is the first command of a debug session where communication with the target is
required. If you receive error messages while executing this command, there can be several reasons. The
Following chapters list possible errors and explains how to fix them.
Target Power Fail

The target has no power, the debug cable is not connected or not connected properly. Check if the
JTAG VCC pin is driven by the target. The voltage of the pin must be identical to the debug voltage of
the JTAG signals. It is recommended to connect VCC directly to the pin, or via a resistor < 5 kOhm.
Emulation Pod Configuration Error

The debugger was not able to identify the connected processor. There are two possible reasons for this
error. In both cases, please check the AREA window for more information:
The connected processor is not supported by the used software. Please check if the processor is
supported by the debugger. Processors that appeared later than the debugger software version
are usually not supported. Please download and install the latest software from our homepage,
or contact technical support to get a newer software. Please also check if the processor or the
software update is covered by your current licence.
A JTAG communication error prevented correct determination of the connected processor.

Please check if the debugger is properly connected to the target.
Target Reset Fail

On SYStem.Up, the debugger will assert HReset in order to stop the CPU at the reset address. A target
reset fail means, that an unexpected reset behavior caused an error:
The reset is asserted longer than 500ms and is not visible on the JTAG connector. Try
SYStem.Option.SLOWRESET, and check signal level of the JTAG HRESET pin.
The target reset is permanently asserted. Check target reset circuitry and reset pull-up
A chip external watchdog caused a reset after the debugger asserted reset. Disable the
watchdog and try again.
PQIII Debugger
Troubleshooting
Emulation Debug Port Fail

An emulation debug port fail can have a variety of reasons. Please check the AREA window for a detailed
error message. Here is a collection of frequently seen issues:
JTAG communication error. Please check the signals on the debug connector
Problems related with Reset can not always be detected as those. Please check Target Reset
Fail
AREA window error message Error reading BPTR: This error usually occurs if the CPU is
permanently in reset or checkstop. Please check on your target:
- reset and checkstop signals
- power supply
- system clocks and PLL
- bootstrap configuration pins
In many cases it is possible to verify the bootstrap configuration even if SYStem.Up fails:
SYStem.CPU MPC85XX
SYStem.DETECT CPU
SYStem.MemAccess CPU
SYStem.Mode.Attach
PER , "Global Utilities,Power-On" /DualPort
If the above sequence fails to display the power-on reset configuration registers (displaying question marks,
bus error. This can e.g. be the case when the PLL configuration is wrong), there is an alternative method to
access the bootstrap configuration information. For instructions please contact bdmppcpq3support@lauterbach.com.
SYStem.Up will also fail if the processor is configured to boot from NAND, but the NAND flash contains
invalid data. The processor enables NAND error checking upon reset. If the ECC in the spare area does not
match data in main AREA, loading the NAND flash sector fails and the debugger can not connect. The
workaround is to change the bootstrap configuration to ROM_LOG=GPCM.
If the bootstrap configuration was found to be wrong or needs to be changed temporarily (e.g. for NAND
programming), it is possible to override the bootstrap configuration setting through JTAG. For instructions
again please contact support using above email address.
PQIII Debugger
10
Troubleshooting
FAQ
Debugging via
VPN
The debugger is accessed via Internet/VPN and the performance is very

slow. What can be done to improve debug performance?
The main cause for bad debug performance via Internet or VPN are low data
throughput and high latency. The ways to improve performance by the debugger
are limited:
in practice scripts, use "SCREEN.OFF" at the beginning of the script and
"SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen updates.
Please note that if your program stops (e.g. on error) without executing
"SCREEN.OFF", some windows will not be updated.
"SYStem.POLLING SLOW" will set a lower frequency for target state
checks (e.g. power, reset, jtag state). It will take longer for the debugger to
recognize that the core stopped on a breakpoint.
"SETUP.URATE 1.s" will set the default update frequency of Data.List/
Data.dump/Variable windows to 1 second (the slowest possible setting).
prevent unneeded memory accesses using "MAP.UPDATEONCE
[address-range]" for RAM and "MAP.CONST [address--range]" for ROM/
FLASH. Address ranged with "MAP.UPDATEONCE" will read the specified
address range only once after the core stopped at a breakpoint or manual
break. "MAP.CONST" will read the specified address range only once per
SYStem.Mode command (e.g. SYStem.Up).
PQIII Debugger
11
Troubleshooting
Setting a
Software
Breakpoint fails
What can be the reasons why setting a software breakpoint fails?

Setting a software breakpoint can fail when the target HW is not able to
implement the wanted breakpoint.
Possible reasons:
The wanted breakpoint needs special features that are only possible to
realize by the trigger unit inside the controller.
Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set
window). Breakpoints with checking in real-time for data-values ("Data").
Breakpoints with special features ("action") like TriggerTrace, TraceEnable,
TraceOn/TraceOFF.
TRACE32 can not change the memory.
Example: ROM and Flash when no preparation with FLASH.Create,
FLASH.TARGET and FLASH.AUTO was made. All type of memory if the
memory device is missing the necessary control signals like WriteEnable or
settings of registers and SpecialFunctionRegisters (SFR).
Contrary settings in TRACE32.
Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type>
Onchip (HARD is only available for ICE and FIRE).
RTOS and MMU:
If the memory can be changed by Data.Set but the breakpoint doesn't work it
might be a problem of using an MMU on target when setting the breakpoint to a
symbolic address that is different than the writable and intended memory
location.
MPC8540_MP
C8560
CPU stops
unexpected
when booting
OS (e.g. Linux)
Why does the CPU stop unexpected after the operating system booted?
For MPC8560 and MPC8540 revision 1, the debugger can not differentiate
between hitting a breakpoint and the CPU entering a low-power mode. If the
DOZE bit in the HID0 register is enabled and the CPU enters the IDLE loop, the
debugger will halt the CPU.
The solution is to disable low-power modes. A workaround would be to disable
the DOZE/NAP/SLEEP bits in the HID0 register, when the CPU stops for the
first time.
All other processors of the MPC85XX series are fully supported even with lowpower modes enabled. The debugger will display the current power state in the
status line, e.g. "running (doze)".
PQIII Debugger
12
Troubleshooting
MPC85XX
Error Message:
"emulation pod
configuration
error"
Error message "emulation pod configuration error" after starting the T32
ICD software
This error can have three sources:
The CPU selection in the SYStem window does not match the CPU on the
target. Check if the selection matches the processor on the target. Try to
use auto detection (PPC..XX selection) if available.
The CPU detection failed. Check the JTAG connection to the target.
The CPU on the target is not supported by the used debugger software
release. In most cases there is additional information given in the AREA
window.
MPC85XX_P10
XX_P2020_BS
C913X
Board bring-up
using the
debugger
SYStem.Up does not work on my new board, how can I analyze the
problem using the debugger?
On MPC85XX, QorIQ P10XX/P2010/P2020 and PSC913x, this problem is often
caused by a wrong bootstrap configuration. The typical indication is that the
processor could be detected, but SYStem.Up does not work (see message
AREA contents for information about the type of error).
In many cases, though not always, it is possible to perform memory accesses.
When possible, memory access can be used to observe the Power-On Reset
Configuration registers. This can be done using the following sequence:
SYStem.CPU MPC85XX
When a wrong configuration was identified, but can not be fixed on the current
target hardware, it is possible to override this setting through JTAG. Please
contact bdmppcpq3-support@lauterbach.com for instructions to use the reset
configuration override function.
Should memory access to the Power-On Reset Configuration registers fail
(question marks shown in peripheral view), there is still a chance to get
information about the bootstrap information. In this case also contact
bdmppcpq3-support@lauterbach.com for instructions.
MPC85XX_P10
XX_P2020_BS
C913X
Breakpoints
and HLL steps
do not work
Breakpoints and HLL steps do not work on MPC85XX

Affected Processors: MPC8540, MPC8541, MPC8555, MPC8560
In order to work with software or on-chip breakpoints, for this processor it is
necessary that the Debug Interrupt Vector (IVPR+IVOR15) points to an address
with a valid instruction in memory. Ensure that there is also a valid MMU entry
for this address.
We recommend placing a NOP followed by RFCI at this address. These two
instructions at the debug interrupt address are also the prerequisite for
SYStem.Option.FREEZE (freeze the time bases when CPU stopped).
Also keep in mind that the software running on the target can change the
interrupt vector registers and memory contents any time (usually during system
initialization). You should then write NOP RFCI again to the new address before
using any breakpoints.
PQIII Debugger
13
Troubleshooting
MPC85XX_P10
XX_P2020_BS
C913X
Breakpoints
are not working
properly
Breakpoints are not working properly or stop working completely

To use breakpoints, the debugger relies on the MSR_DE (debug enable) bit to
be set permanently. If the MSR_DE bit is disabled and the CPU hits an on-chip
breakpoint, the regarding debug event is stalled until the MSR_DE bit is enabled
again. The debugger can not prevent this bit to be cleared, therefore it depends
on the target code's handling of this bit.
There are three events that can cause this bit to be cleared:
Target code clears MSR_DE by MTMSR instruction. The only workaround
is to remove/change this instructions.
Machine Check Interrupt clears MSR_DE. The CPU clears MSR_DE upon
entering a machine check interrupt. Workaround: Add code at the beginning of the machine check interrupt handler to restore MSR_DE.
Critical Interrupt clears MSR_DE. The CPU clears MSR_DE upon entering
a critical interrupt. See FAQ "Debugging Critical Interrupts".
MPC85XX_P10
XX_P2020_BS
C913X
Debugging
Critical
Interrupts
Debugging critical interrupts on MPC85XX

When debugging critical interrupts, two issues have to be taken in concern:
CPU clears MSR_DE upon entering the critical interrupt handler.
Software and on-chip breakpoints will overwrite the original CSRR0 and
CSRR1 contents.
There are two workarounds for this issue:
Set SYStem.Option.CIntDebug ON. The debugger will restore MSR_DE on
entering the critical interrupt and restore the original CSRR0/CSRR1 when
a breakpoint was hit.
Patch the interrupt handler code. On entry save CSRR0/CSRR1 and
restore MSR_DE. Before exit restore CSRR0/1 to the saved values. Breakpoints can be used safely between the two patch locations.
PQIII Debugger
14
Troubleshooting
MPC85XX_P10
XX_P2020_BS
C913X
Imprecise
Debug Event
Why does the debugger stop at a wrong address with error message
"imprecise debug event" when a breakpoint is set?
When a breakpoint is hit while MSR_DE is disabled, the debug event will not
cause the CPU to stop. Instead, the debug event is stalled until MSR_DE is
enabled again. In this case, the address where the debug event occurred is
unknown, therefore it is called imprecise debug event. If an imprecise debug
event ocurrs, the CPU will stop at an address after MSR_DE has been enabled.
To prevent the CPU from stopping at an imprecise debug event, it must be
ensured that MSR_DE is permanently set. The debugger will set MSR_DE
every time the CPU is started, but it can not prevent MSR_DE from being
cleared by the application.
There are two possible actions for target code to clear MSR_DE. One is to
directly write to MSR using the MTMSR Rx instruction. Check if Rx has the
MSR_DE bit (0x0200) set. The other action is to indirectly write using the RFI
instruction and the SRR0/1 registers. In this case, check SRR1 for MSR_DE.
For Linux, patch following files (not all are available in all versions):
head_e500.s head_fsl_booke.s reg_booke.h

MSR_DE will also be cleared upon entry of critical interrupts. See FAQ
"Debugging Critical Interrupts".
MPC85XX_P10
XX_P2020_BS
C913X
Initializing
internal L2
SRAM
I cannot write data to the internal SRAM

If you can neither write nor read the internal SRAM, first check if the SRAM is
configured and if there is a correct MMU TLB entry for those address range. If
you don't want to set up the MMU, you can also use the memory class A: to
bypass the MMU. (e.g. d.dump a:0x50000000).
If you can already see the SRAM contents and just fail to write to it, you have to
initialize the SRAM because of the ECC protection. For correct initialization, you
have to write at least 32 bytes at an aligned address in SRAM (e.g. 'D.S
ASD:0x50000000--0x5003FFFF %BE %quad 0' if SRAM is configured to start
at 0x50000000).
PQIII Debugger
15
Troubleshooting
Configuration
System Overview
PODBUS Cable
PODPC
PODPAR
PODETH
Debug
Interface
EPROM
Simulator
(optional)
...
Debug Cable
CPU CLK
Target Connector
EPROM
TS4 (400 only)
Target
RESET
INT
(600
only)
Basic configuration for the BDM Interface
PQIII Debugger
16
Configuration
PowerPC MPC85XX/QorIQ specific Implementations
Breakpoints
There are two types of breakpoints available: Software breakpoints and on-chip breakpoints.
Software Breakpoints
To set a software breakpoint, before resuming the CPU, the debugger replaces the instruction at the
breakpoint address with a TRAP instruction.
On-chip Breakpoints
To set breakpoints on code in read-only memory, only the on-chip instruction address breakpoints are
available. With the command MAP.BOnchip <range> it is possible to declare memory address ranges for
use with on-chip breakpoints to the debugger. The number of breakpoints is then limited by the number of
available on-chip instruction address breakpoints.
On-chip breakpoints: Total amount of available on-chip breakpoints.
Instruction address breakpoints: Number of on-chip breakpoints that can be used to set
Program breakpoints into ROM/FLASH/EEPROM.
Data address breakpoints: Number of on-chip breakpoints that can be used as Read or Write
breakpoints.
Data value breakpoint: Number of on-chip data value breakpoints that can be used to stop the
program when a specific data value is written to an address or when a specific data value is read
from an address
Processor
On-chip
Breakpoints
Instruction
Address
Breakpoints
Data Address
Breakpoints
Data Value
Breakpoints
MPC85XX
P10xx
P20xx
(e500)
4 Instruction
2 Read/Write
no counters
2 single
breakpoints
-- or -1 breakpoint
ranges
2 single
breakpoints
-- or -1 breakpoint
range
none
You can see the currently set breakpoints with the command Break.List.
If no more on-chip breakpoints are available you will get an error message when trying to set a new on-chip
breakpoint.
PQIII Debugger
17
PowerPC MPC85XX/QorIQ specific Implemen-
Breakpoints on Program Addresses

The debugger sets software and on-chip breakpoints to the effective address. If a breakpoint is set on a
program address, the debugger will first try to set a software breakpoint. If writing the software breakpoint
fails (translation error or bus error), then an on-chip breakpoint will be set instead. If a memory range must
not be written by the debugger, it can be declared for on-chip breakpoint usage using MAP.BOnchip.
Alternatively, it is also possible to force a single breakpoint to on-chip using the command Break.Set with
option /Onchip:
Map.BOnchip 0xFFFC0000--0xFFFFFFFF ;use on-chip breakpoints in FLASH
Break.Set 0xFFFFF064
;debugger sets on-chip breakpoint
Break.Set my_func1
Break.Set my_func1 /Onchip
;debugger sets on-chip or sw breakp.

;debugger sets on-chip breakpoint
Two on-chip program address breakpoints can be combined to an address range:

Break.Set 0x00000000--0x00002000 /Onchip
Break.Set IVOR0_Handler--IVOR15_Handler /Onchip
Breakpoints can be configured to stop if the break event occurred a given number of times.
;stop on the 20th call of function foo
Break.Set foo /Onchip /COUNT 20.
Breakpoints on Data Addresses

Data address breakpoints cause a debug event when a certain address or address range is read or written
by the core. A data address breakpoint to a single address has a granularity of 1 byte.
Break.Set 0xC3F80004 /Read
Break.Set 0xC3F80004 /Write
Break.Set 0xC3F80004 /ReadWrite
;break when core reads from 0xC3F80004

;break when core writes to 0xC3F80004
;break on read or write access
Break.Set 0xC3F80000--0xC3F80023 /Write

Var.Break.Set counter /Write
;break address range
;break on variable write access
Equal to program address breakpoints, data address breakpoints can be configured to stop if the break
event occurred a given number of times:
;stop on the 8th write to arrayindex
Break.Set arrayindex /Write /COUNT 20.
Data address breakpoint limitations:

PQIII Debugger
18
1.
The source of the data access (read and/or write) must be the core, as the data address
breakpoints are part of the core. Any other accesses from on-chip or off-chip peripherals (DMA
etc.) will not be recognized by the data address breakpoints.
2.
The data being targeted must be qualified by an address in memory. It is not possible to set a
data address breakpoint to GPR, SPR etc.
Breakpoints on Data Access at Program Address

A normal data access breakpoint as described above hits on all data accesses to the memory address or
address range, independent of the program address which caused the access. It is also possible to set a
data address breakpoint which only hits if the access is performed from a specified program address. The
specified program address must be a load or store instruction.
;Break if the instruction at address 0x40001148 reads from variable count
Break.Set 0x40001148 /MemoryRead count
;Break if the instruction at address 0x40001148 writes to range
Break.Set 0x40001148 /MemoryWrite 0xFFFFF000--0xFFFFFFFF
The program address can also be an address range or a range of debug symbols:
;Break on all accesses to count from code of the address range
Break.Set 0x40000100--0x400001ff /MemoryReadWrite count
;Break if variable nMyIntVar is written by an interrupt handler
;(debug symbols IVORxx_Handler loaded from debug symbols)
Break.Set IVOR0_Handler--IVOR15_Handler /MemoryWrite nMyIntVar
;Break if variable nTestValue is written within function test_func
Break.Set sYmbol.RANGE(test_func) /MemoryWrite nTestValue
;Break if variable nTestValue is written outside of test_func
Break.Set sYmbol.RANGE(test_func) /EXclude /MemoryWrite nTestValue
Breakpoints on Data Value

The e500 core does not support on-chip breakpoints on data values, but TRACE32 supports them by
software emulation. When a data value breakpoint is set, the debugger will use one of the data address
breakpoint s. When the core hits that breakpoint, the target application will stop and the debugger will
evaluate if the data value matches. If the value matches, the debugger will stop execution, if it does not
match, the debugger will restart the application. Using software emulated data value breakpoints will cause
the target application to slow down.
PQIII Debugger
19
Examples for setting data value breakpoints:

;Break when the value 0x1233 is written to the 16-bit word at 0x40000200
Break.Set 0x40000200 /Write /Data.Word 0x1233
;Break when a value not equal 0x98 is written to the 8-bit variable xval
Break.Set xval /Write /Data.Byte !0x98
;Break when decimal 32-bit value 4000 is written
;to variable count within function foo
Break.Set sYmbol.RANGE(foo) /MemoryWrite count /Data.Long 4000.
PQIII Debugger
20
Access Classes
Access classes are used to specify how TRACE32 PowerView accesses memory, registers of
peripheral modules, addressable core resources, coprocessor registers and the TRACE32 Virtual
Memory.
Addresses in TRACE32 PowerView consist of:
An access class, which consists of one or more letters/numbers followed by a colon (:)
A number that determines the actual address
Here are some examples:

Command:
Effect:
Data.List P:0x1000
Opens a List window displaying program memory
Data.dump D:0xFF800000 /LONG
Opens a DUMP window at data address 0xFF800000
SPR:415. %Long 0x00003300
Write value 0x00003300 to the SPR IVOR15
PRINT Data.Long(ANC:0xFFF00100)
Print data value at physical address 0xFFF00100
Access Classes to Memory and Memory Mapped Resources

The following memory access classes are available:
Access Class
Description
Program (memory as seen by cores instruction fetch)
Program, disassembly shows std. PowerPC instructions
Program, disassembly shows VLE encoded instructions
Data (memory as seen by cores data access)
IC
L1 Instruction Cache (or L1 Unified cache)
DC
L1 Data Cache
L2
L2 Cache
NC
No Cache (access with caching inhibited)
In addition to the access classes, there are access class attributes: Examples:
Command:
Effect:
Data.List SP:0x1000
Opens a List window displaying supervisor program memory
ED:0x3330 0x4F
Write 0x4F to address 0x3330 using real-time memory access
PQIII Debugger
21
The following access class attributes are available:

Access Class Attributes
Description
Use real-time memory access
Given address is physical (bypass MMU)
TS (translation space) == 1 (user memory)
TS (translation space) == 0 (supervisor memory)
If an Access class attributes is specified without an access class, TRACE32 PowerView will automatically
add the default access class of the used command. For example, Data.List U:0x100 will be changed to
Data.List UP:0x100.
Access Classes to Other Addressable Core and Peripheral Resources

The following access classes are used to access registers which are not mapped into the processors
memory address space.
Access Class
Description
SPR
Special Purpose Register (SPR) access
PMR
Performance Monitor Register (PMR) access
Cache
Memory Coherency
The following table describes which memory will be updated depending on the selected access class:
Access Class
D-Cache
I-Cache
L2 Cache
Memory (uncached)
DC:
updated
not updated
not updated
not updated
IC:
not updated
updated
not updated
not updated
L2:
not updated
not updated
updated
not updated
(*) Depending on the debugger configuration, the coherency of the instruction cache will not be
achieved by updating the instruction cache, but by invalidating the instruction cache. See
SYStem.Option.ICFLUSH for details.
PQIII Debugger
22
Access Class
D-Cache
I-Cache
L2 Cache
Memory (uncached)
NC:
not updated
not updated
not updated
updated
D:
updated
not updated
updated
updated
P:
not updated
updated (*)
updated
updated
(*) Depending on the debugger configuration, the coherency of the instruction cache will not be
achieved by updating the instruction cache, but by invalidating the instruction cache. See
SYStem.Option.ICFLUSH for details.
PQIII Debugger
23
MESI States and Cache Status Flags

The data cache logic of Power Architecture cores is described as states of the MESI protocol. The debugger
displays the cache state using the cache line status flags valid, dirty and shared. The debugger also displays
additional status flags (e. g. locked) which can not be mapped to any of the MESI states.
State translation table:
MESI state
Flag
M (modified)
V(alid) && D(irty)
E (exclusive)
V(alid) && NOT D(irty)
S (shared)
V(alid) && S(hared)
I (invalid)
NOT V(alid)
Viewing Cache Contents

The cache contents can be viewed using the CACHE.DUMP command.
Cache
Command
L1 instruction cache
CACHE.DUMP IC
L1 data dache
CACHE.DUMP DC
L2 (unified cache)
CACHE.DUMP L2
The meaning of the data fields in the CACHE.DUMP window os explained in the following table:
Data field
Meaning
address
Physical address of the cache line. The address is composed of

cache tag and set index.
set
way
Set and way index of the cache
v, d, s
Status bits of the cache line v(alid), d(irty), s(hared)
MESI state
l(ocked).
00 04 08 ...
Address offsets within cache line corresponding to the cached data
address (right field)
Debug symbol assigned to address
PQIII Debugger
24
Debugging Information
Setting-up the Debug Interrupt for MPC85XX/QorIQ
In order to properly use all debug features (breakpoints, single step etc) of the MPC85XX/QorIQ series, the
Debug Interrupt Vector (IVPR+IVOR15) must be set to an address which is
properly mapped in the MMU (memory management unit) and
points to an address which contains a valid instruction (NOP is recommended).
Please note that both IVOR/IVPR and memory contents can be changed by the application any time,
especially during the boot process. When debugging is done after the boot process finished, the interrupt
vector and memory is usually properly set up by the application. There are however operating systems that
dont use the debug interrupt and let it point to an illegal instruction.
For early CPU revisions (PVR=0x8020XXXX) it is recommended to place the instructions NOP followed by
RFCI to the debug interrupt vector. These two instructions are needed for SYStem.Option.FREEZE.
PQIII Debugger
25
; CORE 1 setup script:
SYStem.CPU 5516
SYStem.CPU 5516
SYStem.CONFIG.CORE 1. 1.
SYStem.UP
SYStem.Mode.Attach
; do board initialization here
; z0 is still in reset
Data.LOAD.Elf demo.elf
Data.LOAD.Elf demo.elf /NoCode
Go
; start z1
; application will start z0
; core
Break
; with this command

; z0 will stop when
; reset is released
WAIT !RUN()
; wait until cpu stops
Break.Set somez0function
Go
Multicore Debugging e500 Cores

SMP Debugging
For the dual-core processors MPC8572 and the dual-core variants of P10xx and P20xx, SMP debugging is
selected by default. No further configuration is needed. As soon as the debugger is connected (SYStem.Up,
SYStem.Mode.Attach etc.), it is possible to switch to any core using the CORE <core index> command.
The currently selected core is displayed in the status line. If the cores are running and one of the cores hits a
breakpoint, the debuggers view will automatically switch to this core.
AMP Debugging
For AMP debugging, a separate instance of TRACE32 has to be started for each core. It is recommended to
use T32Start to start the TRACE32 instances. Optionally the second instance can also be started by
PRACTICE script. Each TRACE32 instance has to be configured to address one of the cores. This is done
using the commands SYStem.CONFIG.CORE and CORE.NUMBER. SYStem Options PERSTOP and
DCFREEZE have to be turned OFF to maintain cache coherency for the times when one of the cores is
running and the other stopped.
PQIII Debugger
26
The following commands show the basic setup commands for both TRACE32 instances:
SYStem.CPU P2020
SYStem.CPU P2020
CORE.NUMBER 1
CORE.NUMBER 1
SYStem.Option.PERSTOP OFF
SYStem.Option.PERSTOP OFF
SYStem.Option.DCFREEZE OFF
SYStem.Option.DCFREEZE OFF
SYStem.Up
SYStem.Mode.ATTACH
In order to synchronously run and halt both cores, use the SYnch commands.
There is a complete demo for debugging P10xx/20xx dual-core processors on AMP mode in
demo\powerpc\hardware\qoriq_p1_p2\amp_debugging in the TRACE32 installation directory.
Synchronous stop of both e500 cores
MPC8572/P10xx/P20xx processors do not implement a break switch on silicon. If SYnch is configured to

synchronous break in AMP mode, or always if SMP mode is selected, the core that did not hit a breakpoint
will be stopped by the debugger. The missing hardware implementation on the processor causes a delay
between both cores typically in the 1...10 millisecond range.
Programming Flash on MPC85XX / QorIQ P10XX/P20XX, PSC93XX

There are many example scripts for NOR FLASH, NAND FLASH and EEPROMs available.
The example scripts are in the folders:
~~\demo\powerpc\hardware\mpc85xx\
~~\demo\powerpc\hardware\qoriq_p1_p2\
~~\demo\powerpc\hardware\psc913x\
For NOR FLASH on LBC/IFC CS0, there are ready-to-use flash scripts which can be used without change.
These scripts can be found in the all_boards sub-folder.
Scripts for NAND, EMMC, SPI and for the I2C boot sequencer EEPROM have to be modified in respect of
the target boards characteristics and used FLASH devices. Therefore many reference scripts usable on
evaluation boards are included in the corresponding sub-folder.
PQIII Debugger
27
There are also example script which can encode and program the data as requested by the processor when
booting from SPI or using the boot sequencer, for example:
~~/demo/powerpc/hardware/mpc85xx/mpc8536ds/program_spibootflash.cmm
~~/demo/powerpc/hardware/mpc85xx/mpc8569mds/program_bootsequencer.cmm
On-chip Trace on MPC85XX/QorIQ

Processors of the MPC85XX series have a built-in trace buffer with 256 entries. It can be used to trace
transactions that occur on the internal memory bus according to the selected major interface (local bus,
DDR SDRAM and PCI). The trace buffer holds information about transaction address, transaction type,
source, target ID and the byte count.
The interface can be selected with the command Onchip.Mode.IFSel. All other configurations can be done
directly via the menu for CPU peripherals in the section Debug Features and Watchpoint Facility.
Here is an example on how to set up the on-chip trace buffer to trace the data accesses of the PowerPC
core. Please note that only uncached accesses will be recorded in the trace buffer:
; select interface ECM
Onchip.Mode.IFSEL ECM
; configure on-chip trace
; TBCR0 address match disable
;
transaction match disable
;
source ID enable
;
method trace events
Data.Set iobase.address()+0x000E2040 %LONG
0x40000000
0x20000000
0x04000000
0x00020000
0x64020000
; TBCR1 src ID = d-fetch

0x00110000
Data.Set iobase.address()+0x000E2044 %LONG 0x00110000
; enable automatically when CPU is started
Onchip.AutoArm ON
; initialize trace buffer
Onchip.Init
; start program until some_func is reached
Go some_func
; display trace buffer
Onchip.List
PQIII Debugger
28
Regarding instruction fetch traces, please note that the trace buffer is connected outside the caches, so
instruction fetches on cached addresses will not appear in the trace. As the core will always fetch a full
instruction cache way (32 bytes) at once, the program trace can not be reconstructed using this on-chip
trace.
Also data trace is limited to uncached accesses. The data value of the load/store access is not contained in
the trace data.
For more information about general trace commands see Trace and Onchip trace commands.
PQIII Debugger
29
General SYStem Commands
SYStem.BdmClock
Set BDM clock frequency
Format:
SYStem.BdmClock <rate>
<rate>:
5kHz 50MHz
Selects the frequency for the debug interface. For multicore debugging, it is recommended to set the same
JTAG frequency for all cores.
NOTE:
MPC85XX / QorIQ
The recommended maximum JTAG frequency is 1/10th of the core frequency.
Multi-core processors are limited to max. 30 MHz
PQIII Debugger
30
SYStem.CONFIG
Configure debugger according to target topology
Format:
SYStem.CONFIG <parameter> <number_or_address>

SYStem.MultiCore <parameter> <number_or_address> (deprecated)
<parameter>
(JTAG):
DRPRE
DRPOST
IRPRE
IRPOST
TAPState
TCKLevel
TriState
Slave
state
The four parameters IRPRE, IRPOST, DRPRE, DRPOST are required to inform the debugger about the
TAP controller position in the JTAG chain, if there is more than one processor in the JTAG chain. The
information is required before the debugger can be activated e.g. by a SYStem.Up. See example below.
TriState has to be used if (and only if) more than one debugger are connected to the common JTAG port at
the same time. TAPState and TCKLevel define the TAP state and TCK level which is selected when the
debugger switches to tristate mode.
NOTE:
When using the TriState mode, nTRST/JCOMP must have a pull-up resistor on the
target. In TriState mode, a pull-down is recommended for TCK, but targets with pullup are also supported.
DRPRE
(default: 0) <number> of TAPs in the JTAG chain between the core of interest
and the TDO signal of the debugger. If each core in the system contributes only
one TAP to the JTAG chain, DRPRE is the number of cores between the core of
interest and the TDO signal of the debugger.
DRPOST
(default: 0) <number> of TAPs in the JTAG chain between the TDI signal of the
debugger and the core of interest. If each core in the system contributes only
one TAP to the JTAG chain, DRPOST is the number of cores between the TDI
signal of the debugger and the core of interest.
IRPRE
(default: 0) <number> of instruction register bits in the JTAG chain between the
core of interest and the TDO signal of the debugger. This is the sum of the
instruction register length of all TAPs between the core of interest and the TDO
signal of the debugger.
IRPOST
(default: 0) <number> of instruction register bits in the JTAG chain between the
TDI signal and the core of interest. This is the sum of the instruction register
lengths of all TAPs between the TDI signal of the debugger and the core of
interest. See also Daisy-Chain Example.
PQIII Debugger
31
TAPState
(default: 7 = Select-DR-Scan) This is the state of the TAP controller when the
debugger switches to tristate mode. All states of the JTAG TAP controller are
selectable.
TCKLevel
(default: 0) Level of TCK signal when all debuggers are tristated.
TriState
(default: OFF) If more than one debugger share the same JTAG port, this option
is required. The debugger switches to tristate mode after each JTAG access.
Then other debuggers can access the port.
Slave
(default: OFF) If more than one debugger share the same JTAG port, all except
one must have this option active. Only one debugger - the master - is allowed
to control the signals nTRST and nSRST (nRESET).
state
Show state.
PQIII Debugger
32
Daisy-Chain Example
IRPOST
TAP1
TDI
TAP2
IRPRE
TAP3
IR
IR
IR
DR
DR
DR
TAP4
Chip
DRPOST
IR: Instruction register length
IR
DR
TDO
DRPRE
DR: Data register length
Chip: The chip you want to debug
Daisy chains can be configured using a PRACTICE script (*.cmm) or the SYStem.CONFIG.state window.
The PRACTICE code example below explains how to obtain the individual IR and DR values for the above
daisy chain.
PRACTICE code example:

SYStem.CONFIG.state /Jtag
; optional: open the window
SYStem.CONFIG IRPRE
6.
; IRPRE: There is only one TAP.

; So type just the IR bits of TAP4, i.e. 6
SYStem.CONFIG IRPOST 12.
; IRPOST: Add up the IR bits of TAP1, TAP2

; and TAP3, i.e. 4 + 3 + 5 = 12
SYStem.CONFIG DRPRE
1.
; DRPRE: There is only one TAP which is

; in BYPASS mode.
; So type just the DR of TAP4, i.e. 1
SYStem.CONFIG DRPOST
3.
; DRPOST: Add up one DR bit per TAP which

; is in BYPASS mode, i.e. 1 + 1 + 1 = 3
; This completes the configuration.
PQIII Debugger
33
TapStates
0
Exit2-DR
Exit1-DR
Shift-DR
Pause-DR
Select-IR-Scan
Update-DR
Capture-DR
Select-DR-Scan
Exit2-IR
Exit1-IR
10
Shift-IR
11
Pause-IR
12
Run-Test/Idle
13
Update-IR
14
Capture-IR
15
Test-Logic-Reset
PQIII Debugger
34
SYStem.CPU
Select the target processor
Format:
SYStem.CPU <cpu_name>
<cpu_name>:
MPC85XX | MPC8540 | MPC8560 |
Select the target processor or target core. If the target processor is not available in the CPU selection of the
SYStem window, or if the command results in an error,
check if the licence of the debug cable includes the desired processor. You will find the
information in the VERSION window.
check if the debugger software is sufficiently recent to support the target processor. The
debugger software version can be looked up in the VERSION window. If the processor release
occurred after the debugger software release, the processor is most likely not supported. Please
check the Lauterbach download center (http://www.lauterbach.com) for updates. If the debugger
software version from the download center also does not support the processor, please contact
technical support and request a software update.
If you are unsure about the processor, try SYStem.DETECT CPU for automatic detection.
PQIII Debugger
35
SYStem.CpuAccess
Run-time CPU access (intrusive)
Format:
SYStem.CpuAccess <mode>
<mode>:
Enable | Denied | Nonstop
This option declares if an intrusive memory access can take place while the CPU is executing code. To
perform this access, the debugger stops the CPU shortly, performs the access and then restarts the CPU.
The run-time memory access has to be activated for each window by using the access class E: (e.g.
Data.dump E:0x100) or by using the format option %E (e.g. Var.View %E var1).
Enable
In order to perform a memory read or write while the CPU is executing the
program the debugger stops the program execution shortly.
Each short stop takes 1 100 ms depending on the speed of the debug
interface and on the size of the read/write accesses required.
Denied
No intrusive memory read or write is possible while the CPU is executing the
program.
Nonstop
Nonstop ensures that the program execution can not be stopped and that the
debugger doesnt affect the real-time behavior of the CPU.
Nonstop reduces the functionality of the debugger to:
run-time access to memory and variables
trace display
The debugger inhibits the following:
to stop the program execution
all features of the debugger that are intrusive (e.g. spot breakpoints, performance analysis via StopAndGo, conditional breakpoints etc.)
SYStem.LOCK
Format:
Lock and tristate the debug port
SYStem.LOCK [ON | OFF]
Default: OFF.
If the system is locked, no access to the debug port will be performed by the debugger. While locked, the
debug connector of the debugger is tristated. The main intention of the lock command is to give debug
access to another tool.
The command has no effect for the simulator.
PQIII Debugger
36
SYStem.MemAccess
Run-time memory access (non-intrusive)
Format:
SYStem.MemAccess <mode>
<mode>:
Denied | CPU
This option declares if and how a non-intrusive memory access can take place while the CPU is executing
code. Although the CPU is not halted, run-time memory access creates an additional load on the
processors internal data bus. The run-time memory access has to be activated for each window by using
the access class E: (e.g. Data.dump E:0x100) or by using the format option %E (e.g. Var.View %E var1). It
is also possible to activate this non-intrusive memory access for all memory ranges displayed on the
TRACE32 screen by setting SYStem.Option DUALPORT ON.
Denied
Memory access is disabled while the CPU is executing code.
CPU
The debugger performs memory accesses via a dedicated CPU interface. This
memory access will snoop data cache and L2 cache if a access class for data
(D:) is used.
PQIII Debugger
37
SYStem.Mode
Select operation mode
Format:
SYStem.Mode <mode>
<mode>:
Down | NoDebug | Go | Attach | StandBy | Up
Select target reset mode.

Down
Disables the debugger. The state of the CPU remains unchanged.
NoDebug
Resets the target with debug mode disabled. In this mode no debugging is
possible. The CPU state keeps in the state of NoDebug.
Go
Resets the target with debug mode enabled and prepares the CPU for debug
mode entry. Now, the processor can be stopped with the break command or any
break condition.
Attach
Connect to the processor without resetting target/processor. Use this command

to connect to the processor without changing its current state.
StandBy
Debugging/Tracing through power cycles.

The debugger will wait until power-on is detected and then stop the CPU at the
first instruction at the reset address.
Up
Resets the target/processor and sets the CPU to debug mode. After execution
of this command the CPU is stopped and prepared for debugging.
PQIII Debugger
38
CPU specific SYStem Commands
SYStem.Option.CINTDebug
Format:
Enable debugging of critical interrupts
SYStem.Option CINTDebug [ON | OFF]
If the CPU enters a critical interrupt, MSR_DE will be cleared, which means that breakpoints are disabled.
Enable this option in order to set a breakpoint in a critical interrupt handler. When enabled, the debugger will
stop the CPU upon entering a critical interrupt, set MSR_DE and run the CPU again.
Please note that this option will have influence on the run-time behavior (i.e. performance loss) of the
system, as the debugger needs to stop the CPU to set MSR_DE. As alternative to this option, patch the
application to re-enable MSR_DE in the critical interrupt handlers. After MSR_DE has been restored, it is
safe to use breakpoints.
SYStem.Option CoreStandBy
Format:
On-the-fly breakpoint setup
SYStem.Option CoreStandBy [ON | OFF]
On multi-core processors, only one of the cores starts to execute code right after reset. The other cores
remain in reset or disabled state. In this state it is not possible to set breakpoints or configure the core for
tracing. This option works around this limitation and makes breakpoints and tracing available right from the
first instruction executed. This option has impact on the real-time behavior. Releasing a secondary core from
reset / disable state will be delayed for a few milliseconds.
SYStem.Option DCFREEZE Prevent data cache line load/flush in debug mode
Format:
SYStem.Option DCFREEZE [ON | OFF]
Default: ON. If enabled, the debugger will prevent that a memory access by the debugger causes a cache
line to be loaded or flushed to memory. The debugger will however show and update data in cache, i.e. only
the cache tags and status bits are frozen.
If disabled, the debugger will perform cache snoops for memory accesses. During the cache snoop, the
processor will flush dirty lines from data caches before the debuggers memory access takes place.
PQIII Debugger
39
In either setting, the memory contents displayed by the debugger are consistent. Only the method to achieve
consistency changes (cache evaluation <-> cache snoop).
SYStem.Option DCREAD
Format:
Read from data cache
SYStem.Option DCREAD [ON | OFF]
Default: ON. If enabled, Data.dump windows for access class D: (data) and variable windows display the
memory values from the d-cache or L2 cache, if valid. If data is not available in cache, physical memory will
be read.
SYStem.Option DUALPORT
Format:
Implicitly use run-time memory access
SYStem.Option DUALPORT [ON | OFF]
Forces all list, dump and view windows to use the access class E: (e.g. Data.dump E:0x100) or to use the
format option %E (e.g. Var.View %E var1) without being specified. Use this option if you want all windows to
be updated while the processor is executing code. This setting has no effect if
SYStem.Option.MemAccess is disabled.
Please note that while the CPU is running, MMU address translation can not be accesses by the debugger.
Only physical addresses accesses are possible. Use the access class modifier A: to declare the access
physical addressed, or declare the address translation in the debugger-based MMU manually using
TRANS.Create.
PQIII Debugger
40
SYStem.Option FREEZE
Format:
Freeze system timers on debug events
SYStem.Option FREEZE [ON | OFF]
Enabling this option will lead the debugger to set the FT bit in the DBCR0 register. This bit will lead the CPU
to stop the system timers (TBU/TBL and DEC) upon all debug events, that can be defined in DBCR0.
NOTE:
MPC85XX
with PVR
0x8020XXXX
For the MPC85XX CPU family, the debugger needs to execute a RFCI
instruction out of memory to unfreeze the system timers on a resume (go, step).
In order to use SYStem.Option.FREEZE, you have to patch two instructions to
memory, a NOP followed by a RFCI, and let the IVPR/IVOR15 point to the NOP
instruction.
If SYStem.Option.Freeze is ON, the debugger will automatically check if the
IVPR/IVOR15 vector is pointing to the NOP / RFCI instructions. If this condition
does not match, the system timers will stay frozen and there will be an error
output in the AREA window.
SYStem.Option HOOK
Format:
Compare PC to hook address
SYStem.Option HOOK <address>
The command defines the hook address. After program break the hook address is compared against the
program counter value.
If the values are equal, it is supposed that a hook function was executed. This information is used to
determine the right break address by the debugger.
SYStem.Option ICFLUSH
Format:
Invalidate instruction cache before go and step
SYStem.Option ICFLUSH [ON | OFF]
Default: ON.
PQIII Debugger
41
Invalidates the instruction cache before starting the target program (Step or Go). If this option is disabled, the
debugger will update Memory and instruction cache for program memory downloads, modifications and
breakpoints. Disabling this option might cause performance decrease on memory accesses.
SYStem.Option ICREAD
Format:
Read from instruction cache
SYStem.Option ICREAD [ON | OFF]
Default: OFF:
If enabled, Data.List window and Data.dump window for access class P: (program memory) display the
memory values from the instruction cache or L2 cache if valid. If the data is not available in cache, the
physical memory will be displayed.
SYStem.Option IMASKASM
Format:
Disable interrupts while single stepping
SYStem.Option IMASKASM [ON | OFF]
Default: OFF.
If enabled, the interrupt mask bits of the CPU will be set during assembler single-step operations. The
interrupt routine is not executed during single-step operations. After single step the interrupt mask bits are
restored to the value before the step.
SYStem.Option IMASKHLL
Format:
Disable interrupts while HLL single stepping
SYStem.Option IMASKHLL [ON | OFF]
Default: OFF. If enabled, the interrupt mask bits of the cpu will be set during HLL single-step operations. The
interrupt routine is not executed during single-step operations. After single step the interrupt mask bits are
restored to the value before the step.
NOTE:
Do not enable this option for code that disables MSR_EE. The debugger will
disable MSR_EE while the CPU is running and restore it after the CPU stopped. If a
part of the application is executed that disables MSE_EE, the debugger cannot
detect this change and will restore MSE_EE.
PQIII Debugger
42
SYStem.Option MMUSPACES
Format:
Enable multiple address spaces support
SYStem.Option MMUSPACES [ON | OFF]

SYStem.Option MMU [ON | OFF] (deprecated)
Enables the usage of the MMU to support multiple address spaces. The command should not be used if
only one translation table is used. Enabling the option will extend the address scheme of the debugger by a
16 bit memory space identifier. The option can only be enabled when there are no symbols loaded.
SYStem.Option.NoDebugStop
Format:
Disable JTAG stop on debug events
SYStem.Option NoDebugStop [ON | OFF]
Default: OFF.
On-chip debug events that cause a debug interrupt can be configured to cause one of two actions. If a JTAG
debugger is used, the CPU is configured to stop for JTAG upon these debug events.
If this option is set to ON, the CPU will be configured to not stop for JTAG, but to enter the debug interrupt,
like it does when no JTAG debugger is used.
Enable this option if the CPU should not stop for JTAG on debug events, in order to allow a target application
to use the debug interrupt. Typical usages for this option are run-mode debugging (e.g. with t32server/
gdbserver) or setting up the system for a branch trace via LOGGER (trace data in target RAM) or
INTEGRATOR.
PQIII Debugger
43
SYStem.Option OVERLAY
Format:
Enable overlay support
SYStem.Option OVERLAY [ON | OFF | WithOVS]
Default: OFF.
ON: Activates the overlay extension and extends the address scheme of the debugger with a 16 bit virtual
OverlayID. Addresses therefore have the format <OverlayID>:<address>. This enables the
debugger to handle overlayed program memory.
OFF: Disables support for code overlays.
WithOVS: Like option ON, but also enables support for software breakpoints. This means that TRACE32
writes software breakpoint opcodes both to the execution area (for active overlays) and to the storage area.
In this way, it is possible to set breakpoints into inactive overlays. Upon activation of the overlay, the target's
runtime mechanisms copies the breakpoint opcodes to execution area. For using this option, the storage
area must be readable and writable for the debugger.
SYStem.Option OVERLAY ON
Data.List 0x2:0x11c4
SYStem.Option PERSTOP
Format:
; Data.List <OverlayID>:<address>
Stop on-chip peripherals in debug mode
SYStem.Option PERSTOP [ON | OFF]
Default: ON. If enabled the debugger will halt the on-chip peripherals of the processor while in debug mode.
Memory accesses and cache snoops of e.g. TSEC, USB etc will not take place and memory spaces of
some peripherals are inaccessible. If disabled, the on-chip peripherals will stay active also during debug
mode. The data buffers of TSEC etc. can overflow, because the target application does not process the data
when stopped.
NOTE:
If SYStem.Option.PERSTOP is disabled, it is recommended to also disable

SYStem.Option.DCFREEZE, in order to see the memory accesses performed by
the peripherals.
PQIII Debugger
44
SYStem.Option SLOWRESET
Format:
Relaxed reset timing
SYStem.Option SLOWRESET [ON | OFF]
This system option defines, how the debugger will test JTAG_RESET. For some system mode changes, the
debugger will assert JTAG_RESET. By default (OFF), the debugger will release RESET and then read the
RESET signal until the RESET pin is released. Reset circuits of some target boards prevent that the current
level of RESET can be determined via JTAG_RESET. If this system option is enabled, the debugger will not
read JTAG_RESET, but instead waits up to 4 s and then assumes that the boards RESET is released.
SYStem.Option STEPSOFT
Format:
Use alternative method for ASM single step
SYStem.Option STEPSOFT [ON | OFF]
This method uses software breakpoints to perform an assembler single step instead of the processors builtin single step feature. Works only for software in RAM. Do not turn ON, unless advised by Lauterbach.
NOTE:
All CPUs: servicing watchdog

If the debugger is servicing the watchdog, conditions might occur, where the
watchdog times out before the debugger is able to service it. Unintended resets
or interrupts can occur.
Further, SWT window mode is not supported by the debugger.
MPC5516, revision 0
If the system option is ON, the debugger will configure the watchdog to the
longest timeout period on SYStem.Up and SYStem.Mode.StandBy. During
debugging, the watchdog timer will be serviced if SWE is on.
PQIII Debugger
45
CPU specific MMU Commands
MMU.DUMP
Page wise display of MMU translation table
Format:
MMU.DUMP <table> [<range> | <addr> | <range> <root> | <addr> <root>]

MMU.<table>.dump (deprecated)
<table>:
PageTable
KernelPageTable
TaskPageTable <task>
and CPU specific tables
Displays the contents of the CPU specific MMU translation table.
If called without parameters, the complete table will be displayed.
If the command is called with either an address range or an explicit address, table entries will
only be displayed, if their logical address matches with the given parameter.
The optional <root> argument can be used to specify a page table base address deviating from the default
page table base address. This allows to display a page table located anywhere in memory.
PageTable
Display the current MMU translation table entries of the CPU.

This command reads all tables the CPU currently used for MMU translation
and displays the table entries.
KernelPageTable
Display the MMU translation table of the kernel.

If specified with the MMU.FORMAT command, this command reads the
MMU translation table of the kernel and displays its table entries.
TaskPageTable
Display the MMU translation table entries of the given process.

In MMU based operating systems, each process uses its own MMU
translation table. This command reads the table of the specified process,
and displays its table entries.
See also the appropriate OS awareness manuals: RTOS Debugger for
<x>.
PQIII Debugger
46
CPU specific tables:
TLB0
Displays the contents of TLB0.
TLB1
Displays the contents of TLB1.
MMU.List
Compact display of MMU translation table
Format:
MMU.List <table> [<range> | <address>]

MMU.<table>.List (deprecated)
<table>:
PageTable
KernelPageTable
Lists the address translation of the CPU specific MMU table. If called without address or range parameters,
the complete table will be displayed.
If called without a table specifier, this command shows the debugger internal translation table.
See TRANSlation.List.
If the command is called with either an address range or an explicit address, table entries will only be
displayed, if their logical address matches with the given parameter.
PageTable
List the current MMU translation of the CPU.

This command reads all tables the CPU currently used for MMU
translation and lists the address translation.
KernelPageTable
List the MMU translation table of the kernel.

MMU translation table of the kernel and lists its address translation.
TaskPageTable
List the MMU translation of the given process.

and lists its address translation.
<x>.
PQIII Debugger
47
MMU.SCAN
Load MMU table from CPU
Format:
MMU.SCAN <table> [<range> <address>]

MMU.<table>.SCAN (deprecated)
<table>:
PageTable
KernelPageTable
ALL
and CPU specific tables
Loads the CPU specific MMU translation table from the CPU to the debugger internal translation table. If
called without parameters the complete page table will be loaded. The loaded address translation can be
viewed with TRANSlation.List.
If the command is called with either an address range or an explicit address, page table entries will only be
loaded if their logical address matches with the given parameter.
PageTable
Load the current MMU address translation of the CPU.

This command reads all tables the CPU currently used for MMU translation,
and copies the address translation into the debugger internal translation
table.
KernelPageTable
Load the MMU translation table of the kernel.

table of the kernel and copies its address translation into the debugger
internal translation table.
TaskPageTable
Load the MMU address translation of the given process.

and copies its address translation into the debugger internal translation
table.
<x>.
ALL
Load all known MMU address translations.

This command reads the OS kernel MMU table and the MMU tables of all
processes and copies the complete address translation into the
debugger internal translation table.
<x>.
PQIII Debugger
48
CPU specific tables:
TLB0
Loads the TLB0 from the CPU to the debugger internal translation table.
TLB1
Loads the TLB1 from the CPU to the debugger internal translation table.
Use this command to make the translation information available for the debugger even when the program
execution is running and the debugger has no access to the TLBs. This is required for the real-time memory
access (See also SYStem.MemAccess and SYStem.Option DUALPORT). Use the command
TRANSlation.ON to enable the debugger internal MMU table.
MMU.Set
Set an MMU TLB entry
Formats:
MMU.Set TLB0 <index> <mas1> <mas2> <mas3> <mas7>

MMU.Set TLB1 <index> <mas1> <mas2> <mas3> <mas7>
MMU.<table>.SET (deprecated)
<index>:
TLB entry index. From 0 to (number of TLB entries)-1 of the specified TLB table
<mas1>:
<mas2>:
<mas3>:
<mas7>
Values corresponding to the values that would be written to the MAS registers
in order to set a TLB entry. See the processors reference manual for details on
MAS registers.
MAS7 contains the most significant bits of the physical 36 bit address (e500v2
cores only)
Sets the specified MMU TLB table entry in the CPU. The parameter <tlb> is not available for CPUs with only
one TLB table.
PQIII Debugger
49
CPU specific BenchMarkCounter Commands

The BenchMarkCounter features are based on the cores performance monitor, accessed through the
performance monitor registers (PMR). PMC access is only possible while the core is halted.
Notes:
BMC.PROfile and BMC.SnoopSet are not supported.
For information about architecture-independent BMC commands, refer to BMC

(general_ref_b.pdf).
For information about architecture-specific BMC commands, see command descriptions below.
Events can be assigned to BMC.<counter>.EVENT <event>. For descriptions of available events,

please check Freescales core reference manual.
BMC.FREEZE
Format:
Freeze counters while core halted
BMC.FREEZE [ON | OFF]
Enable this setting to prevent that actions of the debugger have influence on the performance counter. As
this feature software controlled (no on-chip feature), some events (especially clock cycle measurements)
may be counted inaccurate even if this setting is set ON.
BMC.<counter>.SIZE
Format:
No function
BMC.<counter>.SIZE <size>
Since only one counter size is possible, this command is only available for compatibility reasons.
PQIII Debugger
50
BMC.SnoopSet
Format:
Assign event counter to TRACE32 SnooperTrace
BMC.SnoopSet [ON | OFF]
The TRACE32 SNOOPer Trace can be used to record the event counters periodically, if the target system
allows to read the event counters while the program execution is running.
TRACE32 provides various ways to analyze the recorded information.
Example for the pure JTAG debugger.
BMC.state
; display the BMC Configuration

; window
BMC.<counter1> <event1>
; assign event of interest to

; the event counter
;BMC.<counter2> <event2>
; several assignments possible
BMC.SnoopSet ON
; configure the TRACE32 SNOOPer

; Trace for event counter recording
SNOOPer.state
; display the SNOOPer Trace

; Configuration window to inspect
; the setup
Go
; start the program execution to

; fill the SNOOPer trace
Break
; stop the program execution
SNOOPer.List
; display a SNOOPer trace listing

; please pay attention to the
; ti.back time, it informs you on
; the SNOOPer sampling rate
SNOOPer.PROfileChart.COUNTER
; display a profile statistic
PQIII Debugger
51
PQIII Debugger
52
CPU specific TrOnchip Commands
TrOnchip.CONVert
Format:
Adjust range breakpoint in on-chip resource
TrOnchip.CONVert [ON | OFF]
There are 2 data address breakpoints. These breakpoints can be used to mark two single data addresses or
one data address range.
ON (default)
After a data address breakpoint is set to an address range all on-chip

breakpoints are spent. As soon as a new data address breakpoint is set the
data address breakpoint to the address range is converted to a single data
address breakpoint. Please be aware, that the breakpoint is still listed as a
range breakpoint in the Break.List window. Use the Data.View command to
verify the set data address breakpoints.
OFF
An error message is displayed when the user wants to set a new data address
breakpoint after all on-chip breakpoints are spent by a data address breakpoint to
an address range.
TrOnchip.CONVert ON
Break.Set 0x6020++0x1f
Break.Set 0x7400++0x3f
Data.View 0x6020
Data.View 0x7400
TrOnchip.RESet
Format:
Reset on-chip trigger settings
TrOnchip.RESet
Resets the on-chip trigger system to the default state.
PQIII Debugger
53
TrOnchip.Set
Enable special on-chip breakpoints
Format:
TrOnchip.Set <event> [ON | OFF]
<event>:
Break events, see below.
Enables the specified on-chip trigger facility to stop the CPU on below events:
BRT
IRPT
RET
CIRPT
CRET
CI
MC
DS
IS
EI
AL
PR
FP
SC
AU
DEC
FIT
WD
DTLB
ITLB
DBG
SPEU
SPED
SPER
PM
Break on branch taken event.

Break on interrupt entry.
Break on return from interrupt.
Break on critical interrupt entry.
Break on return from critical interrupt.
Break on critical input interrupt.
Break on machine check interrupt.
Break on data storage interrupt.
Break on instruction storage interrupt.
Break on external input interrupt.
Break on alignment interrupt.
Break on program interrupt.
Break on fpu unavailable interrupt.
Break on system call.
Break on auxiliary processor unavailable interrupt.
Break on decrementer interrupt.
Break on fixed interval timer interrupt.
Break on watchdog interrupt.
Break on data TLB error interrupt.
Break on instruction TLB interrupt.
Break on debug interrupt - do not clear if breakpoints are used.
Break on SPE APU unavailable interrupt.
Break on SPE floating-point data interrupt.
Break on SPE floating-point round interrupt.
Break on performance monitor interrupt.
PQIII Debugger
54
TrOnchip.VarCONVert
Adjust HLL breakpoint in on-chip resource
Format:
TrOnchip.VarCONVert [ON | OFF]
ON (default)
After a data address breakpoint is set to an hll variable all on-chip breakpoints
are spent. As soon as a new data address breakpoint is set the data address
breakpoint to the hll variable is converted to a single data address breakpoint.
Please be aware, that the breakpoint is still listed as a range breakpoint in the
Break.List window. Use the Data.View command to verify the set data address
breakpoints.
OFF
An error message is displayed when the user wants to set a new data address
breakpoint after all on-chip breakpoints are spent by a data address breakpoint to
an hll variable.
TrOnchip.VarCONVert ON
Var.Break.Set flags
Var.Break.Set ast
Data.View flags
Data.View ast
PQIII Debugger
55
TrOnchip.view
Format:
View on-chip trigger setup window
TrOnchip.view
Display the trigger setup dialog window.
PQIII Debugger
56
MPC85XX/QorIQ Specific On-chip Trace Settings
Onchip.Mode.IFSel
Select interface to be traced
Format:
Onchip.Mode.IFSel <interface>
<interface>:
ECM (processor core interface)

SDRAM (SDRAM interface)
PCI, PCI2 (PCI controller interface)
RIO (RapidIO interface)
PCIEX, PCIEX2, PCIEX2 (PCI Express interface)
Interface selection. Specifies the interface that sources information for both comparison/buffer control and
buffer data capture. The availability of certain <interface> options depends on the target processor. Please
check the processor users manual for which interfaces are available.
The complex trigger unit also provides flags to store an internal state. This state can be used as element of
conditions.
Format:
Flag[.<action>] [IF <condition>]
<mode>:
FALSE
TRUE
Toggle
For not CPU-specific keywords, see non-declarable input variables in ICE/FIRE Analyzer Trigger Unit
Programming Guide (analyzer_prog.pdf).
PQIII Debugger
57
MPC85XX/QorIQ Specific On-chip Trace Set-
JTAG Connector
Mechanical Description
JTAG Connector MPC85XX (COP)
Signal
TDO
TDI
(RUNSTOP-)
TCK
TMS
(SRESET-)
HRESET(CKSTOPOUT-)
Pin
1
3
5
7
9
11
13
15
Pin
2
4
6
8
10
12
14
16
Signal
N/C
TRSTJTAG-VREF
(CHKSTPIN-)
N/C
GND
N/C (KEY PIN)
GND
This is a standard 16 pin double row (two rows of eight pins) connector (pin to pin spacing: 0.100 in.).
(Signals in brackets are not strong necessary for basic debugging, but its recommended to take in
consideration for future designs.)
Support
BSC9130
BSC9131
BSC9132
E2V_P2010
E2V_P2020
MPC8533E
MPC8536E
MPC8540
MPC8541E
YES
YES
YES
YES
YES
YES
YES
YES
YES
INSTRUCTION
SIMULATOR
POWER
INTEGRATOR
ICD
TRACE
ICD
MONITOR
ICD
DEBUG
FIRE
ICE
CPU
Available Tools
YES
YES
YES
YES
YES
YES
YES
YES
YES
PQIII Debugger
58
JTAG Connector
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
INSTRUCTION
SIMULATOR
POWER
INTEGRATOR
ICD
TRACE
ICD
MONITOR
ICD
DEBUG
FIRE
ICE
CPU
MPC8543E
MPC8544E
MPC8545E
MPC8547E
MPC8548E
MPC8555E
MPC8560
MPC8567E
MPC8568E
MPC8569E
MPC8572E
P1010
P1011
P1012
P1013
P1014
P1015
P1016
P1017
P1020
P1021
P1022
P1023
P1024
P1025
P2010
P2020
PC8540
PC8548
PC8572
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
PQIII Debugger
59
Support
Compilers
Language
Compiler
Company
Option
ADA
GNAT
ELF/DWARF
C
C
CXPPC
XCC-V
C
C
GREEN-HILLS-C
MCCPPC
C
C
C
C
C
C
C
C++
CC
ULTRA-C
HIGH-C
DCPPC
D-CC
D-CC
D-CC
GCC
C++
C++
GREEN-HILLSC++
CCCPPC
Free Software
Foundation, Inc.
Cosmic Software
GAIO Technology Co.,
Ltd.
Greenhills Software Inc.
Mentor Graphics
Corporation
NXP Semiconductors
Radisys Inc.
Synopsys, Inc
TASKING
Wind River Systems
Wind River Systems
Wind River Systems
Free Software
Foundation, Inc.
Greenhills Software Inc.
C++
C++
C++
C++
C/C++
MSVC
HIGH-C++
D-C++
GCCPPC
GCC
C/C++
GCC
CODEWARRIOR
GCC
JAVA
FASTJ
Mentor Graphics
Corporation
Microsoft Corporation
Synopsys, Inc
Wind River Systems
Wind River Systems
HighTec EDV-Systeme
GmbH
NXP Semiconductors
Free Software
Foundation, Inc.
Wind River Systems
Comment
ELF/DWARF
SAUF
ELF/DWARF
ELF/DWARF
XCOFF
ROF
ELF/DWARF
ELF/DWARF
IEEE
COFF
ELF/DWARF
ELF/DWARF
ELF/DWARF
ELF/DWARF
EXE/CV5
ELF/DWARF
ELF/DWARF
ELF/STABS
ELF/DWARF
WindowsCE
ELF/DWARF
ELF/DWARF
ELF/DWARF
PQIII Debugger
60
Support
Realtime Operation Systems

Name
Company
Comment
AMX
ChorusOS
CMX-RTX
DEOS
ECOS
Elektrobit tresos
ERCOSEK
Erika
FreeRTOS
Linux
Linux
LynxOS
MQX
MQX
NetBSD
NORTi
Nucleus PLUS
OS-9
OSE Delta
OSEK
OSEKturbo
PikeOS
ProOSEK
pSOS+
QNX
RTEMS
RTXC 3.2
RTXC Quadros
Sciopta
SMX
ThreadX
uC/OS-II
uITRON
VRTXsa
VxWorks
KadakProducts Ltd.
Oracle Corporation
CMX Systems Inc.
DDC-I, Inc.
eCosCentric Limited
Elektrobit Automotive GmbH
ETAS GmbH
Evidence
Freeware I
MontaVista Software, LLC
LynuxWorks Inc.
NXP Semiconductors
Synopsys, Inc
MISPO Co. Ltd.
Mentor Graphics Corporation
Radisys Inc.
Enea OSE Systems
NXP Semiconductors
Sysgo AG
Elektrobit Automotive GmbH
Wind River Systems
QNX Software Systems
RTEMS
Quadros Systems Inc.
Quadros Systems Inc.
Sciopta
Micro Digital Inc.
Express Logic Inc.
Micrium Inc.
Mentor Graphics Corporation
Wind River Systems
implemented by DDC-I
1.3, 2.0 and 3.0
via ORTI
via ORTI
via ORTI
v7
Kernel Version 2.4 and 2.6, 3.x, 4.x
3.0, 3.1, 4.0, 5.0
3.1.0, 3.1.0a, 4.0
3.x and 4.x
2.40 and 2.50
4.x and 5.x

via ORTI
via ORTI/former MetrowerksOSEK
via ORTI
2.1 to 2.5, 3.0, with TRACE32
6.0 to 6.5.0
4.10
3.4 to 4.0
3.0, 4.0, 5.0
2.0 to 2.92
HI7000, RX4000, NORTi,PrKernel
5.x to 7.x
PQIII Debugger
61
Support
3rd Party Tool Integrations

CPU
Tool
Company
ALL
ALL
ALL
ADENEO
X-TOOLS / X32
CODEWRIGHT
ALL
CODE CONFIDENCE
TOOLS
CODE CONFIDENCE
TOOLS
EASYCODE
ECLIPSE
RHAPSODY IN MICROC
RHAPSODY IN C++
CHRONVIEW
LDRA TOOL SUITE
UML DEBUGGER
Adeneo Embedded
blue river software GmbH
Borland Software
Corporation
Code Confidence Ltd
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
ALL
POWERPC
POWERPC
POWERPC
ATTOL TOOLS
VISUAL BASIC
INTERFACE
LABVIEW
CODE::BLOCKS
C++TEST
RAPITIME
DA-C
TRACEANALYZER
SIMULINK
TA INSPECTOR
UNDODB
VECTORCAST UNIT
TESTING
VECTORCAST CODE
COVERAGE
WINDOWS CE PLATF.
BUILDER
GR228X ICTESTSYSTEME
OSE ILLUMINATOR
DIAB RTA SUITE
Host
Windows
Windows
Windows
Code Confidence Ltd
Linux
EASYCODE GmbH
Eclipse Foundation, Inc
IBM Corp.
IBM Corp.
Inchron GmbH
LDRA Technology, Inc.
LieberLieber Software
GmbH
MicroMax Inc.
Microsoft Corporation
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Windows
NATIONAL
INSTRUMENTS
Corporation
Open Source
Parasoft
Rapita Systems Ltd.
RistanCASE
Symtavision GmbH
The MathWorks Inc.
Timing Architects GmbH
Undo Software
Vector Software
Windows
Windows
Windows
Windows
Windows
Windows
Windows
Linux
Windows
Vector Software
Windows
Windows
Windows
Battefeld GmbH
Windows
Enea OSE Systems

Wind River Systems
Windows
Windows
PQIII Debugger
62
Support
Products
Product Information
OrderNo Code
Text
LA-3796
JTAG Debugger for MPC85XX/QorIQ e500 (ICD)
DEBUG-PQ3
supports PowerQuiccIII (MPC85XX) and

QorIQ 32-bit with e500 core
(P10XX, P2010, P2020, BSC9xxx)
includes software for Windows, Linux and MacOSX
requires Power Debug Module
debug cable with 16 pin connector
Concurrent debugging of two or more cores
in multicore chip requires a
License for Multicore Debugging (LA-7960X)
LA-3796X
JTAG Debugger Ext. for MPC85XX/QorIQ e500
DEBUG-PQ3-X
debugger extension for PowerQuiccIII (MPC85XX) and

QorIQ with e500 core
requires a valid software guaranty or a valid
software maintenance key
only suitable for debug cables newer than 07/2008
please add the serial number of the base debug
cable to your order
Order Information
Order No.
Code
Text
LA-3796
LA-3796X
DEBUG-PQ3
DEBUG-PQ3-X
JTAG Debugger for MPC85XX/QorIQ e500 (ICD)

JTAG Debugger Ext. for MPC85XX/QorIQ e500
Additional Options
LA-7729X DEBUG-MPC8260-X
LA-3735X DEBUG-MPC86XX-X
LA-7721X DEBUG-PPC603-X
LA-7719X DEBUG-PPC74XX-X
LA-3795X DEBUG-QORIQ32-X
LA-3794X DEBUG-QORIQ64-X
LA-7734X JTAG-MPC5200-X
LA-7960X MULTICORE-LICENSE
JTAG Debugger Extension for MPC8260/MPC8240

JTAG Debugger Extension for MPC86xx
JTAG Debugger Extension for PPC603(ICD)
JTAG Debugger Extension for MPC74xx (ICD)
JTAG Debugger Extension for QorIQ 32 Bit
JTAG Debugger Extension for QorIQ 64 Bit
JTAG Debugger Extension for MPC5200/MPC512x
License for Multicore Debugging
PQIII Debugger
63
Products
PQIII Debugger
64
Products

Debugger Ppcpq3

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Debugger Ppcpq3

Загружено:

Авторское право:

Доступные форматы

PQIII Debugger

TRACE32 Online Help

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

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

PQIII Debugger .....................................................................................................................

General Note ......................................................................................................................

Brief Overview of Documents for New Users .................................................................

Target Design Requirement/Recommendations ............................................................

Quick Start .........................................................................................................................

PowerPC MPC85XX/QorIQ specific Implementations ....................................................

Breakpoints on Program Addresses

Breakpoints on Data Addresses

Breakpoints on Data Access at Program Address

Breakpoints on Data Value

Access Classes to Memory and Memory Mapped Resources

Access Classes to Other Addressable Core and Peripheral Resources

MESI States and Cache Status Flags

Viewing Cache Contents

Multicore Debugging e500 Cores

Synchronous stop of both e500 cores

1989-2016 Lauterbach GmbH

Programming Flash on MPC85XX / QorIQ P10XX/P20XX, PSC93XX

On-chip Trace on MPC85XX/QorIQ

General SYStem Commands ............................................................................................

Configure debugger according to target topology

Run-time CPU access (intrusive)

Lock and tristate the debug port

Run-time memory access (non-intrusive)

Select operation mode

CPU specific SYStem Commands ...................................................................................

On-the-fly breakpoint setup

Prevent data cache line load/flush in debug mode

Read from data cache

Implicitly use run-time memory access

Freeze system timers on debug events

Compare PC to hook address

Invalidate instruction cache before go and step

Read from instruction cache

Disable interrupts while single stepping

Disable interrupts while HLL single stepping

Enable multiple address spaces support

Disable JTAG stop on debug events

Enable overlay support

Stop on-chip peripherals in debug mode

Relaxed reset timing

Use alternative method for ASM single step

CPU specific MMU Commands ........................................................................................

Compact display of MMU translation table

Load MMU table from CPU

Set an MMU TLB entry

CPU specific BenchMarkCounter Commands ................................................................

Freeze counters while core halted

Assign event counter to TRACE32 SnooperTrace

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

Adjust range breakpoint in on-chip resource

Reset on-chip trigger settings

Enable special on-chip breakpoints

Adjust HLL breakpoint in on-chip resource

View on-chip trigger setup window

MPC85XX/QorIQ Specific On-chip Trace Settings .........................................................

JTAG Connector ................................................................................................................

JTAG Connector MPC85XX (COP)

Realtime Operation Systems

3rd Party Tool Integrations