TRACE32 Documents... ICD In-Circuit Debugger... Processor Architecture Manuals... ZSP... ZSP Debugger... 1

Transcription

1 ZSP Debugger TRACE32 Online Help TRACE32 Directory TRACE32 Index TRACE32 Documents... ICD In-Circuit Debugger... Processor Architecture Manuals... ZSP... ZSP Debugger... 1 Brief Overview of Documents for New Users... 4 ESD Protection... 6 FAQ... 7 Quick Start JTAG Troubleshooting System Up Errors 14 System Startup for EB System Startup for EB500P (ZSP500) 15 Configuration 16 Hardware and Software Debug Modes 18 ZSP500 Hardware Debug Mode 18 ZSP500 Software Debug Mode (Default) 19 ZSP500 Mixed Software and Hardware Debug Mode 19 Breakpoints 20 Breakpoints in ROM (ZSP500) 20 CPU specific TrOnchip Commands TrOnchip.CONVert Adjust range breakpoint in on-chip resource 22 TrOnchip.RESet Set on-chip trigger to default state 22 TrOnchip.state Display on-chip trigger window 22 Memory Access Memory Addressing (ZSP400) 23 Memory Addressing (ZSP500) 24 General System Settings SYStem.CPU Selects the processor type 25 SYStem.CpuAccess CPU access mode 25 SYStem.JtagClock Selects the frequency for the debug interface 26 SYStem.MemAccess Memory access mode 27 ZSP Debugger 1

2 SYStem.Mode Selects target reset mode 28 SYStem.CONFIG Configure debugger according to target topology 30 SYStem.Option EnReset Allow the debugger to drive nreset (ZSP400) 33 SYStem.Option HardwareDebug Select debug mode (ZSP5xx) 34 SYStem.Option IBOOT Configure IBOOT board signal (ZSP5xx) 35 SYStem.Option IMASKASM Disable interrupts while ASM single stepping 35 SYStem.Option IMASKHLL Disable interrupts while HLL single stepping 35 SYStem.Option.ADIAFTERBREAKIN Handling of external breakpoints 35 SYStem.Option.BREAKOUTAFTERSWBREAK Creating a break-out signal 37 SYStem.Option MEMDEU Memory access via DEU (ZSP5xx) 38 SYStem.Option RisingTDO TDO sampled on rising TCK edge (LSI402ZX) 38 SYStem.Option SLOWRESET Slow reset 38 SYStem.Option SVTADDR Configure SVTADDR (ZSP500) 39 Multicore Debugging SYStem.LOCK Lock debug port (ZSP400) 40 Design Decisions and Limitations (ZSP5xx) Disassembler 41 Timer0, Timer1 Registers 41 Single Stepping over RETI Fails 41 Software Breakpoints in CEXE Blocks 41 On-chip Breakpoints (ZSP500 Hardware Erratum) 42 Software Debug Mode and Hardware Debug Mode 42 Simulator Interface for ZSP5xx Cores Limitations of the Simulators 43 File I/O with Simulator Targets 43 Performance Measurements with Simulator Interface 44 JTAG Connector Mechanical Description of 20-pin Debug Cable for ZSP400/ZSP Mechanical Description of JTAG Connector for ZSP400 (obsolete) 45 Technical Data Mechanical Dimensions 46 Operation Voltage 46 Operating Frequency 46 Support Probes 47 Available Tools 47 Compilers ZSP Compilers ZSP Target Operating Systems 48 3rd Party Tool Integrations 49 Products ZSP Debugger 2

3 Product Information 50 Order Information 50 ZSP Debugger 3

