Debugger Ppc600

PPC600 Family Debugger
TRACE32 Online Help

TRACE32 Directory
TRACE32 Index
TRACE32 Documents ......................................................................................................................
ICD In-Circuit Debugger ................................................................................................................
Processor Architecture Manuals ..............................................................................................
PQII, MPC5200, MPC603/7xx, MPC74xx ................................................................................
PPC600 Family Debugger ....................................................................................................
General Note ......................................................................................................................
Brief Overview of Documents for New Users .................................................................
Warning ..............................................................................................................................
Signal Level
ESD Protection
Target Design Requirement/Recommendations ............................................................

General
7
7
Quick Start .........................................................................................................................
Troubleshooting ................................................................................................................
10
Problems with Memory Access
11
FAQ
12
Configuration .....................................................................................................................
27
System Overview
27
General Restrictions
28
PowerPC 600 Family Specific Implementations .............................................................

Breakpoints
29
29
Software Breakpoints
29
SW-BP Handling for MPC8200, PPC603, PPC700
30
On-chip Breakpoints
32
Breakpoints in Interrupt Handlers
33
Breakpoints in ROM
33
Breakpoints on Physical or Virtual Addresses
33
Examples for Breakpoints
34
34
On-chip Program Address Breakpoints
34
On-chip Data Address Breakpoints
34
Access Classes
35
1989-2016 Lauterbach GmbH
Access Classes to Memory and Memory Mapped Resources
35
Access Classes to Other Addressable Core and Peripheral Resources
36
Cache
36
Memory Coherency
36
MESI States
37
Little Endian Operation
38
General System Commands .............................................................................................
39
SYStem.BdmClock
Set JTAG frequency
39
SYStem.CPU
Select the CPU type
39
Run-time memory access (intrusive)
40
SYStem.CpuAccess
SYStem.LOCK
Lock and tristate the debug port
40
Real-time memory access (non-intrusive)
41
Select operation mode
42
Configure debugger according to target topology
43
SYStem.MemAccess
SYStem.Mode
SYStem.CONFIG
Daisy-chain Example
45
TapStates
46
SYStem.CONFIG.CORE
Assign core to TRACE32 instance
47
CPU specific System Commands ....................................................................................
48
SYStem.Option BASE
Set base address for on-chip peripherals
48
SYStem.Option BUS32
Use 32-Bit data-bus mode
49
SYStem.Option CONFIG
Select RCW configuration
49
Read from data cache
49
Implicitly use run-time memory access
50
SYStem.Option DCREAD
SYStem.Option DUALPORT
SYStem.Option FREEZE
Freeze timebase when core halted
50
Compare PC to hook address
50
Override HRCW on SYStem.UP
51
Invalidate instruction cache before go/step
51
SYStem.Option HOOK
SYStem.Option HRCWOVR
SYStem.Option ICFLUSH
SYStem.Option ICREAD
SYStem.Option IMASKASM
SYStem.Option IMASKHLL
SYStem.Option IP
Read from instruction cache
52
Disable interrupts while single stepping
52
Disable interrupts while HLL single stepping
52
Set MSR_IP value for breakpoints / sys.up
53
SYStem.Option.LittleEnd
True little endian mode
53
SYStem.Option.MemProtect
Enable memory access safeguard
53
SYStem.Option.MemSpeed
Configure memory access timing
54
Enable multiple address spaces support
54
SYStem.Option MMUSPACES
SYStem.Option.NoDebugStop
SYStem.Option.NOTRAP
Disable JTAG stop on debug events
55
Use alternative software breakpoint instruction
55
Enable overlay support
56
Generate parity on memory access
56
SYStem.Option OVERLAY
SYStem.Option PARITY
SYStem.Option.PINTDebug
Program interrupt debugging
56
PPC little endian mode
57
Evaluate PTE table for address translation
57
Select reset mode for SYStem.Up
58
SYStem.Option.PPCLittleEnd
SYStem.Option.PTE
SYStem.Option ResetMode
SYStem.Option.SLOWRESET
Relaxed reset timing
SYStem.Option.STEPSOFT
58
Use alternative method for ASM single step
59
Leave software watchdog enabled
60
CPU specific MMU Commands ........................................................................................
61
SYStem.Option WATCHDOG
MMU.DUMP
MMU.List
Page wise display of MMU translation table
61
Compact display of MMU translation table
62
MMU.SCAN
Load MMU table from CPU
63
Write MMU TLB entries to CPU
65
CPU specific BenchMarkCounter Commands ................................................................
66
MMU.Set
BMC.FREEZE
Freeze counters while core halted
66
No function
66
CPU specific TrOnchip Commands .................................................................................
67
BMC.<counter>.SIZE
TrOnchip.view
View on-chip trigger setup window
67
TrOnchip.DISable
Disable debug register control
67
TrOnchip.ENable
Enable debug register control
67
Adjust range breakpoint in on-chip resource
68
TrOnchip.CONVert
TrOnchip.VarCONVert
Adjust complex breakpoint in on-chip resource
68
Reset on-chip trigger settings
68
Set filter for the trace
69
TrOnchip.TOFF
Switch the sampling to the trace to OFF
69
TrOnchip.TON
Switch the sampling to the trace to ON
69
Set a trigger for the trace
69
Mechanical Description ....................................................................................................
70
TrOnchip.RESet
TrOnchip.TEnable
TrOnchip.TTrigger
JTAG/COP Connector PPC603e/700/MPC8200

Technical Data ...................................................................................................................
Operation Voltage
70
71
71
Support ...............................................................................................................................
72
Available Tools
72
Compilers
74
Realtime Operation Systems
76
3rd Party Tool Integrations
77
Products .............................................................................................................................
78
Product Information
78
Order Information
80

Version 24-May-2016
B::Data.List
addr/line
code
P:FFF021C0 39400000
P:FFF021C4 915F0018
567
P:FFF021C8
P:FFF021CC
P:FFF021D0
P:FFF021D4
39200000
2C890012
40850008
4800001C
B::Register
R0
0
R1
0FFFFFFD8
R2
0
R3
0
R4
0
R5
0
R6
0
R7
0
SPRG0
0
SPRG1
0
SPRG2
0
R8
R9
R10
R11
R12
R13
R14
R15
SRR0
SRR1
SRR2
label
mnemonic
li
stw
for ( i = 0 ; i <= SIZE ; flags[ i++ ] = TRUE ) ;

li
r9,0
; i,0
cmpwi
cr1,r9,12
; cr1,i,18
ble
cr1,0FFF021D8
b
0FFF021F0
0
0
0
0
0
0
0
0
0
0
0
B::PER
EXISR 80000000 CIS pending
D0IS wait
E0IS wait
SRIS wait
D1IS wait
E1IS wait
S
D
E
Input
Output Configuration
IOCR 00000000 E0T level E1T level E2T le
E0L negative E1L negative
RDM disabled TCS sysclk
S
Bank 0
BR0
FF183FFE BAS 0FF00000
comment
r10,0
r10,18(r31)
BS 1MB
BU rea
General Note
This documentation describes the processor specific settings and features for
TRACE32-ICD for the following CPU families:
MPC603x
MPC51xx, MPC5200, MPC5200B
MPC7xx, MPC74xx
MPC82xx, MPC83xx
MPC86xx
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.
General Note
Warning
Signal Level
All
The debugger drives the output pins of the BDM/JTAG/COP connector with the
same level as detected on the VCCS pin. If the I/O pins of the processor are 3.3 V
compatible then the VCCS should be connected to 3.3 V.
See also System.up errors.
Supported debug voltage:
Debug cable with blue ribbon cable 2.5 5.0 V.
Debug cable with gray ribbon cable 1.8 5.0 V (Available since 03/2004).
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.
Warning
Target Design Requirement/Recommendations
General
Locate the 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 50 MHz, and you might want to use high
frequencies for optimized download and upload 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.
It is not necessary to connect QACK and QREQ to the JTAG connector. However, if CPU_QACK
is not connected to any peripheral device, it must be connected to GND for debugger operation.
The debug cable uses the VCCS pin to generate the power supply for the JTAG output buffers.
The load on the VCCs pin caused by the debug cable depends on the debug cable version:
Gray ribbon
cable
The VCCS pin is used as reference voltage for the internal power supply
in the debug cable. This causes a load of about 50 k. It is
recommended to use a resistor with max. 5 k to VCC, and max 1 k for
systems with VCCS = 1. 8V
Blue ribbon
cable
The VCCS pin should be connected to VCC through a resistor with max.
10 , as the output buffers are directly supplied by the VCCS pin.
Target Design Requirement/Recommendations
Quick Start
Starting up the Debugger is done as follows:
1.
Select the device prompt B: for the ICD Debugger, if the device prompt is not active after the
TRACE32 software was started.
b:
2.
Select the CPU type to load the CPU specific settings.

SYStem.CPU MPC8323
3.
Tell the debugger wheres FLASH/ROM on the target.

MAP.BOnchip 0xFF000000++0xFFFFFFFF
This command is necessary for the use of on-chip breakpoints.

4.
Enter debug mode.

SYStem.Up
This command resets the CPU (HRESET) and enters debug mode. After this command is executed it
is possible to access the registers.
5.
Show registers of on-chip peripherals.

PER.view
6.
Set the chip selects to get access to the target memory.

Data.Set ANC:(IOBASE()|0x00010100) %Long 0xFF801801
Data.Set ANC:(IOBASE()|0x00010104) %Long 0xFF800EF4
;.....
7.
Load the program and debug symbols.

