ARM’s developer website includes documentation, tutorials, support resources and more.
Over the next few months we will be adding more developer resources and documentation for all the products and technologies that ARM provides.
CloseSorry, your browser is not supported. We recommend upgrading your browser. We have done our best to make all the documentation and resources available on old versions of Internet Explorer, but vector image support and the layout may not be optimal. Technical documentation is available as a PDF Download.
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:
General new target knowledge
New target help
| I need help connecting to my target. Where do I go? |
| I am working with a certain target. Are there existing resources to help me get started? |
Platform Configuration Editor autodetection
To debug a target with Arm DS or DS-5, you must have the following:
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.
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:
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.
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.
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:
Add a configuration database section of the Arm Development Studio User Guide shows how to add a configuration database to Arm Development Studio.
Add a Platform Configuration to a Configuration Database section of the Arm Development Studio User Guide shows how to add a platform configuration to Arm Development Studio.
Adding a configuration database to DS-5 section of the Arm DS-5 Debugger User Guide shows how to add a configuration database to DS-5.
Installing Debug Support Packages for Custom or Third Party Devices tutorial shows how to add a platform configuration to DS-5.
Choose the tool you are using for further information:
Arm Development Studio supports autodetecting boards with the DSTREAM, DSTREAM-ST, DSTREAM-PT, DSTREAM-HT, and ULINKpro family debug probes.
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.
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.
If you need help with connecting to your target with Arm Development Studio or DS-5, read Requesting help with board bring-up.
The following links provide information about bringing up certain targets with DS-5 or Arm Development Studio:
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:
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:
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.
Some targets have one or more locked devices on the JTAG scan chain. Program these devices to make the JTAG scan chain accessible.
Steps:
Some targets have one or more secure devices on the JTAG scan chain or on the target. Program these devices to make the JTAG scan chain and components on the target accessible for debug.
Steps:
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:
PCE can have difficulties autodetecting a target which is running at low frequencies. Emulation and simulation targets often run at low frequencies.
Steps:
PCE tries to identify components on the JTAG scan chain by clocking out their identifying (ID) information. If PCE cannot find a match for an ID received, the component is not added to the platform configuration.
Note: PCE is mostly only aware of Arm-implemented JTAG components.
Steps:
On some targets, steps must be taken to enable JTAG communication.
Steps:
PCE defaults to using JTAG as the debug connection type. Some boards or target connectors only support SWD.
Steps:
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.
Steps:
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:
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:
If the DAP is powered down, no components are found behind the DAP. If PCE is unable to power up the DAP, in the PCE Console view, a Failed to power up DAP error message appears.
Steps:
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:
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:
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:
Steps:
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:
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 activity using the DAP logger tool. This tool works with the DSTREAM family units, like DSTREAM, DSTREAM-ST, DSTREAM-PT, DSTREAM-HT. Consult the How to use the DAP logger tool KBA for instructions on how to capture a DAP log.
Note: You must have a good understanding of the following to interpret the DAP log output:
Even if the Platform Configuration Editor (PCE) autodetection process completes successfully, you might still see unexpected messages. These messages appear:
If the messages are in yellow text, the messages are warnings.
If the messages are in red text, the messages are errors.
Steps:
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 following list offers further help for diagnosing missing component or component connections:
PCE tries to identify components on the JTAG scan chain by clocking out their identifying (ID) information. If PCE cannot find a match for an ID received, the component is not added to the platform configuration.
Note: PCE is mostly only aware of Arm-implemented JTAG components.
Steps:
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:
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:
Steps:
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:
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:
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:
Steps:
The following are some resources available to help customize your platform configuration or connection options in DS-5 or Arm Development Studio:
Important Information for the Arm website. This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.
