Learn about common questions and answers when debugging or tracing a target with Arm Development Studio (Arm DS) and Arm DS-5 (DS-5). This page focuses on connecting to, debugging, and tracing emulation, FPGA, and silicon targets.

To debug a target with Arm DS or DS-5, you must have the following:

  1. A debug probe, like DSTREAM, DSTREAM-ST, DSTREAM-PT, DSTREAM-HT, DSTREAM-XT, and ULINKpro family debug probes, or a Functional I/O connection.
  2. An Arm DS or DS-5 installation that supports the processor you want to debug.
  3. An Arm DS or DS-5 license that enables your Arm DS or DS-5 edition.

If you cannot find solutions to your questions here:


I have a DS-5 or Arm DS platform configuration for my target. I cannot connect to my target with DS-5 or Arm DS. Why?

Unfortunately, you can have a DS-5 or Arm Development Studio platform configuration, but still not successfully connect to your target. Many factors can prevent a successful debug connection.

The following is a list of some common reasons why a debug connection is unsuccessful:

Processors are in a powered down state
Processors are held in reset
OS is interfering with the debugger
Target is not set up for debug
Reset signal strength used by the debug probe is not correct for the target
System is unstable
Debug connector or signal issues
Debug probe or debug cable issues

The following is a list of resources to help diagnose debugger connection issues:

Back to top





Processors are in a powered down state

On some targets, processors or cores are powered down. If a core is powered down on connection, Arm Development Studio and DS-5 displays a <core_number> powered down message in the Debug Control view. If a processor or core is powered down, connecting to the processor or core or performing debug operations, like run, stop, and step, might fail.

Steps:

Back to main question

Back to top

Processors are held in reset

On some targets, processors or cores are held in reset. If a processor or core is held in reset, performing debug operations, like run, stop, and step, is not possible. If a core is in reset on connection, Arm Development Studio and DS-5 displays <core_number> held in reset in the Debug Control view.

Steps:

Back to main question

Back to top

OS is interfering with the debugger

Depending on the target, an OS might be running on the target when a debug connection is attempted. Some OSes prevent debug connections or cause unexpected debugger behavior.

The following are common items to check for when debugging a target with an OS running:

  • The OS has not powered down devices necessary for debug.
  • The OS has enabled the device clock source.
  • The OS has configured the device reset correctly.
  • The platform management controllers allow debug access.
  • If extra drivers are necessary to manage or register target resources.
  • The OS was built with debug support.

Steps:

Back to main question

Back to top

 

Target is not set up for debug

Some targets might not support debug connections out-of-the-box and might require extra steps to make a debug connection possible.

Common extra steps to check for are:

  • If you are working with an FPGA target, a debug-enabled image is loaded.  Also, the correct hardware components, like switches and cards, are used.
  • Debug connectors are enabled.
  • If debug and trace signals are shared with other devices, like General Purpose Input/Output (GPIO).

Steps:

  • Consult the target designer, manufacturer, or documentation to determine whether the target is set up for debugging.
    • If you have a target example where debug is enabled, try connecting to the example first. A successful debug connection to the target example proves that the target can be set up for debug.

Back to main question

Back to top

Reset signal strength used by the debug probe is not correct for the target

On some targets, you might need to adjust the debug probe reset signal strength for PCE autodetection to work. If the reset signal strength is incorrect for the target, autodetection does not complete successfully.

Note:  Some boards do not use the nSRST and nTRST reset signals. If the nSRST and nTRST signals are not used, check that these signals are tied off according to your debug probe documentation. Read the following for more information about the nSRST and nTRST signals:

Steps:

Back to main question

Back to top

System is unstable

If the system you have connected to is in an unstable state, the debugger connection might fail. Some examples of an unstable system are the core is in a fault or abort start or PCE autodetection fails for core-specific reasons. If the debug connection fails because of an unstable system, after connecting, a Failed to obtain target state message might appear in the Commands view.

Steps:

Back to main question

Back to top

Debug connector or signal issues

Debug connectors or the debug signals might not work as expected. Problems with debug connectors or signals can prevent Arm Development Studio or DS-5 from connecting to a target or cause unstable debug connections.

Steps:

Back to main question

Back to top

Debug probe or debug cable issues

Target autodetection is reliant on having a working debug probe and debug cables. Also, the debugger must be able to connect to and communicate with the debug probe.

If the debug probe or cable setup is not working with other targets, you might have a broken debug setup.

Steps:

Back to main question

Back to top


I can connect to my target, but I am not getting trace data or I am seeing corrupted trace data. Why?

Unfortunately, a successful debug connection does not mean trace data appears automatically or entirely valid trace data is captured. If the trace data is corrupted, a corrupted message appears in the Arm Development Studio or DS-5 Trace view.

The following are common reasons why trace data might not appear or might be corrupted:

Initial trace capture did not capture any or enough data
Trace devices are not listed in the platform configuration .sdf file
Component connection was not visible through PCE testing
Incorrect trace infrastructure
Target is not fully set up for trace
Discrepancy between possible and working trace port width
No or unstable trace clock
Trace clock signal is too fast
Working with DSTREAM-PT
Working with DSTREAM-HT
Working with DSTREAM-XT
Trace signal or connector issues
Debug probe or debug or trace cable issues

If off-chip trace, like TPIU, is not working as expected, switch to using on-chip trace.  Using on-chip trace, like ETB or ETF, might give you a better trace result.

Back to top


Initial trace capture did not capture any or enough data

When tracing, no relevant trace data or not enough trace data is captured for any data to be displayed in the Trace view. Try running the target again and see if any trace data appears.

