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

If you cannot find solutions to your questions here:


How do I debug a target with DS-5 or Arm DS?

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, 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.

The following diagram shows the debug flow when using a new target with Arm DS or DS-5:

Note: DS-5 does not support CMSIS-Pack configurations.

Debug flow for a new target

Back to top


My target is not listed as a supported platform for DS-5 or Arm DS. How do I debug the target?

Arm Development Studio (Arm DS) and Arm DS-5 Development Studio (DS-5)  connects to and debugs targets using a platform configuration in a configuration database (configDB). In Arm Development Studio, connecting is also possible using a CMSIS Pack. Your tools license determines which processors you can debug.

Choose the tool you are using for further information:

If you are using Arm Development Studio

If you are using DS-5

Back to top

If you are using Arm Development Studio

Arm Development Studio (Arm DS) uses two methods to connect to hardware targets: configuration database (configDB) and CMSIS Packs. Read What are CMSIS software components? for an overview of CMSIS.

Arm Development Studio manages CMSIS Packs using the CMSIS-Pack Manager perspective. Watch Introduction to Pack Manager for an introduction to the Development Studio CMSIS-Pack Manager.

Arm DS Supported Processor Cores lists which processor cores Arm Development Studio supports. If your processor is not listed on this page, try connecting and debugging the processor with Arm Development Studio anyway. Debugging might work because Arm Development Studio provides generic Arm architecture support. If you are still unable to connect to or debug the processor, refer to the I need help connecting to my target. Where do I go? section of this page.

Note: Your Arm Development Studio license determines which processors you can debug. Arm DS Compare Editions contains a comparison table which lists the processors each Arm Development Studio edition supports.

The Arm Development Studio has a Hardware Connection wizard to create hardware connections. The Hardware Connection wizard lists the configDB and CMSIS Packs Arm Development Studio supports. Arm DS Supported device list lists which configDB platforms Arm Development Studio supports. CMSIS Packs lists the CMSIS-Packs available.

If your target is not listed, use the Hardware Connection wizard to create a platform configuration. The Hardware Connection wizard uses the Platform Configuration Editor (PCE) to generate platform configurations for targets. Generate a platform configuration with Arm Development Studio using:

Further tutorials on PCE are available at:

Note: Some of the following resources focus on the DS-5 tools approach, but much of the content is still relevant for Arm Development Studio.

When connecting to a new target, it is recommended that users try autodetecting the target with PCE first. If autodetection does not complete, read the Platform Configuration Editor (PCE) autodetection did not work. Why? section of this page.

Back to main question

Back to top

If you are using DS-5

DS-5 SoC and Platform Support lists which platforms DS-5 supports. If your target is not listed on this page, create a platform configuration for your target.

DS-5 Supported Processor Cores lists which processor cores DS-5 supports. If your processor is not listed on this page, try connecting and debugging the processor with DS-5 anyway. Debugging might work because DS-5 provides generic Arm architecture support. If you are still unable to connect to or debug the processor, refer to the I need help connecting to my target. Where do I go? section of this page.

Note: Your DS-5 license determines which processors you can debug. Compare section of Which version of Arm DS-5 Development Studio is right for me? contains a comparison table which lists the processors each DS-5 edition supports.

Note: DS-5 is no longer being developed, so no further processor or platform support is available.

Eclipse for DS-5 uses a perspective called DS-5 Configuration to add platform configurations to DS-5. The DS-5 Configuration perspective uses the Platform Configuration Editor (PCE) to generate platform configurations.

Generate a platform configuration with DS-5 using:

When connecting to a new target, it is recommended that users try autodetecting the target with PCE first. If autodetection does not complete, read the Platform Configuration Editor (PCE) autodetection did not work. Why? section of this page.

Back to main question

Back to top


I have been given a configuration database or platform configuration. How do I use it?

Arm Development Studio and DS-5 use platform configurations to connect to boards. Platform configurations are stored in configuration databases (configDBs). If you are given a platform configuration or a configuration database, add it to the debugger using the following tool-specific steps:

If you are using Arm Development Studio

If you are using DS-5

Back to top


If you are using Arm Development Studio

Arm Development Studio supports autodetecting boards with the DSTREAM, DSTREAM-ST, DSTREAM-PT, DSTREAM-HT, and ULINKpro family debug probes. From Arm Development Studio 2020.0, target connection using the ST-LINK debug probe from STMicroelectronics is supported.

You can add other debug probes, referred to as third party probes or 3PP, to Arm Development Studio for connection, autodetection, and debug purposes. The Third-party Debug Probe API section of the Arm Development Studio User Guide and the Add a third party debug probe section of the Arm Development Studio User Guide explain how to add a non-Arm debug probe to Arm Development Studio. Easier to add support for 3rd party probes shows how to add support for third party probes.

Note: The preceding video focuses on DS-5, but most of the content remains the same for Arm Development Studio.

