You are on page 1of 81

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

Software Breakpoints

34

On-chip Program Address Breakpoints

34

On-chip Data Address Breakpoints

34

Access Classes

35
1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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
1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

PPC600 Family Debugger


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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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"

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

14

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.

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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"

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

17

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.

MGT5100/
MPC5200
Instruction/
Data Address
Breakpoints do
not work
MPC5100/5200
Error Message:
"emulation pod
configuration
error"

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.
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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

18

Troubleshooting

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

19

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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)

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

Error message "emulation pod configuration error" after starting the T32
ICD software

Error Message:
"emulation pod
configuration
error"

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.

MPC82XX/
83XX
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.
1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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
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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

29

PowerPC 600 Family Specific Implementations

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

30

PowerPC 600 Family Specific Implementations

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

31

PowerPC 600 Family Specific Implementations

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

32

PowerPC 600 Family Specific Implementations

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

33

PowerPC 600 Family Specific Implementations

Examples for Breakpoints


Software 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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

34

PowerPC 600 Family Specific Implementations

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

35

PowerPC 600 Family Specific Implementations

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

36

PowerPC 600 Family Specific Implementations

(*) 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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

37

PowerPC 600 Family Specific Implementations

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

38

PowerPC 600 Family Specific Implementations

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

39

General System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

40

General System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

41

General System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

42

General System Commands

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

43

General System Commands

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

44

General System Commands

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

45

General System Commands

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

46

General System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

47

General System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

48

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

49

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

50

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

51

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

52

CPU specific System Commands

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.


1989-2016 Lauterbach GmbH

PPC600 Family Debugger

53

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

54

CPU specific System Commands

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

55

CPU specific System Commands

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).

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

56

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

57

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

58

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

59

CPU specific System Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

60

CPU specific System Commands

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>.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

61

CPU specific MMU Commands

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
TaskPageTable <task>

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

62

CPU specific MMU Commands

KernelPageTable

List 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 lists its address translation.

TaskPageTable

List the MMU translation 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 lists its address translation.
See also the appropriate OS awareness manuals: RTOS Debugger for
<x>.

MMU.SCAN

Load MMU table from CPU

Format:

MMU.SCAN <table> [<range> <address>]


MMU.<table>.SCAN (deprecated)

<table>:

PageTable
KernelPageTable
TaskPageTable <task>
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.


If specified with the MMU.FORMAT command, this command reads the
table of the kernel and copies its address translation into the debugger
internal translation table.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

63

CPU specific MMU Commands

TaskPageTable

Load the MMU address translation 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 copies its address translation into the debugger internal translation
table.
See also the appropriate OS awareness manuals: RTOS Debugger for
<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.
See also the appropriate OS awareness manuals: RTOS Debugger for
<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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

64

CPU specific MMU Commands

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

65

CPU specific MMU Commands

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

67

CPU specific TrOnchip Commands

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
Break.Set 0x1001--0x17ff /Write

; sets breakpoint at range


; 1000--17ff sets single breakpoint
; at address 1001

TrOnchip.CONVert OFF
Break.Set 0x1000--0x17ff /Write
Break.Set 0x1001--0x17ff /Write

; 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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

68

CPU specific TrOnchip Commands

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

Obsolete command. Refer to the Break.Set command to set trace filters.

TrOnchip.TON

Format:

Switch the sampling to the trace to ON

TrOnchip.TON EXT | Break

Obsolete command. Refer to the Break.Set command to set trace filters.

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.

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

69

CPU specific TrOnchip Commands

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

77

Support

Products

Product Information
OrderNo Code

Text

LA-7721

JTAG Debugger for PPC603/MPC74x/75x (ICD)

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

JTAG Debugger Extension for PPC603(ICD)

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

JTAG Debugger for MPC74xx (ICD)

DEBUG-PPC74XX

supports (1.8V - 5.0V) MPC7410


includes software for Windows, Linux and MacOSX
requires PowerDebug Module
debug cable with 16 pin connector

LA-7719X

JTAG Debugger Extension for MPC74xx (ICD)

DEBUG-PPC74XX-X

supports MPC74XX
requires a valid software guaranty or a valid
software maintenance key
not suitable for debug cables older than 02/2004
(blue ribbon cable)
please add the serial number of the base debug
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

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

78

Products

OrderNo Code

Text

LA-7734

JTAG Debugger for MPC5200/MPC512x (ICD)

JTAG-MPC5200

supports (1.8V - 5.0V) MGT5100, MPC512x, MPC5200


includes software for Windows, Linux and MacOSX
requires Power Debug Module
debug cable with 16 pin connector

LA-7734X

JTAG Debugger Extension for MPC5200/MPC512x

JTAG-MPC5200-X

supports MGT5100, MPC5200, MPC512x


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-7729

JTAG Debugger for MPC82xx/MPC83xx(ICD)