4 ZSP Debugger Version 06-Nov-2017 B::SYStem Mode MemAccess Option Down CPU IMASKASM NoDebug Denied IMASKHLL Go CpuAccess SLOWRESET Attach Enable StandBy Denied Up (Stand Nonstop MultiCore Up JtagClock CPU 5.0MHz LSI402ZX B::Var.Frame /Locals /Caller -000>sieve() ()i = 0x0000 ()primz = 0x0003 ()k = 0x01C8 ()anzahl = 0x end of frame B::Data.List addr/line source int anzahl; 684 anzahl = 0; 686 for ( i = 0 ; i <= SIZE ; flags[ i++ ] = TRUE ) ; 688 for ( i = 0 ; i <= SIZE ; i++ ) { 690 if ( flags[ i ] ) { 692 primz = i + i + 3; 693> k = i + primz; 694 while ( k <= SIZE ) { 696 flags[ k ] = 697 k += primz; 698 } 699 anzahl++; } } 703 return anzahl; LSE; Brief Overview of Documents for New Users Architecture-independent information: ZSP Debugger 4

5 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. ZSP Debugger 5

6 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. ZSP Debugger 6

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

8 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. ZSP5XX Break after sys.up failed. Debug monitor (DMC) missing Ref: 0223 ZSP5XX Break in SW Debug Mode fails Ref: 0225 After sys.up I get the following error message: 'Break after sys.up failed. Debug monitor (DMC) missing? Try loading DMC in HW mode.' What does this mean? If in SW mode, the debugger tries to set a SW breakpoint at the reset vector address (configured via sys.o.svtaddr). If this succeeds, the core will stop at the first instruction at the reset vector after sys.up. If this fails, the debugger tries to stop the core asynchronously by asserting the Debug Emulation Interrupt (DEI). If also this fails it is likely that there is no debug monitor code (DMC) in the target and TRACE32 generates a warning. In that case link your target program with a DMC and load it after switching to HWD mode. For more information see the sys.up command. What does the following message mean: "Break in SW mode failed. Switch to HW debug mode to continue."? Under certain conditions the core cannot enter the SW debug mode. One reason is that the core enters halt mode when a program compiled with the LSI SDK terminates. Therefore the core does not execute instructions anymore and cannot enter the DMC. By entering the HWD mode (sys.o.hardwaredebug on), one can see where the core is stopped and memory contents can be examined. ZSP Debugger 8

9 ZSP5XX Evaluation Board Problems Ref: 0220 ZSP5XX Internal and External Memory Ref: 0228 ZSP5XX Invalid Program Memory Content Ref: 0222 ZSP5XX Limitation of Debug Mode Ref: 0224 Resetting the EB500P Eval board does not work reliably and sometimes I get the message "access timeout, processor running" Be sure to enable the option sys.o.slowreset. This makes the debugger wait for 1000ms after releasing the reset line (recommended by LSI for EB500P Eval board). How does the debugger distinguish between internal and external memory? The debugger accesses memory addresses according to the current value of the DIR and DDR bits in the %smode register. There is no support for paged memory. Also, the upper bits of memory address (e.g. bit 31 internal/external, bit 30 data/instruction) are not interpreted by the debugger. After booting, the core executes the program correctly but the debugger shows invalid program memory contents. In the address range P:0x0--0x1FFFF the ZSP500 can map internal and external program memories. The actual memory is selected by a board-level signal. Set sys.option IBOOT and sys.option SVTADDR so the debugger shows the same memory area that is accessed by the core. What does the following message mean: "Limitations of ZSP500 HW debug mode apply. See manual."? There is a number of limitations associated with HWD mode: Setting the PC is unreliable and may fail Single stepping is not possible The shown PC is imprecise See the section "Hardware and Software Debug Modes" for more details. ZSP5XX No Detection of Halt Mode Ref: 0231 The core has entered halt mode but the debugger indicates "running" state. Why is that? The debugger cannot detect if the target enters halt mode without stopping the core clock and there fore will show "running" when the target enters halt mode. When the user does a break (debugger in SW mode) while the target is in halt mode, this will fail because the target will not enter the debug monitor. TRACE32 detects this situation and report the target's operation mode (normal, idle, sleep, halt). In order to continue debugging in the aforementioned situation switch to HWD mode and do a break again. The core will be stopped in HWD mode and you can read memory contents and registers. ZSP Debugger 9

10 ZSP5XX Number in Brackets after a CEXE Instruction Ref: 0227 ZSP5XX On-chip Breakpoint Ignoration Ref: 0229 ZSP5XX Setting Program Counter in HW Debug Mode Ref: 0230 What does the number in brackets after a CEXE instruction mean? CEXE instructions are disassembled slightly differently from the ZSP SDK: The number of instructions belonging to a CEXE block is indicated by a number in curly brackets rather than by a pair of brackets around the body of the CEXE block. The sample code indicates that the three following instructions are part of the conditionally executed block: cexe (z,nu){3} it_a r2,r8,r4 mov %loop1, r5 mov %loop3, r1 In SWD mode sometimes on-chip breakpoints are ignored. Why is that? When hitting an on-chip breakpoint the debugger will switch the core from HWD mode to SWD mode. In the process of doing this, all instructions in the pipeline are executed (draining the pipeline). To avoid hitting additional, closely located on-chip breaks ("double-break scenario"), on-chip breaks are disabled temporarily while draining the pipeline. What does the following message mean: "Attempted to set PC:=0x1234 in HW mode. This may have failed or worked. See manual"? Setting the program counter in HW debug mode is not possible reliably in HW debug mode (ZSP500 issue). In many cases setting the PC will succeed, in other cases the core will ignore the new PC. This behavior seems to be related to the instructions currently in the pipeline. Conditional branches seem to cause problems. For reliably setting the PC proceed as follows: sys.o.hardwaredebug off switch to SWD mode, requires a DMC! r.s PC 0x1234 set the PC sys.o.hardwaredebug on switch back to HWD mode ZSP5XX Sign "%-" in Disassembler Output What does the sign "%-" in the disassembler output mean? The sign "%-" indicates control register operands that are illegal for this instruction. Ref: 0226 ZSP5XX Single Step Fail Ref: 0221 I cannot single step my program. The core starts running and does not stop. This may happen if the program is located in Flash or ROM memory. As the debugger cannot set SW breakpoints a single step operation will start the core but not stop it. Use the break command to stop the core asynchronously. ZSP Debugger 10

11 ZSP5XX Single Stepping Modifies %smode Register Why does single stepping modify the %smode register? This is a side effect of the debug monitor code. It toggles the ICT (instruction cache toggle) bit in %smode at each step invalidating the instruction cache. This is done because the PC might have been set to a new address by the debugger. Ref: 0233 ZSP5XX Stop Problems in Single Step Mode Ref: 0232 ZSP5XXSimula tor Generic MDI Error When single stepping, the debugger does not stop at the last HLL line. Why? When steping over the last HLL of a function, the debugger does not stop at the closing bracket "}" before returning to the calling function. This is because the ZSP compiler does not treat the function epilogue with closing bracket as separate source line in the debug information. What is a "Generic MDI error"? The most frequent cause of the "Generic MDI error" message is when an unsupported simulator target is selected before sys.up. Ref: 0217 ZSP5XXSimula tor Program Fails after Reloading Ref: 0218 ZSP5XXSimula tor Script Fails with "Access Timeout" Ref: 0219 Why does a program fail when it is loaded the second time? The reason for this problem (only in cycle accurate simulation) is that with zsim simulators (CA) it is not possible to set the PC (similar to HWD mode in silicon targets). When you load the program first (after sys.up) the PC will be already be 0. When you reload the program, the PC will be inside your program. Therefore you need to reset the PC to 0 by doing sys.d/sys.up fo restarting the program. Simply reloading the program with d.load.elf will not work. A script fails with "Access timeout" but only in cycle accurate mode. Why? The following code sequence (most of the time) works on the cycle zisim but fails on zsim with "Access timeout, processor running": data.load.elf cr/cr077/clobber.elf b.s 0x150 go print v.value(main\main_1234) This fails only in cycle accurate mode. The reason is that zisim (instruction accurate) is very fast and will hit the break point before T32 executes the next line (print v.value(main\main_1234)). As zsim (cycle accurate) is slower, it will take considerable time to arrive at the break point and stop: T32 will try to access the memory before the stopped core is detected. Solution: Add a WAIT 10.ms statement or WHILE RUN() loop to the PRACTICE script. ZSP Debugger 11

12 Quick Start JTAG Starting up the Debugger is done as follows: 1. Select the device prompt B: for the ICD Debugger. b: If you are working with the PODPC card, a Podbus-Ethernet interface or a Podbus-Parallel adapter device b:: is already selected. 2. Select the CPU type to load the CPU specific settings. SYStem.CPU LSI402ZX SYStem.o.RisingTDO ON // only for LSI402ZX 3. Tell the debugger where s FLASH/ROM on the target. MAP.BOnchip 0x0f800++0xFFFF This command is necessary for the use of on-chip breakpoints. 4. Enter debug mode SYStem.Up This command resets the CPU (RESET) and enters debug mode. After this command is executed it is possible to access the CPU registers. 5. Load the program. Data.LOAD.Elf diabc.x ; elf specifies the format, ; diabc.x is the file name The option of the Data.LOAD command depends on the file format generated by the compiler. For information on the compiler options refer to the section Compiler. A detailed description of the Data.LOAD command is given in the General Commands Reference. ZSP Debugger 12

13 The start-up can be automated using the PRACTICE script programming language. A typical start sequence is shown below: b:: WinCLEAR MAP.BOnchip 0x x0FFFF SYStem.cpu LSI402ZX SYStem.o.RisingTDO ON SYStem.Up Data.LOAD.Elf diabc.x ; Select the ICD device prompt ; Clear all windows ; Specify where s ROM ; Select the processor type ; Create specific option; only LSI402ZX ; Reset the target and enter debug mode ; Load the application Data.List ; Open disassembly window *) Register /SpotLight ; Open register window *) Frame.view /Locals /Caller Var.Watch %Spotlight flags ast ; Open the stack frame with ; local variables *) ; Open watch window for variables *) PER.view ; Open window with peripheral register **) Break.Set sieve ; Set breakpoint to function sieve Break.Set 0x1200 /Program ; Set software breakpoint to address 1200 ; (address 1200 is in internal memory) Break.Set 0xf900 /Program ; Set on-chip breakpoint to address ; 0xf900 (address 0xf900 is in ROM) *) These commands open windows on the screen. The window position can be specified with the WinPOS command. **) There is no predefined peripheral file for ZSP500 as there is no standard peripheral register mapping. ZSP Debugger 13

