Debugger Microblaze

MicroBlaze Debugger and Real-Time Trace 1
1989-2013 Lauterbach GmbH

MicroBlaze Debugger and Real-Time Trace
TRACE32 Online Help
TRACE32 Directory
TRACE32 Index
TRACE32 Documents ......................................................................................................................
ICD In-Circuit Debugger ................................................................................................................
Processor Architecture Manuals ..............................................................................................
MicroBlaze ...............................................................................................................................
MicroBlaze Debugger and Real-Time Trace ...................................................................... 1
General Note ...................................................................................................................... 5
Brief Overview of Documents for New Users ................................................................. 5
MicroBlaze debug and trace features supported by TRACE32 .................................... 6
ESD Protection .................................................................................................................. 7
Quick Start of the Debugger ............................................................................................. 8
Quick-Start of the Real-Time Trace ................................................................................. 10
Compiling Software with Debug Information ................................................................. 12
Designs with little-endian MicroBlaze and AXI bus ....................................................... 12
Troubleshooting ................................................................................................................ 13
SYStem.Up Errors 13
FAQ ..................................................................................................................................... 14
Displaying MicroBlaze Core Configuration .................................................................... 20
CPU specific Implementations ......................................................................................... 21
Memory Accesses Causing Bus Errors 21
Breakpoints 22
Software Breakpoints 22
On-chip Breakpoints 22
Breakpoints in ROM 22
Example for Breakpoints 23
SYStem.Option.BrkHandler Control writing of software break handler 24
SYStem.Option.BrkVector Configures an alternative breakvector 24
SYStem.Option IMASKASM Interrupt disable on ASM 24
SYStem.Option IMASKHLL Interrupt disable on HLL 25
SYStem.Option MMUSPACES Enable multiple address spaces support 25
SYStem.Option.ResetMode Select the reset mode 25
Data.Load.Elf /CYgdrive Translate Cygwin path to OS path 26
TERM.Method MDMUART Terminal configuration 26
Memory Classes 26
Register Names 27
General SYStem Commands ............................................................................................ 28
SYStem.CPU Select the used CPU 28
SYStem.CpuAccess Run-time memory access (intrusive) 29
SYStem.JtagClock Selects the frequency for the debug interface 30
SYStem.LOCK Lock and tristate the debug port 30
SYStem.MemAccess Run-time memory access 30
SYStem.Mode Select operation mode 31
SYStem.CONFIG Configure multi-core debugger 32
Daisy-chain Example 34
TapStates 35
SYStem.CONFIG.Core Map system topology to debugger topology model 36
TrOnchip Commands ........................................................................................................ 37
TrOnchip.view Display on-chip trigger window 37
TrOnchip.RESet Set on-chip trigger to default state 37
TrOnchip.CONVert Adjust range breakpoint in on-chip resource 38
TrOnchip.VarCONVert Adjust complex breakpoint in on-chip resource 38
TrBus Commands ............................................................................................................. 39
TrBus.Out Define source for the external trigger pulse 39
TrBus.Set Define the target for the incoming trigger 39
CPU specific MMU Commands ........................................................................................ 40
MMU.DUMP Display MMU table 40
MMU.List Display MMU table 41
MMU.SCAN Load MMU table from CPU 42
Real-Time Trace ................................................................................................................. 43
SYStem.Option.DTM Control data trace messages 43
SYStem.Option.QUICKSTOP Control trace of software breakpoints 43
SYStem.Option.UserBSCAN Set default user bscan port 44
Configuring your FPGA .................................................................................................... 45
JTAG Connector ................................................................................................................ 46
Mechanical Description 46
JTAG Connector for Xilinx Microblaze 46
Support ............................................................................................................................... 47
Available Tools 47
Compilers 47
Realtime Operation System 47
3rd Party Tool Integrations 48
Products ............................................................................................................................. 49
Product Information 49
Order Information 49
MicroBlaze Debugger and Real-Time Trace
Version June, 11 2013
B::Data.List
addr/line code label mnemonic comment
P:FFF021C0 39400000 li r10,0
P:FFF021C4 915F0018 stw r10,18(r31)
567 for ( i = 0 ; i <= SIZE ; flags[ i++ ] = TRUE ) ;
P:FFF021C8 39200000 li r9,0 ; i,0
P:FFF021CC 2C890012 cmpwi cr1,r9,12 ; cr1,i,18
P:FFF021D0 40850008 ble cr1,0FFF021D8
P:FFF021D4 4800001C b 0FFF021F0
B::Register B::PER
R0 0 R8 0 EXISR 80000000 CIS pending SRIS wait S
R1 0FFFFFFD8 R9 0 D0IS wait D1IS wait D
R2 0 R10 0 E0IS wait E1IS wait E
R3 0 R11 0
R4 0 R12 0 Input Output Configuration
R5 0 R13 0 IOCR 00000000 E0T level E1T level E2T le
R6 0 R14 0 E0L negative E1L negative
R7 0 R15 0 RDM disabled TCS sysclk S
SPRG0 0 SRR0 0
SPRG1 0 SRR1 0 Bank 0
SPRG2 0 SRR2 0 BR0 FF183FFE BAS 0FF00000 BS 1MB BU rea
MicroBlaze Debugger and Real-Time Trace 5 General Note
General Note
Before starting please be sure to have up to date debugger software by getting an update from the
LAUTERBACH website. Note that the downloads on the website are stable releases but not necessarily the
latest versions. Therefore in case of problems please contact LAUTERBACH support at admicroblaze-
[email protected] for getting the latest software update.
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 system-
aware debugging. The appropriate RTOS manual informs you how to enable the OS-aware
debugging.
Please note that multicore configuration will be required in most cases, even when there is only a single
Microblaze processor in the target. For information about setting up multicore-configuration see the
application note Connecting to MicroBlaze Targets for Debug and Trace (app_microblaze.pdf).
MicroBlaze Debugger and Real-Time Trace 6 MicroBlaze debug and trace features supported
MicroBlaze debug and trace features supported by TRACE32
TRACE32 for MicroBlaze supports the following features:
Basic debugging (stop, go, software breakpoints, ...).
Debugging Linux kernel code and user applications.
MMU translation.
Onchip breakpoints (program breakpoints, data write and read breakpoints).
Program and data trace are supported via the Xilinx MicroBlaze Trace Core (XMTC) IP. The
XMTCs trigger features are currently not supported.
NOTE: As onchip breakpoints require additional FPGA resources and may slow down
the maximum frequency of a MicroBlaze desig, it is necessary to explicitly
configure them in the FPGA design.
NOTE: XMTC is officially supported and tested by Xilinx until EDK12.4 and thus up to
MicroBlaze V7.30.a.
MicroBlaze Debugger and Real-Time Trace 7 ESD Protection
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:
Disconnect the debug cable from the target while the target power is off.
Connect the host system, the TRACE32 hardware and the debug cable.
Power ON the TRACE32 hardware.
Start the TRACE32 software to load the debugger firmware.
Connect the debug cable to the target.
Switch the target power ON.
Configure your debugger e.g. via a start-up script.
Power down:
Switch off the target power.
Disconnect the debug cable from the target.
Power OFF the TRACE32 hardware.
MicroBlaze Debugger and Real-Time Trace 8 Quick Start of the Debugger
Quick Start of the Debugger
For getting started with debugging, the installation CD contains sample bit streams and scripts for ML310,
ML403, Spartan3EStarter, Spartan3ADSP1800Starter boards. You find them on the CD at
<InstallCD>files/demo/microblaze/hardware
The following example uses ML403. Configure the target with the bit stream
<InstallCD>/files/demo/microblaze/hardware/mb.v700a/download.bit
The FPGA configuration can be done using Xilinx iMPACT or the TRACE32 command JTAG.LOADBIT.
After starting the TRACE32 software enter the following commands for connecting to the target and load a
sample file:
1. Select the first (and usually only) MicroBlaze core:
2. Configure multicore settings for telling the debugger where the MicroBlaze core is located in the
JTAG scan chain. For Xilinx EVB ML403 use the following settings:.
3. Attach to the target and enter debug mode, using the multicore settings from above:
This command resets the CPU and enters debug mode. After executing this command, memory and
registers can be accessed.
Multicore configuration will be required in most cases, even when there is only a
single Microblaze processor in the target. For information about setting up
multicore-configuration see the application note Connecting to MicroBlaze
Targets for Debug and Trace (app_microblaze.pdf).
SYStem.CPU MICROBLAZE0
sys.mc irpost 28.
sys.mc irpre 8.
sys.mc drpost 2.
sys.mc drpre 1.
Note the . indicating
decimal numbers.
SYStem.Up
MicroBlaze Debugger and Real-Time Trace 9 Quick Start of the Debugger
4. Load a sample program..
Note the option /CYGDRIVE. As the Xilinx MicroBlaze compiler is executed within a Cygwin
environment it creates debug symbols with paths beginning with \cygdrive\c\. By using the
option /CYGDRIVE TRACE32 internally converts this prefix to the correct syntax e.g. to c:\ on
windows hosts.
5. Open the disassembly and register windows:
6. You are now ready to debug your program.
cd files/demo/microblaze/hardware/ml403
Data.LOAD.Elf Sieve_24000000.elf /CYGDRIVE
Data.List ; Open disassembly window
Register ; Open register window
MicroBlaze Debugger and Real-Time Trace 10 Quick-Start of the Real-Time Trace
Quick-Start of the Real-Time Trace
The trace probe connects to a matched impedance connector (mictor) on the target, either directly or via
an adaptor. For details on connectors available from LAUTERBACH see the application note Connecting
to MicroBlaze Targets for Debug and Trace (app_microblaze.pdf)
The following example uses ML403, together with the trace connector LA-3804. The sample script and the
bit stream are found on the installation CD under
files/demo/microblaze/hardware/ml403/mb.v700b.xmtc/
Configure the target with the bit stream download.bit, start the debugger and execute the script below
(demo.mb.v700b.cmm). The individual commands are explained in the following.
Select CPU and make multicore settings, specific for ML403:
If the debug interface has a trace probe (analyzer), we configure it for FIFO mode (oldest trace data is
overwritten by new data), for keeping trace data between break/continue operations, enable data trace
messages (DTM) and optimize the handling of software breaks. Finally we open windows for manual
analyzer configuration and for displaying the collected trace data:
NOTE: The Xilinx MicroBlaze Trace Core IP (XMTC) is supported and tested by Xilinx only
until EDK12. In later EDK versions XMTC support was dropped. For the time being,
MicroBlaze V7.30.a is the last version with trace support.
sys.cpu microblaze0
sys.mc irpost 28.
sys.mc irpre 8.
sys.mc drpost 2.
sys.mc drpre 1.
; XILINX EVB ML403
if analyzer()
(
analzyer.mode.fifo
analyzer.autoinit off
sys.o.dtm on
sys.o.quickstop on
analyzer
analyzer.list
)
MicroBlaze Debugger and Real-Time Trace 11 Quick-Start of the Real-Time Trace
Now we connect to the target, load the demo application and run it up to the function sieve():
You can now debug your application and observe the traced instruction stream in the analyzer.list
window.
sys.up
data.load.elf mb.v700b.xmtc/sieve/sieve_8c000000.elf /cygdrive
go sieve
data.list
MicroBlaze Debugger and Real-Time Trace 12 Compiling Software with Debug Information
Compiling Software with Debug Information
For debugging, the target programs need to contain debug information. It is recommended to compile
MicroBlaze software with the GCC option -g3. The option -g creates debug info that does not work well
with TRACE32. Also keep in mind that using code optimization can cause problems with debugging.
Designs with little-endian MicroBlaze and AXI bus
Xilinx introduced support for the AXI bus starting with EDK13 and recommends using it for new designs. The
AXI bus is used in systems with ARM cores and therefore MicroBlaze uses little endian byte-ordering in
these systems.
Configure TRACE32 for connecting to MicroBlaze cores with little endian byte order with the command
The default setting is OFF, because traditionally MicroBlaze cores used big-endian byte order (in OPB and
PLB systems).
NOTE: It is recommended to compile MicroBlaze software with the GCC option -g3.
SYStem.Option.LittleEnd ON
NOTE: For debugging little-endian systems, a TRACE32 version from December 2012 or
later is recommended.
MicroBlaze Debugger and Real-Time Trace 13 Troubleshooting
Troubleshooting
SYStem.Up Errors
The SYStem.Up command is used to establish a debug connection to the target. If you receive error
messages while executing this command this may have one reasons listed below. For additional information
please refer to the FAQ sectionn if this manual and on the LAUTERBACH website.
All The target has no power.
All The multicore settings are incorrect. For information how to calculate the multi-
core settings see Connecting to MicroBlaze Targets for Debug and Trace
(app_microblaze.pdf)
All The debugger software is out of date. The Microblaze architecture evolves rap-
idly and therefore regular updates of the debugger software are necessary. Note
that the software downloads on the LAUTERBACH website represent stable
releases but are not necessarily the latest versions. If the problems persist after
updating from the website, please contact LAUTERBACH support.
All The target FPGA is not configured correctly. The FPGA configuration (e.g. via
ACE files) can be disturbed, if the debug cable is attached to the target but the
debugger is powered down. Try to detach the debug cable and attach it after
FPGA configuration.
All The target is in reset:
The debugger controls the processor reset and use the RESET line to reset the
CPU on every SYStem.Up.
All You used a wrong JTAG connector on the target. In particular on ML310 always
use the 14pin JTAG connector J9 for debugging Microblaze.
MicroBlaze Debugger and Real-Time Trace 14 FAQ
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).

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.
MICROBLAZE
Connection to
Target Fails
Why does the connection to the target fails?
When connecting to XILINX targets be sure to use a recent version of the debug
cable (see picture).