DEBUG-MPC8260

supports (1.8V - 5.0V) MPC82xx, MPC83xx,


includes software for Windows, Linux and MacOSX
requires Power Debug Module
debug cable with 16 pin connector

LA-7729X

JTAG Debugger Extension for MPC8260/MPC8240

DEBUG-MPC8260-X

supports (1.8V - 5.0V) MPC82xx, MPC83xx,


(whisker version of the debug cable)
requires a valid software guaranty or a valid
software maintenance key
please add the serial number of the base debug
cable to your order

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

79

Products

Order Information

Order No.

Code

Text

LA-7721
LA-7721X

DEBUG-PPC603
DEBUG-PPC603-X

JTAG Debugger for PPC603/MPC74x/75x (ICD)


JTAG Debugger Extension for PPC603(ICD)

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-3794X DEBUG-QORIQ64-X
LA-7734X JTAG-MPC5200-X
LA-7960X MULTICORE-LICENSE

JTAG Debugger Extension for MPC8260/MPC8240


JTAG Debugger Extension for MPC86xx
JTAG Debugger Extension for MPC74xx (ICD)
JTAG Debugger Ext. for MPC85XX/QorIQ e500
JTAG Debugger Extension for QorIQ 32 Bit
JTAG Debugger Extension for QorIQ 64 Bit
JTAG Debugger Extension for MPC5200/MPC512x
License for Multicore Debugging

Order No.

Code

Text

LA-7719
LA-7719X
LA-7719U

DEBUG-PPC74XX
DEBUG-PPC74XX-X
DEBUG-PPC74XX-UPG

JTAG Debugger for MPC74xx (ICD)


JTAG Debugger Extension for MPC74xx (ICD)
Hardware Upgrade JTAG Debugger PPC74XX

Additional Options
LA-7729X DEBUG-MPC8260-X
LA-3735X DEBUG-MPC86XX-X
LA-7721X DEBUG-PPC603-X
LA-3796X DEBUG-PQ3-X
LA-3795X DEBUG-QORIQ32-X
LA-3794X DEBUG-QORIQ64-X
LA-7734X JTAG-MPC5200-X
LA-7960X MULTICORE-LICENSE

JTAG Debugger Extension for MPC8260/MPC8240


JTAG Debugger Extension for MPC86xx
JTAG Debugger Extension for PPC603(ICD)
JTAG Debugger Ext. for MPC85XX/QorIQ e500
JTAG Debugger Extension for QorIQ 32 Bit
JTAG Debugger Extension for QorIQ 64 Bit
JTAG Debugger Extension for MPC5200/MPC512x
License for Multicore Debugging

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

80

Products

Order No.

Code

Text

LA-7734
LA-7734X

JTAG-MPC5200
JTAG-MPC5200-X

JTAG Debugger for MPC5200/MPC512x (ICD)


JTAG Debugger Extension for MPC5200/MPC512x

Additional Options
LA-7729X DEBUG-MPC8260-X
LA-3735X DEBUG-MPC86XX-X
LA-7721X DEBUG-PPC603-X
LA-7719X DEBUG-PPC74XX-X
LA-3796X DEBUG-PQ3-X
LA-3795X DEBUG-QORIQ32-X
LA-3794X DEBUG-QORIQ64-X

JTAG Debugger Extension for MPC8260/MPC8240


JTAG Debugger Extension for MPC86xx
JTAG Debugger Extension for PPC603(ICD)
JTAG Debugger Extension for MPC74xx (ICD)
JTAG Debugger Ext. for MPC85XX/QorIQ e500
JTAG Debugger Extension for QorIQ 32 Bit
JTAG Debugger Extension for QorIQ 64 Bit

Order No.

Code

Text

LA-7729
LA-7729X

DEBUG-MPC8260
DEBUG-MPC8260-X

JTAG Debugger for MPC82xx/MPC83xx(ICD)


JTAG Debugger Extension for MPC8260/MPC8240

Additional Options
LA-3735X DEBUG-MPC86XX-X
LA-7721X DEBUG-PPC603-X
LA-7719X DEBUG-PPC74XX-X
LA-3796X DEBUG-PQ3-X
LA-3795X DEBUG-QORIQ32-X
LA-3794X DEBUG-QORIQ64-X
LA-7734X JTAG-MPC5200-X

JTAG Debugger Extension for MPC86xx


JTAG Debugger Extension for PPC603(ICD)
JTAG Debugger Extension for MPC74xx (ICD)
JTAG Debugger Ext. for MPC85XX/QorIQ e500
JTAG Debugger Extension for QorIQ 32 Bit
JTAG Debugger Extension for QorIQ 64 Bit
JTAG Debugger Extension for MPC5200/MPC512x

1989-2016 Lauterbach GmbH

PPC600 Family Debugger

81

Products