SoC Bring-Up Using the Platform Configuration Editor PCE

This tutorial shows how to use the Platform Configuration Editor (PCE) in DS-5 to detect underlying system architecture of a SoC and configure any missing elements of the system.


This tutorial shows how to use the Platform Configuration Editor (PCE) in Arm DS-5 Development Studio. By the end of this guide, you should be able to connect to an Arm-based System-on-Chip (SoC), use the PCE to detect its underlying system architecture and configure any missing elements of the system. By using the PCE, you will save time and avoid the pitfalls of manually creating debug configuration scripts.

Arm SoC Debug and Trace

In order to provide effective debug and trace support for a SoC, a debugger needs a certain amount of information. The debugger needs to know:

  • Which devices are present in the SoC (including the type and configuration details of each device, and connection details such as CoreSight base address)
  • How these devices relate or connect to each other (their topology)

DS-5 debugger can automatically detect most of this information. However, debugger sometimes fails to detect certain features. The information presented by the SoC may be incomplete or corrupted, or information may be missing because parts of the SoC are powered down, or devices inside the SoC may interfere with topology detection.

This means that a debugger often has to work with incomplete or incorrect information about a SoC. This can greatly affect the level of debug and trace functionality that the debugger can offer. The debugger could try to make assumptions based on its knowledge of other SoCs, but the flexibility of Arm-based designs means that these assumptions are often limited in their success. Often a CoreSight topology diagram is available, but we have to find some way to get the information in that topology diagram into the debugger.

How the PCE is Useful

DS-5 contains Platform Configuration Editor (PCE), which provides a simple and flexible way to add platform configuration to DS-5 debugger. In this example, the PCE is used to bring-up a SoC that in the past has caused problems. The SoC contains a mix of Cortex-A and Cortex-M cores, and the device and topology information that it presents is incomplete.

SoC Bring-Up in DS-5

The PCE is launched by selecting File > New > Other... from the DS-5 menu and then selecting DS-5 Configuration Database > Platform Configuration:

PCE Wizard in DS-5

All DS-5 platform configurations have to be stored in a configuration database. Select a configuration database, or create a new one:

Selecting or configuring a new database in the PCE of DS-5

I need to give a manufacturer and platform name:

Adding new platform information in the PCE Wizard of DS-5

In the next step, there is a choice of workflows. I would like DS-5 to do as much as possible, I don’t want to get involved in manual device addition or advanced configuration, and I don’t have an existing file to import. So I can just accept the recommended workflow:

Choosing a platform configuration workflow in the PCE of DS-5

Once I’ve selected my DSTREAM unit, DS-5 will connect to the SoC and try to read all the information it needs for debug and trace:

Specifying which debug vehicle your target is connected to

After DS-5 has gathered all the information it can from the SoC, I’m presented with a simple summary of the devices that were found in the SoC. I can choose to do nothing now (DS-5 will save the platform configuration it’s just generated, and I’ll be able connect and debug later) or I can debug straight away.

There's no need to rebuild the configuration database. That has already been done and represents a simplification over earlier DS-5 releases. The generated platform configuration will be the best that DS-5 can give from the information it could acquire from the SoC, so there may be missing functionality (particularly trace).

DS-5 PCE autodetection summary

From this device summary, I can see a Cortex-A9 and a Cortex-M3. When I try to debug the target, I find that debug works well for both cores, but I only have trace options for the Cortex-A9. I don’t have the ability to configure and collect trace for the Cortex-M3, so it looks like DS-5 couldn't acquire all the information it needed from the SoC. When I review the platform I can see this device summary:

DS-5 PCE device summary, showing ARM cores and CoreSight blocks

The left pane shows my device hierarchy: I have a DAP, which provides access to a number of Access Ports (APs) of various types, which in turn provide access to the devices. Summary device details are shown in the right pane. If I select Component Connections I can view the topology information acquired from the SoC:

DS-5 PCE summary table of component connections

Here I can see that the topology information acquired from the SoC is incomplete, and may also be corrupted. I can see two cores (Cortex-A9 and Cortex-M3) but three core trace macrocells (a PTM and two ETMs). One of the ETMs seems to be “spare”. It is connected to the trace funnels (at port 0) but doesn’t seem to be connected to either of the cores.

Topology for the Cortex-A9 looks pretty good. It is associated with both a PTM and a CTI, and the PTM is connected to the trace funnels (at port 3), then onwards to the ETB and the TPIU. This topology information was used by DS-5 when it generated the platform configuration, and the trace support that my DS-5 now offers for the Cortex-A9 works just fine. However there’s no topology information for the Cortex-M3, and this is reflected as a lack of functionality in my generated platform configuration.

Adding the link between the Cortex-M3 and its ETM is simple; we should assume that the core and its ETM are on the same AP:

DS-5 PCE dialog enabling users to link master to slave devices

However connecting the ETM to the funnels is more difficult because we have to choose a funnel port. We know that ports 0 and 3 are taken, but that leaves us with a choice of 6 ports. I could use information from a topology diagram if I had one – but since I don’t have the necessary information my only option is to try each port in turn:

Testing each port in turn to establish the correct connection in the DS-5 PCE

When I save my changes, the platform configuration is automatically rebuilt and I can connect for debug and trace. In this case I’m lucky: port 1 is the first port I tried and it’s the correct port, so now I have trace working for the Cortex-M3 as well as for the Cortex-A9. Although I had to enter some information manually I did not have to open the generated platform configuration and do any manual scripting, and this represents a significant improvement.


SoC bring-up in a debugger can be a tricky process that in the past might demand a level of debug expertise and some manual scripting. The PCE bring-up tool in DS-5 contains a number of important features that bring significant benefits to the SoC bring-up process:

  • The PCE, with support for automatic detection of platform configuration information from SoC, reduces time and effort needed to bring up a new SoC.
  • The PCE does not make assumptions about topology information that cannot be read from the SoC. This makes it easier for the user to spot the missing information, which can then be added.
  • Manually adding missing topology information can be done through the main user interface, using simple dialogs. There’s no need to hand-edit complex topology files.


As mentioned earlier, configuring an Arm-based SoC for bring-up can be tricky. Arm provides detailed technical support for our customers, so if you are finding it difficult to bring-up a particular device, don't hesitate to get in touch with us. You can raise a support case here »