MicroBlaze Debugger and Trace

Transcription

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 TRACE ESD Protection... 7 Quick Start of the Debugger... 8 Quick-Start of the Real-Time Trace Compiling Software with Debug Information Designs with little-endian MicroBlaze and AXI bus Troubleshooting SYStem.Up Errors 13 FAQ Displaying MicroBlaze Core Configuration CPU specific Implementations 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

2 SYStem.Option.ResetMode Select the reset mode 27 TERM.Method MDMUART Terminal configuration 28 Memory Classes 29 Register Names 29 General SYStem Commands 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 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 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 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 JTAG Connector Mechanical Description 47 JTAG Connector for Xilinx Microblaze 47 Support Available Tools 48 Compilers 48 Target Operating Systems 48 3rd-Party Tool Integrations 49 Products Product Information 50 Order Information 50 MicroBlaze Debugger and Trace 2

3 MicroBlaze Debugger and Trace 3

4 MicroBlaze Debugger and Trace Version 22-Mar-2018 B::Data.List addr/line code label mnemonic comment P:FFF021C li r10,0 P:FFF021C4 915F0018 stw r10,18(r31) 567 for ( i = 0 ; i <= SIZE ; flags[ i++ ] = TRUE ) ; P:FFF021C li r9,0 ; i,0 P:FFF021CC 2C cmpwi cr1,r9,12 ; cr1,i,18 P:FFF021D ble cr1,0fff021d8 P:FFF021D C b 0FFF021F0 B::Register B::PER R0 0 R8 0 EXISR CIS pending SRIS wait S R1 0FFFFFFD8 R9 0 D0IS wait D1IS wait D R2 0 R10 0 E0IS wait E1IS wait E R3 0 R11 0 R4 0 R12 0 Input Output Configuration R5 0 R13 0 IOCR E0T level E1T level E2T le R6 0 R14 0 E0L negative E1L negative R7 0 R15 0 RDM disabled TCS sysclk S SPRG0 0 SRR0 0 SPRG1 0 SRR1 0 Bank 0 SPRG2 0 SRR2 0 BR0 FF183FFE BAS 0FF00000 BS 1MB BU rea MicroBlaze Debugger and Trace 4

5 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 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 systemaware debugging. The appropriate RTOS manual informs you how to enable the OS-aware debugging. Please note that multicore configuration will be required in most cases, even when there is only a single Microblaze processor in the target. For information about setting up multicore-configuration see the application note Connecting to MicroBlaze Targets for Debug and Trace (app_microblaze.pdf). MicroBlaze Debugger and Trace 5

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

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

8 Quick Start of the Debugger 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). 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: SYStem.CPU MICROBLAZE0 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:. SYStem.CONFIG IRPOST 28. SYStem.CONFIG IRPRE 8. SYStem.CONFIG DRPOST 2. SYStem.CONFIG DRPRE 1. Note the. indicating decimal numbers. 3. Attach to the target and enter debug mode, using the multicore settings from above: SYStem.Up This command resets the CPU and enters debug mode. After executing this command, memory and registers can be accessed. MicroBlaze Debugger and Trace 8

9 4. Load a sample program.. CD ~~/demo/microblaze/hardware/ml403/mb.v710d.xmtc.100b.noddrram Data.LOAD.Elf sieve_ elf /CYGDRIVE 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: Data.List Register ; Open disassembly window ; Open register window 6. You are now ready to debug your program. MicroBlaze Debugger and Trace 9

10 Quick-Start of the Real-Time Trace 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. 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 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: SYStem.CPU microblaze0 SYStem.CONFIG IRPOST 28. SYStem.CONFIG IRPRE 8. SYStem.CONFIG DRPOST 2. SYStem.CONFIG DRPRE 1. ; XILINX EVB 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: if analyzer() ( analzyer.mode.fifo analyzer.autoinit off sys.o.dtm on sys.o.quickstop on analyzer analyzer.list ) MicroBlaze Debugger and Trace 10

11 Now we connect to the target, load the demo application and run it up to the function sieve(): SYStem.P Data.LOAD.Elf mb.v700b.xmtc/sieve/sieve_8c elf /cygdrive Go sieve Data.List You can now debug your application and observe the traced instruction stream in the analyzer.list window. MicroBlaze Debugger and Trace 11

12 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. NOTE: It is recommended to compile MicroBlaze software with the GCC option -g3. 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 SYStem.Option.LittleEnd ON The default setting is OFF, because traditionally MicroBlaze cores used big-endian byte order (in OPB and PLB systems). NOTE: For debugging little-endian systems, a TRACE32 version from December 2012 or later is recommended. MicroBlaze Debugger and Trace 12