If your target uses CoreSight SoC-600, which conforms to the ARM Debug Interface Architecture Specification ADIv6.0, you might be able to connect and debug your target using Functional I/O.  Some Functional I/O connections types are USB, PCIe, and TCP IP. The Debug and trace over functional I/O section of the Arm Development Studio User Guide and the Add a debug connection over functional I/O section of the Arm Development Studio User Guide describe how to use Functional I/O with Arm Development Studio. Support for ADIv6 shows how to use Functional I/O.

Back to main question

Back to top

If you are using DS-5

DS-5 supports autodetecting boards with DSTREAM and DSTREAM-ST. If you are using DS-5 v5.29.x, DS-5 supports autodetecting boards with the ULINKpro family debug probes.

If you are using DS-5 5.29.x, you can add other debug probes, referred to as third party probes or 3PP, to DS-5. The Adding a third-party debug probe section of the Arm DS-5 Debugger User Guide describes how to add a custom debug probe to DS-5. Easier to add support for 3rd party probes shows how to add support for third party probes.

Back to main question

Back to top



I am working with a certain target. 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


Platform Configuration Editor (PCE) autodetection did not work. Why?

PCE autodetection might not work for various reasons. The following lists cover common reasons why autodetection fails and provides steps to resolve the issue:

No devices or an incorrect number of devices is discovered on the JTAG scan chain

Most external debuggers communicate with the JTAG scan chain of the target either through JTAG or Serial Wire Debug (SWD). PCE interrogates the devices on the JTAG scan chain to determine the number and type of devices on the scan chain.

The following lists common reasons why PCE might not find any devices or an incorrect number of devices on the JTAG scan chain:

Locked devices on the scan chain
Secure devices on the target
Debug Access Port (DAP) or other components on the JTAG scan chain are not powered up
Target is running too slowly
PCE is receiving unrecognized device IDs
Target not set up for JTAG communication
Need Serial Wire Debug (SWD) rather than JTAG
Reset signal strength used by the debug probe is not correct for the target
Debug connector or signal issues
Debug probe or debug cable issues

The JTAG scan chain is complete, but PCE did not find any devices to debug 

If you have a target that uses the CoreSight debug infrastructure, the components to debug are usually behind a Debug Access Port (DAP).

DAPs and possibly other JTAG scan chain components are found when autodetecting a target with PCE.  PCE might not find any components to debug.

The following list gives common reasons PCE might not find any components to debug behind a DAP:

DAP cannot be powered up
Wrong number or type of Access Ports (APs) found
AHB-AP or APB-AP ROM Table cannot be found
AHB-AP or APB-AP ROM Table is incomplete or incorrect
PCE could not get the identifying information for the devices behind the DAP

The following list provides resources to help you diagnose Platform Configuration Editor (PCE) autodetection issues:

If you need assistance with bringing up your target, refer to the I need help connecting to my target. Where do I go? section of this page.

Back to top

Debug Access Port (DAP) or other components on the JTAG scan chain are not powered up

A target can have one or more components directly connected to the JTAG scan chain. If any of these connected components are powered down from a debug perspective, the scan chain is not read correctly.

If working with a CoreSight target, if the DAP is powered down, none of the devices behind the DAP, like the processors and trace components, are found.

Steps:

Back to main question

Back to top

Target not set up for JTAG communication

On some targets, steps must be taken to enable JTAG communication.

Steps:

  • Consult the target designer, manufacturer, or documentation to determine if extra steps are required to establish JTAG communication to the target.
    • If the target has a working debug example image or setup, try using that for testing and comparison purposes to your own custom environment.

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 targets 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

Debug connector or signal issues

Sometimes debug connector or the debug signals are not working 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. 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

Wrong number or type of Access Ports (APs) found

The DAP has APs that allow accesses to devices for debug and trace purposes. The Platform Configuration Editor (PCE) tries to detect which APs are present behind the DAP. If the APs are not tied off according to the integration documentation, PCE is unable to determine where the APs end. PCE assumes the maximum number of APs are present. In the PCE Console view, this behavior is shown as the autodetection process finding many APs.

Steps:

Back to main question

Back to top

AHB-AP or APB-AP ROM Table cannot be found

If components are connected to a Debug Port (DP) or a Memory Access Port (MEM-AP), the DP or MEM-AP has a ROM Table. The ROM Table provides a listing of what components are attached to the DP or MEM-AP. If PCE does not find a ROM Table for a DP or MEM-AP, a No ROM table is present on this AP message appears in the PCE Console view. If you see this message for a DP or MEM-AP that does have a ROM Table, do the following step.

Steps:

Back to main question

Back to top

AHB-AP or APB-AP ROM Table is incomplete or incorrect

There are several ways a ROM Table can be incorrect or incomplete. Incorrect or incomplete ROM Tables cause components on the target not to be added to the platform configuration. The following is a list of common ROM Table issues:

  • If the PRESENT bit is not set for a ROM Table entry, the PCE Console view shows the message Entry present bit not set, no device interrogation will occur. If the PRESENT bit is not set, PCE ignores the ROM Table entry. The corresponding component is not added to the platform configuration. 
  • If a ROM Table contains the wrong address for a nested ROM Table, the components listed in the nested ROM Table are not added to the platform configuration.
  • A ROM Table is terminated correctly by having a 0x0 entry or having an entry at ROM Table offset 0xEFC. If the ROM Table is not terminated correctly, the PCE autodetection process might not find all the components on the target.
  • If a ROM Table is missing entries for components connected to the associated DP or AP, PCE does not add the components to the platform configuration.