Data.LOAD.Elf diabc.x
8.
If the program was compiled on a different computer / environment, the source file path might
have to be adopted.
Data.LOAD.Elf diabc.x /StripPART 5. /SOURCEPATH "L:\prj\src"
Quick Start
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 Compilers. A detailed description of the
Data.LOAD command is given in the General Commands Reference.
9.
Set a breakpoint to the function to be debugged.

Break.Set main
10.
Start application. The core will halt when the breakpoint is reached.
Go
11.
Open windows to show source code, core registers and local variables. The window position can
be specified with the WinPOS command.
Data.List
Register /SpotLight
Frame.view /Locals /Caller
Quick Start
Troubleshooting
The SYStem.Up command is the first command of a debug session where communication with the target is
required. If you receive error messages while executing this command this may have the following reasons.
Error Message
Reason
target power fail
Target has no power or debug cable is not connected. Check if the

JTAG VCC pin is driven by the target.
emulation pod
configuration error
The debugger was not able to determine the connected processor.

There are two possible reasons for this error: The CPU you are using
is not supported by the used software, or a communication error prevented a correct determination. Check the AREA window for more
information.
target processor in reset
The reset line is/was asserted by the target while the debugger performed a power-on reset. Try SYStem.Option.SLOWRESET, and
check signal level of the JTAG HRESET pin.
emulation debug port fail
The debugger was unable to perform a power-on reset with the processor. Check all JTAG port signals.
emulation debug port fail
If the target reset is asserted for >500ms, or the target reset state is
not reflected on the JTAG_HReset pin, SYStem.Option.SLOWRESET
might be necessary.
target reset fail

emulator debug port reset
error
10
Troubleshooting
Problems with Memory Access

For processors of some device families (esp. MPC82XX/MPC83XX), it is important that no unimplemented
memory addresses are accessed by the debugger. Unimplemented memory means address ranges which
would cause a data access exception when accessed by the target application in the current target state.
Memory that is only available after target initialization, like SDRAM is unimplemented memory until initialized
(e.g. a Data.dump window (or the stack view in the Register window) to SDRAM directly after reset). Also,
virtual addresses are unimplemented if the memory management unit is currently disabled or the address
unmapped (e.g. a Data.List window to Linux code at 0xC0000000 directly after reset).
The effects of accessing unimplemented memory are temporarily flickering memory windows up to
permanently hanging memory buses, which can only be recovered by a reset. The debugger can rarely
detect if a memory bus is hanging or not. Typical values displayed in dump/list windows are 0x00000000,
0xDEADBEE0, 0xDEADBEE1 or ???????? (bus error).
Hints for safe memory accesses:
directly after reset, set R1 to zero before opening the register window (which includes the stack
view)
directly after reset, close all windows that display data from SDRAM etc. which is not accessible
directly after reset
MPC82XX: close the peripheral view window before SYStem.UP. Usually the IMMR base
address is different after reset and after target initialization. Always set the right base address
with SYStem.Option.BASE before opening the peripheral view.
Protect the debugger from accessing unimplemented memory using MAP.DENYACCESS.
11
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).
12
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.
arm
!QACK
Termination
Strange behavior during or after system.up; Step/Go do not work

correctly; External memory flicker
The !QACK signal is a confirmation input for the CPU.
The signal indicates that no other device will access/use the 603 bus and no bus
snoop is necessary by the CPU. Only after this confirmation the CPU changes
from user mode back to debug mode.
Normally this signal is served by any external memory controller/bridge or any
other logic. In this case the signal needs a pull-up because it's LOW active.
If there is no device using the 603 bus or serving this signal, !QACK must have a
pull-down or be tied to GND.
On a target with a MPC107 bus controller, some boot loaders configure the
MPC107 so, that !QACK is driven HIGH if it is not asserted. The MPC107 has to
be configured to tristate the signal in this case. If the signal is LOW, the
debugger is not able to control the CPU properly.
13
Troubleshooting
MPC600/7XX
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.
Debugging via
VPN

are limited:
14
Troubleshooting
Setting a
Software
Breakpoint fails

Possible reasons:
TraceOn/TraceOFF.
RTOS and MMU:
location.
MPC7448
Single Step
over store
instruction fails
Is there a workaround for MP7448 chip errata #24?

Due to MPC7448 chip errata #24, the processor may hang when store type
instructions are single stepped with a JTAG debugger.
If you encounter this problem while single stepping through code in RAM, there
is also a workaround implemented in the debugger. Enable this workaround
using the command:
SYStem.Option.STEPSOFT ON
See Processor Architecture Manual for details about this command.
15
Troubleshooting
MPC744X/
745X
Flash/Memory
Mapped
Registers
Invisible
The debugger can not display flash data and/or memory mapped registers,
although the target program can access this memory/registers.
The MPC744X/5X debug controller only supports burst accesses for the
debugger. Some devices however, like flash devices or peripherial controllers do
not support burst accesses.
There is a workaround, which can be activated using MAP.DENYBURST
[address-range]. This workaround enables variable size memory accesses for
the given address range. Please be aware that this workaround is very slow.
Keep data.list/dump windows as small as possible and select a high JTAG
frequency.
This issue is documented in Freescale's MPC74XX chip errata, errata #8
"Variable size memory accesses via COP cannot be performed using the
service bus". MPC7448 and newer are not affected.
MPC744X/
745X/
MPC86XX
SYStem.UP
fails when
FLASH erased
SYStem.UP fails with MPC744x/MPC745x or MPC86xx