14 Troubleshooting System Up Errors The SYStem.Up command is the first command of a debug session where communication with the target is required. If you receive error messages while executing this command this may have the following reasons. All All All All All LSI402ZX LSI403.. EB403 The target has no power. The target is in reset: The debugger controls the processor reset and uses the RESET line to reset the CPU on every SYStem.Up. There is logic added to the JTAG state machine: By default the debugger supports only one processor on one JTAG chain. If the processor is member of a JTAG chain the debugger has to be informed about the target JTAG chain configuration. See Multicore Debugging. There are additional loads or capacities on the JTAG lines. The pull-up resistor between the JTAG[VCCS] pin and the target VCC is too large The system option RisingTDO is switched OFF (default!). It must be switched ON before a system up will be done. The system option RisingTDO is switched ON. It must be switched OFF before a system up will be done. The system option EnReset is switched on (default!). Switch the EnReset option OFF, reset the target by pressing the reset button for at least 2 s and do a system up afterwards. See note below. ZSP Debugger 14

15 System Startup for EB403 For the EB403 of LSI SYStem.Up will not work, if the system option enreset was not switched OFF before. This is because the reset signal influences the TRST signal and prevents the target from booting. Therefore the EB403LP requires a special boot sequence which does not assert the reset signal. 1. ; Connect JTAG cable, while target power is off 2. ; Start debugger 3. SYS.O ENRESET OFF ; Disable reset 4. ; Switch target power on 5. SYStem.Up ; Do system up of target via debugger After the first SYStem.Up, subsequent SYStem.Up commands will only succeed after resetting the board by pressing the reset button for at least 2 s. System Startup for EB500P (ZSP500) The EB500P evaluation board requires up to 1000 ms delay after releasing the reset line in order to initialize. For taking into account this delay, enable the option for slow reset: sys.option SLOWRESET ON In the default configuration the EB500P will boot from Flash at 0xF800. For correct debugger operation the IBOOT and SVTADDR variables need to be configured: sys.option IBOOT OFF sys.option SVTADDR 0xf800 If configured incorrectly, the debugger may show internal instruction memory contents (RAM) in the range of the IBOOT windows (0xF800-0xFFFF) instead of the Flash memory which is accessed by the core. In many configurations the EB500P will boot a demo program with flashing LEDs. As this program is located in Flash memory it is not possible to set SW breakpoints and therefore it is not possible to single step this program. NOTE: The EB500P eval board is equipped with a 20 pin (J13) and a 10 pin (J14) connector for attaching a JTAG debugger. Which of these connectors is actually connected to the core depends on the FPGA configuration (depends on board versions). In case of problems attaching the debugger to the target, please try the other connector. ZSP Debugger 15

