This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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).
• 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.
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).
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
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.
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.
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.
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).
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.
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.
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 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
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
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
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.
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.
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.
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.
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.
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”.
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.
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.
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, ... )
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.
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.
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.
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).
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).
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.
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.
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.
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.
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).
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.
<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).
Loads the CPU-specific MMU translation table from the CPU to the debugger-internal translation table. If called without parameters, the complete page table will be loaded. The loaded address translation can be viewed with TRANSlation.List.
If the command is called with either an address range or an explicit address, page table entries will only be loaded if their logical address matches with the given parameter.
PageTable Load the current MMU address translation of the CPU. This command reads all tables the CPU currently 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>.
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.
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).
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.
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.
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
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