Multicore Debugging with Ozone

Ozone supports multicore debugging by using a dedicated Ozone instance per core. The scripting functionality combined with the automation interface helps hiding some of the complexity inert to multicore debugging from the end user and also allows for high-level features such as simultaneously starting and stopping multiple cores or even halting other cores in case one core runs onto a break point.

General Approach

Multiple Ozone instances are used: One main instance and one or more sub instances. The main instance performs the whole setup required for multicore debugging that cannot be done on the sub instances. E.g. a sub instance may not be able to download the program to the target or perform a reset, so all this is done in the main instance.

Each Ozone instance operates on a dedicated project script (*.jdebug) that is tailored for the debugging of one core in the multicore environment. Each Ozone instance can be used to perform the desired debug actions on the respective core: The debug session can be started, break points can be set, the target can be started and halted, etc.

Often it is sufficient to have a setup where the main session is just used to enable single core debugging on a debug session on a sub core.

It is also possible to simultaneously debug multiple cores. In that case the user has to operate multiple Ozone instances. Doing this manually is possible but may be a bit cumbersome: E.g. for starting all cores the user needs to click onto the resume button in all Ozone instances, which may result in quite some aim-and-click practice.

Ozone's scripting interface in combination with the automation interface can be used to simplify such tasks and even implement complex scenarios, allowing for powerful debug features, including manually resuming or halting multiple cores and even halting multiple cores if one core runs into a break point. For tasks operating on multiple Ozone instances the Ozone automation interface is used, which allows remote-controlling an Ozone instance via a socket interface. A little Python script connects to the socket of the respective sub Ozone instance and sends a command, which is then executed. That Python script is invoked from within the main Ozone instance using Ozone's feature for interworking with external applications. The custom tool bar feature in Ozone makes such even complex functionality available with a single click.

Example Setup

Here is described how multicore debugging can be performed on the evaluation board CYTVII-B-H-8M-176-CPU Rev. 3 which accommodates a CYT4BF8CDDES. Multicore debugging is performed on the 1st and 2nd Cortex-M7 core of that device, the M7_0 will be the main core and the M7_1 will be the sub core.

J-Link Script

For multicore debugging special low-level handling is required. This is implemented in the J-Link script file that exist for each core to be targeted. Those script files can be found in the folder J-LinkScriptFiles.

Main Project

First of all, the project for the main Ozone instance contains the mandatory things, such as specifying the device and loading the ELF file. Since this core is supposed to download the images for the main core as well as the sub core, the project replacement function TargetDownload() is implemented. Here the ELF files for main and sub core are downloaded.

Sub Project

Like the main project, the Ozone project for the sub core contains the mandatory things, such as specifying the device and loading the ELF file. This core is not supposed to perform any download, therefore the process replacement function TargetDownload() is available here but is empty. This will overwrite the default behavior which would download the ELF file contents with a procedure that does not do anything, resulting in no download whatsoever being performed here.

Host Based Core Synchronization

The main project also implements some features for host based core synchronization that are made available in the custom button bar:

• "Launch Ozone for Sub" starts an Ozone instance for the sub core and ensures that the correct Ozone project file is loaded. Also, the port number for the automation interface to be used by the sub instance is specified.
• "Run all" resumes execution on both main core and sub core. Resuming the main core is done by simply invoking Target.Resume(). For resuming the sub core the external application interworking interface is used to invoke a Python script that is instructed to send the command Target.Resume() to the sub instance. The script opens a TCP socket and sends the command which is received by the automation interface on the Ozone instance for the sub core and processed. Thus the sub core is resumed.
• "Break all" halts execution on all cores. This is done in the very same way: The main core is halted by invoking Target.Break() locally, the sub core is halted by sending the same command via the Python script.
• "Run Sub" resumes the sub core only. This is done by invoking Target.Resume() on the sub core via the Python script.
• "Break Sub" halts execution on the sup core only.
• "Exit Sub" stops the debug session on the sub core and closes that Ozone instance.

With that functionality it is possible to halt the sub core when the main core runs into a break point: A user function is attached to the break point and in that user function the sub core is halted with the aid of the Python script. In the very same way, a break point on the sub core may halt the main core: The only difference is that the Python script is invoked with the port number of the main instance, which, in this example, is the default port number.

The Python Script

The Python script is just a simple way to send a character string via a socket connection. The script expects the port number in the parameter --port and the command in the parameter --cmd. The parameter --timeout specifies the duration for which the script waits for a response. Any output received via the socket interface is printed to the console, so it is collected by Ozone and written into the console window.

The script is provided for means of simplicity. There may be more sophisticated, powerful or efficient ways to accomplish the task, allowing to meet customer demands that cannot be met by that script.

Downloads

The example discussed here is based on Infineon CYT4BF Multi Core Support. The Ozone projects and the Python script can be found here: OzoneMultiCoreSampleTraveo.zip. Extract the example application start Ozone and open Main.jdebug.