SYStem.UP of MPC744X/5X/MPC86XX can fail if the instruction at the reset
address is invalid. This is a side effect of a chip errata (e.g. MPC7448 chip errata
#7)
If the FLASH memory at the reset address (0xFFF00100) is not programmed,
the CPU will not stop at the reset address. The debugger will print an error
message to the AREA window that the CPU stopped at a wrong address
(0xFFF00800). In this case, use the sequence:
SYStem.Mode.Attach
Break
to stop the CPU.
If the SYStem.UP fails as described above, but it is known that the FLASH is
programmed (e.g. boot loader running), usually the problem is that
JTAG_HReset resets only the processor, but not other devices on the board,
esp. the memory controller. If the memory controller will not be reset, the FLASH
contents for the reset address are probably not mapped correctly. Make sure
that JTAG_HReset resets processor and memory controller.
MPC74XX
Error Message:
"emulation pod
configuration
error"
ICD software
window.
16
Troubleshooting
MPC74XX
Instruction/
Data Address
Breakpoints do
not work
Data/Instruction address breakpoints do not work or stop working at a

certain point in target code.
The instruction/data address breakpoints probably stop working if the target
program enables the memory management unit, i.e. MSR_IR and/or MSR_DR
bit set to 1.
Solution: Type MMU.ON to the command line. This command will enable MMU
support of the debugger, which will configure the on-chip breakpoints properly.
Debugging via
VPN

are limited:
17
Troubleshooting
Setting a
Software
Breakpoint fails

Possible reasons:
TraceOn/TraceOFF.
RTOS and MMU:
location.
MGT5100/
MPC5200
Instruction/
Data Address
Breakpoints do
not work
MPC5100/5200
Error Message:
"emulation pod
configuration
error"

bit set to 1.
ICD software
window.
18
Troubleshooting
Debugging via
VPN

are limited:
19
Troubleshooting
Setting a
Software
Breakpoint fails

Possible reasons:
TraceOn/TraceOFF.
RTOS and MMU:
location.
20
Troubleshooting
MPC826x/80/
7x/41/42
BUS-ERRORS
on valid
addresses
After SYStem.Up or when opening a dump/register window all displayed

memory data is invalid (e.g. 0xDEADBEEx)
Accesses to unimplemented memory address ranges (outside of valid chip
selects), can cause a blocked memory bus which can only be resolved by a
RESET. It is not possible to detect a blocked memory bus for the debugger,
usually is appears that all displayed data has the value 0xDEADBEEx or random
data.
Debugger software before 04/2004:
Make sure that none of the windows access unimplemented memory. Close the
peripherial view window while changing the IMMR base address (by program or
via debugger)
Debugger software between 04/2004 and 11/2007:
chip select 11 (or 7) will be activated on SYStem.UP . This prevents blocking the
memory bus. NOTE: In some cases CS7/11 has to be disabled before changing
the IMMR base address.
Debugger software since 11/2007 and newer: The handling of CS7/11 has
been improved, but has to be enabled using
SYStem.Option.MemProtect ON together with SYStem.Option.BASE AUTO .
The debugger software can detect IMMR changes during assembler steps and
will handle CS7/11 accordingly. The base address of the peripherial view is
automatically updated.
Usage:
Set
SYStem.Option.BASE to AUTO if RSTCONF is read from FLASH, or set the
IMMR base address manually for any other options.
SYStem.Option.MemProtect ON
; CS7 or 11 will be enable on system.up for safe memory accesses
SYStem.UP
SYStem.Option.BASE AUTO
; enable automatic IMMR change detection
Start execution until the instruction that changes IMMR is reached, e.g.
GO 0xFFF09038 /ONCHIP
Step.ASM
; assembler single step
Now the debugger will use the new IMMR address for peripheral view and
servicing the watchdog.
21
Troubleshooting
MPC82XX
Problems when
changing
IMMR
(software
before 11/
2007)
When changing the IMMR base address to a new value memory access
results in a buserror (for software before 11/2007)
The cause of the problem is that the MPC82XX series does not provide a
possibility to read IMMR directly via JTAG. Only in a few cases the debugger can
detect IMMR. If the IMMR known to the debugger does not match the IMMR of
the processor, debugger accesses to the IMMR base can cause memory access
errors. Here are the steps for handling IMMR address changes:
For Software older than 11/2007:
The debugger will only detect IMMR on SYStem.UP when
SYStem.Option.BASE AUTO is used and RSTCONF can be read from FLASH.
If the application changes IMMR, SYStem.Option.BASE has to be updated
manually.
Use a cmm script file:
SCREEN.ON
entry &NewBase
if "&NewBase"==""
ENDDO
&OldBase=IOBASE()
PER.S ASD:(&OldBase|0x101A8) %LONG &NewBase
SYStem.Option.BASE &NewBase
PRINT "change old (&OldBase) IOBASE address to =: " iobase()
ENDDO
With screen!=always the hole file will be executed up to the end then the next
access from the debugger take place.
Iconize, close all windows or use a new empty
WinPAGE.Create . Iconized/closed windows are inactive and do not cause a
repeatedly access to the target CPU.
Watchdog service (SYStem.Option.WatchDog.ON) will periodically access
to the SWSR register, which is also within the internal memory space!
If the IMMR register will be changed by the application, the SYStem.Option.BASE also has to be switched to the new value before the CPU
is stopped or stops again!
NOTE:
This issue does not exist for MPC83XX and MPC85XX, as the IMMR base
address can always be read via JTAG
22
Troubleshooting
MPC82XX
Problems when
changing
IMMR (sw
since 11/2007)
When changing the IMMR base address to a new value memory access
results in a buserror (for software since 11/2007)
The cause of the problem is that the MPC82XX series does not provide a
possibility to read IMMR directly via JTAG. Only in a few cases the debugger can
detect IMMR. If the IMMR known to the debugger does not match the IMMR of
the processor, debugger accesses to the IMMR base can cause memory access
errors. Here are the steps for handling IMMR address changes:
New implementation for MPC82XX since 11/2007: SYStem.Option.BASE AUTO
has been extended to detect IMMR changes automatically upon two events:
Memory write / modify via
Data.Set
Assembler single step
The new implementation makes it possible to change the IMMR base address
with the debugger, even while SYStem.Option.WATCHDOG (watchdog is active
and serviced by the debugger) is active, or single stepping a IMMR base
address change.
Usage:
Set
SYStem.Option.BASE to AUTO if RSTCONF is read from FLASH, or set the
IMMR base address manually for any other options.
SYStem.UP
SYStem.Option.BASE AUTO
; enable automatic IMMR change detection
Start execution until the instruction that changes IMMR is reached, e.g.
GO 0xFFF09038 /ONCHIP
Step.ASM
; assembler single step
Now the debugger will use the new IMMR address for peripheral view and
servicing the watchdog.
NOTE:
if
SYStem.Option.BASE is not set to AUTO, the behavior is equal to software
before 11/2007.
This issue does not exist for MPC83XX and MPC85XX, as the IMMR base
address can always be read via JTAG
23
Troubleshooting
MPC82XX
Processor
seems to step
backwards
Processor seems to step backwards.

A bus error happened which cannot be recognized and/or handled by the
debugger. Maybe any indirect store/load command use an un-initialized GPR
register (R1-R15). R0 can only be used as offset zero!!!
A complete new SYStem.Up and target init is necessary.
MPC82XX
There are few exceptions where SYStem.Option.BASE.AUTO (default

setting) does not work:
SYStem.Optio
n.BASE.AUTO
does not work
There are several MPC82xx CPU used as Master/Slave.

Multiprozessor/multicore using
CS0 memory will be changed right after HRESET from any target board
logic.
The RSTCONF word has to be readable by the debugger after system.up
(HRESET) at CS0!
RSTCONF[CIP] does not use the same memory area as the RSTCONF[BMS].
FLASH is empty/erased. Memory content is 0xffffffff.
In this case the RSTCONF[CDIS] bit is set to "disable core" and the internal
default RSTCONF word has to be used.
RSTCONF pin is HIGH.
Internal/default RSTCONF word (0x00000000) is used. In this case set
SYS.O.BASE to 0x0.
In all these cases the SYStem.Option.BASE field has to be set to the true
internal space base address which will be active right after HRESET. Only the 8
possible addresses from RSTCONF[ISP] are valid internal space base
addresses.
MPC82XX
SYStem.Optio
n.IP.AUTO
does not work
There are few exceptions where SYStem.Option.IP.AUTO (default setting)

does not work:
FLASH is empty/erased. Memory content is 0xffffffff.
In this case the RSTCONF[CDIS] bit is set to "disable core" and the internal
default RSTCONF word has to be used.
Wrong signal termination or a not finished board design prevent CPU to
fetch the reset vector from the memory bus.
Additional target board logic needs a huge time after negating the
HRESET, for a specific board, logic or memory controller initialisation.
The most time this problem could be solved with the
SYStem.Option.SLOWRESET.
In all these cases the SYStem.Option.IP field has to be set to:
0, if the reset vector is at 0x00000100 (RSTCONF[CIP]==1)
1, if the reset vector is at 0xfff00100 (RSTCONF[CIP]==0)
24
Troubleshooting
MPC82XX
SYStem.UP
fails when flash
is not
programmed
Why does the debugger fail to connect to the processor after erasing
FLASH memory?
The cause of this problem is that the CPU reads the HARD RESET
CONFIGURATION WORD from the erased flash. The HRCW reads as
0xFFFFFFFF, which menas that the CORE_DISABLE bit of the HRCW is set.
Solution:
Switch the RSTCONF pin to HIGH to use the internal default reset configuration word (0x00000000).
Set SYStem.Option.BASE to 0x00000000
SYStem.UP
Set up chip select 0 for FLASH
program reset configuration word to flash
Switch the RSTCONF pin to LOW to use external reset configuration word
Recommendation: Make sure to program reset configuration word to flash
immediately after erasing it.
MPC82XX/
83XX
Writing SYPCR has no effect.

The SYPCR register can only be written one time.
Cannot write to
SYPCR
If the SYSTEM.OPTION.WATCHDOG is set to OFF then the CPU WATCHDOG

function will be disabled by the debugger during a SYSTEM.UP. To disable the
WATCHDOG on the CPU the debugger writes to SYPCR and uses the one-time
write access to the SYPCR register.
MPC82XX/
83XX
ICD software
Error Message:
"emulation pod
configuration
error"

window.
MPC82XX/
83XX
Instruction/
Data Address
Breakpoints do
not work

bit set to 1.
25
Troubleshooting
MPC83XX
Memory
access fails
after program
ran
The debugger's memory access works after SYStem.UP, but fails after the
running the application. What can be the problem?
For MPC834x, MPC837x and MPC831X, the unit performing memory accesses
for the debugger is clocked together with another peripheral block. For proper
memory access, make sure that this unit does not get disabled by your
application.
The units which must be kept enabled are:
MPC834x: TSEC2
MPC837x: eSDHC / I2C1
MPC831x: encryption engine
Make sure that the corresponding peripheral block does not get disabled in the
System Clock Control Register (SCCR).
MPC83XX
SYStem.UP
fails when flash
is not
programmed
Why does the debugger fail to connect to the processor after erasing
FLASH memory?
The cause of this problem is that the CPU reads the HARD RESET
CONFIGURATION WORD from the erased flash. The HRCW reads as
0xFFFFFFFF, which menas that the CORE_DISABLE bit of the HRCW is set.
Solution: Use SYStem.Option.HRCWOVR to override the HRCW with the
debugger.
Example:
SYStem.CPU MPC8349
SYStem.Option.HRCWOVR 0xB060A00004040000 ; 64-bit HRCW set by
debugger
SYStem.UP
SYStem.Option.HRCWOVR ; disable HRCW override
Notes:
The Processor will keep the overridden HRCW intil the next power cycle or
power-on reset
If HRESET of the JTAG connector asserts PORESET on the target, then
SYStem.Option.HRCWOVR does not work. When designing a target, is is
recommended to connect JTAG_HRESET to CPU_HRESET.
26
Troubleshooting
Configuration
System Overview
HUB
PC or
Workstation
1 GBit Ethernet
Target
PODBUS SYNC
JTAG
Connector
SELECT
ACTIVITY
ETHERNET
LAUTERBACH
DEBUG CABLE
LINK
DEBUG CABLE
RUNNING
USB
Ethernet
Cable
Debug Cable
POWER DEBUG II
POWER
TRIG
POWER
7-9 V
PODBUS OUT
LAUTERBACH
PODBUS EXPRESS OUT
POWER DEBUG II
AC/DC Adapter
PC
Target
Debug Cable
PODBUS IN
USB
Cable
POWER DEBUG INTERFACE / USB2
POWER
DEBUG CABLE
USB
POWER
7-9 V
LAUTERBACH
SELECT
EMULATE
DEBUG CABLE
TRIG
PODBUS OUT
JTAG
Connector
LAUTERBACH
POWER DEBUG INTERFACE / USB 2

AC/DC Adapter
27
Configuration
General Restrictions
All
There is a special handling necessary for breakpoint within the program

exception handler. See also Breakpoint Restrictions.
PPC600
Old revisions of the 603e, like rev. 104, do not support debugging with enabled
cache. Every read/write from/to I-Cache will cause an I-Cache flush and a read/
write from/to physical memory. Accesses to D-Cache will be always a store/
read to physical memory. You can check the revision in you peripheral window
with PER.
All
The CPU handles software breakpoints similar to an exception. Therefore using

software breakpoints in the non-recoverable state (MSR[RI]) of the CPU will
cause the SRR0/1 registers to be lost.
Breakpoints should not be placed at the start and end of exception handlers to
avoid this problem or on-chip breakpoints should be used for interrupt
debugging (e.g. MAP.BOnchip 0x0--0x1fff).
For the special handling for breakpoint within the program exception handler
see Breakpoint Restrictions.
28
Configuration
PowerPC 600 Family Specific Implementations
Breakpoints
There are two types of breakpoints available: Software breakpoints (SW-BP) and on-chip breakpoints.
Software breakpoints are the default breakpoints. They can only be used in RAM areas. There is no
restriction in the number of software breakpoints. Please consider that setting a large number of software
breakpoints will reduce the debug speed.
All
Since this CPU can only be stopped by an on-chip breakpoint,

TRACE32-ICD sets an on-chip breakpoint to the Trap exception
handler, whenever a software breakpoint is used. Because of that,
software breakpoints can not be used if all on-chip breakpoints are
directly used.
MPC60X, MPC7XX,
MPC824X/6X, MPC74XX,
MPC5100, MPC86XX
The current exception position must be known by the debugger at

that time the SW-BP take place. See also SYStem.Option.IP.
MPC512X,
MPC5200,MPC8280,
MPC827X,MPC8247,
MPC8248, MPX83XX
CPUs with at least two on-chip breakpoints can use

SYStem.Option.IP BOTH. The debugger will set on-chip breakpoints
to both interrupt addresses.
For software breakpoint functionality, the debugger must set an on-chip breakpoint to the program interrupt
address. In some applications, especially during the target initialization stage, some applications have
interrupts disabled and use the interrupt address range for non-interrupt code. In this situation, there are two
possible workarounds:
Configure CPU and debugger to use the interrupt addresses that are not used at this stage. This
can be done by setting MSR_IP. Please note that the target application can modify this value any
time.
Force on-chip breakpoints to a different address until target initialization is finished. E.g. set the
on-chip breakpoint to the address where the code at the interrupt addresses is not executed
anymore. If this point is reached, clear the on-chip breakpoint and continue debugging. If the
used CPU has more than one on-chip breakpoint, set the second breakpoint to an unused
address
29
SW-BP Handling for MPC8200, PPC603, PPC700

For software breakpoint functionality, the debugger must set an on-chip breakpoint to the program interrupt
address. As PPC603-based cores have two possible interrupt addresses based on MSR[IP].
In situations where there are less than two on-chip breakpoints available there is a resource conflict. The
unavailability can be caused by CPU design, or if the user makes direct use of on-chip breakpoints.
If the source code modifies MSR[IP], then a manual correction is necessary to use the correct exception
handler.
Following some logic structure examples to explain this special situations.
Source code structure for all modes:
0x00
0x04
0x08
0x0C
0x10
0x14
0x18
0x1C
0x20
code
code
1. SW-BP
code
code
code change MSR[IP] bit to 0
code
2. SW-BP
code
AUTO-Mode:
Command Sequence / CPU Status
MSR[IP]
Exception Pos
Comment
CPU is stopped, PC at 0x00

go
CPU stop at 0x08
go
CPU is still running
1
1
1
1/0
0
1
1
1
1
1
Break OK.
Command Sequence / CPU Status
MSR[IP]
Exception Pos
Comment
CPU is stopped, PC at 0x00

go
CPU stop at 0x08
set sys.option.ip 0
go
CPU stop at 0x1C
1
1
1
1
1/0
0
1
1
1
0
0
0
Break error!
Manual-Mode 0/1
Break OK.
Break OK.
30
Conclusion:
This means, if you know, that your source code will change the MSR[IP] bit and your first SW-BP will take
affect after this alteration, so use the SYStem.Option.IP to select the right exception handler.
NOTE: If the target application uses page tables, software breakpoints can only be set to page tables which
are already available. If it is necessary to set breakpoints in pages not yet mapped, only on-chip breakpoints
can be used.
Software breakpoints can be overwritten by the target application, e.g. if a breakpoint is set in an area which
will be loaded by a boot loader. Use on-chip breakpoints in this case.
31
On-chip Breakpoints
The following list gives an overview of the usage of the on-chip breakpoints by TRACE32-ICD:
CPU family
Instruction breakpoints: Number of on-chip breakpoints that can be used for program and spot
breakpoints
Read/Write breakpoints: Number of on-chip breakpoints that can be used as read or write
breakpoints. Can be only set on 8 byte boundaries
Data breakpoints: Number of on-chip data breakpoints that can be used to stop the program
when a specific data value is written to an address or when a specific data value is read from an
address.
CPU Family
Instruction
Breakpoints
Read/Write
Breakpoints
Data Value
Breakpoints
Notes
PPC603
MPC8240
MPC8245
MPC8255
MPC8260
MPC8265
MPC8266
1 single
address
Instruction
breakpoint is not
available if software
breakpoints are used
MGT5100
PPC7XX
MPC74XX
MPC86XX
1 single
address
1 single
address
Instruction
breakpoint is not
available if software
breakpoints are used
MPC512X
MPC5200
MPC8247
MPC8248
MPC8270
MPC8275
MPC8280
MPC83XX
2 single
addresses
or
1 range
2 single
addresses
or
1 range
If software
breakpoints are
used, instruction
breakpoints are
reduced to one
single address
NOTE: On-chip breakpoints can be cleared by the target application or by a target reset. If an on-chip
breakpoint is not hit, first check (with the peripheral view), if the on-chip breakpoint is set or not.
32
Breakpoints in Interrupt Handlers

If software breakpoints are used in interrupt handlers, the registers SRR0 and SRR1 will get corrupted. The
reason for this corruption is, that software breakpoints also use SRR0/1, so the return address of the
interrupt handler to be debugged gets lost. There are two ways to debug interrupt handlers without
corrupting SRR0/1:
Use on-chip breakpoints. On-chip breakpoints will not corrupt SRR0/1. Please note that if only a
single on-chip instruction address breakpoint is available, using the on-chip breakpoint will
prevent using any further software breakpoints.
Patch the interrupt handler, so that SRR0/1 are saved upon interrupt entry and restored before
interrupt exit. If the interrupt handler it patched that way, it is safe to use software breakpoints
after SRR0/1 have been saved.
Breakpoints in ROM
If an instruction breakpoint is set, per default, the debugger tried to set a software breakpoint. If writing to the
breakpoint address failed, the debugger will set an onchip breakpoint.
With the command MAP.BOnchip <range> it is possible to inform the debugger where you have ROM
(FLASH, EPROM) on the target. If a breakpoint is set within the specified address range, the debugger uses
automatically the available on-chip breakpoints. Use this command, if write accesses to a read-only memory
space are forbidden, e.g. because it could cause a reset etc.
Example:
MAP.BOnchip 0xFF800000--0xFFFFFFFF
Breakpoints on Physical or Virtual Addresses

On-chip breakpoints of almost all PPC603 based processors have a TE bit to configure if the breakpoint
matches, if the access was performed on physical addresses (MSR_IR / MSR_DR off) of on virtual
addresses (MSR_IR / MSR_DR on). In order to match, the processor compares IABR_TE / DABR_TE with
MSR_IR for instruction and with MSR_DR for data accesses.
Per default, the debugger configures the breakpoints to match on physical addresses. In order to set the onchip breakpoints to virtual addresses, use the command TRANSlation.ON (Activate MMU translation).
This command will enable MMU support, including breakpoint configuration.
Software breakpoints hit on virtual addresses if MSR_IR is set, and on physical addresses if MSR_IR is not
set, regardless of any other configuration.
33
Examples for Breakpoints

Break.Set 0x101000
; single address
Break.Set FooBar
; function name
Software breakpoints on ranges not possible.

On-chip Program Address Breakpoints
Break.Set 0xFFF00244 /onchip /program
; single address
Break.Set 0xFFF00244 /onchip
; single address
Break.Set MyFlashFunction /onchip
; function name
Break.Set 0x2000--0x2fff /onchip
; address range
NOTE: Address ranges are only possible with CPUs that have at least two on-chip program address
breakpoints. The option /program is optional.
On-chip Data Address Breakpoints
Break.Set 0xFFF00244 /read
; single address read
Break.Set 0xFFF00244 /write
; single address write
Break.Set 0xFFF00244 /readwrite
; single address any
Break.Set nMyValue /write
; variable name
Break.Set 0x2000--0x2fff /readwrite
; address range
Data address breakpoints of all PPC603e based cores will operate on 8 byte boundaries.
34
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
Data.Set 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)
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
Data.Set ED:0x3330 0x4F
Write 0x4F to address 0x3330 using real-time memory access
35
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
SPRs and PMRs are addressed by specifying the register number after the access class.
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
NC:
not updated
not updated
not updated
updated
D:
updated
not updated
updated
updated
P:
not updated
updated (*)
updated
updated
36
(*) 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
Invalidate instruction cache before go/step (debugger_ppc600.pdf) for details.
MESI States
The cache logic of e300, e600, e700 and PPC603e based cores is described as MESI states. Fhis MESI
state are represented in the CPU as the flags Valid and Dirty. The debugger will display both MESI state and
the status flag representation.
State translation table:
MESI state
Flag
M (modified)
Valid && Dirty
E (exclusive)
Valid && NOT Dirty
S (shared)
Shared
I (invalid)
NOT Valid
37
Little Endian Operation