With the old version of the debug cable target connection will fail or be
unreliable.
MicroBlaze
Fail of Single
Stepping
Single stepping sometimes fails with MB V4.00.a, MB V5.00.A. What can I
do?
In MicroBlaze V4.00.a, V5.00.A there is a hardware issue that can lead to
erroneous single stepping behavior. Solution: update to TRACE32 from
December 2006 or later. This release works around the problem.
MicroBlaze
FPGA
configuration
via TRACE32
FPGA configuration via TRACE32 fails but works with Xilinx Impact
In one case it was observed, that FPGA configuration worked with Xilinx Impact
but failed with TRACE32. In this case the target had been set up for FPGA
configuration via SPI. This implies the possibility to override the configuration via
JTAG.

After jumpering the target for "JTAG dedicated" configuration, downloading the
bitstream via TRACE32 worked fine. Note that in the failing case the download
failed silenty i.e. jtag.loadbit did not report an error.

In general be sure to set multicore pre/post parameters before configuring the
FPGA with identical values as used for debugging.
MicroBlaze
Generating
correct debug
info
Why are local variables displayed incorrectly?
When compiling MicroBlaze applications for debugging them with TRACE32, be
sure to use the correct compiler options. The option "-g3" and DWARF2 debug
info are recommended.

Note: The option "-g" creates debug info that is mostly intended for GDB and
does not work well with TRACE32. The debugger will no be able to correctly
display local variables, stack back trace etc.
MicroBlaze
Go.Up
Command
Fails
Why does the Go.Up command fail inside interrupt handlers?
The Go.Up command (function key F6) may fail inside an interrupt, exception or
break handler that is called via the brk or brki instructions. Use go.return to get
to the end of the handler routine and leave it via step.asm until the PC is back in
the interrupted routine.
MicroBlaze
Loading C++
programs
I have problems loading C++ programs for Microblaze. Which parameters
do I need?
For loading C++ programs for Microblaze that were generated with the Xilinx
Tool chain use the Data.Load.ELF command with the parameters /cygdrive /
gcc3 /gnucpp

