Chapter 2

SDK GUI, and Debug Configuration

Introduction

In this chapter, the various debug perspectives will be explored, including the debug/run and

the C debugging perspectives. The user will learn how to set up a debug configuration and learn

to navigate through the various configuration panels, including how to set up remote debug

using system Debugger. Multi-Processor Debug, and Linux Application Debug on the System

Debugger will be discussed

System Debugger

Now that the Software system is successfully compiled, it is now time to execute the application

to see if the application performs as expected. The software developer can use the System

Debugger to do this. If the developer right clicks on the application there will be three options

seen below in Figure 2.1

Figure 2.1: System Debugger

The three options as seen in Figure 2.1 are; Run As, Debug As, and Profile As. If the developer is

satisfied with the functionality of the application and wants to execute the application, then

System Debugger

simply choose Run As. However, to allow the developer more access to the debugging of the

application, then Debug As shall be used. The Debug As will set the optimization level to -O0.

When –O0 optimization level is used, this will restrict the compiler from optimizing the

application. Finally, the developer can choose to profile the application using Profile As. This

will allow the developer to identify the frequency of functions calls to allow the user identify any

bottlenecks. In this guide, the Debug As will be used, and the various Debug As Configurations

will be mentioned.

The Debug Configurations are set up by right clicking on the application and selecting Debug As

-> Debug Configurations. The Debug Configuration GUI is seen in Figure 2.1, below:

Figure 2.1: Debug Configuration

To create a new Debug Configuration, double click on the Xilinx C/C++ application (System

Debugger) section on the left hand side of the Debug Configuration GUI seen in Figure 2.1.

Here the various debug options are available to the developer. The developer can set up the

target using the Target Setup tab. The example seen in Figure 2.3 is targeting a Zynq device, so

the developer has options specific to the Zynq device such as Run ps7_init, and Run

System Debugger

ps7_post_config. These options are explained in the summary window on the right hand side.

The equivilant XMD commands are seen below:

Figure 2.3: Target Setup

Remote Debug with System Debugger

Remote Debug with System Debugger

If the developer is using a board that is not local to the machine that the tools are running on,

then Remote Debugging can be used. The following steps detail how to set up Remote

Debugging with System Debugger. In this example, the ZC702 board is connected to a local

machine and the SDK tools are run from a Linux machine on a server.

1. Determine the IP address of the machine that the board is connected to. For example on

a windows machine this can be obtained by typing “ipconfig” in a command prompt.

2. Launch the hw_server with a non-default port (for example: 3122) from a Vivado shell on

the local machine.

hw_server –s tcp::3122

3. Launch SDK

To configure the JTAG settings, click Xilinx Tools > Configure JTAG Settings

Populate the Configure JTAG Settings with the relevant information as seen in Figure 2.6

Figure 2.6: Configure JTAG Settings

Remote Debug with System Debugger

4. Click Run > Debug As > Launch on Hardware (System Debugger)

Figure 2.7: Launch on Hardware (System Debugger)

Debugging Tips:

1. Disable any firewall on your local machine.

2. If the board is connected locally, try connect to the board via XMD on the local machine

to make sure that the board can be connected to.

3. Ping the local machine from SDK shell(Xilinx Tools > Launch Shell) to verify that the

connection can be made.

4. Enable the Trace Log information Level in SDK. Window > Preferences > Xilinx SDK >

Log Information Level. This will determine if the issue is on the SDK end.

5. Use the –L- option on the hw_server command line. This will dump the TCF log file. This

will indicate if the issue is on the hw_server end.

Symbol Files

Symbol Files

The System Debugger will produce a disassembled image file. This can be trouble-some to track

in debug. Developers will also be unable to add breakpoints or watchpoints without adding the

symbol information. In the example below, a Dual ARM Zynq design is executing a Hello World

Application. Here in Figure 2.8, the Disassembly code is shown:

Figure 2.8: Disassembly Code

For ease of use, the developer can assign a Symbol File to the System Debugger Debug