TRACE32 supports debugging processors which are operated in big-endian mode, true little-endian mode
and modified (PowerPC) little-endian mode. The debugger switched to little-endian presentation, if MSR[LE]
and one of the following system options is set:
For true little-endian mode, enable SYStem.Option.LittleEnd.
For modified (PowerPC) little-endian mode, enable SYStem.Option.PPCLE.
The following table lists processors which support one or both little endian modes:
Processor
true
little-endian
modified
little-endian
Notes
MPC603
MPC745
MPC750 (FSL)
MPC755
PPC750xx (IBM)
Yes
MPC5121
MPC5123
MPC5125
Yes
e300 core only supports true little-endian
MGT5100
MPC5200
Yes
Yes
HID2[TLE] == 1 for true little-endian
MPC74XX
Yes
MPC8247
MPC8248
MPC8271
MPC8272
Yes
MPC83XX
Yes
MPC86XX
Yes
e300 core only supports true little-endian
38
General System Commands
SYStem.BdmClock
Set JTAG frequency
Format:
SYStem.BdmClock <frequency>
<frequency>:
0.1 50.0 MHz.
(Default 10.0 MHz)
Selects the frequency for the debug interface. Usually, the maximum allowed JTAG frequency for PowerPC
is 1/10th of the core frequency.
SYStem.CPU
Select the CPU type
Format:
SYStem.CPU <cpu>
<cpu>:
603EV2 | 750 | 8240 | 8260 | 7448 | 5200
Selects the CPU type. If the needed CPU type is not available un 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 CPU type. You will find the
information in the VERSION window.
check if the debugger software is up-to-date. Please check the VERSION window to see which
version is installed. CPUs that appeared later than the software release are usually not
supported. Please check www.lauterbach.com for updates. If the needed CPU appeared after
the release date of the debugger software, please contact technical support and request a
software update.
if the CPU name matches one the names in the CPU selection. Search for the CPU name in the
SYStem window, or type SYStem.CPU to the command line and click through the hot keys.
39
SYStem.CpuAccess
Format:
Run-time memory access (intrusive)
SYStem.CpuAccess Enable | Denied | Nonstop
Default: Denied.
Enable
Allow intrusive run-time memory access.

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
number of the read/write accesses required.
A red S in the state line of the TRACE32 screen indicates this intrusive behavior
of the debugger.
Denied
Lock intrusive run-time memory access.
Nonstop
Lock all features of the debugger, that affect the run-time behavior.
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. action Spot for breakpoints, performance analysis via StopAndGo mode, 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.
40
SYStem.MemAccess
Real-time memory access (non-intrusive)
Format:
SYStem.MemAccess CPU | Denied<cpu_specific>

