|
|
|
 |
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
.
NS=secure
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:
Onchip.DISable
Onchip.Attach
SYStem.Mode Attach
Break
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
SYStem.Option MULTIPLEFIX ON
|
|
|
|
|
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:
|
