Lauterbach TRACE32-ICD User manual

PQIII Debugger 1
©1989-2020 Lauterbach GmbH
PQIII Debugger
TRACE32 Online Help
TRACE32 Directory
TRACE32 Index
TRACE32 Documents ...................................................................................................................... 
ICD In-Circuit Debugger ................................................................................................................ 
Processor Architecture Manuals .............................................................................................. 
PQIII .......................................................................................................................................... 
PQIII Debugger ..................................................................................................................... 1
Introduction ....................................................................................................................... 4
Brief Overview of Documents for New Users 4
Warning .............................................................................................................................. 5
Target Design Requirement/Recommendations ............................................................ 6
General 6
Quick Start ......................................................................................................................... 7
Troubleshooting ................................................................................................................ 8
SYStem.Up Errors 8
FAQ ..................................................................................................................................... 9
Configuration ..................................................................................................................... 10
System Overview 10
PowerPC MPC85XX specific Implementations ............................................................... 11
Breakpoints 11
Software Breakpoints 11
On-chip Breakpoints 11
Breakpoints on Program Addresses 12
Breakpoints on Data Addresses 12
Breakpoints on Data Access at Program Address 13
Breakpoints on Data Value 13
Access Classes 15
Access Classes to Memory and Memory Mapped Resources 15
Access Classes to Other Addressable Core and Peripheral Resources 16
Memory Classes 17
Cache 18
Memory Coherency 18
MESI States 19
Debugging Information 20

PQIII Debugger 2
©1989-2020 Lauterbach GmbH
Setting-up the Debug Interrupt for MPC85XX 20
Multicore Debugging e500 Cores 21
SMP Debugging 21
AMP Debugging 21
Synchronous stop of both e500 cores
Programming Flash on MPC85XX / QorIQ P10XX/P20XX, PSC93XX 22
On-chip Trace on MPC85XX/QorIQ 22
General SYStem Commands ............................................................................................ 24
SYStem.BdmClock Set BDM clock frequency 24
SYStem.CONFIG.state Display target configuration 24
SYStem.CONFIG Configure multi-core debugger 26
Example 27
SYStem.CONFIG.CHKSTPIN Control pin 8 of debug connector 28
SYStem.CONFIG.DriverStrength Configure driver strength of TCK pin 29
SYStem.CONFIG.QACK Control QACK pin 29
SYStem.CPU Select the CPU type 30
SYStem.CpuAccess Run-time CPU access (intrusive) 31
SYStem.LOCK Lock and tristate the debug port 31
SYStem.MemAccess Run-time memory access (non-intrusive) 32
SYStem.Mode Select operation mode 33
CPU specific SYStem Commands ...................................................................................34
SYStem.Option.CINTDebug Enable debugging of critical interrupts 34
SYStem.Option CoreStandBy On-the-fly breakpoint setup 34
SYStem.Option DCFREEZE Prevent data cache line load/flush in debug mode 34
SYStem.Option DCREAD Read from data cache 35
SYStem.Option DUALPORT Implicitly use run-time memory access 35
SYStem.Option FREEZE Freeze system timers on debug events 36
SYStem.Option HOOK Compare PC to hook address 36
SYStem.Option ICFLUSH Invalidate instruction cache before go/step 36
SYStem.Option ICREAD Read from instruction cache 37
SYStem.Option IMASKASM Disable interrupts while single stepping 37
SYStem.Option IMASKHLL Disable interrupts while HLL single stepping 37
SYStem.Option MMUSPACES Enable multiple address spaces support 38
SYStem.Option.NoDebugStop Disable JTAG stop on debug events 38
: SYStem.Option OVERLAY Enable overlay support 39
SYStem.Option.PERSTOP Stop on-chip peripherals in debug mode 39
SYStem.Option RESetBehavior Set behavior when target reset detected 40
SYStem.Option.STEPSOFT Use alternative method for ASM single step 40
SYStem.Option.SLOWRESET Relaxed reset timing 40
CPU specific MMU Commands ........................................................................................ 42
MMU.DUMP Page wise display of MMU translation table 42
MMU.List Compact display of MMU translation table 44