13 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 All All All All All The target has no power. 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) 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. 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. The target is in reset: The debugger controls the processor reset and use the RESET line to reset the CPU on every SYStem.Up. You used a wrong JTAG connector on the target. In particular on ML310 always use the 14pin JTAG connector J9 for debugging Microblaze. MicroBlaze Debugger and Trace 13

14 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 script and "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen updates. Please note that if your program stops (e.g. on error) without executing "SCREEN.OFF", some windows will not be updated. "SYStem.POLLING SLOW" will set a lower frequency for target state checks (e.g. power, reset, jtag state). It will take longer for the debugger to recognize that the core stopped on a breakpoint. "SETUP.URATE 1.s" will set the default update frequency of Data.List/Data.dump/Variable windows to 1 second (the slowest possible setting). prevent unneeded memory accesses using "MAP.UPDATEONCE [address-range]" for RAM and "MAP.CONST [address--range]" for ROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read the specified address range only once after the core stopped at a breakpoint or manual break. "MAP.CONST" will read the specified address range only once per SYStem.Mode command (e.g. SYStem.Up). MicroBlaze Debugger and Trace 14

15 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 to realize by the trigger unit inside the controller. Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set window). Breakpoints with checking in real-time for data-values ("Data"). Breakpoints with special features ("action") like TriggerTrace, TraceEnable, TraceOn/TraceOFF. TRACE32 can not change the memory. Example: ROM and Flash when no preparation with FLASH.Create, FLASH.TARGET and FLASH.AUTO was made. All type of memory if the memory device is missing the necessary control signals like WriteEnable or settings of registers and SpecialFunctionRegisters (SFR). Contrary settings in TRACE32. Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type> Onchip (HARD is only available for ICE and FIRE). RTOS and MMU: If the memory can be changed by Data.Set but the breakpoint doesn't work it might be a problem of using an MMU on target when setting the breakpoint to a symbolic address that is different than the writable and intended memory location. MICROBLAZE Ref: 0422 MICROBLAZE Connection to Target Fails Ref: 0291 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). 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 Debugger and Trace 15

16 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 Debugger and Trace 16

17 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 MicroBlaze Go.Up Command Fails Ref: 0241 MicroBlaze Loading C++ programs Ref: 0272 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. 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. 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 Debugger and Trace 17

18 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 MicroBlaze On-chip Data Breaks with unaligned Memory Ref: 0239 MicroBlaze On-chip Databreak Problem Ref: 0238 MicroBlaze Problems with Source Code Display Ref: 0236 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 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 0x x2003 /read". (Note the "--" double minus for range specifiation). 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. 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 Debugger and Trace 18

19 MicroBlaze Setting Register R0 fails Why does the setting of register R0 fail? The architectural register R0 in Microblaze is hardcoded to 0. Therefore changing the register value to other values will fail. Ref: 0240 MicroBlaze Software Breakpoints or Single Stepping fail with uclinux Ref: 0259 MicroBlaze Target Connection Ref: 0234 MicroBlaze Trace Interface for MicroBlaze Ref: 0243 MICROBLAZE XPS demo applications do not work Ref: 0340 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. 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. 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. Many of the demo applications generated by the XPS (Xilinx platform studio) give feedback via printf(). Therefore be sure to open a terminal window in TRACE32, otherwise the application will appear to fail working, because it is blockes waiting for the debugger to read the output data. Use the following sequence to open a terminal window term.res ; be sure to reset terminal functionality term.method mdmuart term.size ; make T32 poll the target for text output term.gate MicroBlaze Debugger and Trace 19

20 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 MicroBlaze Debugger and Trace 20

21 Displaying MicroBlaze Core Configuration As the Microblaze core is configurable the available debug features depend on the actual core. The configuration of the core can be displayed using the command per.when pointing the mouse at an entry, the debugger displays an explanation in the status line. MicroBlaze Debugger and Trace 21

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

23 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. NOTE: The number of available onchip breakpoints depends on the configuration of the MicroBlaze core defined in the FPGA design. 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. MicroBlaze Debugger and Trace 23

24 Example for Breakpoints Assume you have a target with FLASH from 0 to 0xFFFFF and RAM from 0x to 0x11FFFF. The command to configure TRACE32 correctly for this configuration is: Map.BOnchip 0x0--0x0FFFFF The following breakpoint combinations are possible. Software breakpoints: Break.Set 0x /Program ; Software Breakpoint 1 Break.Set 0x /Program ; Software Breakpoint 2 Break.Set 0xx /Program ; Software Breakpoint 3 On-chip breakpoints: Break.Set 0x100 /Program ; On-chip Breakpoint 1 Break.Set 0x0ff00 /Program ; On-chip Breakpoint 2 Data.LOAD.Elf /CYgdrive Translate Cygwin path to OS path Format: Data.Load.Elf <filename> /CYGDRIVE 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. MicroBlaze Debugger and Trace 24