In some cases it is necessary to execute the symbol.cleanup command (no
parameters) after loading the .elf file.

Example:

d.load.elf filename.elf /cygdrive /gcc3 /gnucpp
MicroBlaze
MC Settings
Calculation
How are multicore settings calculated?
For a description of how to calculate multicore settings (PRE/POST values) for
MicroBlaze cores see the application note "Connecting to MicroBlaze Targets for
Debug and Trace" (app_microblaze.pdf)
MICROBLAZE
MicroBlaze
spontaneously
stops while
debugging
interrupts
MicroBlaze spontaneously stops while TRACE32 is attached
In some configurations of MicroBlaze using interrupts it was observed, that the
core stopped without apparent reason, if TRACE32 was attached. Without the
debugger, the program runs OK.

Apparently this is because MicroBlaze's mechanism for polling the run state can
fail when the core takes an interrupt.

To work around the problem, move the SW break vector to an address far away
from the interrupt handler (0x10) e.g. to the address 0x40. The distance should
ideally be 24 bytes or more.

sys.o.BRKVECTOR 0x40 ; Attention: set this _before_ SYStem.UP
MICROBLAZE
No Source
Code shown
on Xilinx
Targets
Virtex: after loading an ELF file (PPC or Microblaze) to the target, no
source code is displayed. Why?
The Xilinx compilers from the EDK operate inside a Cygwin environment and
therefore create debug information with non-standard path names. Use the
option /cygdrive when loading these ELF files: data.load.elf eventgen_ppc/
executable.elf /CYGDRIVE
MicroBlaze
On-chip Data
Breaks with
unaligned
Memory
Why are the on-chip databreaks unaligned with memory?
There is a (mostly theoretical) problem with the on-chip breakpoint
implementation in MBV4, MBV5 related to unaligned memory accesses. A "sw"
or "lw" instruction (store word, load word) writing/reading address 0x2003 will
automatically word-align its address to 0x2000 before executing. However, an
on-chip breakpoint set at 0x2000 will _not_ detect this access. The case is
largely theoretical because the MB compiler does not create this kind of access.
If necessary, the problem can be worked-around by using an address range for
the OnChip as in "break.set 0x2000--0x2003 /read". (Note the "--" double minus
for range specifiation).
MicroBlaze
On-chip
Databreak
Problem
MB V4.00.a: OnChip Data Breaks do not work as expected
Microblaze MB V4.00.a has a hardware issue that affects use of on-chip breaks.
When specifying a read or write data value, the OnChip break logic does not
consider the width of the access. Therefore avoid using the /data.byte, /
data.word, /data.long options. Simple read/write on-chip breaks that do not
specify a data value work.