PQIII Debugger 3
©1989-2020 Lauterbach GmbH
MMU.SCAN Load MMU table from CPU 45
MMU.Set Set a MMU TLB entry 46
CPU specific TrOnchip Commands .................................................................................47
TrOnchip.CONVert Adjust range breakpoint in on-chip resource 47
TrOnchip.RESet Reset on-chip trigger settings 47
TrOnchip.Set Enable on-chip trigger facilities 48
TrOnchip.VarCONVert Adjust HLL breakpoint in on-chip resource 49
TrOnchip.view View on-chip trigger setup window 50
MPC85XX specific Onchip Trace Settings ...................................................................... 51
Onchip.Mode.IFSel Select interface to be traced 51
CPU specific TrBus Commands ...................................................................................... 52
TrBus.Out Define source for the external trigger pulse 52
TrBus.Set Define the target for the incoming trigger 52
JTAG Connector ................................................................................................................ 53
Mechanical Description 53
JTAG Connector MPC85XX (COP) 53

PQIII Debugger 4
©1989-2020 Lauterbach GmbH
PQIII Debugger
Version 19-Oct-2020
Introduction
This document describes the processor specific settings and features of TRACE32-ICD for the following
CPU families:
• Freescale PowerQuicc III Series MPC85XX
• Freescale QorIQ P101x, P102x, P2010, P2020
• Freescale Qonverge PSC91XX, PSC92XX series
Please keep in mind that only the Processor Architecture Manual (the document you are reading at the
moment) is CPU specific, while all other parts of the online help are generic for all CPUs supported by
Lauterbach. So if there are questions related to the CPU, the Processor Architecture Manual should be your
first choice.
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.
•“OS Awareness Manuals” (rtos_<os>.pdf): TRACE32 PowerView can be extended for operating
system-aware debugging. The appropriate OS Awareness manual informs you how to enable the
OS-aware debugging.

PQIII Debugger 5
©1989-2020 Lauterbach GmbH
Warning
Signal Level
ESD Protection
NOTE: The debugger drives the output pins of the BDM/JTAG/COP connector with the
same level as detected on the VCCS pin. If the debug/trace I/O pins of the
processor are operating at e.g. 3.3 V, then VCCS should be connected to 3.3 V as
well.
See also System.up Errors.
WARNING: To prevent debugger and target from damage it is recommended to connect or
disconnect the debug cable only while the target power is OFF.
Recommendation for the software start:
1. Disconnect the debug cable from the target while the target power is
off.
2. Connect the host system, the TRACE32 hardware and the debug
cable.
3. Power ON the TRACE32 hardware.
4. Start the TRACE32 software to load the debugger firmware.
5. Connect the debug cable to the target.
6. Switch the target power ON.
7. Configure your debugger e.g. via a start-up script.
Power down:
1. Switch off the target power.
2. Disconnect the debug cable from the target.
3. Close the TRACE32 software.
4. Power OFF the TRACE32 hardware.

PQIII Debugger 6
©1989-2020 Lauterbach GmbH
Target Design Requirement/Recommendations
General
• Locate the BDM/JTAG/COP connector as close as possible to the processor to minimize the
capacitive influence of the trace length and cross coupling of noise onto the JTAG signals. Don’t
put any capacitors (or RC combinations) on the JTAG lines.
• Connect TDI, TDO, TMS and TCK directly to the CPU. Buffers on the JTAG lines will add delays
and will reduce the maximum possible JTAG frequency. If you need to use buffers, select ones
with little delay. Most CPUs will support JTAG above 30 MHz, and you might want to use high
frequencies for optimized download performance.
• Ensure that JTAG HRESET is connected directly to the HRESET of the processor. This will
provide the ability for the debugger to drive and sense the status of HRESET
. The target design
should only drive HRESET with open collector/open drain.
• For optimal operation, the debugger should be able to reset the target board completely
(processor external peripherals, e.g. memory controllers) with HRESET
.
• In order to start debugging right from reset, the debugger must be able to control CPU HRESET
and CPU TRST independently. There are board design recommendations to tie CPU TRST to
CPU HRESET, but this recommendation is not suitable for JTAG debuggers.
.
Debug cable
with blue
ribbon cable
The T32 internal buffer/level shifter will be supplied via the VCCS pin.
Therefore it is necessary to reduce the VCCS pull-up on the target board
to a value smaller 10 .