25 SYStem.Option.BrkHandler Control writing of software break handler Format: SYStem.Option BrkHandler [AUTO ON OFF] 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 preloaded with the memory image must contain a breakpoint handler. If all program memory is read-only consider the use of OnChip breaks as alternative. NOTE: A software breakpoint handler is required for using software breakpoints on MicroBlaze cores with versions < 7.20.A. SYStem.Option.BrkVector Configures an alternative breakvector Format: SYStem.Option BrkVector <vector> <vector>: 0 0xFFFC, 32-bit aligned 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. MicroBlaze Debugger and Trace 25

26 When changing the breakpoint vector, the debugger automatically uses a matching opcode for software breakpoints. NOTE: For additional information see SYStem.Option BrkHandler. SYStem.Option IMASKASM Interrupt disable on ASM Format: SYStem.Option IMASKASM [ON OFF] Mask interrupts during assembler single steps. Useful to prevent interrupt disturbance during assembler single stepping. SYStem.Option IMASKHLL Interrupt disable on HLL Format: SYStem.Option IMASKHLL [ON OFF] Mask interrupts during HLL single steps. Useful to prevent interrupt disturbance during HLL single stepping. SYStem.Option MMUSPACES Enable space IDs Format: SYStem.Option MMUSPACES [ON OFF] SYStem.Option MMUspaces [ON OFF] (deprecated) SYStem.Option MMU [ON OFF] (deprecated) Default: OFF. MicroBlaze Debugger and Trace 26

27 Enables the use of space IDs for logical addresses to support multiple address spaces. 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. Examples: ;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 SYStem.Option.ResetMode Select the reset mode Format: SYStem.Option ResetMode <mode> <mode>: CORE SYSTEM 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. MicroBlaze Debugger and Trace 27

28 TERM.Method MDMUART Terminal configuration Format: TERM.Method MDMUART 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: TERM.RESet TERM.METHOD MDMUART TERM.SIZE TERM.GATE ; be sure to reset term funtionality ; configure MDM UART for stdio ; cosmetics ; make T32 poll the target for data 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. MicroBlaze Debugger and Trace 28

29 Memory Classes The following memory classes are available: Memory Class P D Description Program memory Data memory Register Names In TRACE32, the general purpose registers (R0-R31) and special purpose registers (e.g. MSR - machine state register, SLR - Stack low register etc.) are 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. Data.Assemble 0x1000 mfs r0, MSR Data.Assemble 0x1004 mts SLR, r3 MicroBlaze Debugger and Trace 29

30 General SYStem Commands SYStem.CPU Select the used CPU Format: SYStem.CPU <cpu> <cpu>: MICROBLAZE MICROBLAZE0 MICROBLAZE1 MICROBLAZE2 MICROBLAZE3 (deprecated) 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: 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 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. 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,... ) MicroBlaze Debugger and Trace 30

31 SYStem.CpuAccess Run-time memory access (intrusive) Format: SYStem.CpuAccess Enable Denied Nonstop Default: Denied. Enable Denied Nonstop 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 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. Lock intrusive run-time memory access. Lock all features of the debugger that affect the run-time behavior. Nonstop reduces the functionality of the debugger to: Run-time access to memory and variables Trace display The debugger inhibits the following: To stop the program execution All features of the debugger that are intrusive (e.g. action Spot for breakpoints, performance analysis via StopAndGo mode, conditional breakpoints, etc.) MicroBlaze Debugger and Trace 31

32 SYStem.JtagClock Selects the frequency for the debug interface Format: SYStem.JtagClock <rate> SYStem.BdmClock <rate> (deprecated) <fixed>: Selects the JTAG clock frequency for the debug interface. For fast setup of the clock speed pre-configured buttons can be used to select commonly used frequencies. The default frequency is 1.0 MHz. NOTE: Buffers, additional loads or high capacities on the JTAG lines reduce the maximum operation frequency of the JTAG clock and should be avoided. SYStem.LOCK Lock and tristate the debug port Format: SYStem.LOCK [ON OFF] Default: OFF. If the system is locked, no access to the debug port will be performed by the debugger. While locked, the debug connector of the debugger is tristated. The main intention of the lock command is to give debug access to another tool. SYStem.MemAccess Run-time memory access Format: SYStem.MemAccess Denied No run-time memory access is possible for Microblaze cores. Denied No memory access is possible while the CPU is executing the program. MicroBlaze Debugger and Trace 32

33 SYStem.Mode Select operation mode Format: SYStem.Mode <mode> <mode>: Down NoDebug Go Attach Up Select target reset mode. Down NoDebug Go Up Attach StandBy Disables the Debugger. The state of the CPU remains unchanged. 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 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. 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. 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. Not supported. MicroBlaze Debugger and Trace 33