Back to main question

Back to top

Trace devices are not listed in the platform configuration .sdf file

The Platform Configuration Editor (PCE) collects information about the trace devices behind the DAP to determine which trace devices are present. The information is collected by reading specific device debug registers. If the device debug registers are not accessible, the trace device is not added to the platform configuration. If the debug registers for a trace device are not accessible, in the PCE Console view, a Failed to read x bytes from AP <AP number> @ <component debug register base address> message appears. 

The following lists common reasons why the debug registers are not accessible:

  • The device is powered down.
  • The device cannot enter debug state. The inability to enter debug state might occur because of a stall or lock up on the memory bus.
  • Debug capability is disabled. Software running on the target, like an OS, can disable debug.

Steps:

Back to main question

Back to top



Component connection was not visible through PCE testing

The Platform Configuration Editor (PCE) interrogates a device debug registers to determine what is connected to the component.

The following are common reasons why the component connections are not found:

  • The tested component is powered down.
  • The connected components are powered down.
  • Debug capability is disabled. Software running on the target, like an OS, can disable debug.

Steps:

  1. Determine why the PCE component connection was not found and fix the issue. Read Common reasons why components and component connections do not appear and How PCE identifies the CoreSight components on the target board for help with determining why the component connection is not found.
  2. Try the autodetection process again.
  3. If the reason for the missing component connection is not determinable, manually add a component connection to the platform configuration .sdf file. For instructions on how to add a component connection, read Manually configuring a platform configuration for trace section of the Arm Debugger Manual Configuration Tutorial.

Back to main question

Back to top


Incorrect trace infrastructure

Some .sdf files might have incorrect trace component connections because of hardware issues or incorrectly connected components. For example, a trace source is connected to the wrong trace funnel port in the .sdf file. Another example, a ETMv4 trace source with both instruction and data trace only has one trace funnel port assigned to it instead of two.

Steps:

Back to main question

Back to top

Target is not fully set up for trace

Some boards might not support trace connections out-of-the-box and require extra steps to make a trace connection possible.

Common extra steps to check for are:

  • If you are working with an FPGA target, the debug and trace-enabled image is loaded. Also, the correct hardware components, like switches and cards, are used.
  • Debug and trace connectors are enabled.
  • If the target has a separate trace connector, the trace cable is plugged in.
  • If there are multiple debug or trace connectors on the target, the correct trace connector is used.
  • Trace signals are not output to a physical connector.
  • Trace signals are shared with other devices, like General Purpose Input/Output (GPIO).
  • The necessary trace devices are not powered up.

Steps:

  • Consult the target designer, manufacturer, or documentation to determine whether the target is set up for tracing.
    • If you have a target example where trace is enabled, try connecting to the example first. A successful trace connection to the target example proves that the target can be set up for trace.
  • If you are not seeing timestamps in the decoded trace data, read How do I enable timestamps in my trace?.

Back to main question

Back to top


Discrepancy between possible and working trace port width

Target documentation states the off-chip trace port width of the target. The off-chip trace port width is often referred to as the TPIU port width. When executing real-world code, you might find:

  • The effective trace port width is less than what is stated in the target documentation. For example, if the trace port width is too large, you might see no or corrupted trace in the Trace view.
  • The trace port width does not support the amount of trace data being generated. For example, if the trace port width is too small, you might see Buffer overflow messages in the Trace view.

Steps:

Back to main question

Back to top

No or unstable trace clock

You must have a valid, stable trace clock signal to capture off-chip trace data. Off-chip trace is where trace data generated on a SoC is passed to a debug probe and then to an external debugger. Off-chip trace is often referred to as Trace Port Interface Unit (TPIU) trace.

For a DSTREAM, DSTREAM-ST, or DSTREAM-PT, the TRC CLK LED indicates the state of the trace clock signal. If the TRC CLK LED is solid green, the DSTREAM family debug probe has registered a valid, stable trace clock signal. If the TRC CLK signal is not on, flashing red, or solid red, there is not a valid, stable trace clock signal.

Note: For DSTREAM-HT, the TRC CLK LED only applies when you are using parallel trace. The status of the TRC CLK LED does not apply when performing HSSTP trace.

Note: With DSTREAM-XT, trace data is acquired through the PCIe interface of the target. To learn the meanings of the trace LEDs on the DSTREAM-XT probe, read The DSTREAM-XT probe section of the DSTREAM-XT Getting Started Guide.

Steps:

Back to main question

Back to top



Trace clock signal is too fast

On some targets, the trace clock signal might be running at too high a frequency for the rate the trace data is appearing. A high trace clock frequency can cause trace buffer overflows that leads to corrupted trace data. If the trace clock frequency is too high, you might see Buffer overflow or corrupted messages in the Trace view.

Steps:

Back to main question

Back to top

Working with DSTREAM-PT

The DSTREAM-PT has a Real-Time Monitor (RTM) that calibrates the trace signals during trace capture.  The RTM allows trace data to be captured more reliably. The RTM might fail to get a lock on the trace signals for signal calibration. If the RTM cannot get a signal lock, you might not see trace data in the Trace view.

Steps:

Back to main question

Back to top

Debug probe or debug or trace cable issues

Target autodetection is reliant on having a working debug probe and debug cables. Also, the debugger must be able to connect to and communicate with the debug probe.

If the debug probe or cable setup is not working with other targets, you might have a broken debug setup or trace setup.

Steps:

Back to main question

Back to top


I am working with a certain board. Are there existing resources to help me get started?

The following links provide information about bringing up certain targets with DS-5 or Arm Development Studio:

Back to top