16 TRIG POWER 7-9 V TRIG POWER 7-9 V PODBUS IN POWER SELECT EMULATE RECORDING TRIGGER CON ERR TRANSMIT RECEIVE COLLISION PODBUS OUT PODBUS SYNC POWER SELECT RUNNING LINK ACTIVITY PODBUS OUT PODBUS EXPRESS OUT C B A Configuration HUB 100 MBit Ethernet PC or Workstation Debug Cable Target POWER DEBUG / ETHERNET Ethernet Cable USB ETHERNET LAUTERBACH RESERVED FOR POWER TRACE DEBUG CABLE DEBUG CABLE LAUTERBACH JTAG Connector POWER DEBUG / ETHERNET AC/DC Adapter HUB 1 GBit Ethernet PC or Workstation POWER DEBUG II Debug Cable Target Ethernet Cable USB ETHERNET DEBUG CABLE DEBUG CABLE LAUTERBACH JTAG Connector LAUTERBACH POWER DEBUG II AC/DC Adapter ZSP Debugger 16

17 TRIG POWER 7-9 V PODBUS IN POWER SELECT EMULATE PODBUS OUT PC Target Debug Cable USB Cable USB POWER DEBUG INTERFACE / USB2 LAUTERBACH DEBUG CABLE DEBUG CABLE LAUTERBACH JTAG Connector POWER DEBUG INTERFACE / USB 2 AC/DC Adapter ZSP Debugger 17

18 Hardware and Software Debug Modes The ZSP cores support two different debug modes: Hardware debug mode (HWD) and Software debug (SWD) mode. In SWD mode there must be a debug monitor (DMC) in the target. Technically the DMC is an exception handler which is called when a debug interrupt request is performed by the debugger (e.g. for stopping the core) or as result of program execution (e.g. when hitting a SW breakpoint). In HWD mode the core resources (registers, memories, ) are accessed using a hardware device emulation unit (DEU), obviating the need for a SW debug monitor. Using the hardware debug mode requires that the core has a register scan chain (which is not always the case) and that TRACE32 knows its layout. For ZSP400 only SWD mode and SW breakpoints are supported by TRACE32. There is no support for onchip breakpoints. For ZSP500 both modes ares supported. The mode is selected by SYStem.Option HardwareDebug. As HWD mode is specific for each implementation and sometimes even depends on the chip revision of a ZSP500 core, the correct core needs to be selected before activating HWD mode. Currently only EB500P is supported in HWD mode. If you want to debug your core in HWD mode, please check that the core actually supports HWD mode (there are ZSP5xx implementations without a scan chain) and contact LAUTERBACH support. Selection with sys.cpu ZSP40x ZSP500, ZSP540, ZSP600 EB500P (from LSI Eval Board) ; Supported Mode ; SWD ; SWD ; SWD + HWD ZSP500 Hardware Debug Mode The main advantage of the HWD mode is that no debug monitor program is required in the target. Also the HWD mode works even if the core is in a state that does not allow it to enter the DMC (e.g. in halt mode). The hardware debug mode requires that the debugger knows the exact layout of the register scan chain. This layout is specific for each core version and describe in a register map file. The mapfile for ZSP500 (from EB500P eval board, COREID 0x D) is known to T32. For using other cores in HW debug mode please contact LAUTERBACH support for instructions. The main drawback of HWD mode is that the shown PC is imprecise. The PC shown is that of the RD pipeline stage, not that of the EX stage. As the core can have up to 32 instructions between the pipeline stages RD and EX, the PC may be wrong by that number of instructions. In general the shown PC will be ahead of actual program execution. The instruction indicated will not necessarily be on the execution path of the core (e.g. in case of conditional branches). ZSP Debugger 18

