Arm recently announced Development Studio, a new suite of tools for editing, compiling, and debugging embedded C/C++ software for the Arm architecture. Arm Debugger can be used with virtual prototypes, hardware emulators, FPGA prototypes, and many different Arm boards using a variety of connection methods. Development Studio connects and communicates with models using the Component Architecture Debug Interface (CADI). Development Studio can connect to any model which supports CADI. As an interface, CADI has a few interesting aspects including being a self-describing API which is architecture independent. CADI uses synchronous function calls when the target is stopped and asynchronous function calls for run control from the models. For more information refer to the CADI Developer Guide.
Although CADI has done a good job connecting debuggers to Arm models, it’s time for a new solution which covers both debug and trace functionality. The new solution is called Iris and is now available in Fast Models 11.5. If you are starting now to create a new debugger connection or implementing other tools with debug and trace functionality it’s highly recommended to use Iris and get the benefit of a single solution compared to using CADI for debug functionality and Model Trace Interface (MTI) for trace features.
Arm silicon partners are constantly working to create unique systems and software using Arm IP. More software teams have also been creating custom Fast Models systems for continuous integration (CI) and continuous testing (CT). For engineers working on these projects, creating a unique virtual platform based on Fast Models is critical.
Fast Models are great for early software development and continuous integration. Fast Models excel at tasks such as:
Compared to previous Arm tools, the connection between Development Studio and Fast Models has been improved. It’s much easier to know where to start and requires about half of the steps required in the past.
This article outlines the process and provides some tips to help connect Development Studio to Fast Model systems and start running and debugging as quickly as possible.
A heterogeneous system with multiple Arm CPUs running different software will be used to demonstrate the process. The system has a single Cortex-A53 and a quad-core Cortex-R8. Each has different software and a different memory map.
The diagram from the Fast Models System Canvas is shown below. Each CPU has memory and a PL011 UART attached to it for input and output.
The goal is to connect Development Studio, customize the debug configurations, and start software debugging. It is possible to focus on only one CPU core, one CPU cluster, or debug all CPUs at the same time.
The initial setup is a one-time task per system and once it’s done it’s just one click to disconnect and one click to reconnect.
The default Development Studio layout provides the Project Explorer and the Debug Control is a single view. This makes it easy to navigate and avoids changing perspectives.
The New Debug Connection button in the lower left in the Debug Control panel invokes the wizard to connect to a model.
First, select Model Connection and click Next.
Next, a dialog to name the debug connection will appear. Provide a name for the connection and click Next.
The next dialog is the place to click “Add a new model…” so Development Studio can be made aware of the custom Fast Model system.
The next dialog provides two options to choose from:
The first option, Launch, tells Development Studio to take care of starting the simulation and connect to the simulation when it starts. Development Studio will also take care of terminating the simulator when instructed to disconnect from the target. Everything can be done from within Development Studio when using this option. To make the connection Development Studio passes two arguments to the simulation: --cadi-server and --print-port-number and expects to be able to use the output from the printed port number to make the CADI connection. The specific model can be an executable or a script, but make sure it gets the arguments passed by Development Studio.
The second option, Browse, tells Development Studio to look for an already running simulation and assumes it has been started manually. It also means that when debugging the simulation must be started manually before DS can connect. When Development Studio disconnects the simulator will not be terminated.
Select the method that best fits the desired use case.
When using the launch method, use the File button to navigate to the executable or script used to start the simulation. If a script is used make sure to pass through the command line arguments sent by Development Studio. For example, using bash to do some environment setup and run a simulation called system_sim should add $* to the command name. The default name for Fast Model systems is isim_system, but it may be something else depending on the compilation flow used.
#!/bin/bash <do some environement setup> ./run_system_sim $*
To use the Launch method enter the path to the simulation executable or script to launch and click Finish.
To use the Browse method to connect to a running simulation click the Browse button, select the running simulation and it will appear in the Model field. Select the simulation then click Finish.
Development Studio will import the Fast Model system and it will appear in the Imported area of the available model connections.
Click the Finish again and the debug configuration dialog will open.
Development Studio uses debug configurations to manage connections to target systems. There are 3 important tabs on the dialog: Connection, Files, and Debugger. In the Connection tab select the CPUs for the debugger to connect to.
The Files tab can be used to specify the software to load. It can be from the file system or from a C/C++ project workspace. If the image has already been loaded by the virtual platform, the Load Symbols from a file is a good option since there is no need to write the image to target memory.
The Debugger tab can be used to either debug from the image entry point or debug from a symbol such as main. Usually the “Debug from entry point” is the best option for bare metal software development.
Use Apply to save at any time and the Debug button to connect to the target.
Right-click to disconnect as connect as needed keeping in mind the previously described choices of launching the simulation or connecting to an already running simulation.
When Development Studio is restarted all that is needed is to right-click the connection and connect.
Since the example system also includes a Cortex-A53 CPU another debug configuration can be created to connect to it. This time select the Cortex-A53 from the imported system. This enables the ability to set a different software image on the Cortex-A53.
Another tip is to copy the first debug configuration and just change the software image and the CPU to connect to. To copy a debug configuration use Run -> Debug Configurations to open the debug configurations and right click the existing configuration and select “Duplicate”. This will guarantee that everything else is the same.
Now Development Studio can connect to the Cortex-R8 cluster, the Cortex-A53, or both. Of course, if only one of the debug configurations is connected it means the other will not get any software loaded. To solve this problem, load the software into the Fast Model system directly using the -a option for load application.
DS will show both connections and all Development Studio windows will be linked to the selected CPU context.
Development Studio is an excellent debugger for Arm software development. Because it can connect to many different target types, it takes a little more setup to import and connect to a custom Fast Model simulation. Hopefully, this article provided some additional insight into how to quickly connect to a new system and start debugging. After the one-time setup has been completed the connection process is a simple two-click process.
The primary benefit of Development Studio is a single, synchronized view of all cores in the system. This makes understanding multi-core systems much more manageable compared to connecting a debugger to each core and trying to manage multiple debug windows. Development Studio also offers powerful scripting, a familiar command line prompt, OS and RTOS awareness, and understands exceptions levels and complex breakpoints. If you are debugging software on Fast Models and need more insight give Development Studio a try.
[CTAToken URL = "https://developer.arm.com/products/software-development-tools/arm-development-studio/evaluate" target="_blank" text="Try Development Studio free for 30 days" class ="green"]
Great write-up. I look forward to using this. I will definitely be coming back here for the steps when I do. Thanks again, Jason!