PQIII Debugger 7
©1989-2020 Lauterbach GmbH
Quick Start
Starting up the Debugger is done as follows:
5. Select the CPU to load the CPU specific settings. SYStem.DETECT CPU can set the appropriate
CPU automatically.
6. Specify that on-chip breakpoints should be used by the debugger, e.g. for program in FLASH.
7. Reset processor and enter debug mode
The core is now stopped at the reset address.
8. After SYStem.Up, only the boot page is visible for the CPU. Initialize MMU TLBs to configure
which memory is visible to the CPU at which address. See MMU.Set for details.
9. This step prepares the target memory for program loading. To configure the CPU for the access
to all memories either run the initialization code on your target or configure the CPU by using the
Data.Set command. For complete example scripts, see ~~/demo/powerpc/hardware.
10. Load the program.
The option of the Data.LOAD command depends on the file format generated by the compiler. A detailed
description of the Data.LOAD command is given in the “General Commands Reference”.
SYStem.CPU MPC85XX
SYStem.DETECT CPU
MAP.BOnchip 0xFF800000--0xFFFFFFFF
SYStem.Up
; set up TLB entry starting from address 0 for SDRAM
MMU.Set TLB1 1. 0x80000600 0x00000000 0x0000003f
; set CCSR base address to 0xE0000000
Data.Set ANC:iobase() %LONG 0x000E0000
; local access window
Data.Set ANC:iobase()+0x0C08 %long 0x00000000
Data.Set ANC:iobase()+0x0C10 %long 0x80F0001C
...
Data.LOAD.ELF demo.elf (ELF specifies the format,
demo.elf is the file name)

PQIII Debugger 8
©1989-2020 Lauterbach GmbH
Troubleshooting
SYStem.Up Errors
The SYStem.Up command is the first command of a debug session where communication with the target is
required. If you receive error messages while executing this command, there can be several reasons. The
Following chapters list possible errors and explains how to fix them.
Target Power Fail
The target has no power, the debug cable is not connected or not connected properly. Check if the
JTAG VCC pin is driven by the target. The voltage of the pin must be identical to the debug voltage of
the JTAG signals. It is recommended to connect VCC directly to the pin, or via a resistor < 5 kOhm.
Emulation Pod Configuration Error
The debugger was not able to identify the connected processor. There are two possible reasons for this
error. In both cases, please check the AREA window for more information:
• The connected processor is not supported by the used software. Please check if the processor is
supported by the debugger. Processors that appeared later than the debugger software version
are usually not supported. Please download and install the latest software from our homepage,
or contact technical support to get a newer software. Please also check if the processor or the
software update is covered by your current licence.
• A JTAG communication error prevented correct determination of the connected processor.
Please check if the debugger is properly connected to the target.
Target Reset Fail
On SYStem.Up, the debugger will assert HReset in order to stop the CPU at the reset address. A target
reset fail means, that an unexpected reset behavior caused an error:
• The reset is asserted longer than 500ms and is not visible on the JTAG connector. Try
SYStem.Option.SLOWRESET, and check signal level of the JTAG HRESET pin.
• The target reset is permanently asserted. Check target reset circuitry and reset pull-up
• A chip external watchdog caused a reset after the debugger asserted reset. Disable the
watchdog and try again.

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