19 On-chip breakpoints may be used in HW debug mode. Due to their implementation, the core will not stop exactly at the requested instruction (IA breaks) or the when the specified data (DAB, DAV breaks) is accessed. Software breakpoints are not supported in HWD mode. Single stepping cannot be implemented in HWD mode due to imprecise on-chip breakpoints and program counter (PC). SW breakpoints cannot be used in HWD mode due to the lack of the DMC. Setting the program counter (PC) is not reliable in hardware mode (ZSP500 hardware issue). In many cases setting the PC will succeed, in other cases the core will ignore the new PC. This behavior seems to be related to the instructions currently in the pipeline. Conditional branches seem to cause problems. For reliably setting the PC proceed as follows (provided there is a DMC in the target): sys.o.hardwaredebug off r.s PC 0x1234 sys.o.hardwaredebug on ; Switch to SWD mode ; Set the PC ; Switch back to HWD mode Despite these limitations the HWD mode is useful in particular situations where the SWD mode does not function anymore e.g. when the core entered halt mode and will not execute the DMC anymore. In that case you can switch the debugger into HWD mode and analyze registers and memory. Generally the SWD mode is more convenient than HWD and the latter is employed as a last resort if it fails. ZSP500 Software Debug Mode (Default) The advantages of the SWD mode are the unlimited number of (software) breakpoints and the fact that the shown program counter (PC) is precise i.e. it corresponds to the next instruction to be executed. Due to pipelining effects the latter is not the case in hardware debug mode. Software breakpoints are implemented by writing a breakpoint instruction at the requested address and require writable memory. In SW debug mode the TPC (trap program counter) register is not visible because the PC of the interrupted instruction is passed in the TPC register. The actual PC register points to the SW Debug Monitor and is irrelevant for the debugged program. ZSP500 Mixed Software and Hardware Debug Mode For targets that support hardware debug mode, TRAC32 supports the unique so-called mixed hardware and software debug mode. In this debug mode, TRACE32 uses a debug monitor (DMC) as in software debug mode but at the same time allows to use OnChip breakpoints. NOTE: The mixed mode only works for targets that also support the hardware debug mode. ZSP Debugger 19

20 Breakpoints There are two types of breakpoints available: Software breakpoints and on-chip breakpoints (ZSP500 only). For SW breakpoints there must be writable memory at the required address. As single stepping is implemented via SW breakpoints, it is not possible to step through code in Flash or ROM. On-chip breaks are not entirely precise and may stop the core too late: the PC may have advanced beyond the instruction causing the break. SW breakpoints do not have this problem. Using on-chip breaks in SW mode is implemented by switching the core from HWD mode (entered after hitting the on-chip break) into SWD mode. This transition will take effect after the pipeline is empty i.e. with some delay (normally less than 8 instructions). Therefore the core will stop beyond the breakpoint e.g. inside a subroutine even if the break was set on the call instruction. Despite this, the shown PC is always precise in SW mode i.e. points to the next instruction to be executed. NOTE: the core might encounter additional, closely located on-chip breaks while draining the pipeline. As this would disturb the draining process, the following on-chip breaks are disabled while switching from HWD to SWD mode (and re-enabled before continuing program execution later). Breakpoints in ROM (ZSP500) With the command MAP.BOnchip <range> it is possible to define address ranges in which the debugger uses on-chip breakpoints on default. Commonly the command is used to inform the debugger about ROM (FLASH, EPROM) memories on the target. If a breakpoint is set within the specified address range the debugger uses automatically the available on-chip breakpoints. Alternatively on-chip breakpoints can be set using the /OnChip parameter: break.set 0xf890 /OnChip Assuming a target with ROM from 0xF800 to 0xFFFF, Flash memory from 0x to 0x10.FFFF, and otherwise internal memory or RAM. The commands to configure TRACE32 correctly for this configuration are: Map.BOnchip 0xf800++0x0xffff Map.BOnchip 0x x10ffff Based on these settings, TRACE32 will automatically select the appropriate type of breakpoint (on-chip or software) for each address as shown below: Break.Set 0x4000 /Program ; Software Breakpoint 1 Break.Set 0xf750 /Program ; Software Breakpoint 2 Break.Set 0x /Program ; Software Breakpoint 3 ZSP Debugger 20

21 Break.Set 0xf810 /Program Break.Set 0x10100 /Program ; On-chip Breakpoint (in ROM) ; On-chip Breakpoint (in Flash) ZSP Debugger 21

22 CPU specific TrOnchip Commands 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 TrOnchip.RESet Set on-chip trigger to default state Format: TrOnchip.RESet Sets the TrOnchip settings and trigger module to the default settings. TrOnchip.state Display on-chip trigger window Format: TrOnchip.state Opens the TrOnchip.state window. ZSP Debugger 22

23 Memory Access The following memory classes are available: Memory Class P D Description Program memory Data memory Whether the debugger accesses internal or external memory is determined by the current setting of the %smode register bits DDR (disable internal data RAM) and DIR (disable internal instruction RAM). Therefore the debugger will always show the memory contents that would be accessed by the core in its current state. Be sure to configure SYStem.Option.IBOOT and SYStem.Option.SVTADDR for taking into account the IBOOT window. Memory Addressing (ZSP400) Internally the memory addresses are 16 bit addresses. Therefore the ZSP400 addresses always the range 0x0000-0xffff. Since the ZSP400 may have up to 5 instruction memories and up to 5 data memories with the same address range the address will be expanded to a 8 digit address. The TRACE32 debugger uses the same address format as the debugger of the SDK development kit. The address format is as follows: Digit 7 Digit 6 Digit 5 Digit 4 Digits pageno int/ext instr/data address where Digit /Name Description 7 not relevant 6 / page external page number (stored in mempcr) 5 / ext 1 to access external memory 0 to access internal memory 4 / instr 0 to access instruction memory 2 to access data memory bit address ZSP Debugger 23