34 SYStem.CONFIG Configure debugger according to target topology 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] The four parameters IRPRE, IRPOST, DRPRE, DRPOST are required to inform the debugger about the TAP controller position in the JTAG chain, if there is more than one core in the JTAG chain (e.g. ARM + DSP). The information is required before the debugger can be activated e.g. by a SYStem.Up. See Daisychain Example. For some CPU selections (SYStem.CPU) the above setting might be automatically included, since the required system configuration of these CPUs is known. TriState has to be used if several debuggers ( via separate cables ) are connected to a common JTAG port at the same time in order to ensure that always only one debugger drives the signal lines. TAPState and TCKLevel define the TAP state and TCK level which is selected when the debugger switches to tristate mode. Please note: ntrst must have a pull-up resistor on the target, TCK can have a pull-up or pull-down resistor, other trigger inputs need to be kept in inactive state. Multicore debugging is not supported for the DEBUG INTERFACE (LA-7701). CORE DRPRE 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. (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. MicroBlaze Debugger and Trace 34

35 DRPOST IRPRE IRPOST TAPState TCKLevel TriState Slave (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. (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. (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. (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. (default: 0) Level of TCK signal when all debuggers are tristated. (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. (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). MicroBlaze Debugger and Trace 35

36 Daisy-chain Example TDI Core A Core B Core C Core D TDO Chip 0 Chip 1 Below, configuration for core C. Instruction register length of Core A: 3 bit Core B: 5 bit Core D: 6 bit SYStem.CONFIG.IRPRE 6 SYStem.CONFIG.IRPOST 8 SYStem.CONFIG.DRPRE 1 SYStem.CONFIG.DRPOST 2 ; IR Core D ; IR Core A + B ; DR Core D ; DR Core A + B SYStem.CONFIG.CORE ; Target Core C is Core 0 in Chip 1 MicroBlaze Debugger and Trace 36

37 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 MicroBlaze Debugger and Trace 37

38 SYStem.CONFIG.CORE Assign core to TRACE32 instance Format: SYStem.CONFIG.CORE <coreindex> <chipindex> SYStem.MultiCore.CORE <coreindex> <chipindex> (deprecated) <chipindex>: 1 i <coreindex>: 1 k 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). MicroBlaze Debugger and Trace 38

39 TrOnchip Commands TrOnchip.state Display on-chip trigger window Format: TrOnchip.state Opens the TrOnchip.state window. TrOnchip.RESet Set on-chip trigger to default state Format: TrOnchip.RESet Sets the TrOnchip settings and trigger module to the default settings. TrOnchip.CONVert Adjust range breakpoint in on-chip resource Format: TrOnchip.CONVert [ON OFF] The on-chip breakpoints can only cover specific ranges. If a range cannot be programmed into the breakpoint, it will automatically be converted into a single address breakpoint when this option is active. This is the default. Otherwise an error message is generated. TrOnchip.CONVert ON Break.Set 0x x17ff /Write Break.Set 0x x17ff /Write TrOnchip.CONVert OFF Break.Set 0x x17ff /Write Break.Set 0x x17ff /Write ; sets breakpoint at range ; ff sets single breakpoint ; at address 1001 ; sets breakpoint at range ; ff ; gives an error message MicroBlaze Debugger and Trace 39

40 TrOnchip.VarCONVert Adjust complex breakpoint in on-chip resource Format: TrOnchip.VarCONVert [ON OFF] The on-chip breakpoints can only cover specific ranges. If you want to set a marker or breakpoint to a complex variable, the on-chip break resources of the CPU may be not powerful enough to cover the whole structure. If the option TrOnchip.VarCONVert is ON the breakpoint will automatically be converted into a single address breakpoint. This is the default setting. Otherwise an error message is generated. MicroBlaze Debugger and Trace 40

41 CPU specific MMU Commands MMU.DUMP Page wise display of MMU translation table Format: MMU.DUMP <table> [<range> <addr> <range> <root> <addr> <root>] MMU.<table>.dump (deprecated) <table>: PageTable KernelPageTable TaskPageTable <magic_number> <task_id> <task_name> <cpu_specific_tables> Displays the contents of the CPU specific MMU translation table. If called without parameters, the complete table will be displayed. If the command is called with either an address range or an explicit address, table entries will only be displayed, if their logical address matches with the given parameter. The optional <root> argument can be used to specify a page table base address deviating from the default page table base address. This allows to display a page table located anywhere in memory. PageTable KernelPageTable TaskPageTable <magic_number> <task_id> <task_name> 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. 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). MicroBlaze Debugger and Trace 41