FAQs for ARM Debugger

The embedded tools company

Search FAQs

PDF document ( 100KB / 08-May-2021 )

Does TRACE32 need access to the ROM table to read the CoreSight settings?
Ref: 0462

The ROM table can be scanned in TRACE32 using the command SYStem.DETECT DAP . However, TRACE32 does not rely on the ROM table. If the chip is supported by TRACE32 then it is enough to select the right CPU using the command SYStem.CPU . Otherwise, the CoreSight settings have to be set up with a script using the SYStem.CONFIG commands.

How to access the memory on Arm Cortex-A/R without stopping the CPU?
Ref: 0519

The debugger cannot access the memory on run-time through the CPU. Thus an external bus has to be used e.g. AHB or AXI. This access method only works if an AHB or AXI is present.
You have to take into consideration that the AHB/AXI bus will generally bypass caches. In the case where the address is cacheable and the memory value is only updated in the cache but not in memory (write-back cache), its current state will be invisible to the debugger.

To enable the real-time memory access use the command:
    SYStem.MemAccess AXI | AHB | ...
Use the E: access class for memory dumps and the %E option when displaying variables:
    Data.dump E:0x10000000
    Var.View %E MyVar

How to generate and load debug information using a Greenhills Compiler?
Ref: 0432

Depending on the version the following parameters must be passed to the compiler:
C-Code: -g -dual_debug -dwarf2
C++-Code: -g -dual_debug -dwarf2 -no_ignore_debug_references
Please note that not all options can be selected in the user interface and must be added manually in the compilers configuration file. Within TRACE32 it is recommended to load the files with option /GHS e.g.:
Data.LOAD.Elf filename /GHS

I get an "emulation running" error when I try to stop the target with the Break command.
Ref: 0518

The target did not respond to the break request. Possible reasons are:
  • Current command does not finish: e.g. a memory access which hangs. In case an ETM trace is available, it can be used to analyze to program flow. The SNOOPer trace can be used otherwise to sample the program counter. If the PC is stuck at a single address (which is not the idle loop) then the processor is most probably hanging.
  • Processor is in secure mode and debugging in secure mode is not allowed. Check the Debug Status and Control Register by executing the command PER , "Debug Registers" /DualPort .
    means that the processor is in secure mode and SPIDDIS=yes that debugging in secure more is not allowed. For some cores, TRACE32 PowerView shows in this case the message "running (secure world)" in the status line.
  • Core has no power.
  • Core is in reset.

Is it possible to attach to the target without resetting the onchip trace?
Ref: 0501

You should use the following command sequence to attach to the target without loosing the onchip trace contents e.g. in case the onchip trace has already been set up by the target application and should not be reset by the debugger:
SYStem.Mode Attach
The trace contents can be then displayed using the command Trace.List .

Is it possible to set an on-chip breakpoint on a physical address for a processor with enabled MMU?
Ref: 0476

On-chip breakpoints trigger on addresses used by the core. If the Memory Management Unit (MMU) is enabled, the core uses virtual addresses. It is thus not possible to set an on-chip breakpoint using the physical address. Please note that specifying the memory class A: has no effect, the given address will be simply considered as virtual address. You should instead find all virtual addresses that are mapped to the given physical address and set an on-chip breakpoint on each virtual address. This won't work however in case the address mapping is created after setting the breakpoint.
The TRACE32 command MMU.INFO <address> can be used to find all virtual to physical address mappings for a given physical address.

Is there a register on ARM Cortex cores that can be used by the target program to detect if a debugger is connected?
Ref: 0454

There is a register called DBGDSCR (Debug Status and Control Register) which can be used for this purpose. In fact, if the debugger connects to the core it will set the bit 14 "DBGDSCR.HDen" ("Halting debug-mode enable" bit). This bit is cleared on reset.

The CPU selection is set to "NONE" when I try to detect my Arm chip using the command SYStem.DETECT.
Ref: 0455

The SYStem.DETECT command is not intended to detect the used CPU on Arm, but to detect the DAP in the JTAG chain. Please check if your chip is listed under SYStem.CPU . If not, please contact the Lauterbach support (support@lauterbach.com) and specify your TRACE32 software version. You may also check if the chip is officially supported by Lauterbach using the "Chip" search field on the Lauterbach web site.

What is the functionality of the DBGACK and DBGREG signals?
Ref: 0577

These signals can be used for fast triggering/stopping. For older Arm cores previous to CoreSight, these signals were used for synchronous halt/stop of all cores in a multicore system. They are not needed for Cortex cores which can be started/stopped synchronously using the CTI.
An example is to start/stop multiple chips/targets synchronously.
Both signals are generally not provided by the chip anymore. They should be not connected in the debug header in this case.

When displaying the DRAM memory some values are flickering.
Ref: 0499

Most probably, the DRAM controller is not optimally set. The timing may be tight so that the problem occurs with certain external events. In case the DRAM is not soldered, the issue could be due to a contact problem. Moreover, the problem could depend on the temperature. Another possibility is that the memory bus is operated over its limit.

Please note that the debugger memory access could cause a memory flickering in some rare cases (see below), however the whole memory will flicker in these cases and not only some memory cells:

  • Core clock and JTAG clock not synchronous. The solution here is to decrease the JTAG clock (e.g. SYStem.JtagClock 50Khz ) or use RTCK if available.
  • The debugger memory access uses burst access. Some chips however do not allow such accesses. You can disable burst access with the command

Why do I get a "debug port fail" error message when I try to establish a debug connection over JTAG?
Ref: 0517

The error message "debug port fail" is returned when the TDO response is different from the expected one.
Different reasons could cause such a wrong behavior. Please refer for more information to the Troubleshooting chapter in the ARM Debugger Manual.

Why do I get a "target power fail" error message when I try to establish a debug connection?
Ref: 0516

The error message "target power fail" is returned when no target power is detected. Please check if the target power is turned on. If the error persists, check if the VCC pin on the debug connector is powered (without and with debug cable connected).
Please check for more information about the VTREF operation voltage the following document:

Copyright © 2021 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: 08-May-2021