microblaze debugger and trace - lauterbach · · 2017-11-06microblaze debugger and trace 1...

MicroBlaze Debugger and Trace

TRACE32 Online Help

TRACE32 Directory

TRACE32 Index

TRACE32 Documents ......................................................................................................................

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

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

MicroBlaze ...............................................................................................................................

MicroBlaze Debugger and 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 .................................................................... 21

CPU specific Implementations ......................................................................................... 22

Memory Accesses Causing Bus Errors 22

Breakpoints 23

Software Breakpoints 23

On-chip Breakpoints 23

Breakpoints in ROM 23

Example for Breakpoints 24

Data.LOAD.Elf /CYgdrive Translate Cygwin path to OS path 24

SYStem.Option.BrkHandler Control writing of software break handler 25

SYStem.Option.BrkVector Configures an alternative breakvector 25

SYStem.Option IMASKASM Interrupt disable on ASM 26

SYStem.Option IMASKHLL Interrupt disable on HLL 26

SYStem.Option MMUSPACES Enable space IDs 26

MicroBlaze Debugger and Trace 1 ©1989-2018 Lauterbach GmbH

SYStem.Option.ResetMode Select the reset mode 27

TERM.Method MDMUART Terminal configuration 28

Memory Classes 29

Register Names 29

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

SYStem.CPU Select the used CPU 30

SYStem.CpuAccess Run-time memory access (intrusive) 31

SYStem.JtagClock Selects the frequency for the debug interface 32

SYStem.LOCK Lock and tristate the debug port 32

SYStem.MemAccess Run-time memory access 32

SYStem.Mode Select operation mode 33

SYStem.CONFIG Configure debugger according to target topology 34

Daisy-chain Example 36

TapStates 37

SYStem.CONFIG.CORE Assign core to TRACE32 instance 38

TrOnchip Commands ........................................................................................................ 39

TrOnchip.state Display on-chip trigger window 39

TrOnchip.RESet Set on-chip trigger to default state 39

TrOnchip.CONVert Adjust range breakpoint in on-chip resource 39

TrOnchip.VarCONVert Adjust complex breakpoint in on-chip resource 40

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

MMU.DUMP Page wise display of MMU translation table 41

MMU.List Compact display of MMU translation table 42

MMU.SCAN Load MMU table from CPU 43

Real-Time Trace ................................................................................................................. 44

SYStem.Option.DTM Control data trace messages 44

SYStem.Option.QUICKSTOP Control trace of software breakpoints 44

SYStem.Option.UserBSCAN Set default user bscan port 45

Configuring your FPGA .................................................................................................... 46

JTAG Connector ................................................................................................................ 47

Mechanical Description 47

JTAG Connector for Xilinx Microblaze 47

Support ............................................................................................................................... 48

Available Tools 48

Compilers 48

Target Operating Systems 48

3rd-Party Tool Integrations 49

Products ............................................................................................................................. 50

Product Information 50

Order Information 50


MicroBlaze Debugger and Trace

Version 22-Mar-2018

B::Data.Listaddr/line code label mnemonic commentP:FFF021C0 39400000 li r10,0P:FFF021C4 915F0018 stw r10,18(r31)

567 for ( i = 0 ; i <= SIZE ; flags[ i++ ] = TRUE ) ;P:FFF021C8 39200000 li r9,0 ; i,0P:FFF021CC 2C890012 cmpwi cr1,r9,12 ; cr1,i,18P:FFF021D0 40850008 ble cr1,0FFF021D8P:FFF021D4 4800001C b 0FFF021F0