24 Address examples: Data.Set 0x1000 0x0 Data.Set 0x x1234 Data.Set 0x xf Data.Set 0x xa611 Data.Set 0xc x0 ; writes 0x0 into internal instruction ; memory at address 0x1000 ; writes 0x1234 into internal data memory ; at address 0x4000 ; writes 0xf into external instruction ; memory page 0 ; writes 0xa611 into external instruction ; memory page 2 at address 0x2500 ; writes 0x0 into external data memory ; page 0xc at address 0x0 Data.Set 0x12a000 0x55 ; writes 0x55 into external memory page 0 ; at address 0xa000 Trying to access memory not belonging to the memory map of the processor will be refused with the error message no memory mapped at address D: Memory Addressing (ZSP500) In ZSP500 mode, there is no special interpretation of the upper bits of the memory by the debugger. Program or data memory are selected with the P: and D: memory access qualifiers. The distinction between internal and external memory is made using the current value of the %smode processor register: Bit 0 (DDR) and 1 (DIR) disable internal data RAM respectively internal instruction RAM. Therefore memory displayed via Data.dump or Data.List will show the same memory area that the core would access in its current state. ZSP500 may implement a so-called IBOOT (internal boot) window for supporting booting from external memory. If the IBOOT signal is enabled (ON), the core will access internal memory within the IBOOT window s address range (fixed at P:0xF800--0xFFFF), provided %smode=0 (as is the case after a reset). When the IBOOT signal is disabled (OFF), the core will access external memory in this address range (regardless of the %smode register). The IBOOT signal is external to the core and cannot be determined by the debugger itself. Therefore to show the correct memory area (internal vs. external) in the IBOOT window, sys.o.iboot needs to be configured. ZSP Debugger 24

25 General System Settings SYStem.CPU Selects the processor type Format: SYStem.CPU <cpu> <cpu>: ZSP400 LSI402ZX LSI403LP LSI403Z ZSP500 ZSP540 Selects the processor type. SYStem.CpuAccess CPU access mode Format: SYStem.CpuAccess <mode> <mode>: Enable Denied Nonstop Default: Denied. The option controls whether the debugger may (briefly) interrupt program execution in order to access system memory for updating memory display windows or setting breakpoints etc. Enable Denied Nonstop Allow intrusive run-time memory access. If CpuAccess is Enabled, setting breakpoints and accessing memories is possible by briefly stopping program execution. Lock intrusive run-time memory access. By selecting Denied most accesses are blocked. Lock all features of the debugger that affect the run-time behavior. The setting Nonstop guarantees that any accesses are suppressed that could affect real-time behavior of the target program. ZSP Debugger 25

26 SYStem.JtagClock Selects the frequency for the debug interface Format: SYStem.JtagClock <rate> SYStem.BdmClock <rate> (deprecated) <fixed>: (ZSP400) (ZSP500) Selects the frequency for the debug interface. For a fast setup of the clock speed the pre-configured buttons can be used to enter the clock speed. These are the most commonly used frequencies. The default frequency for the fixed clock is 5 MHz. The following commands are only used in case of multicore systems with ARM CPU. Please refer to SYStem.JtagClock in ARM Debugger (debugger_arm.pdf) for a detailed description ARTCK CRTCK CTCK RTCK Accelerated Returned TCK - clock mode. Compensation by RTCK - clock mode. Compensation by TCK - clock mode. Returned TCK - clock mode. NOTE: Buffers, additional loads or high capacities on the JTAG/COP lines reduce the maximum operation frequency of the JTAG clock and should be avoided. The mode CRTCK can not be used if a DEBUG INTERFACE (LA-7701) or a debug cable with 14-pin flat cable (LA-7740) is used. And it is required that the target provides a RTCK signal. ZSP Debugger 26

27 SYStem.MemAccess Memory access mode Format: SYStem.MemAccess <mode> <mode>: CPU Denied The option controls if system memory can be accessed while the core is executing. CPU Denied A run-time memory access is made without CPU intervention while the program is running. This is only possible on the instruction set simulator. No memory access is possible while the CPU is executing the program. ZSP400: The switch is fixed to the denied state because there is no way to access memory while the core is running. ZSP500: The switch can be set as desired. If enabled, memory is accessed via the device emulation unit (DEU). The DEU is a bus master device that can access all internal and external system memories and busses independently of and without stopping the ZSP500 core. For deciding whether to access internal or external memory the debugger uses the current setting of the %smode register. For ZSP500 this option should be changed only while the debugger is in SYStem.Up mode. ZSP Debugger 27