The hardware issue is fixed in MB V5.00.b.
MicroBlaze
Problems with
Source Code
Display
Why does not the debugger display the source code associated with my
program?
The Xilinx Microblaze compiler is based on the GNU GCC and the Cygwin
toolset. Therefore file paths in the debug information in the .ELF file are
generated in a non-standard form e.g. as /cygdrive/c/sample instead of c:/
sample. Use the option /CYGDRIVE for enabling automatic path conversion:
Data.LOAD.ELF MBSample/sample.elf /CYGDRIVE
MicroBlaze
Setting
Register R0
fails
Why does the setting of register R0 fail?
The architectural register R0 in Microblaze is hardcoded to 0. Therefore
changing the register value to other values will fail.
MicroBlaze
Software
Breakpoints or
Single
Stepping fail
with ucLinux
Why do software breakpoints or single stepping fail with ucLinux for
MicroBlaze?
Because the initialization code for ucLinux overwrites the breakpoint handler,
single stepping and software breakpoints will fail after starting the ucLinux
kernel.

Use the command

SYStem.Option BrkVector 0x70

to specify an alternative location for the breakpoint handler.
MicroBlaze
Target
Connection
How should I connect the target? Why does connection to ML310 fail?
For connecting to the target use the included adapter together with the debug
cable. The adapter plugs into the 14-pin connector of the target board. This port
is also used to configure the FPGAs via the Xilinx download cable and often
labelled as "FPGA&CPU Debug" or "PC4 JTAG".

For debugging Microblaze on Xilinx EVB ML310 always use the "PC4 JTAG"
connector. The "CPU JTAG" connector will not work.

