FAQs for JTAG-ZSP


The embedded tools company

Search FAQs



PDF document ( 49KB / 13-Oct-2016 )


TOP

Break after sys.up failed. Debug monitor (DMC) missing (ZSP5XX)

Ref: 0223
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.

TOP

Break in SW Debug Mode fails (ZSP5XX)

Ref: 0225
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.

TOP

Evaluation Board Problems (ZSP5XX)

Ref: 0220
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).

TOP

Internal and External Memory (ZSP5XX)

Ref: 0228
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.

TOP

Invalid Program Memory Content (ZSP5XX)

Ref: 0222
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.

TOP

Limitation of Debug Mode (ZSP5XX)

Ref: 0224
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.

  • TOP

    No Detection of Halt Mode (ZSP5XX)

    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.

    TOP

    Number in Brackets after a CEXE Instruction (ZSP5XX)

    Ref: 0227
    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


    TOP

    On-chip Breakpoint Ignoration (ZSP5XX)

    Ref: 0229
    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.

    TOP

    Setting Program Counter in HW Debug Mode (ZSP5XX)

    Ref: 0230
    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

  • TOP

    Sign "%-" in Disassembler Output (ZSP5XX)

    Ref: 0226
    What does the sign "%-" in the disassembler output mean?

    The sign "%-" indicates control register operands that are illegal for this instruction.

    TOP

    Single Step Fail (ZSP5XX)

    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.

    TOP

    Single Stepping Modifies %smode Register (ZSP5XX)

    Ref: 0233
    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.

    TOP

    Stop Problems in Single Step Mode (ZSP5XX)

    Ref: 0232
    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.

    TOP

    Generic MDI Error (ZSP5XXSimulator)

    Ref: 0217
    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.

    TOP

    Program Fails after Reloading (ZSP5XXSimulator)

    Ref: 0218
    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.

    TOP

    Script Fails with "Access Timeout" (ZSP5XXSimulator)

    Ref: 0219
    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.




    Copyright © 2016 Lauterbach GmbH, Altlaufstr.40, D-85635 Höhenkirchen-Siegertsbrunn, Germany  Impressum
    The information presented is intended to give overview information only.
    Changes and technical enhancements or modifications can be made without notice. Report Errors
    Last generated/modified: 13-Oct-2016