SYStem.ACCESS (deprecated)
CPU
Real-time memory access during program execution to target is enabled.
Denied
Real-time memory access during program execution to target is disabled.
Default: Denied.
QMON
Select QNX monitor (pdebug) for Run Mode Debugging of embedded QNX.
Ethernet is used as communication interface. For more information, RTOS
Debugger for QNX - Run Mode (rtos_qnx_run.pdf).
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.
NOTE: SYStem.MemAccess CPU is only available for the MPC86XX.
41
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 debugger does not influence the target or the
running application. The output signals of the debug cable are tristated.
NoDebug
Resets the target with debug mode disabled. In this mode no debugging is
possible. The CPU state keeps in the state of NoDebug and the output signals
of the debug cable are tristated.
Go
Resets the target with debug mode enabled and prepares the CPU for debug
mode entry. After this command the CPU is in the system.up mode and running.
Now, the processor can be stopped with the break command or until any break
condition occurs.
Attach
Connect to the processor without asserting reset. The state of the target/
application does not change. After this command the CPU is in the system.up
mode and running.
StandBy
If this mode is used to start debugging from power-on. The debugger will wait
until power-on is detected and then stop the CPU at the first instruction at the
reset address. Not available for all PowerPC families covered by this manual.
Up
Resets the target and sets the CPU to debug mode. After execution of this
command the CPU is stopped and prepared for debugging. All register are set
to the default value.
42
SYStem.CONFIG
Configure debugger according to target topology
Format:
SYStem.CONFIG <parameter> <number_or_address>

SYStem.MultiCore <parameter> <number_or_address> (deprecated)
<parameter>
(General):
state
CORE
(JTAG):
DRPRE <bits>
DRPOST <bits>
IRPRE
<bits>
IRPOST <bits>
TAPState <state>
TCKLevel <level>
TriState [ON | OFF]
Slave
[ON | OFF]
<core>
The four parameters IRPRE, IRPOST, DRPRE, DRPOST are required to inform the debugger about the
TAP controller position in the JTAG chain, if there is more than one core in the JTAG chain (e.g. ARM +
DSP). The information is required before the debugger can be activated e.g. by a SYStem.Up. See Daisychain Example.
For some CPU selections (SYStem.CPU) the above setting might be automatically included, since the
required system configuration of these CPUs is known.
TriState has to be used if several debuggers (via separate cables) are connected to a common JTAG port
at the same time in order to ensure that always only one debugger drives the signal lines. TAPState and
TCKLevel define the TAP state and TCK level which is selected when the debugger switches to tristate
mode. Please note: nTRST must have a pull-up resistor on the target, TCK can have a pull-up or pull-down
resistor, other trigger inputs needs to be kept in inactive state.
Multicore debugging is not supported for the DEBUG INTERFACE (LA-7701).
43
state
Show multicore settings.
CORE
For multicore debugging one TRACE32 GUI has to be started per core.
To bundle several cores in one processor as required by the system this
command has to be used to define core and processor coordinates within
the system topology.
Further information can be found in SYStem.CONFIG.CORE.
DRPRE
(default: 0) <number> of TAPs in the JTAG chain between the core of

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

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

between the TDI signal and the core of interest. This is the sum of the
instruction register lengths of all TAPs between the TDI signal of the
debugger and the core of interest.
TAPState
(default: 7 = Select-DR-Scan) This is the state of the TAP controller when

the debugger switches to tristate mode. All states of the JTAG TAP
controller are selectable.
TCKLevel
(default: 0) Level of TCK signal when all debuggers are tristated.
TriState
(default: OFF) If several debuggers share the same debug port, this
option is required. The debugger switches to tristate mode after each
debug port access. Then other debuggers can access the port. JTAG:
This option must be used, if the JTAG line of multiple debug boxes are
connected by a JTAG joiner adapter to access a single JTAG chain.
Slave
(default: OFF) If more than one debugger share the same debug port, all
except one must have this option active.
JTAG: Only one debugger - the master - is allowed to control the signals
nTRST and nSRST (nRESET).
44
Daisy-chain Example
TDI
Core A
Core B
Core C
Chip 0
Core D
TDO
Chip 1
Below, configuration for core C.

Instruction register length of
Core A: 3 bit
Core B: 5 bit
Core D: 6 bit
SYStem.CONFIG.IRPRE 6
; IR Core D
SYStem.CONFIG.IRPOST 8
; IR Core A + B
SYStem.CONFIG.DRPRE 1
; DR Core D
SYStem.CONFIG.DRPOST 2
; DR Core A + B
SYStem.CONFIG.CORE 0. 1.
; Target Core C is Core 0 in Chip 1
45
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
46
SYStem.CONFIG.CORE
Assign core to TRACE32 instance
Format:
SYStem.CONFIG.CORE <coreindex> <chipindex>

SYStem.MultiCore.CORE <coreindex> <chipindex> (deprecated)
<chipindex>:
1i
<coreindex>:
1k
Default coreindex: depends on the CPU, usually 1. for generic chips

Default chipindex: derived from CORE= parameter of the configuration file (config.t32). The CORE
parameter is defined according to the start order of the GUI in T32Start with ascending values.
To provide proper interaction between different parts of the debugger the systems topology must be mapped
to the debuggers topology model. The debugger model abstracts chips and sub-cores of these chips. Every
GUI must be connect to one unused core entry in the debugger topology model. Once the SYStem.CPU is
selected a generic chip or none generic chip is created at the default chipindex.
None Generic Chips
None generic chips have a fixed amount of sub-cores with a fixed CPU type.
First all cores have successive chip numbers at their GUIs. Therefore you have to assign the coreindex and
the chipindex for every core. Usually the debugger does not need further information to access cores in
none generic chips, once the setup is correct.
Generic Chips
Generic chips can accommodate an arbitrary amount of sub-cores. The debugger still needs information
how to connect to the individual cores e.g. by setting the JTAG chain coordinates.
Start-up Process
The debug system must not have an invalid state where a GUI is connected to a wrong core type of a none
generic chip, two GUI are connected to the same coordinate or a GUI is not connected to a core. The initial
state of the system is value since every new GUI uses a new chipindex according to its CORE= parameter
of the configuration file (config.t32). If the system contains fewer chips than initially assumed, the chips must
be merged by calling SYStem.CONFIG.CORE.
47
CPU specific System Commands
SYStem.Option BASE
Format:
Set base address for on-chip peripherals
SYStem.Option Base [AUTO | <value>]
MPC8260, MPC8280 and compatible