PQIII Debugger 1 0
©1989-2020 Lauterbach GmbH
Configuration
System Overview
PODBUS Cable
PODPC
PODPAR Debug EPROM
PODETH Interface Simulator ...
(optional)
Debug Cable

CPU CLK RESET
INT
Target Connector (600
EPROM only)

Target TS4 (400 only)
Basic configuration for the BDM Interface

PQIII Debugger 1 1
©1989-2020 Lauterbach GmbH
PowerPC MPC85XX specific Implementations
Breakpoints
There are two types of breakpoints available: Software breakpoints and on-chip breakpoints.
Software Breakpoints
To set a software breakpoint, before resuming the CPU, the debugger replaces the instruction at the
breakpoint address with a TRAP instruction.
On-chip Breakpoints
To set breakpoints on code in read-only memory, only the on-chip instruction address breakpoints are
available. With the command MAP.BOnchip <range> it is possible to declare memory address ranges for
use with on-chip breakpoints to the debugger. The number of breakpoints is then limited by the number of
available on-chip instruction address breakpoints.
•On-chip breakpoints: Total amount of available on-chip breakpoints.
•Instruction address breakpoints: Number of on-chip breakpoints that can be used to set
Program breakpoints into ROM/FLASH/EEPROM.
•Data address breakpoints: Number of on-chip breakpoints that can be used as Read or Write
breakpoints.
•Data value breakpoint: Number of on-chip data value breakpoints that can be used to stop the
program when a specific data value is written to an address or when a specific data value is read
from an address
You can check your currently set breakpoints with the command Break.List.
If no more on-chip breakpoints are available you will get an error message on trying to set a new on-chip
breakpoint.
Processor On-chip
Breakpoints
Instruction
Address
Breakpoints
Data Address
Breakpoints
Data Value
Breakpoints
MPC85XX
P10xx
P20xx
P40xx
4 Instruction
2 Read/Write
2 single
breakpoints
-- or --
1 breakpoint
ranges
2 single
breakpoints
-- or --
1 breakpoint
range
none

PQIII Debugger 1 2
©1989-2020 Lauterbach GmbH
Breakpoints on Program Addresses
The debugger sets software and on-chip breakpoints to the effective address. If a breakpoint is set on a
program address, the debugger will first try to set a software breakpoint. If writing the software breakpoint
fails (translation error or bus error), then an on-chip breakpoint will be set instead. If a memory range must
not be written by the debugger, it can be declared for on-chip breakpoint usage using MAP.BOnchip.
Alternatively, it is also possible to force a single breakpoint to on-chip using the command Break.Setwith
option /Onchip:
Two on-chip address breakpoints can be combined to an address range:
Breakpoints can be configured to stop if the break event occured a given number of times.
Breakpoints on Data Addresses
Data address breakpoints cause a debug event when a certain address or address range is read or written
by the core. A data address breakpoint to a single address has a granularity of 1 byte.
Equal to program address breakpoints, data address breakpoints can be configured to stop if the break
event occurred a given number of times:
Data address breakpoint limitations:
Map.BOnchip 0xFFFC0000--0xFFFFFFFF ;use on-chip breakpoints in FLASH
Break.Set 0xFFFFF064 ;debugger sets on-chip breakpoint
Break.Set my_func1 ;debugger sets on-chip or sw breakp.
Break.Set my_func1 /Onchip ;debugger sets on-chip breakpoint
Break.Set 0x00000000--0x00002000 /Onchip
Break.Set IVOR0_Handler--IVOR15_Handler /Onchip
;stop on the 20th call of function foo
Break.Set foo /Onchip /COUNT 20.
Break.Set 0xC3F80004 /Read ;break when core reads from 0xC3F80004
Break.Set 0xC3F80004 /Write ;break when core writes to 0xC3F80004
Break.Set 0xC3F80004 /ReadWrite ;break on read or write access
Break.Set 0xC3F80000--0xC3F80023 /Write ;break address range
Var.Break.Set counter /Write ;break on variable write access
;stop on the 8th write to arrayindex
Break.Set arrayindex /Write /COUNT 20.