28 SYStem.Mode Selects target reset mode Format: SYStem.Mode <mode> <mode>: Down NoDebug Go Attach Up Selects the target operation mode. Note that in multicore debugging the actual behavior is also influenced by the option SYStem.CONFIG Slave. Down NoDebug Go Attach StandBy Up Disables the debugger. The state of the CPU remains unchanged. The JTAG port is tristated. ZSP500: Keeps target in rest by holding the reset line asserted. Disables the debugger. In this mode no debugging is possible. For further use of the debugger, system mode Attach must be chosen. The state of the CPU can be stopped or running. ZSP500: Disables on-chip breakpoints in the target, resumes execution and detaches from the target. Resets the target with debug mode enabled and prepares the CPU for debug mode entry. After this command the CPU is running and can be stopped with the break command or until any break condition occurs (breakpoint or external trigger). This command does not reset the target CPU. After this command the CPU is prepared for debug mode. The state of the CPU can be stopped or running. Not available for ZSP. Resets the target, sets the CPU to debug mode and stops the CPU. After execution of this command the CPU is stopped and prepared for debugging. ZSP500: In SW debug mode the debugger sets a SW break at the reset vector to stop the core at the first instruction after the reset. For this to work correctly the following prerequisites must be met: 1. There must be RAM at the reset vector so the debugger can write the SW break. 2. A DMC (debug monitor code) must be loaded with the application. The application must be compiled such that SVT (system vector table) is loaded at the reset vector 3. SYStem.Option.SVTADDR must be configured to point to the reset vector which is configured for the hardware. SYStem.Option.IBOOT must be configured correctly and reflect the hardware's setting of the IBOOT signal (off=external ram, on=internal ram) ZSP Debugger 28

29 If any of these conditions is not met, the core will not hit the SW break after SYStem.Up. The core will therefore execute code before being stopped asynchronously by the debugger after some unavoidable delay. Due to reset delay requirements ( ms) the amount of code executed may be substantial. In HW mode no breakpoint is set to the reset vector (on-chip breaks are cleared by the reset). SYStem.Up will therefore stop the core as soon as possible. However, this will normally takes some milliseconds so the core executes a substantial amount of code. NOTE: With the EB500P board, configured to boot from address 0xF800 and IBOOT=OFF (demo program with running LEDs), the core will not stop at the reset vector (neither in HW mode nor in SW mode). This is because there is flash memory at the reset vector and the SW break cannot be written. The core will therefore stop as soon as the debugger sends the asynchronous stop command. Due to the flash memory it is also not possible to single step through this demo program. ZSP Debugger 29