perspective. To assign a Symbol File, right click on the Processor as shown in Figure 2.9

Figure 2.9: Symbol File

Symbol Files

Add the ELF file, as shown in Figure 2.10 and select OK to exit.

Note: The ELF file must reside on the machine that the HW_SERVER was launched from.

Figure 2.10: Add ELF as Symbol File

Once the ELF file is added, the disassembled code is updated with the Symbol information as

seen in Figure 2.11.

Figure 2.11: Disassembly with Symbol Information

Multi-Processor Debug in System Debugger

Multi-Processor Debug in System Debugger

The Vivado System Debugger allows the designer to debug Multi-Processor designs

simulataneously. To set up Multi-Processor Debug, the designer will need to enable this in the

Debug Configurations, under the Applications Tab, seen in Figure 2.4

Figure 2.4: Multi-Processor Debug Configuration

The SDK will detect all processors in the system based on the XML file. The developer can

choose to configure each processor by ticking the Download Application tick-box in the GUI

The user can also download data files before launch. This is useful for applications that contain

memory files systems, or to pass a known set of data to DDR. To add this, select Add, and pass

the .bin file, and the address offset in hexadecimal.

Multi-Processor Debug in System Debugger

In the example below, there is a simple Hello World application that is run on each processor:

Note: When linking the Applications, make sure that two do not share the same memory. In this

example, the DDR is used. One application is linked at the default 0x00100000 address. The

other application is linked to 0x00200000. This shown below:

MEMORY { /* ps7_ddr_0_S_AXI_BASEADDR : ORIGIN = 0x00100000, LENGTH = 0x3FF00000 */ ps7_ddr_0_S_AXI_BASEADDR : ORIGIN = 0x00200000, LENGTH = 0x3FE00000 ps7_ram_0_S_AXI_BASEADDR : ORIGIN = 0x00000000, LENGTH = 0x00030000 ps7_ram_1_S_AXI_BASEADDR : ORIGIN = 0xFFFF0000, LENGTH = 0x0000FE00

}

Multi-Processor Debug in System Debugger

Here a symbol called “CPU0_TEST” is defined in the application running on the CPU0. To pass

symbols, right click on the application, C/C++ Build Settings > ARM gcc compiler > Symbols

then add the symbol as shown in Figure 2.5

Figure 2.5: Adding Symbol to C/C++ Build Settings

Linux Application Debug with System Debugger

Linux Application Debug with System Debugger

To create a Linux application in SDK, go to File > New > Application Project. Under OS

Platform choose Linux. The developer can choose a Linux Empty Application, Linux Hello World,

or OpenCV Example Application.

To debug the Linux Application in the System Debugger follow the steps below.

Click on Run > Debug Configurations

Create a new Xilinx C/C++ application (System Debugger) Configuration by double clicking on

“Xilinx C/C++ application (System Debugger)” seen in Figure 2.5

Figure 2.5: Xilinx C/C++ application (System Debugger)

In the Target Setup tab, select Debug Type as Linux Application Debug as seen in Figure 2.6

Figure 2.6: Linux Application Debug

Linux Application Debug with System Debugger

Provide the Linux host name or IP address in the Host Name test box in the Linux Host

connection seen in Figure 2.7. By default the tcf-agent will be running on 1534 port on the Linux.

If running the tcf-agent on a different port, the Port test box will need to be updated with the

appropriate port Number.

Figure 2.7: Linux Target Connection

In the Application tab seen in Figure 2.8, provide the Project name using the Browse button. This

will auto fill the application. Provide the Remote File Path, where the application is to be

downloaded into Linux

Figure 2.8: Application

Linux Application Debug with System Debugger

If the application is expecting any arguments, then these need to be specified in the Arguments

tab as seen in Figure 2.9

Figure 2.9: Arguments Tab

If the application is expecting any environment variables to be set, then these need to be

specified in the Arguments tab as seen in Figure 2.9

Figure 3.0: Environment Tab