NOTE: Even though Microblaze and PPC405 use the same debug cable there is
a difference regarding target connections: Microblaze cores are always
debugged via the 14 pin header, whereas PPC405 cores (embedded in some
Xilinx FPGAs) are occasionally accessed via other connectors.
MicroBlaze
Trace Interface
for MicroBlaze
Is there a trace interface for Microblaze cores?
Lauterbach supports a real-time trace for the Xilinx MicroBlaze core up to
MicroBlaze V7. The trace provides up to 512MB of external high speed trace
memory, which is used instead of scarce on-chip memory resources for storing
the trace information. Features included are: program flow and data trace as
well as statistical analysis of function and task run-times, variables access, code
coverage and more.
MICROBLAZE
XPS demo
applications do
not work
Many of the demo applications generated by the XPS (Xilinx platform studio)
give feedback via printf(). Therefore be sure to open a terminal window in
TRACE32, otherwise the application will appear to fail working, because it is
blockes waiting for the debugger to read the output data. Use the following
sequence to open a terminal window
term.res ; be sure to reset terminal
functionality
term.method mdmuart
term.size 110. 1000. ; make T32 poll the target for
text output
term.gate
PPC440
No Source
Code shown
on Xilinx
Targets
Virtex: after loading an ELF file (PPC or Microblaze) to the target, no
source code is displayed. Why?
The Xilinx compilers from the EDK operate inside a Cygwin environment and
therefore create debug information with non-standard path names. Use the
option /cygdrive when loading these ELF files: data.load.elf eventgen_ppc/
executable.elf /CYGDRIVE
MicroBlaze Debugger and Real-Time Trace 20 Displaying MicroBlaze Core Configuration
Displaying MicroBlaze Core Configuration
As the Microblaze core is configurable the available debug features depend on the actual core.
The configuration of the core can be displayed using the command per.When pointing the mouse at an
entry, the debugger displays an explanation in the status line.
MicroBlaze Debugger and Real-Time Trace 21 CPU specific Implementations
CPU specific Implementations
This section gives information about design decision regarding the implementation of some special features.
Memory Accesses Causing Bus Errors
Bus errors can be caused by pointers to invalid address regions or memory that is not mapped by the MMU
(e.g. when using an operating system). Normally bus errors are detected by the debugger and displayed as
????????? in memory dump windows.
However, due to a core limitation detecting bus errors while the core is inside an exception handler would
alter the system state in a way preventing correct continuation of the program. Therefore inside an exception
handler (MSR.EIP=1) , the debugger uses a different memory access method that preserves the correct
system state but does not detect bus errors. In this case the contents of invalid memory regions will show
random data.
Under Linux the most common case for this problem is when a system call branches to the hardware
exception vector on 0x20. In this case the core switches to real mode (MSR.VM=0) but the stack pointer R1
still points to an address in (now unmapped) virtual memory, until it is adapted a few instructions later. If
there is an open register window, the stack area will consequently show random data for a few cycles
(instead of indicating a bus error). Once the stack pointer is set up correctly inside the exception handler, the
stack area is displayed correctly.
Breakpoints
There are two types of breakpoints available:
Software breakpoints (SW-BP) and
Onchip breakpoints.
Software Breakpoints
Software breakpoints are implemented via a breakpoint instruction. These are the default breakpoints and
are usually used in RAM areas. Utilizing advanced TRACE32 mechanisms, in software breakpoints can
also be used in FLASH areas.There is no restriction in the number of software breakpoints.
For using SW breakpoints with ucLinux or other operating systems, setting the option
SYStem.Option.BrkVector may be required.
On-chip Breakpoints
Onchip breakpoints (Lauterbach terminology) allow to stop the core in specific conditions. As this is
implemented via hardware-resources, they are also referred to as hardware breakpoints in non-
Lauterbach terminology.
The following list gives an overview of the usage of the on-chip breakpoints by TRACE32-ICD:
Instruction breakpoints stop the core when it reaches a certain program location.
Read/Write address breakpoints can stop the core upon read or write data accesses.
Data breakpoints stop the program when a specific data value is written to an address or when
a specific data value is read from an address.
Breakpoints in ROM
With the command MAP.BOnchip <address range>, TRACE32 is configured to use onchip breakpoints in
the specified address range. Therefore the command break.set will set an onchip breakpoint in this
range and the parameter /onchip can be ommitted. Typically this feature is used with ROM or FLASH
memories that prevent the use of software breakpoints.
NOTE: The number of available onchip breakpoints depends on the configuration of the
MicroBlaze core defined in the FPGA design.
Example for Breakpoints
Assume you have a target with FLASH from 0 to 0xFFFFF and RAM from 0x100000 to 0x11FFFF. The
command to configure TRACE32 correctly for this configuration is:
The following breakpoint combinations are possible.
Software breakpoints:
On-chip breakpoints:
Map.BOnchip 0x0--0x0FFFFF
Break.Set 0x100000 /Program
; Software Breakpoint 1
Break.Set 0x101000 /Program ; Software Breakpoint 2
Break.Set 0xx /Program ; Software Breakpoint 3
Break.Set 0x100 /Program ; On-chip Breakpoint 1
Break.Set 0x0ff00 /Program ; On-chip Breakpoint 2
SYStem.Option.BrkHandler Control writing of software break handler
Controls whether the debugger writes a handler for software breaks to the target memory (to the address
specified by SYStem.Option.BrkVector). As such a handler is mandatory for using software breaks, the
default it to write the break handler.
The feature should be disabled if the vector table resides in ROM or fetch-only memory areas. In that case
the vector table pre-loaded with the memory image must contain a break handler. In case all memory is
read-only consider the use of OnChip breaks as alternative.
SYStem.Option.BrkVector Configures an alternative breakvector
Use this option to set an alternative breakvector for SW breakpoints if the default vector 0x18 is occupied
(e.g. by interrupt handlers). The debugger will write a break handler to the specified address and use a
specific software breakpoint instruction to branch to the handler.
The option must be set before attaching to the target to have an effect. The vector should be 32bit-
aligned. Do not use 0x0 as break vector.
For ucLinux it is recommended to set the breakvector to 0x70.
For Linux (on cores with MMU) it is recommended to switch off the automatic creation of the breakpoint
handler (by SYStem.Option BrkHandler off) because the kernel already contains a handler for
software breakpoints.
SYStem.Option IMASKASM Interrupt disable on ASM
Mask interrupts during assembler single steps. Useful to prevent interrupt disturbance during assembler
single stepping.
Format: SYStem.Option BrkHandler [ON|off]
Format: SYStem.Option BrkVector <vector>
<vector>: 0 0xFFFC, 32-bit aligned
Format: SYStem.Option IMASKASM [ON | OFF]
SYStem.Option IMASKHLL Interrupt disable on HLL
Mask interrupts during HLL single steps. Useful to prevent interrupt disturbance during HLL single stepping.
SYStem.Option MMUSPACES Enable multiple address spaces support
Default: OFF.
Enables the usage of the MMU to support multiple address spaces. The command should not be used if
only one translation table is used. Enabling the option will extend the address scheme of the debugger by a
16 bit memory space identifier. The option can only be enabled when there are no symbols loaded.
SYStem.Option.ResetMode Select the reset mode
Use this option to select the reset mode. CORE will only reset the MicroBlaze core while SYSTEM will also
reset the peripherals.
Note that a reset of the MicroBlaze core does not reset the register R1-R31, caches and UTLB.
Format: SYStem.Option IMASKHLL [ON | OFF]
Format: SYStem.Option MMUSPACES [ON | OFF]
SYStem.Option MMU [ON | OFF] (deprecated)
Format: SYStem.Option ResetMode <mode>
<mode>: CORE | SYSTEM
Data.Load.Elf /CYgdrive Translate Cygwin path to OS path
Use Data.Load.EL F with the option /CYGDRIVE so the debugger finds the source code associated with an
ELF file.
This is required because the Xilinx MicroBlaze compiler is executed within a a Cygwin environment.
Therefore the debug symbols have paths beginning with \cygdrive\c\ that are not valid in the host file
system. By using the option /CYGDRIVE TRACE32 will convert this prefix to the correct syntax e.g. to c:\ on
windows hosts.
Refer to the general description of Data.Load.EL F for more options.
TERM.Method MDMUART Terminal configuration
Configures the TRACE32 terminal functionality to access the UART controller of the MDM core. Use this
option when your design handles STDIO via MDM UART.
Sample script for opening term window attached to MDM Uart core:
To confirm if the MDM UART is enabled in your design, open the peripheral window via the PER command
and look for the section MDM UART Configuration.
Memory Classes
The following memory classes are available:
Format: Data.Load.Elf <filename> /CYGDRIVE
Format: TERM.Method MDMUART
term.res
term.method MDMUART
term.size 110. 1000.
term.gate
; be sure to reset term funtionality
; configure MDM UART for stdio
; cosmetics
; make T32 poll the target for data
Memory Class Description
P Program memory
D Data memory
Register Names
In TRACE32, the general purpose registers (R0-R31) and special purpose registers (e.g. MSR - machine
state register, SLR - Stack low register etc.) are anmed according to the convention in the MicroBlaze
Processor Reference Guide and shown accordingly in the register window.
These names are also used in the disassembly views and the Data.Assemble command. This is in
deviation from the Xilinx suggestions to use rmsr, rslr, etc. in the context of assembly language.
Data.Assemble 0x1000 mfs r0, MSR
Data.Assemble 0x1004 mts SLR, r3
MicroBlaze Debugger and Real-Time Trace 28 General SYStem Commands
General SYStem Commands
SYStem.CPU Select the used CPU
This command selects the CPU that shall be debugged.
The only valid option is MICROBLAZE. This option is selected by default. The other options are
deprecated.
The deprecated options were used for selecting one of multiple cores in an FPGA design. Instead of using
the deprecated options, the following sequence is recommended to attach to a specific core in an FPGA
design:
Note that all the cores inside an FPGA share identical multicore settings (PRE, POST values) because
they are accessed via the same TAP controller implemented in the Xilinx MDM IP block.
Format: SYStem.CPU <cpu>
<cpu>: MICROBLAZE |
(deprecated) MICROBLAZE0 | MICROBLAZE1 | MICROBLAZE2
| MICROBLAZE3
system.config.corenumber <number of cores in the design>
core.assign <core to use> ; NOTE: core numbers start with 1 i.e. 1, 2, 3, 4, ...
SYStem.Up
NOTE: The core number parameter for core.assign starts counting with 1 (valid values
1,2,3, ...) whereas the obsolete commands for selecting a CPU started with the
index 0 (MICROBLAZE0, MICROBLAZE1, MICROBLAZE2, ... )
SYStem.CpuAccess Run-time memory access (intrusive)
Default: Denied.
Format: SYStem.CpuAccess Enable | Denied | Nonstop
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 break-
points, performance analysis via StopAndGo mode, conditional break-
points etc.)
SYStem.JtagClock Selects the frequency for the debug interface
Selects the JTAG clock frequency for the debug interface.
For fast setup of the clock speed pre-configured buttons can be used to select commonly used frequencies.
The default frequency is 1.0 MHz.
NOTE: Buffers, additional loads or high capacities on the JTAG lines reduce the maximum operation
frequency of the JTAG clock and should be avoided.
SYStem.LOCK Lock and tristate the debug port
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.
SYStem.MemAccess Run-time memory access
No run-time memory access is possible for Microblaze cores.
Format: SYStem.JtagClock <rate>
SYStem.BdmClock <rate> (deprecated).
<fixed>: 1 000 00025 000 000
Format: SYStem.LOCK [ON | OFF]
Format: SYStem.MemAccess Denied
Denied No memory access is possible while the CPU is executing the program.
SYStem.Mode Select operation mode
Select target reset mode.
Format: SYStem.Mode <mode>
<mode>: Down
NoDebug
Go
Attach
Up
Down Disables the Debugger. The state of the CPU remains unchanged.
NoDebug Resets the target with debug mode disabled (for the PPC400 family the same
as Go). In this mode no debugging is possible. The CPU state keeps in the
state of NoDebug
Go Resets the target with debug mode enabled and prepares the CPU for debug
mode entry. 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.
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.
Attach This command works similar to Up command. The difference is, that the target
CPU is not resetted. The BDM/JTAG/COP interface will be synchronized and
the CPU state will be read out. After this command the CPU is in the
SYStem.Up mode and can be stopped for debugging.
StandBy Not supported.
SYStem.CONFIG Configure multi-core debugger
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 Daisy-
chain Example.
For some CPU selections (SYStem.CPU) the above setting might be set automatically, since the required
system configuration of these CPUs are well-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.
Format: SYStem.CONFIG <parameter> <number_or_address>
SYStem.MultiCore <parameter> <number_or_address> (deprecated)
<parameter>
(General):
(JTAG):
view
CORE <core>
DRPRE <bits>
DRPOST <bits>
IRPRE <bits>
IRPOST <bits>
TAPState <state>
TCKLevel <level>
TriState [ON | OFF]
Slave [ON | OFF]
Multicore debugging is not supported for the DEBUG INTERFACE (LA-7701).

