FAQs Archive for ZSP Debugger

The embedded tools company

Search FAQs

PDF document ( 121KB / 27-Mar-2022 )

A script fails with "Access timeout" but only in cycle accurate mode. Why? (ZSP5XXSimulator)
Ref: 0219

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
Break.Set 0x150
PRINT VAR.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.

After booting, the core executes the program correctly but the debugger shows invalid program memory contents. (ZSP5XX)
Ref: 0222

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.

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? (ZSP5XX)
Ref: 0223

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.

How does the debugger distinguish between internal and external memory? (ZSP5XX)
Ref: 0228

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.

I cannot single step my program. The core starts running and does not stop. (ZSP5XX)
Ref: 0221

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.

In SWD mode sometimes on-chip breakpoints are ignored. Why is that? (ZSP5XX)
Ref: 0229

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.

Resetting the EB500P Eval board does not work reliably and sometimes I get the message "access timeout, processor running" (ZSP5XX)
Ref: 0220

Be sure to enable the option SYStem.Option.SLOWRESET. This makes the debugger wait for 1000ms after releasing the reset line (recommended by LSI for EB500P Eval board).

The core has entered halt mode but the debugger indicates "running" state. Why is that? (ZSP5XX)
Ref: 0231

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.

What does the following message mean: "Attempted to set PC:=0x1234 in HW mode. This may have failed or worked. See manual"? (ZSP5XX)
Ref: 0230

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:


switch to SWD mode, requires a DMC!

Register.Set PC 0x1234 set the PC

switch back to HWD mode

What does the following message mean: "Break in SW mode failed. Switch to HW debug mode to continue."? (ZSP5XX)
Ref: 0225

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.

What does the following message mean: "Limitations of ZSP500 HW debug mode apply. See manual."? (ZSP5XX)
Ref: 0224

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.

What does the number in brackets after a CEXE instruction mean? (ZSP5XX)
Ref: 0227

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

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

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

When single stepping, the debugger does not stop at the last HLL line. Why? (ZSP5XX)
Ref: 0232

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.

Why does a program fail when it is loaded the second time? (ZSP5XXSimulator)
Ref: 0218

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.

Why does single stepping modify the %smode register? (ZSP5XX)
Ref: 0233

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.

Copyright © 2023 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany   Impressum     Privacy Policy
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: 02-Jan-2023