Steps:

Back to main question

Back to top

PCE could not get the identifying information for the devices behind the DAP

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

Steps:

Back to main question

Back to top


The Platform Configuration Editor (PCE) autodetection process completed. I see unexpected messages in the PCE Console. What do these messages mean?

Even if the PCE autodetection process completes successfully, you might still see unexpected messages in the PCE Console view.

For information on the PCE autodetection process and common PCE Console view messages, read How PCE identifies the CoreSight components on the target board and How to configure debug and trace.

To test the responsiveness or presence of certain components, you can interact with them using the CoreSight Access Tool (CSAT) or the CoreSight Access Tool for SoC600 (CSAT600). The following lists reference material for CSAT and CSAT600:

If you are using a CoreSight target, you can obtain a log of the low-level debug activity. If you are using a DSTREAM family unit, consult the How to use the DAP logger tool KBA for instructions on how to capture a DAP log. If you are using a ULINKpro family unit, consult the How can I use the ULINK debug probe to collect the debug log in Arm DS? KBA for instructions on how to capture a debug log.

Note: You must have a good understanding of the following to interpret the logs:

  • CoreSight Architecture
  • CoreSight components
  • The target CoreSight topology details
  • Processor-specific debug information, like the CoreSight register offsets

Back to top


The Platform Configuration Editor (PCE) autodetection process completed. I see unexpected messages at the top of the .sdf file. What do these messages mean?

Even if the Platform Configuration Editor (PCE) autodetection process completes successfully, you might still see unexpected messages. These messages appear:

  • In the Summary dialog shown at the end of the autodetection process
  • At the top of the platform configuration SDF file, .sdf file extension

If the messages are in yellow text, the messages are warnings.

If the messages are in red text, the messages are errors.

Steps:

Back to top


When my target is autodetected, why do some component or component connections not appear?

For a summary of common reasons why PCE does not discover component or component connections, read Common reasons why components and component connections do not appear.

The following list provides common reasons why PCE does not discover components or component connections:

The Platform Configuration Editor (PCE) is receiving unrecognized device IDs
AHB-AP or APB-AP ROM Table cannot be found
AHB-AP or APB-AP ROM Table is incorrect or incomplete
PCE could not get the identifying information for the devices behind the DAP
Invisible component connections
Component connection is not visible through PCE testing

The following list offers further help for diagnosing missing component or component connections:

Back to top

AHB-AP or APB-AP ROM table cannot be found

If components are connected to a Debug Port (DP) or a Memory Access Port (MEM-AP), the DP or MEM-AP has a ROM Table. The ROM Table provides a listing of what components are attached to the DP or MEM-AP. If PCE does not find a ROM Table for a DP or MEM-AP, a No ROM table is present on this AP message appears in the PCE Console view. If you see this message for a DP or MEM-AP that does have a ROM Table, do the following step.

Steps:

Back to main question

Back to top

AHB-AP or APB-AP ROM table is incomplete or incorrect

There are several ways a ROM Table can be incorrect or incomplete. Incorrect or incomplete ROM Tables cause components on the target not to be added to the platform configuration. The following is a list of common ROM Table issues:

  • If the PRESENT bit is not set for a ROM Table entry, the PCE Console view shows the message Entry present bit not set, no device interrogation will occur. If the PRESENT bit is not set, PCE ignores the ROM Table entry. The corresponding component is not added to the platform configuration. 
  • If a ROM Table contains the wrong address for a nested ROM Table, the components listed in the nested ROM Table are not added to the platform configuration.
  • A ROM Table is terminated correctly by having a 0x0 entry or having an entry at ROM Table offset 0xEFC. If the ROM Table is not terminated correctly, the PCE autodetection process might not find all the components on the target.
  • If a ROM Table is missing entries for components connected to the associated DP or AP, PCE does not add the components to the platform configuration.

Steps:

Back to main question

Back to top

PCE could not get the identifying information for the devices behind the DAP

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

Steps:

Back to main question

Back to top

Invisible component connections

Note: This content only applies if you are using an Arm Development Studio version earlier than 2020.0.

Some targets might contain components which have no programmer's model or are not listed in a ROM Table. If either of the preceding is true, the component is invisible to the PCE autodetection process. The component connections might not be added to the generated .sdf file. A Device x has multiple connections to master interface y, check for correctness warning message might appear at the top of the .sdf file.

Steps:

Back to main question

Back to top

Component connection is 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 debug section of the Arm Debugger Manual Configuration Tutorial.

Back to main question

Back to top


What resources are there to customize my platform configuration or connection options?

The following are some resources available to help customize your platform configuration or connection options in DS-5 or Arm Development Studio:

Back to top