Overview

One of the key features of S32 Design Studio is its great support for debugging embedded C and C++ applications for S32 devices, both created in the wizard and imported to the workspace. Debugging is performed by means of the GDB tools supplemented with extra code (scripts, libraries, SDKs) to provide support for the target device, virtualization, and other options.

Support for each family of devices is brought to the debugging process with a respective software package or several packages that have to be installed into S32 Design Studio .

Debugging environment

User interface

Debugging can be started and managed from the GDB command line and from the user graphical interface of S32 Design Studio . When using the graphical interface, the developer is switched to the Debug or VDK Debug perspective that includes customizable views for inspecting values and managing the debugging process. The views available to the developer are Variables, Breakpoints, Expressions, Peripheral Registers, Arm System Registers, Peripherals, Watch Registers, Memory Spaces, and other. The information about the debugging status appears in the Console, Debugger Console, and Problems views. The debug sessions with the included processes and threads can be managed in the Debug view.

Debug configuration

In S32 Design Studio , a project is created with a collection of out-of-the-box debug configurations. A debug configuration consolidates all project specific debugging information. This includes the paths of the executable file and of the project, the settings responsible for the project rebuild, for connection and initialization of the board, for starting debuggers, and for file lookup. A debug configuration is the place to specify the first breakpoint and additional GDB commands. Optionally, a debug configuration can reference external symbols and an image file not included in the project.

The set of debug configurations created for a project includes at least one “debug” configuration and one “release” configuration. These configurations have similar settings and only differ in meta information. For projects created for debugging on a bare-metal target, S32 Design Studio generates configurations for debugging a program from RAM and from flash.

Loading a program to the device

The simplest way to load a program to RAM or flash memory of the device is by running the respective debug configuration. The selected configuration already includes all settings and requires only a couple of final clicks from the developer.

While debugging from flash, the developer can use the command line interface to read flash memory and to reload a program to flash. This option is provided by the flash programmer tool for advanced debugging scenarios.

Another way to load a program directly to flash memory is by using the S32 Flash tool. This tool is installed with S32 Design Studio but is run as a standalone application. Learn more in S32 Flash Tool User Guide.

Debugging

To start debugging, the developer runs one of the debug configurations available for the project. This event initializes the board and prepares the target cores (if applies), and executes the GDB commands specified in the configuration. Once done, a debug session is started. The GDB client and GDB server processes and the application process are executed in the context of the debug session.

If specified in the debug configuration, the debug session halts at the first breakpoint. The user releases the program execution and starts stepping though the code. During debugging, the user can set breakpoints, inspect and edit memory registers and peripheral registers, create variables and expressions, debug the source code or step through instructions.

Multi-core debugging

In S32 Design Studio , the developer can start several concurrent debug sessions on different cores of the device and switch between them. Concurrent debug sessions can be started manually or using a launch group.

Launch group

S32 Design Studio provides launch groups for running several executable files on a multi-core device with a single click. A launch group includes multiple debug configurations ranged the order of launching. When a developer runs a launch group, the included debug configurations are executed one after another.

A separate debug session is created for each launched configuration. The first (“boot”) debug session has to initialize the board, run and load the boot core, prepare the secondary cores, and start the GDB processes. The remaining (“secondary”) debug sessions load the code to the other cores. The debug sessions created by the launch group are managed and terminated independently.

Semihosting

Semihosting is an option that allows user input and output of the debugging information in the console during debugging. Semihosting can be enabled in the debug configuration.

Code trace

Code trace collection is available for on-chip debugging with S32 Debug Probe. S32 Design Studio integrates the tools for collecting code trace, for managing this process during debugging, and for analysis of the collected data. Learn more in S32DS Software Analysis Documentation available in the help system of S32 Design Studio .

Debug Probe Connection

Using Remote Probe Connection allows connecting to a S32 Debugger connection server that was been launched manually.