The BASE address is the address of the IMMR register. This address is necessary to get known by the
debugger to enable/disable the watchdog after reset and calculate the base address of the peripherals
(peripheral window).
AUTO
The debugger reads RSTCONF from FLASH to detect the IMMR address. If
your target is configures
<value>
If the address of the IMMR from the reset configuration word is known, the
address can be directly put in the BASE field.
This will speed up the SYStem.Up considerable.
MPC8240
The BASE address is the address of the EUBR registers (EUMBBAR). This address is necessary to get
known by the debugger to calculate the base address of the Message Unit, DMA, ATU, I2C and EPIC
registers.
AUTO
The AUTO entry set the Base address to the EUMBBAR value at SYStem.Up.
Only works with the Address Map B!
<value>
If the address of the EUMB registers is known or change anytime after

SYStem.Up was executed, the address can be directly put in the BASE field.
MPC83XX, MPC512X, MPC5200, MPC86XX

The debugger will determine the current base address via JTAG. This option has no effect.
PPC603x, PPC750xx, MPC755, PPC74XX

This option is disabled for embedded host processors, because no memory mapped on-chip peripherials
are available.
48
SYStem.Option BUS32
Format:
Use 32-Bit data-bus mode
SYStem.Option BUS32 [ON | OFF]
Default: OFF. Enable this option if the CPU is operated in the reduced 32-bit data bus width mode. This
mode is often used in designs with PPC603e processors.
SYStem.Option CONFIG
Format:
Select RCW configuration
SYStem.Option CONFIG [Master | Slave1..7]
For MPC82XX only. When SYStem.Option.BASE is set to AUTO, this setting defines if the RCW is read
from the location designated to the configuration master, or from one of the seven locations designated to
the configuration slaves. By default setting, the debugger will read from the configuration master location.
SYStem.Option DCREAD
Format:
Read from data cache
SYStem.Option DCREAD [ON | OFF]
Data.dump windows for access class D: displays the memory value from the data caches if valid. If no valid
data is found in the caches, the physical memory will be read. If supported by the CPU unified L2/L3 caches
will also be used if this system option is enabled
If caching is disabled via the appropriate hardware registers (HID0 for PPC603
Series) or cache is invalid, read and writes from/to memory will directly reflect to
contents of physical memory even if a cache access class is selected.
The following table describes how DCREAD and ICREAD influence the behavior of the debugger
commands that are used to display memory.
ICREAD off
DCREAD off
DC:
IC:
NC:
D:
P:
D-Cache
I-Cache
phys. mem.
phys. mem.
phys. mem.
49
ICREAD on
DCREAD off
D-Cache
I-Cache
phys. mem.
phys. mem.
I-Cache
ICREAD off
DCREAD on
D-Cache
I-Cache
phys. mem.
D-Cache
phys. mem.
ICREAD on
DCREAD on
D-Cache
I-Cache
phys. mem.
D-Cache
I-Cache
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 or real-time memory access not
available for used CPU.
SYStem.Option FREEZE
Format:
Freeze timebase when core halted
SYStem.Option FREEZE [ON | OFF]
When enabled, the cores timebase is stopped when the core is halted in debug mode. It is recommended to
set this option ON.
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.
50
SYStem.Option HRCWOVR
Override HRCW on SYStem.UP
Format:
SYStem.Option HRCWOVR <value>
<value>:
hard reset configuration word (64 bit) in the order 0xHHHHHHHHLLLLLLLL
MPC83XX and MPC512X only. Override the HRCW on SYStem.UP via JTAG. To disable this system
option, call without parameter. This command is usually required to connect to a processor with erased/
empty flash (HRCW not set).
NOTES:
The CPU will remember and use the overridden HRCW until the next power cycle or power-on
reset.
If JTAG_HRESET is connected to CPU_PORESET, SYStem.Option.HRCWOVR will only work in

conjunction with SYStem.Option.ResetMode JTAG_HRST.
Usage:
SYStem.CPU MPC8360
SYStem.Option.HRCWOVR 0x8060000004040006
SYStem.UP
SYStem.Option.HRCWOVR
SYStem.Option ICFLUSH
Format:
;
;
;
;
select CPU
desired HRCW
reset processor
disable HRCW override
Invalidate instruction cache before go/step
SYStem.Option ICFLUSH [ON | OFF]
ON (default): Invalidates the instruction cache before starting the target program (Step or Go).
OFF: Write accesses by the debugger to the memory of the class P: are performed in the instruction cache
and the memory.
51
SYStem.Option ICREAD
Format:
Read from instruction cache
SYStem.Option ICREAD [ON | OFF]
Data.List window and Data.dump window for access class P: displays the memory value from the
instruction cache if valid. If I-cache is not valid the physical memory will be read. If supported by the CPU,
L2 caches will also be used if this system option is enabled.
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: Dont 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 can not detect this change and will restore MSE_EE.
52
SYStem.Option IP
Format:
Set MSR_IP value for breakpoints / sys.up
SYStem.Option IP [0 | 1 | AUTO | BOTH]
This option is used by the debugger to use the correct exception handler for the software breakpoints. See
also Software Breakpoints.
AUTO
Depend on the current/last state of the MSR[IP] bit the debugger uses the lower
or the higher exception handler.
Independent of the MSR[IP] the debugger uses the lower exception handler at
0x00000700.
Independent of the MSR[IP] the debugger uses the higher exception handler at
0xFFFF0700.
BOTH
Use both exception handler addresses. Only available for CPUs with two or
more instruction address on-chip breakpoints (MPC8280, MPC83XX and
compatible).
SYStem.Option.LittleEnd
Format:
True little endian mode
SYStem.Option LittleEnd [ON | OFF]
Enable this system option if the PowerPC core is operated in true little endian mode. If the CPU is
operated in modified (PowerPC) little endian mode, use command SYStem.Option.PPCLittleEnd.
To find out which mode is supported by the target processor, see Little Endian Operation.
SYStem.Option.MemProtect
Format:
Enable memory access safeguard
SYStem.Option MemProtect [ON | OFF]
PowerQuicc II (MPC824X, MPC826X, MPC827X, MPC8280) only.

53
This option can help to prevent a hanging memory bus caused by debugger accesses to unimplemented
memory. USe together with SYStem.Option.BASE AUTO.
Usage:
Set SYStem.Option.BASE to AUTO if RSTCONF is read from FLASH, or set the IMMR base
address manually for any other options.
SYStem.Option.MemProtect ON ; CS7 or 11 will be enable on system.up for safe memory

accesses
SYStem.UP
SYStem.Option.BASE AUTO ; enable automatic IMMR change detection
Start execution until the instruction that changes IMMR is reached, e.g. GO 0xFFF09038 /
ONCHIP
Step.ASM ; assembler single step
Now the debugger will use the new IMMR address for peripheral view and servicing the
watchdog.
SYStem.Option.MemSpeed
Configure memory access timing
Format:
SYStem.Option MemSpeed <value>
<value>:
1(fastest) ... 255(slowest)

0: default speed
This option can be used to configure the access speed for memory accesses by the debugger. Only use this
option when advised by Lauterbach.
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.
54
SYStem.Option.NoDebugStop
Format:
Disable JTAG stop on debug events
SYStem.Option NoDebugStop [ON | OFF]
Default: OFF.
On-chip debug events Breakpoint (instruction/data address), single step and branch trace 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 breakpoint/trace
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 debug events. 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.
SYStem.Option.NOTRAP
Use alternative software breakpoint instruction
Format:
SYStem.Option NOTRAP <type>
<type>:
OFF | FPU | ILL

ON (deprecated, same as FPU)
Defines which instruction is used to implement software breakpoints.
OFF
Use TRAP instructions as software breakpoint (default setting).
FPU
Use an FPU instruction as software breakpoint. Use only if the application does
not make use of floating point instructions (neither hardware nor software
emulated). The application must permanently set MSR[FP] to 0.
ILL
Use an illegal opcode as software breakpoint. This setting is recommended for

MPC82XX, MPC5200 (G2/G2_LE cores).
55
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 overlay ID. Addresses therefore have the
format <overlay_id>:<address>. This enables the debugger to
handle overlaid program memory.
OFF
Disables support for code overlays.
WithOVS
Like option ON, but also enables support for software breakpoints. This
means that TRACE32 writes software breakpoint opcodes 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
; Data.List <overlay_id>:<address>
SYStem.Option PARITY
Format:
Generate parity on memory access
SYStem.Option PARITY [ON | OFF]
Compute the parity bit for the Data.Set command to support memory with parity.
SYStem.Option.PINTDebug
Format:
Program interrupt debugging
SYStem.Option PINTDebug [ON | OFF]
Software breakpoints for e300/e600 (former PPC603e based) cores are implemented using the trap
instruction. However, the CPU will not stop for JTAG directly on the TRAP instruction. Instead, the TRAP
instruction causes a program interrupt. To let the CPU stop for JTAG, the debugger sets an on-chip
breakpoint to the program interrupt address (0700).
56
The on-chip breakpoint at the program interrupt address will stop on all program interrupts, not just for TRAP
instructions. If the cause of the program interrupt is other than TRAP, the debugger will print a message, the
instruction pointer will be set to the instruction that caused the interrupt.
Enable this option, if it is necessary to execute program interrupts not caused by TRAP. The debugger will
restart the CPU automatically. This event will be displayed in the status line. Please note that this feature has
an impact on the real-time behavior, because the CPU will stop for a short time every time a program
interrupt occurs.
Notes:
On MPC82XX and MPC5200 (G2/G2_LE cores), SYStem.Option.PINTDebug can not support