PQIII Debugger 1 3
©1989-2020 Lauterbach GmbH
1. The source of the data access (read and/or write) must be the CPU, as the data address break-
points are part of the CPU. Any other accesses from on-chip or off-chip peripherals (DMA etc.)
will not be recognized by the data address breakpoints.
2. The data being targeted must be qualified by an address in memory. It is not possible to set a
data address breakpoint to GPR, SPR etc.
Breakpoints on Data Access at Program Address
A normal data access breakpoint as described above hits on all data accesses to the memory address or
address range, independent of the program address which caused the access. It is also possible to set a
data address breakpoint which only hits if the access is performed from a specified program address. The
specified program address must be a load or store instruction.
The program address can also be an address range or a range of debug symbols:
Breakpoints on Data Value
The e500 core does not support onchip breakpoints on data values, but TRACE32 supports them by
software emulation. When a data value breakpoint is set, the debugger will use one of the data address
breakpoint s. When the core hits that breakpoint, the target application will stop and the debugger will
evaluate if the data value matches. If the value matches, the debugger will stop execution, if it does not
match, the debugger will restart the application. Using software emulated data value breakpoints will cause
the target application to slow down.
;Break if the instruction at address 0x40001148 reads from variable count
Break.Set 0x40001148 /MemoryRead count
;Break if the instruction at address 0x40001148 writes to range
Break.Set 0x40001148 /MemoryWrite 0xFFFFF000--0xFFFFFFFF
;Break on all accesses to countfrom code of the address range
Break.Set 0x40000100--0x400001ff /MemoryReadWrite count
;Break if variable nMyIntVaris written by an interrupt handler
;(debug symbols IVORxx_Handler loaded from debug symbols)
Break.Set IVOR0_Handler--IVOR15_Handler /MemoryWrite nMyIntVar
;Break if variable nTestValueis written within function test_func
Break.Set sYmbol.RANGE(test_func) /MemoryWrite nTestValue
;Break if variable nTestValueis written outside of test_func
Break.Set sYmbol.RANGE(test_func) /EXclude /MemoryWrite nTestValue

PQIII Debugger 1 4
©1989-2020 Lauterbach GmbH
Examples for setting data value breakpoints:
;Break when the value 0x1233 is written to the 16-bit word at 0x40000200
Break.Set 0x40000200 /Write /Data.Word 0x1233
;Break when a value not equal 0x98 is written to the 8-bit variable xval
Break.Set xval /Write /Data.Byte !0x98
;Break when decimal 32-bit value 4000 is written
;to variable countwithin function foo
Break.Set sYmbol.RANGE(foo) /MemoryWrite count /Data.Long 4000.

PQIII Debugger 1 5
©1989-2020 Lauterbach GmbH
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:
Access Classes to Memory and Memory Mapped Resources
The following memory access classes are available:
In addition to the access classes, there are access class attributes: Examples:
Command: Effect:
Data.List P:0x1000 Opens a List window displaying program memory
Data.dump D:0xFF800000 /LONG Opens a DUMP window at data address 0xFF800000
SPR:415. %Long 0x00003300 Write value 0x00003300 to the SPR IVOR15
PRINT Data.Long(ANC:0xFFF00100) Print data value at physical address 0xFFF00100
Access Class Description
P Program (memory as seen by core’s instruction fetch)
F Program, disassembly shows std. PowerPC instructions
V Program, disassembly shows VLE encoded instructions
D Data (memory as seen by core’s data access)
IC L1 Instruction Cache (or L1 Unified cache)
DC L1 Data Cache
L2 L2 Cache
NC No Cache (access with caching inhibited)
Command: Effect:
Data.List SP:0x1000 Opens a List window displaying supervisor program memory
ED:0x3330 0x4F Write 0x4F to address 0x3330 using real-time memory access