30 SYStem.CONFIG Configure debugger according to target topology Format: SYStem.CONFIG <parameter> <number_or_address> SYStem.MultiCore <parameter> <number_or_address> (deprecated) <parameter>: (JTAG) CORE DRPRE DRPOST IRPRE IRPOST TAPState TCKLevel TriState Slave state <parameter>: (BugFix) BYPASS <pattern> FILLDRZERO The four parameter IRPRE, IRPOST, DRPRE, DRPOST are required to inform the debugger about the position of the TAP controller 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 example below. TriState has to be used if more than one debugger are connected to the common JTAG port at the same time. 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, EDBGRQ must have a pull-down resistor. Multicore debugging is not supported for the DEBUG INTERFACE (LA- 7701). CORE DRPRE tbd. (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. ZSP Debugger 30

31 DRPOST IRPRE IRPOST TAPState TCKLevel TriState Slave state BYPASS <pattern> FILLDRZERO (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. See also Daisy-Chain Example. (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 more than one debugger share the same JTAG port, this option is required. The debugger switches to tristate mode after each JTAG access. Then other debuggers can access the port. (default: OFF) If more than one debugger share the same JTAG port, all except one must have this option active. Only one debugger - the master - is allowed to control the signals ntrst and nsrst (nreset). Show state. With this option it is possible to change the bypass instruction pattern for other cores in a multicore environment. It only works for the IRPOST pattern and is limited to 64 Bit. The specified pattern (hexadecimal) will be shifted least significant bit first. If no BYPASS option is used, the default value is 1 for all bits. This is a workaround for a certain chip problem available on ARM9 debugger only. With this option it is possible to change the bypass data pattern for other cores in a multicore environment. It changes the pattern from all 1 to all 0. This is a workaround for a certain chip problem available on ARM9 debugger only. ZSP Debugger 31

32 Daisy-Chain Example IRPOST IRPRE TAP1 TAP2 TAP3 TAP4 TDI IR DR 4 1 IR DR 3 1 IR DR 5 1 Core IR DR 6 1 TDO DRPOST DRPRE IR: Instruction register length DR: Data register length Core: The core you want to debug Daisy chains can be configured using a PRACTICE script (*.cmm) or the SYStem.CONFIG.state window. The PRACTICE code example below explains how to obtain the individual IR and DR values for the above daisy chain. PRACTICE code example: SYStem.CONFIG.state /Jtag ; optional: open the window SYStem.CONFIG IRPRE 6. ; IRPRE: There is only one TAP. ; So type just the IR bits of TAP4, i.e. 6 SYStem.CONFIG IRPOST 12. ; IRPOST: Add up the IR bits of TAP1, TAP2 ; and TAP3, i.e = 12 SYStem.CONFIG DRPRE 1. ; DRPRE: There is only one TAP which is ; in BYPASS mode. ; So type just the DR of TAP4, i.e. 1 SYStem.CONFIG DRPOST 3. ; DRPOST: Add up one DR bit per TAP which ; is in BYPASS mode, i.e = 3 ; This completes the configuration. NOTE: In many cases, the number of TAPs equals the number of cores. But in many other cases, additional TAPs have to be taken into account; for example, the TAP of an FPGA or the TAP for boundary scan. ZSP Debugger 32

33 TapStates 0 Exit2-DR 1 Exit1-DR 2 Shift-DR 3 Pause-DR 4 Select-IR-Scan 5 Update-DR 6 Capture-DR 7 Select-DR-Scan 8 Exit2-IR 9 Exit1-IR 10 Shift-IR 11 Pause-IR 12 Run-Test/Idle 13 Update-IR 14 Capture-IR 15 Test-Logic-Reset SYStem.Option EnReset Allow the debugger to drive nreset (ZSP400) Format: SYStem.Option EnReset [ON OFF] Determines, if the debugger may assign/deassign the HRESET signal. Generally the HRESET pin of the JTAG connector resets the CPU and HRESET will be assigned during SYStem.Up, SYStem.NoDebug, SYStem.Go and SYStem.Down. If a target board doesn t reset the CPU with the HRESET signal (EB403LP of LSI!) the system option EnReset must be switched off before a SYStem.Up will be done. It may be necessary after switch off the EnReset that the target board must be reset again with the reset button. ZSP Debugger 33

34 SYStem.Option HardwareDebug Select debug mode (ZSP5xx) Format: SYStem.Option HardwareDebug [ON OFF] Default: Off. The option is used to switch the debugger to hardware debug mode (ON) or software debug mode (OFF). Software debug mode offers better features but requires a DMC in the target. Hardware debug mode has a number of limitations. See section Hardware and Software Debug Modes for details. The option needs to be set before connecting the debugger to the target. Changing the option after attaching to the target has no effect and will not switch to the requested debug mode. ZSP Debugger 34

35 SYStem.Option IBOOT Configure IBOOT board signal (ZSP5xx) Format: SYStem.Option IBOOT [ON OFF] Default: OFF The option needs to be configured according to the actual setting of the IBOOT signal on the target board. This is required so that the debugger can display the correct memory contents in the address range of the so-called IBOOT window. The setting OFF corresponds to a LOW signal on the target board, the setting ON corresponds to a HIGH signal. Note that also the start address of the IBOOT window needs to be configured via SYStem.Option SVTADDR. SYStem.Option IMASKASM Disable interrupts while ASM single stepping Format: SYStem.Option IMASKASM [ON OFF] Mask interrupts during assembler single steps. Useful to prevent interrupt disturbance during assembler single stepping. SYStem.Option IMASKHLL Disable interrupts while HLL single stepping Format: SYStem.Option IMASKHLL [ON OFF] Mask interrupts during HLL single steps. Useful to prevent interrupt disturbance during HLL single stepping. SYStem.Option.ADIAFTERBREAKIN Handling of external breakpoints Format: SYStem.Option.ADIAFTERBREAKIN [ON OFF] Default: Off. When the option is enabled, after an external breakpoint TRACE32 asserts a debug interrupt (ADI). ZSP Debugger 35

36 This option is intended for handling external breakpoints in ZSP systems that do not support HWD mode. This can be due to an unknown or not implemented register scan chain. External breakpoints are typically created by the cross-triggering logic of a multi-core chip. The sequence for handling an external break is as follows: When attaching to the core, TRACE32 shifts (among other commands) DEI_ENABLE_ICE DEI_E0B_CPU (DEI := 0x70c0) (DEI := 0xba8a) When an external breakpoint (break signal) is asserted, the ZSP core disables the core clock TRACE32 detects the external breakpoint because of the stopped core clock TRACE32 shifts the JTAG commands sequence DEI_RESUME (DEI := 0x2080) DEI_ADI (DEI := 0x6080) and thus causes the core to enter the SWD mode Due to the inevitable delay between DEI_RESUME and DEI_ADI, the core will execute some code before entering the SWD mode. At a JTAG clock of 5 MHz this takes approximately 8 microseconds. NOTE: The option must be set while in SYStem.Mode.Down (before connecting to the core via SYStem.Up or SYStem.Attach) or an error message command locked will be displayed. NOTE: For systems that do support HWD mode, the option should not be used. For these systems TRACE32, after an external breakpoint, automatically switches to SWD mode using a method incurring a delay of only a few clock cycles. ZSP Debugger 36

37 SYStem.Option.BREAKOUTAFTERSWBREAK Creating a break-out signal Format: SYStem.Option.BREAKOUTAFTERSWBREAK [ON OFF] Default: Off. When this option is enabled, after hitting a SW breakpoint a break-out signal is created. Technical background: A break-out signal is created by stopping the ZSP s clock (assuming proper configuration of the chips cross-break logic). On ZSP, a SW breakpoint is implemented by an ADI (assert debug interrupt) exception that branches into a debug monitor (DMC). This in itself does not stop the core clock. Therefore TRACE32 sets an auxiliary onchip breakpoint onto the ADI exception vector. This auxiliary onchip breakpoint will be hit immediately after raising the ADI exception and assert the break-out signal. Finally, when TRACE32 detects that the auxiliary onchip breakpoint was hit, it automatically resumes execution of the debug monitor. NOTE: The option must be set while in SYStem.Mode.Down (before connecting to the core via SYStem.Up or SYStem.Attach) or an error message command locked will be displayed. NOTE: In order to set the auxiliary onchip breakpoint, it is mandatory to correctly set SYStem.Option.SVTADDR! If the address is set incorrectly, no break-out signal will be generated. ZSP Debugger 37