view 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 cores in the JTAG chain between the target core
and the TDO signal (one data register bit per core which is in BYPASS
mode).
DRPOST (default: 0) <number> of cores in the JTAG chain between the TDI signal
and the target core (one data register bit per core which is in BYPASS
mode).
IRPRE (default: 0) <number> of instruction register bits of all cores in the JTAG
chain between the target core and the TDO signal.
IRPOST (default: 0) <number> of instruction register bits of all cores in the JTAG
chain between TDI signal and the target core.
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: 0) If more than one debugger share the same debug port 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).
Daisy-chain Example
Instruction register length of
Core A: 3 bit
Core B: 5 bit
Core C: 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
Core A Core B Core C Core D TDO TDI
Chip 0 Chip 1
TapStates
0 Exit2-DR
1 Exit1-DR
2 Shift-DR
3 Pause-DR
4 Select-IR-Scan
5 Update-DR
6 Capture-DR
7 Select-DR-Scan
8 Exit2-IR
9 Exit1-IR
10 Shift-IR
11 Pause-IR
12 Run-Test/Idle
13 Update-IR
14 Capture-IR
15 Test-Logic-Reset
SYStem.CONFIG.Core Map system topology to debugger topology model
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 succesive chipnumbers 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 set-up 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 less chips than initially assumed, the chips must
be merged by calling SYStem.CONFIG.Core.
For MicroBlaze specific information please refer to Connecting to MicroBlaze Targets for Debug and
Trace (app_microblaze.pdf).
Format: SYStem.CONFIG.Core <coreindex> <chipindex>
SYStem.MultiCore.Core <coreindex> <chipindex> (deprecated)
<chipindex>: 1 i
<coreindex> 1 k
MicroBlaze Debugger and Real-Time Trace 37 TrOnchip Commands
TrOnchip Commands
TrOnchip.view Display on-chip trigger window
Open TrOnchip window.
TrOnchip.RESet Set on-chip trigger to default state
Sets the on-chip trace and trigger module to reset state.
Format: TrOnchip.view
Format: TrOnchip.RESet
MicroBlaze Debugger and Real-Time Trace 38 TrOnchip Commands
TrOnchip.CONVert Adjust range breakpoint in on-chip resource
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.VarCONVert Adjust complex breakpoint in on-chip resource
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.
Format: TrOnchip.CONVert [ON | OFF]
TrOnchip.CONVert ON
Break.Set 0x1000--0x17ff /Write
TrOnchip.CONVert OFF
; sets breakpoint at range
; 1000--17ff sets single breakpoint
; at address 1001
; sets breakpoint at range
; 1000--17ff
; gives an error message
Format: TrOnchip.VarCONVert [ON | OFF]
MicroBlaze Debugger and Real-Time Trace 39 TrBus Commands
TrBus Commands
TrBus.Out Define source for the external trigger pulse
Define the source for the external trigger pulse.
TrBus.Set Define the target for the incoming trigger
Select the target for the incoming trigger signal.
Format: TrBus.Out Break | ABreak | ATrigger [ON | OFF]
Break Generate an external trigger pulse when the program execution is stopped.
ABreak Generate an external trigger pulse when the sampling to the trace buffer is
stopped.
ATrigger Generate an external trigger pulse when a trigger is generated for the trace. A
trigger for the trace can be used to stop the sampling to the trace buffer after a
specified delay Analyzer.TDelay.
Format: TrBus.Set Break | ATrigger [ON | OFF]
Break Stop the program execution when the external trigger signal becomes active.
ATrigger Generate a trigger for the trace when the external trigger signal becomes
active. A trigger for the trace can be used to stop the sampling to the trace
buffer directly or after a specified delay Analyzer.TDelay.
MicroBlaze Debugger and Real-Time Trace 40 CPU specific MMU Commands
CPU specific MMU Commands
MMU.DUMP Display MMU table
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.
Format: MMU.DUMP <table> [<range>| <address>]
MMU.<table>.dump (deprecated)
<table>: PageTable
KernelPageTable
TaskPageTable <task>
and CPU specific tables
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>.
MMU.List Display MMU table
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.
Format: MMU.List [<table> [<range>| <address>]]
MMU.<table>.List (deprecated)
<table>: PageTable
KernelPageTable
PageTable List the current MMU translation of the CPU.
This command reads all tables the CPU currently used for MMU
translation and lists the address translation.
KernelPageTable List the MMU translation table of the kernel.
MMU translation table of the kernel and lists its address translation.
TaskPageTable List the MMU translation of the given process.
and lists its address translation.
<x>.
MMU.SCAN Load MMU table from CPU
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.
Format: MMU.SCAN <table> [<range><address>]
MMU.<table>.SCAN (deprecated)
<table>: PageTable
KernelPageTable
ALL
and CPU specific tables
PageTable Load the current MMU address translation of the CPU.
This command reads all tables the CPU currently used for MMU translation,
and copies the address translation into the debugger internal translation
table.
KernelPageTable Load the MMU translation table of the kernel.
table of the kernel and copies its address translation into the debugger
internal translation table.
TaskPageTable Load the MMU address translation of the given process.
and copies its address translation into the debugger internal translation
table.
<x>.
ALL Load all known MMU address translations.
This command reads the OS kernel MMU table and the MMU tables of all
processes and copies the complete address translation into the
debugger internal translation table.
<x>.
MicroBlaze Debugger and Real-Time Trace 43 Real-Time Trace
Real-Time Trace
This sections list CPU specific options for the real-time trace.
SYStem.Option.DTM Control data trace messages
Default: OFF.
Enable this system option in order to record data trace messages of the target program. Note that
MicroBlaze XMTC only supports tracing of data load messages. Data write messages can not be triggered.
The option needs to be enabled before connecting the debugger to the target.
SYStem.Option.QUICKSTOP Control trace of software breakpoints
Default: OFF.
Enable this system option in order to optimize tracing of software breakpoints.
When hitting a software break, earlier versions of MicroBlaze jump to a software break handler and loop
there until the debugger detects the break. As this can last some milliseconds, the trace buffer will contain
irrelevant trace data.
By enabling the option is enabled, the debugger sets an on-chip breakpoint onto the software break handler
and thus stops the core immeditately.
Format: SYStem.Option.DTM [ON | OFF]
NOTE: To see data trace messages in the trace.list window, it is necessary to
increase the level of displayed details by clicking the more button.
Format: SYStem.Option.QUICKSTOP [ON | OFF] (deprecated)
MicroBlaze Debugger and Real-Time Trace 44 Real-Time Trace
SYStem.Option.UserBSCAN Set default user bscan port
Default: 2 (USER2)
For connectingto a MicroBlaze core, the debugger iterates over the User BScan ports of the FPGA JTAG
controller until an MDM core with an attached MicroBlaze core is found. In systems with multiple MDM cores
this option is used to specify the first User BScan port to check and therefore allows to connect to a specific
MDM core. Note that this option is used only in very special designs as normally multiple MicroBlaze cores
are attached to a single MDM core (and selected via the SYStem.CPU command).
Format: SYStem.Option.UserBSCAN <port nr> 1...4
MicroBlaze Debugger and Real-Time Trace 45 Configuring your FPGA
Configuring your FPGA
Before debugging, the FPGA needs to be configured with a design containing a MicroBlaze core enabled for
JTAG debugging. The configuration is done via the command Java.JTAG.LOADBIT. .
Be sure to have correct multicore settings before configuring the FPGA,
otherwise the configuration will fail. These settings are identical with those used
for debugging a MicroBlaze core.
Also ensure that the debugger is in SYStem.down mode, before configuring
your FPGA. Configuring the FPGA will break the communication link between
the debugger and the MicroBlaze core, if your debugger is in SYStem.up mode.
It is recommended to configure the target with the config option JTAG
dedicated i.e. not using a mode where JTAG overrides other configurations like
MSI, SPI etc. In the latter case configuration via TRACE32 may fail silently (no
error message), though configuration via Xilinx Impact works.
MicroBlaze Debugger and Real-Time Trace 46 JTAG Connector
JTAG Connector
Mechanical Description
JTAG Connector for Xilinx Microblaze
It is recommended to connect all N/C Pins to GND (if you work with LAUTERBACH tools only).
The following chart details the pinout of the16 pin PPC400 debug cable, that is also used for debugging
Microblaze cores.