PQIII Debugger 1 6
©1989-2020 Lauterbach GmbH
The following access class attributes are available:
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 processor’s
memory address space.
Access Class Attributes Description
E Use real-time memory access
A Given address is physical (bypass MMU)
U TS (translation space) == 1 (user memory)
S TS (translation space) == 0 (supervisor memory)
Access Class Description
SPR Special Purpose Register (SPR) access
PMR Performance Monitor Register (PMR) access

PQIII Debugger 1 7
©1989-2020 Lauterbach GmbH
Memory Classes
To specify which and how target memory is accessed, there are memory classes. A memory class consists
of one or more letters followed by a colon “:”. Memory classes can be applied almost everywhere an address
has to be specified. Here are some examples:
The following memory classes are available:
In addition to the memory classes, there are memory class attributes: Examples:
The following memory class attributes are available:
Memory class attributes can also be used without a memory class, but U: and S: are usually combined with
D: and P: (UD: user data, SD: supervisor data, UP: user program, UD: user data).
Command: Effect:
DATA.LIST P:0x1000 Opens a List window displaying program memory
DATA.SET SPR:415. %Long 0x00223344 Write value 0x00223344 to SPR IVOR15
Memory Class Description
PProgram
F Program, fixed 32 bit instructions
V Program, VLE encoded instructions
DData
SPR Special Purpose Register
IC Instruction Cache
DC Data Cache
NC No Cache (only physical memory)
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
Memory Class Description
E Use real-time memory access
A Given address is physical (bypass MMU)
U TS (translation space) == 1 (user memory)
S TS (translation space) == 0 (supervisor memory)

PQIII Debugger 1 8
©1989-2020 Lauterbach GmbH
Cache
Memory Coherency
The following table describes which memory will be updated depending on the selected memory class:
Memory
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
(*) 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” (ppce.pdf) for details.

PQIII Debugger 1 9
©1989-2020 Lauterbach GmbH
MESI States
The Cache logic of PPC e500 cores is described as MESI states. The debugger however displays the
cache state using valid/dirty/shared flags according to the following table.
State translation table:
MESI state Flag
M (modified) V(alid) && D(irty)
E (exclusive) V(alid) && NOT D(irty)
S (shared) S(hared)
I (invalid) NOT V(alid)

PQIII Debugger 2 0
©1989-2020 Lauterbach GmbH
Debugging Information
Setting-up the Debug Interrupt for MPC85XX
In order to properly use all debug features (breakpoints, single step etc) of the MPC85XX/QorIQ series, the
Debug Interrupt Vector (IVPR+IVOR15) must be set to an address which is
• properly mapped in the MMU (memory management unit) and
• points to an address which contains a valid instruction (NOP is recommended).
Please note that both IVOR/IVPR and memory contents can be changed by the application any time,
especially during the boot process. When debugging is done after the boot process finished, the interrupt
vector and memory is usually properly set up by the application. There are however operating systems that
don’t use the debug interrupt and let it point to an illegal instruction.
For early CPU revisions (PVR=0x8020XXXX) it is recommended to place the instructions NOP followed by
RFCI to the debug interrupt vector. These two instructions are needed for “SYStem.Option FREEZE
Freeze system timers on debug events” (???).
; CORE 1 setup script: ; CORE 2 setup script:
SYStem.CPU 5516 SYStem.CPU 5516
SYStem.CONFIG.CORE 1. 1. SYStem.CONFIG.CORE 2. 1.
SYStem.UP SYStem.Mode.Attach
; do board initialization here ; z0 is still in reset
Data.LOAD.Elf demo.elf Data.LOAD.Elf demo.elf /NoCODE
Break ; with this command
; z0 will stop when
; reset is released
Go ; start z1
; application will start z0
; core
WAIT !RUN() ; wait until cpu stops
Break.Set somez0function
Go