debugging of illegal instruction type program interrupts.
If SYStem.Option.PINTDebug is enabled, on-chip breakpoints at the first instruction of the

program interrupt handler (0700) are not possible. Set the on-chip breakpoint to 0704 or other.
SYStem.Option.PPCLittleEnd
Format:
PPC little endian mode
SYStem.Option PPCLittleEnd [ON | OFF]
Enable this system option if the PowerPC core is operated in modified (PowerPC) little endian mode. If the
CPU is configured for true little endian mode, use the command SYStem.Option.LittleEnd.
To find out which mode is supported by the target processor, see Little Endian Operation.
SYStem.Option.PTE
Format:
Evaluate PTE table for address translation
SYStem.Option PTE [ON | OFF]
When OFF, the debugger will only evaluate BAT and ITLB/DTLB for address translation. When set to ON,
the debugger will also evaluate the PTE table in memory for address translation.
Important: At the time this option is enabled, PTE table and SDR1 register have to be fully set up. If this
option is enabled without PTE ready (or when memory is not yet initialized), wrong address translation or
even general memory access fail can result. Related to this, make sure to disable this option before
SYStem.Up or target reset.
57
SYStem.Option ResetMode
Select reset mode for SYStem.Up
Format:
SYStem.Option.ResetMode <mode>
<mode>
PIN | JTAG_PORST | JTAG_HRST | JTAG_SRST
MPC83XX and MPC512x only. Default: PIN. Selects the method the debugger uses to reset the processor
at SYStem.Up.
<mode>
Effect at SYStem.Up
PIN
The reset pin (debug connector: pin 13) is asserted to reset the processor.
JTAG_HRST
A hard reset issue is issued via JTAG. The debug connectors reset pin is not
asserted. This option requires that the HRCW is set via JTAG (see
SYStem.Option.HRCWOVR).
JTAG_PORST
A power-on reset is issued via JTAG. The debug connectors reset pin is not
asserted. This option requires that the HRCW is set via JTAG (see
SYStem.Option.HRCWOVR).
JTAG_SRST
A soft reset is issued via JTAG. The debug connectors reset pin is not asserted.
SYStem.Option.SLOWRESET
Format:
Relaxed reset timing
SYStem.Option SLOWRESET [ON | OFF]
This system option defines, how the debugger will test JTAG_HRESET. For some system mode changes,
the debugger will assert JTAG_HRESET. PEr default (OFF), the debugger will release RESET and then
read the HRESET signal until the HRESET pin is released. Reset circuits of some target boards prevent that
the current level of HRESET can be determined via JTAG_HRESET. If this system option is enabled, the
debugger will not read JTAG_HRESET, but instead waits four seconds and then assumes that the boards
HRESET is released.
58
SYStem.Option.STEPSOFT
Format:
Use alternative method for ASM single step
SYStem.Option STEPSOFT [ON | OFF]
The alternative method circumvents a processor problem when a store type instruction is executed at the
time a debug event occurs. This option is a workaround for the following errata:
MPC7448 errata #24
MPC8610 errata JTAG #2
MPC8640/41 errata JTAG #4
Only enable this option, if one of the above processors is used and if the effect of this errata has been
observed.
If the code to be debugged is located in RAM, SYStem.Option.STEPSOFT can be used without further
configuration.
If the code to be debugged is located in read-only memory, the alternative method can be used if RAM is
available and free for debugger use. In this case, declare the read-only memory using MAP.BOnchip, and
the RAM used by the debugger using FLASH.TARGET.
NOTE: The alternative workaround can only fix issues caused by single steps. Manual breaks and onchip
breakpoints can still be affected by the problem.
59
SYStem.Option WATCHDOG
Format:
Leave software watchdog enabled
SYStem.Option WATCHDOG [ON | OFF]
MPC8260, MPC8280, MPC83XX and compatible CPUs only.

SYStem.Option.WATCHDOG OFF: The debugger permanently disables the watchdog at SYStem.Up.
SYStem.Option.WATCHDOG ON: While the CPU is stopped, the debugger will service the watchdog. When
the application is running, the application is expected to service the watchdog.
Software Watchdog Timer (SWT) The SWT asserts a reset or non-maskable
interrupt (as selected by the system protection control register) if the software
fails to service the SWT for a designated period of time (e.g., because the
software is trapped in a loop or lost). After a system reset, this function is
enabled with a maximum time-out period and asserts a system reset if the timeout is reached. The SWT can be disabled or its time-out period can be changed
in the SYPCR. Once the SYPCR is written, it cannot be written again until a
system reset.
60
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>.
61
CPU specific tables:
ITLB
Displays the contents of the Instruction Translation Lookaside Buffer.
DTLB
Displays the contents of the Data Translation Lookaside Buffer.
BAT
Displays the contents of the BAT table.
PTE
Displays the contents of the PTE table.
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.
62
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>.
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.
63
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>.
CPU specific tables:
ITLB
Loads the instruction translation table from the CPU to the debugger internal
translation table.
DTLB
Loads the data translation table from the CPU to the debugger internal
translation table.
BAT
Loads the Block Address Translation table from the CPU to the debugger
internal translation table.
PTE
Loads the PTE table from the CPU to the debugger internal translation table.
64
MMU.Set
Write MMU TLB entries to CPU
Format:
MMU.Set <table> <index> <way> <tlbhi> <tlblo> [<tlbext>]
<table>:
ITLB
DTLB
<index>
index (entry/set number) in TLB table
<way>
way number within the set
<tlbhi>
<tlblo>
<tlbext>
data of the TLB entry.
Loads the specified MMU translation table from the CPU to the debugger internal MMU table. Writing ITLB
and DTLB is not supported for all processors.
ITLB
Translation lookaside buffer for instruction fetches
DTLB
Translation lookaside buffer for data load and store accesses
65
CPU specific BenchMarkCounter Commands

The BenchMarkCounter features are based on the cores performance monitor, accessed through the
performance monitor registers (PMR). Only processors with e300c3 and e300c4 cores have performance
monitor registers:
MPC830X
MPC831X
MPC512X
PMR access is only possible while the core is halted. For other processors, the BenchMarkCounter features
are not available.
NOTE:
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 the BMC commands BMC.<counter>.EVENT
<event> and BMC.<counter>.RATIO X/<counter n>.
For descriptions of available events, see Freescales e300 core reference
manual (Table 11-9, Performance Monitor Event Selection).
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.
66
CPU specific BenchMarkCounter Commands
CPU specific TrOnchip Commands
The features supported by the TrOnchip command for TRACE32-ICD vary for the
different PowerPC families.
TrOnchip.view
Format:
View on-chip trigger setup window
TrOnchip.view
TrOnchip.DISable
Format:
Disable debug register control
TrOnchip.DISable
Not supported. The debugger always controls the debug registers.
TrOnchip.ENable
Format:
Enable debug register control
TrOnchip.ENable
Not supported. The debugger always controls the debug registers.
67
TrOnchip.CONVert
Format:
Adjust range breakpoint in on-chip resource
TrOnchip.CONVert [ON | OFF]
The on-chip breakpoints can only cover specific ranges. If a range cannot be programmed into the
breakpoint it will automatically be converted into a single address breakpoint when this option is active. This
is the default. Otherwise an error message is generated.
TrOnchip.CONVert ON
Break.Set 0x1000--0x17ff /Write
; sets breakpoint at range

; 1000--17ff sets single breakpoint
; at address 1001
TrOnchip.CONVert OFF
; sets breakpoint at range

; 1000--17ff
; gives an error message
TrOnchip.VarCONVert
Format:
Adjust complex breakpoint in on-chip resource
TrOnchip.VarCONVert [ON | OFF]
The on-chip breakpoints can only cover specific ranges. If you want to set a marker or breakpoint to a
complex variable, the on-chip break resources of the CPU may be not powerful enough to cover the whole
structure. If the option TrOnchip.VarCONVert is ON the breakpoint will automatically be converted into a
single address breakpoint. This is the default setting. Otherwise an error message is generated.
TrOnchip.RESet
Format:
Reset on-chip trigger settings
TrOnchip.RESet
Resets the trigger system to the default state.
68
TrOnchip.TEnable
Format:
Set filter for the trace
TrOnchip.TEnable <par>
Obsolete command. Refer to the Break.Set command to set trace filters.
TrOnchip.TOFF
Format:
Switch the sampling to the trace to OFF
TrOnchip.TOFF
TrOnchip.TON
Format:
Switch the sampling to the trace to ON
TrOnchip.TON EXT | Break
TrOnchip.TTrigger
Format:
Set a trigger for the trace
TrOnchip.TTrigger <par>
Obsolete command. Refer to the Break.Set command to set a trigger for the trace.
69
Mechanical Description
JTAG/COP Connector PPC603e/700/MPC8200

Signal
TDO
TDI
(QREQ-)
TCK
TMS
(SRESET-)
HRESET(CKSTOP-)
Pin
Pin
1
3
5
7
9
11
13
15
2
4
6
8
10
12
14
16
Signal
(QACK-)
TRSTJTAG-VREF
(PRESENT-)
N/C
GND
N/C (KEY PIN)
GND
NOTE:
This is a standard 16 pin double row (two rows of eight pins) connector (pin to pin spacing: 0.100 in).
Pin 8 is permanently driven high (level of VCCS) by the debug cable.
Signal in brackets are not needed by the debugger and can be left unconnected.
If CPUs have an QACK input and this input is unused, QACK should be connected to GND. If the
processor does not have QACK/QREQ pins, leave pin 2 and 15 N/C
70
Mechanical Description
Technical Data
Operation Voltage
Adapter
OrderNo
Voltage Range
JTAG Debugger for PPC603/MPC74x/75x (ICD)