The debugger includes the adapter (LA-3731) that converts the PPC400 pinout to that of the 14 pin Xilinx
JTAG connector which is listed below:

NOTE: The HALT- and TRST- signals are irrelevant for debugging MicroBlaze designs.They are only
used for debugging the boot process of PPC cores. See the PowerPC debugger user guide for details.
Signal Pin Pin Signal
TDO 1 2 N/C
TDI 3 4 TRST- (*)
N/C 5 6 VCCS
TCK 7 8 N/C
TMS 9 10 N/C
HALT- 11 12 N/C
N/C 13 14 KEY
N/C 15 16 GND
Pinout of PPC400 debug cable
Signal Pin Pin Signal
GND 1 2 VREF
GND 3 4 TMS
GND 5 6 TCK
GND 7 8 TDO
GND 9 10 TDI
GND 11 12 NC
GND 13 14 NC
Pinout of Xilinx JTAG connector
MicroBlaze Debugger and Real-Time Trace 47 Support
Support
Available Tools

Compilers

Realtime Operation System
No RTOS currently supported.
C
P
U
I
C
E
F
I
R
E
I
C
D
D
E
B
U
G
I
C
D
M
O
N
I
T
O
R
I
C
D
T
R
A
C
E
P
O
W
E
R
I
N
T
E
G
R
A
T
O
R
I
N
S
T
R
U
C
T
I
O
N
S
I
M
U
L
A
T
O
R
MICROBLAZE YES YES YES
Language Compiler Company Option Comment
C++ GCC XILINX ELF
MicroBlaze Debugger and Real-Time Trace 48 Support
3rd Party Tool Integrations