B::Register B::PERR0 0 R8 0 EXISR 80000000 CIS pending SRIS wait SR1 0FFFFFFD8 R9 0 D0IS wait D1IS wait DR2 0 R10 0 E0IS wait E1IS wait ER3 0 R11 0R4 0 R12 0 Input Output ConfigurationR5 0 R13 0 IOCR 00000000 E0T level E1T level E2T leR6 0 R14 0 E0L negative E1L negativeR7 0 R15 0 RDM disabled TCS sysclk SSPRG0 0 SRR0 0SPRG1 0 SRR1 0 Bank 0SPRG2 0 SRR2 0 BR0 FF183FFE BAS 0FF00000 BS 1MB BU rea


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 [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 Debuggers” (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 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 XMTC’s trigger features are currently not supported.

• Use the Xilinx Vivado Design Suite for hardware analysis and the Lauterbach TRACE32 infrastructure for software debugging - over a single (shared) connection to the target board via Lauterbach hardware. For more details, see “Integration for Xilinx Vivado” (int_vivado.pdf).

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: Tracing via XMTC is officially supported and tested by Xilinx until EDK12.4 and thus up to MicroBlaze V7.30.a.


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.


Quick Start of the Debugger

For getting started with debugging, the installation DVD contains sample bit streams and scripts for ML310, ML403, Spartan3EStarter, Spartan3ADSP1800Starter boards. You find them in the TRACE32 demo folder: ~~/demo/microblaze/hardware

The following example uses ML403. Configure the target with the bit stream~~/demo/microblaze/hardware/memecfx12lc/stopandgo/download.bit

The FPGA configuration can be done using Xilinx Vivado (or its predecessor Xilinx iMPACT) or the TRACE32 command JTAG.PROGRAM (or the old version of the 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

SYStem.CONFIG IRPOST 28.SYStem.CONFIG IRPRE 8.SYStem.CONFIG DRPOST 2.SYStem.CONFIG DRPRE 1.

Note the ´.´ indicating decimal numbers.

SYStem.Up


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 ~~/demo/microblaze/hardware/ml403/mb.v710d.xmtc.100b.noddrramData.LOAD.Elf sieve_00000000.elf /CYGDRIVE

Data.List ; Open disassembly window

Register ; Open register window


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 TRACE32 demo folder:~~/demo/microblaze/hardware/ml403/mb.v710d.xmtc.100b.noddrram/

Configure the target with the bit stream download.bit, start the debugger and execute the script below (demo.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.

SYStem.CPU microblaze0SYStem.CONFIG IRPOST 28.SYStem.CONFIG IRPRE 8.SYStem.CONFIG DRPOST 2.SYStem.CONFIG DRPRE 1.

; XILINX EVB ML403

if analyzer() ( analzyer.mode.fifo analyzer.autoinit off sys.o.dtm on sys.o.quickstop on analyzer analyzer.list )


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.

SYStem.P Data.LOAD.Elf mb.v700b.xmtc/sieve/sieve_8c000000.elf /cygdrive Go sieveData.List


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.


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


FAQ

Debugging via VPN

Ref: 0307

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 scriptand "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screenupdates. Please note that if your program stops (e.g. on error) without exe-cuting "SCREEN.OFF", some windows will not be updated.

"SYStem.POLLING SLOW" will set a lower frequency for target statechecks (e.g. power, reset, jtag state). It will take longer for the debugger torecognize that the core stopped on a breakpoint.

"SETUP.URATE 1.s" will set the default update frequency ofData.List/Data.dump/Variable windows to 1 second (the slowest possiblesetting).

prevent unneeded memory accesses using "MAP.UPDATEONCE[address-range]" for RAM and "MAP.CONST [address--range]" forROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read thespecified address range only once after the core stopped at a breakpoint ormanual break. "MAP.CONST" will read the specified address range onlyonce per SYStem.Mode command (e.g. SYStem.Up).


Setting a Software Breakpoint fails

Ref: 0276

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

09-02-15

Ref: 0422

Why are there no peripheral files (.PER) for Xilinx FPGAs?

Peripheral files (.PER) correspond to the peripheral register of a concrete system implementation (i.e. they contain the registers for a memory controller, an I2C bus, an ethernet controller, etc.). In the case of FPGAs they have to correspond to the user's system design and are application specific. Therefore no generic .PER files are available for an FPGA type (e.g. Xilinx Kintex-7 XC7K325-T-2FFG900C). For information about creating custom .PER-files refer to the document "Peripheral Files Programming Commands" (per_prog.pdf).

MICROBLAZE

Connection to Target Fails

Ref: 0291

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

crt0.s not found

Ref: 0400

Why do I get the message Warning: file [...]\gcc\libgloss\microblaze\crt0.S not found

When creating programs with Xilinx EDK, the tool links some standard libraries with your code to create the executable. These standard libraries are built from files like crt0.S, crtinit.S etc. As they are created by Xilinx, the debug info contains paths to the source files specific to the Xilinx build machines. Usually these paths are not consistent with those on your machine. To avoid the warning you can use the command sYmbol.SOURCEPATH.translate to have TRACE32 look in a different directory for the source file. To find out the paths associated with the currently loaded program use the command. sYmbol.List.SOURCE Example: y.sourcepath.translate "\proj\epdsw\gnu\mb_gnu\src\gcc\libgloss\microblaze" "c:\Xilinx\14.4\ISE_DS\EDK\sw\lib\microblaze\src"

MICROBLAZE

Error Reading Processor Config Register

Ref: 0407

What can I do about "Error Reading Processor Config Register"?

The error message "Error Reading Processor Config Register" indicates that the basic communication with the MicroBlaze core could not be established. Most of the time the error is caused by an incorrect JTAG configuration of TRACE32. For details please refer to the documentation of the commands SYStem.Config IRPRE, SYStem.Config IRPOST, ... Attention: For MicroBlaze there is one special case when the width of the IR is bigger than 6bits (e.g. for Virtex5FXT IRWIDTH = 10bits). In this case the IRPOST value needs to be adapted . For details please refer to section "Detecting multicore settings" in the document app_microblaze.pdf ("Connecting to MicroBlaze Targets for Debug and Trace") or contact Lauterbach support.

MicroBlaze

Fail of Single Stepping

Ref: 0237

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

Ref: 0306

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

Ref: 0391

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

Ref: 0241

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

Ref: 0272

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

Ref: 0235

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

Ref: 0341

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

Ref: 0214

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

Ref: 0239

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

Ref: 0238

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

Ref: 0236

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

Ref: 0240

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

Ref: 0259

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

Ref: 0234

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

Ref: 0243

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

Ref: 0340

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 functionalityterm.method mdmuartterm.size 110. 1000. ; make T32 poll the target for text outputterm.gate


PPC440

No Source Code shown on Xilinx Targets

Ref: 0214

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


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.


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

Data.LOAD.Elf /CYgdrive Translate Cygwin path to OS path

Use Data.LOAD.Elf 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.

For more options, refer to the general description of Data.LOAD.Elf.

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

Format: Data.Load.Elf <filename> /CYGDRIVE


SYStem.Option.BrkHandler Control writing of software break handler

Default: AUTO

The option controls whether the debugger writes a handler for software breakpoints to the target memory. The address can be configured via SYStem.Option BrkVector.

The option AUTO detects if the software breakpoint handler is required by the current core.

This can be overridden by the options ON or OFF for special cases. The breakpoint handler should be switched OFF when

• using Linux because it utilizes a breakpoint handler created by the kernel

• if the vector table resides in ROM or “fetch-only” memory areas. In this case the vector table pre-loaded with the memory image must contain a breakpoint handler.

If all program 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 address for the software breakpoint handler created by the debugger. Changing the default address is necessary when the vector 0x18 is occupied e.g. by interrupt handlers.

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 handler address to 0x70.

Format: SYStem.Option BrkHandler [AUTO | ON | OFF]

NOTE: A software breakpoint handler is required for using software breakpoints on MicroBlaze cores with versions < 7.20.A.

Format: SYStem.Option BrkVector <vector>

<vector>: 0 … 0xFFFC, 32-bit aligned


When changing the breakpoint vector, the debugger automatically uses a matching opcode 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.

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

Default: OFF.

NOTE: For additional information see SYStem.Option BrkHandler.

Format: SYStem.Option IMASKASM [ON | OFF]

Format: SYStem.Option IMASKHLL [ON | OFF]

Format: SYStem.Option MMUSPACES [ON | OFF]SYStem.Option MMUspaces [ON | OFF] (deprecated)SYStem.Option MMU [ON | OFF] (deprecated)


Enables the use of space IDs for logical addresses to support multiple address spaces.

Examples:

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.

NOTE: SYStem.Option MMUSPACES should not be used if only one translation table is used on the target.

If a debug session requires space IDs, you must observe the following sequence of steps:

1. Activate SYStem.Option MMUSPACES.

2. Load the symbols with Data.LOAD.

Otherwise, the internal symbol database of TRACE32 may become inconsistent.

;Dump logical address 0xC00208A belonging to memory space with ;space ID 0x012A:Data.dump D:0x012A:0xC00208A

;Dump logical address 0xC00208A belonging to memory space with ;space ID 0x0203:Data.dump D:0x0203:0xC00208A

Format: SYStem.Option ResetMode <mode>

<mode>: CORE | SYSTEM


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

Format: TERM.Method MDMUART

TERM.RESetTERM.METHOD MDMUARTTERM.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 Classes

The following memory classes are available:

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

Memory Class Description

P Program memory

D Data memory

Data.Assemble 0x1000 mfs r0, MSRData.Assemble 0x1004 mts SLR, r3


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 |

MICROBLAZE0 | MICROBLAZE1 | MICROBLAZE2 | MICROBLAZE3 (deprecated)

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 main window 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 displayThe 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, condi-tional breakpoints, 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.

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 000…25 000 000

NOTE: Buffers, additional loads or high capacities on the JTAG lines reduce the maximum operation frequency of the JTAG clock and should be avoided.

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

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 reset. 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 debugger according to target topology

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 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 need to be kept in inactive state.

Format: SYStem.CONFIG <parameter> <number_or_address>SYStem.MultiCore <parameter> <number_or_address> (deprecated)

<parameter>: CORE <core>

<parameter>:(JTAG):

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

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


Daisy-chain Example

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

Core A Core B Core C Core D TDOTDI

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 Assign core to TRACE32 instance

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.

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


TrOnchip Commands

TrOnchip.state Display on-chip trigger window

Opens the TrOnchip.state window.

TrOnchip.RESet Set on-chip trigger to default state

Sets the TrOnchip settings and trigger module to the default settings.

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.

Format: TrOnchip.state

Format: TrOnchip.RESet

Format: TrOnchip.CONVert [ON | OFF]

TrOnchip.CONVert ONBreak.Set 0x1000--0x17ff /WriteBreak.Set 0x1001--0x17ff /Write…

TrOnchip.CONVert OFFBreak.Set 0x1000--0x17ff /WriteBreak.Set 0x1001--0x17ff /Write

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

; sets breakpoint at range; 1000--17ff; gives an error message


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.VarCONVert [ON | OFF]


CPU specific MMU Commands

MMU.DUMP Page wise display of MMU translation 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.

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.

Format: MMU.DUMP <table> [<range> | <addr> | <range> <root> | <addr> <root>]MMU.<table>.dump (deprecated)

<table>: PageTableKernelPageTableTaskPageTable <magic_number> | <task_id> | <task_name><cpu_specific_tables>

PageTable Display the current MMU translation table entries of the CPU. This command reads all tables the CPU currently uses 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 <magic_number> | <task_id> | <task_name>

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>.For information about the parameters, see “What to know about Magic Numbers, Task IDs and Task Names” (general_ref_t.pdf).


MMU.List Compact display of MMU translation 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> | <addr> | <range> <root> | <addr> <root>] MMU.<table>.List (deprecated)

<table>: PageTableKernelPageTableTaskPageTable <magic_number> | <task_id> | <task_name> | <space_id>:0x0

<root> 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 List the current MMU translation of the CPU. This command reads all tables the CPU currently uses for MMU translation and lists the address translation.

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.


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>.For information about the parameters, see “What to know about Magic Numbers, Task IDs and Task Names” (general_ref_t.pdf).


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>: PageTableKernelPageTableTaskPageTable <magic_number> | <task_id> | <task_name>ALL<cpu_specific_tables>

PageTable Load the current MMU address translation of the CPU. This command reads all tables the CPU currently uses 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.


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 manual: RTOS Debugger for <x>.For information about the parameters, see “What to know about Magic Numbers, Task IDs and Task Names” (general_ref_t.pdf).

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 manual: RTOS Debugger for <x>.


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

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)


SYStem.Option.UserBSCAN Set default user bscan port

Default: 2 (USER2)

For connecting to 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


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 JTAG.PROGRAM or its predecessor 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.

Configuration using compressed bitstreams is supported.

It is recommended to configure the target with the configuration 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.


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:

Signal Pin Pin SignalTDO 1 2 N/CTDI 3 4 TRST- (*)N/C 5 6 VCCS

TCK 7 8 N/CTMS 9 10 N/C

HALT- 11 12 N/CN/C 13 14 KEYN/C 15 16 GND

Pinout of PPC400 debug cable

Signal Pin Pin SignalGND 1 2 VREFGND 3 4 TMSGND 5 6 TCKGND 7 8 TDOGND 9 10 TDIGND 11 12 NCGND 13 14 NC

Pinout of Xilinx JTAG connector

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.


Support

Available Tools

Compilers

Target Operating Systems

Currently none supported.

CP

U

ICE

FIR

E

ICD

DE

BU

G

ICD

MO

NIT

OR

ICD

TR

AC

E

PO

WE

RIN

TE

GR

ATO

R

INS

TR

UC

TIO

NS

IMU

LA

TOR

MICROBLAZE YES YESZYNQ-ULTRASCALE+ YES YES YES

Language Compiler Company Option Comment

C++ GCC XILINX ELF


3rd-Party Tool Integrations

CPU Tool Company Host

WINDOWS CE PLATF. BUILDER

- Windows

CODE::BLOCKS - -C++TEST - WindowsADENEO -X-TOOLS / X32 blue river software GmbH WindowsCODEWRIGHT Borland Software

CorporationWindows

CODE CONFIDENCE TOOLS

Code Confidence Ltd Windows

CODE CONFIDENCE TOOLS

Code Confidence Ltd Linux

EASYCODE EASYCODE GmbH WindowsECLIPSE Eclipse Foundation, Inc WindowsCHRONVIEW Inchron GmbH WindowsLDRA TOOL SUITE LDRA Technology, Inc. WindowsUML DEBUGGER LieberLieber Software

GmbHWindows

SIMULINK The MathWorks Inc. WindowsATTOL TOOLS MicroMax Inc. WindowsVISUAL BASIC INTERFACE

Microsoft Corporation Windows

LABVIEW NATIONAL INSTRUMENTS Corporation

Windows

RAPITIME Rapita Systems Ltd. WindowsRHAPSODY IN MICROC IBM Corp. WindowsRHAPSODY IN C++ IBM Corp. WindowsDA-C RistanCASE WindowsTRACEANALYZER Symtavision GmbH WindowsECU-TEST TraceTronic GmbH WindowsUNDODB Undo Software LinuxTA INSPECTOR Vector WindowsVECTORCAST UNIT TESTING

Vector Software Windows

VECTORCAST CODE COVERAGE

Vector Software Windows

MICROBLAZE CHIPSCOPE ANALYZER XILINX WindowsMICROBLAZE VIVADO XILINX Windows


Products

Product Information

Order Information

OrderNo Code Text

LA-3730 JTAG-MICROBLAZE

Debugger for MicroBlaze (ICD)supports MicroBlazeincludes software for Windows, Linux and MacOSXrequires Power Debug Module or PowerTracedebug cable with 16 pin connector

LA-3730A JTAG-MICROBLAZE-A

JTAG Debug. License for MicroBlaze Additonalsupports MicroBlazeplease add the base serial number of your debugcable to your order

LA-3807 JTAG-AD-SPARTAN3

JTAG Converter Spartan3/MicroBlazeJTAG Adapter Spartan3Xilinx MicroBlaze16 pin to 6 pinBoards: 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 AdditonalLA-3807 JTAG-AD-SPARTAN3 JTAG Converter Spartan3/MicroBlaze

Additional OptionsLA-7723A DEBUG-PPC400-A JTAG Debugger License for PPC400 Add.LA-7752A DEBUG-PPC44X-A JTAG Debugger License for PPC44x Add.