JTAG Debugger Extension for PPC603(ICD)
LA-7721
LA-7721X
1.6 .. 5.5 V
1.6 .. 5.5 V
Adapter
OrderNo
Voltage Range
JTAG Debugger for MPC74xx (ICD)

JTAG Debugger Extension for MPC74xx (ICD)
LA-7719
LA-7719X
1.6 .. 5.5 V
1.6 .. 5.5 V
71
Technical Data
Support
MPC603E3
MPC603EV2
MPC740
MPC745
MPC750
MPC755
PC603R
PC745
PC755
PPC603E3
PPC603EV2
PPC740
PPC750
PPC750CL
PPC750CX
PPC750CXE
PPC750CXR
PPC750FL
PPC750FX
PPC750GL
PPC750GX
TSPC603R
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
Available Tools
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
72
Support
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
INSTRUCTION
SIMULATOR
POWER
INTEGRATOR
ICD
TRACE
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
ICD
MONITOR
ICD
DEBUG
FIRE
ICE
MPC603E3
MPC603EV2
MPC740
MPC745
MPC750
MPC755
PC603R
PC745
PC755
PPC603E3
PPC603EV2
PPC740
PPC750
PPC750CL
PPC750CX
INSTRUCTION
SIMULATOR
POWER
INTEGRATOR
ICD
TRACE
ICD
MONITOR
ICD
DEBUG
FIRE
ICE
CPU
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
CPU
MPC7400
MPC7410
MPC7441
MPC7445
MPC7447
MPC7447A
MPC7448
MPC7450
MPC7451
MPC7455
MPC7457
PC7410
PC7447A
PC7448
PC7457
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
73
Support
YES
YES
YES
YES
YES
YES
INSTRUCTION
SIMULATOR
POWER
INTEGRATOR
ICD
TRACE
YES
YES
YES
YES
YES
YES
YES
ICD
MONITOR
ICD
DEBUG
FIRE
ICE
MGT5100
MPC5121
MPC5123
MPC5125
MPC5200
MPC5200B
INSTRUCTION
SIMULATOR
POWER
INTEGRATOR
ICD
TRACE
ICD
MONITOR
ICD
DEBUG
FIRE
ICE
CPU
YES
YES
YES
YES
YES
YES
YES
CPU
PPC750CXE
PPC750CXR
PPC750FL
PPC750FX
PPC750GL
PPC750GX
TSPC603R
YES
YES
YES
YES
YES YES
YES YES
Compilers
Language
Compiler
Company
Option
ADA
GNAT
ELF/DWARF
C
C
CXPPC
XCC-V
C
C
GREEN-HILLS-C
MCCPPC
C
C
C
CC
ULTRA-C
HIGH-C
Free Software
Foundation, Inc.
Cosmic Software
GAIO Technology Co.,
Ltd.
Greenhills Software Inc.
Mentor Graphics
Corporation
NXP Semiconductors
Radisys Inc.
Synopsys, Inc
Comment
ELF/DWARF
SAUF
ELF/DWARF
ELF/DWARF
XCOFF
ROF
ELF/DWARF
74
Support
Language
Compiler
Company
Option
C
C
C
C
C++
DCPPC
D-CC
D-CC
D-CC
GCC
ELF/DWARF
IEEE
COFF
ELF/DWARF
ELF/DWARF
C++
C++
GREEN-HILLSC++
CCCPPC
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
ELF/DWARF
EXE/CV5
ELF/DWARF
ELF/DWARF
ELF/STABS
ELF/DWARF
WindowsCE
ELF/DWARF
ELF/DWARF
ELF/DWARF
75
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
76
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
77
Support
Products
Product Information
OrderNo Code
Text
LA-7721
DEBUG-PPC603
supports (1.8V - 5.0V) PPC603, MPC74x and MPC75x

includes software for Windows, Linux and MacOSX
requires Power Debug Module
debug cable with 16 pin connector
LA-7721X
DEBUG-PPC603-X
JTAG Debugger for PPC603/MPC74x/75x

requires a valid software guaranty or a valid
software maintenance key
please add the serial number of the base debug
cable to your order
OrderNo Code
Text
LA-7719
DEBUG-PPC74XX
supports (1.8V - 5.0V) MPC7410

requires PowerDebug Module
LA-7719X
DEBUG-PPC74XX-X
supports MPC74XX
not suitable for debug cables older than 02/2004
(blue ribbon cable)
cable to your order
LA-7719U
Hardware Upgrade JTAG Debugger PPC74XX
DEBUG-PPC74XX-UPG
Upgrade to whisker version of the debug cable

Note serial number of old debug cable
on purchase order.
Old debug cable must be returned on receipt
of the new one.
Includes 1 year software guarantee
78
Products
OrderNo Code
Text
LA-7734
JTAG Debugger for MPC5200/MPC512x (ICD)
JTAG-MPC5200
supports (1.8V - 5.0V) MGT5100, MPC512x, MPC5200

LA-7734X
JTAG Debugger Extension for MPC5200/MPC512x
JTAG-MPC5200-X
supports MGT5100, MPC5200, MPC512x

cable to your order
OrderNo Code
Text
LA-7729
JTAG Debugger for MPC82xx/MPC83xx(ICD)
DEBUG-MPC8260
supports (1.8V - 5.0V) MPC82xx, MPC83xx,

LA-7729X
JTAG Debugger Extension for MPC8260/MPC8240
DEBUG-MPC8260-X
supports (1.8V - 5.0V) MPC82xx, MPC83xx,

(whisker version of the debug cable)
cable to your order
79
Products
Order Information
Order No.
Code
Text
LA-7721
LA-7721X
DEBUG-PPC603
DEBUG-PPC603-X

Additional Options
LA-7729X DEBUG-MPC8260-X
LA-3735X DEBUG-MPC86XX-X
LA-7719X DEBUG-PPC74XX-X
LA-3796X DEBUG-PQ3-X
LA-3795X DEBUG-QORIQ32-X
LA-7734X JTAG-MPC5200-X
LA-7960X MULTICORE-LICENSE

JTAG Debugger Extension for MPC86xx
JTAG Debugger Ext. for MPC85XX/QorIQ e500
JTAG Debugger Extension for QorIQ 32 Bit
License for Multicore Debugging
Order No.
Code
Text
LA-7719
LA-7719X
LA-7719U
DEBUG-PPC74XX
DEBUG-PPC74XX-X
DEBUG-PPC74XX-UPG

Hardware Upgrade JTAG Debugger PPC74XX
Additional Options
LA-7721X DEBUG-PPC603-X
LA-7960X MULTICORE-LICENSE

License for Multicore Debugging
80
Products
Order No.
Code
Text
LA-7734
LA-7734X
JTAG-MPC5200
JTAG-MPC5200-X
JTAG Debugger for MPC5200/MPC512x (ICD)

Additional Options

Order No.
Code
Text
LA-7729
LA-7729X
DEBUG-MPC8260
DEBUG-MPC8260-X
JTAG Debugger for MPC82xx/MPC83xx(ICD)

Additional Options

81
Products

Debugger Ppc600

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Debugger Ppc600

Uploaded by

Copyright:

Available Formats

PPC600 Family Debugger

TRACE32 Online Help

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

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

PQII, MPC5200, MPC603/7xx, MPC74xx ................................................................................

PPC600 Family Debugger ....................................................................................................

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

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

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

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

Problems with Memory Access

PowerPC 600 Family Specific Implementations .............................................................

SW-BP Handling for MPC8200, PPC603, PPC700

Breakpoints in Interrupt Handlers

Breakpoints on Physical or Virtual Addresses

Examples for Breakpoints

On-chip Program Address Breakpoints

On-chip Data Address Breakpoints

PPC600 Family Debugger

Access Classes to Memory and Memory Mapped Resources

Access Classes to Other Addressable Core and Peripheral Resources

Little Endian Operation

General System Commands .............................................................................................

Set JTAG frequency

Select the CPU type

Run-time memory access (intrusive)

Lock and tristate the debug port

Real-time memory access (non-intrusive)

Select operation mode

Configure debugger according to target topology

Assign core to TRACE32 instance

CPU specific System Commands ....................................................................................

Set base address for on-chip peripherals

Use 32-Bit data-bus mode

Select RCW configuration

Read from data cache

Implicitly use run-time memory access

Freeze timebase when core halted

Compare PC to hook address

Override HRCW on SYStem.UP

Invalidate instruction cache before go/step

Read from instruction cache

Disable interrupts while single stepping

Disable interrupts while HLL single stepping

Set MSR_IP value for breakpoints / sys.up

True little endian mode

Enable memory access safeguard

Configure memory access timing

Enable multiple address spaces support

Disable JTAG stop on debug events

Use alternative software breakpoint instruction

Enable overlay support

Generate parity on memory access

Program interrupt debugging

PPC little endian mode

Evaluate PTE table for address translation

Select reset mode for SYStem.Up

PPC600 Family Debugger

Relaxed reset timing

Use alternative method for ASM single step

Leave software watchdog enabled

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

Page wise display of MMU translation table

Compact display of MMU translation table