CPU Debugger Company Host
ALL X-TOOLS / X32 blue river software GmbH Windows
ALL CODEWRIGHT Borland Software
Corporation
Windows
ALL CODE CONFIDENCE
TOOLS
Code Confidence Ltd Windows
ALL CODE CONFIDENCE
TOOLS
Code Confidence Ltd Linux
ALL EASYCODE EASYCODE GmbH Windows
ALL ECLIPSE Eclipse Foundation, Inc Windows
ALL RHAPSODY IN MICROC IBM Corp. Windows
ALL RHAPSODY IN C++ IBM Corp. Windows
ALL LDRA TOOL SUITE LDRA Technology, Inc. Windows
ALL ATTOL TOOLS MicroMax Inc. Windows
ALL VISUAL BASIC
INTERFACE
Microsoft Corporation Windows
ALL LABVIEW NATIONAL
INSTRUMENTS
Corporation
Windows
ALL CODE::BLOCKS Open Source -
ALL C++TEST Parasoft Windows
ALL RAPITIME Rapita Systems Ltd. Windows
ALL DA-C RistanCASE Windows
ALL SIMULINK The MathWorks Inc. Windows
ALL WINDOWS CE PLATF.
BUILDER
Windows Windows
MICROBLAZE CHIPSCOPE ANALYZER XILINX Windows
MicroBlaze Debugger and Real-Time Trace 49 Products
Products
Product Information

Order Information

OrderNo Code Text
LA-3730
JTAG-MICROBLAZE
Debugger for MicroBlaze (ICD)
supports MicroBlaze
includes software for Windows, Linux and MacOSX
requires Power Debug Module or PowerTrace
debug cable with 16 pin connector
LA-3730A
JTAG-MICROBLAZE-A
JTAG Debug. License for MicroBlaze Additonal
supports MicroBlaze
Extension applicable to the following debug cables
(purchased separately):
for LA-7723 (JTAG Debugger for PPC405)
for LA-7752 (JTAG Debugger for PPC44x)
for LA-7843 (JTAG Debugger for Cortex-A/-R (ARMv7))
please add the base serial number of your debug
cable to your order
LA-3807
JTAG-AD-SPARTAN3
JTAG Converter Spartan3/MicroBlaze
JTAG Adapter Spartan3
Xilinx MicroBlaze
16 pin to 6 pin
Boards: EVB Spartan3EStarter Kit; EVB S3ADSP1800A
Order No. Code Text
LA-3730 JTAG-MICROBLAZE Debugger for MicroBlaze (ICD)
LA-3730A JTAG-MICROBLAZE-A JTAG Debug. License for MicroBlaze Additonal
LA-3807 JTAG-AD-SPARTAN3 JTAG Converter Spartan3/MicroBlaze
Additional Options
LA-7723A DEBUG-PPC400-A JTAG Debugger License for PPC400 Add.
LA-7752A DEBUG-PPC44X-A JTAG Debugger License for PPC44x Add.

Debugger Microblaze

Uploaded by

Copyright:

Available Formats

Debugger Microblaze

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Debugger Microblaze

Uploaded by

Copyright:

Available Formats

MicroBlaze Debugger and Real-Time Trace 1

1989-2013 Lauterbach GmbH

You might also like