The NXP device S32R45 has accelerators that can be programmed. The S32 Debugger included within the S32 Design Studio for S32 Platform IDE with the S32 Debug Probe provides the ability to debug these accelerators. The accelerator covered in this document: Linear Algebra Accelerator (LAX).
Section map:
Preparation
Setup the software tools Setup the hardware
Procedure
Create A New Debug Configuration
Simulator Physical Hardware
Start A Debug Session
Standalone Multi-Core Debugging LAX Once Debug Session is Started Multi-thread LAX Debugging: IPPU & VCPU Multi-LAX-core Debugging
Preparation
Setup the software tools
Install S32 Design Studio for S32 Platform
Install the S32R4xx development package and the Radar extension package for S32R4xx. Both of these are required for the LAX accelerator.
Setup the hardware
Confirm the setup of the S32R45 evaluation board.
Connect the power supply cable
Setup the S32 Debug Probe. Refer to the S32 Debug Probe User Manual for installation instructions.
Connect the S32 Debug Probe to the evaluation board via JTAG cable.
Connect the S32 Debug Probe to the host PC via USB cable OR via Ethernet cable (via LAN or directly connected and configured for static IP address) and power supply connected to USB port.
Launch S32 Design Studio for S32 Platform
Open existing project or create a new project and check that it successfully builds. If creating a new project, be sure the S32 Debugger is selected in the New Project Wizard.
Procedure The procedure for starting a debug session and accessing the associated accelerator-specific registers is detailed here. Application code executing on the LAX accelerator can be debugged using a simulation as well as on physical hardware. Debugging using simulation occurs entirely on the PC and no physical hardware is required.
When debugging LAX on physical hardware, this is primarily conducted through one of two methods:
Standalone: the LAX executable is loaded by a debugger over JTAG using a probe and only the LAX core is executed and available for debugging.
Multi-core: the LAX executable is included within A53 executable, the A53 application loads the LAX executable to the LAX core and both A53 and LAX core are available for debugging. The debug connection is made to the two cores through one of two methods:
Baremetal/Bareboard: the debugger connects to both the A53 and LAX cores using the probe over JTAG.
Linux BSP: the debugger connects to the A53 core, which is running Linux BSP, using a remote Linux connection over Ethernet and then connects to the LAX core using the debug probe over JTAG.
Before a debug session can be started a debug configuration must exist.
Create A New Debug Configuration If the New Project Wizard was used to create the project using the S32DS Application Project option, then there was an opportunity to select the desired debugger from within the wizard. If the desired debugger option was selected at this time, then the needed configuration already exists and will only require adjustments to the hardware connection settings (no hardware settings for LAX Simulator).
If the New Project Wizard was not used to create the project OR the currently desired debugger was not the one selected at the time of project creation, a new debug configuration must be created.
With the existing project selected in Project Explorer, open the Debug Configurations Menu: Run -> Debug Configurations Having the existing project selected in the Project Explorer view will make the creation of a new launch configuration easier as many settings will be imported from the selected project. To select a project, click on it so it becomes highlighted.
Next, select the debugger for which the new debug configuration will be created.
Simulator
To create the new configuration, either click on the ‘New launch configuration’ button from the toolbar at the top and to the left, or right-click on the ‘LAX Simulator’ and select ‘New Configuration’ from the menu.
Once the configuration is created it will be displayed and any errors with the configuration will be shown. If the project was selected in the Project Explorer, then the Name of the debug configuration will contain the project’s name and the Project and C/C++ Application fields will be populated as well. The C/C++ Application field will only be populated if the build output executable exists. Confirm these values are correct before moving on.
There is an error showing that the Device core ID is not specified on the Debugger tab. Switch to the Debugger tab and click on the button ‘Select device and core’.
From the Select Target Device and Core window, expand the listing until all cores are listed. Since the LAX Simulator only supports LAX cores on the S32R45, that is all which is listed. Select the desired LAX core and click OK.
Now that the device and core are selected, the only correct initialization script associated with the LAX is selected automatically.
No further changes are required. Click Apply to save the changes or if you are ready to debug with the LAX Simulator, then click Debug and the changes will be saved and the debug session will launch.
Physical Hardware
To create the new configuration, either click on the ‘New launch configuration’ button from the toolbar at the top and to the left, or right-click on the ‘S32 Debugger’ and select ‘New Configuration’ from the menu.
Once the configuration is created it will be displayed and any errors with the configuration will be shown. If the project was selected in the Project Explorer, then the Name of the debug configuration will contain the project’s name and the Project and C/C++ Application fields will be populated as well. The C/C++ Application field will only be populated if the build output executable exists. Confirm these values are correct before moving on.
There is an error showing that the Device core ID is not specified on the Debugger tab. Switch to the Debugger tab and click on the button ‘Select device and core’.
From the Select Target Device and Core window, expand the listing until all cores are listed. Notice that all supported cores on the S32R45 are listed. Select the desired LAX core and click OK.
Now that the device and core are selected, a generic initialization script associated with the LAX is selected automatically, however, this may not be the correct one. If debugging Standalone, meaning only LAX core will be debugged, then the automatic selection ‘s32r45_generic_bareboard_all_cores.py’ is correct. This script will initialize all of the cores so the LAX can execute properly. If debugging Multicore, meaning both A53 and LAX will be debugged, then the A53 and LAX cores will already be initialized by the time the debugging on LAX begins. So a different script that doesn't initialize all of the cores is needed. Click ‘Browse’ and navigate to ‘{install_dir}\S32DS.3.4\S32DS\tools\S32Debugger\Debugger\scripts\s32r45’ and select the script ‘s32r45_attach.py’. The attach script will allow to start debugging on a core that is already initialized. Refer to the S32 Debugger User Guide, or the document 'README.txt' located in the same folder as these script files for details on all of the provided scripts.
Confirm the setting of the ‘Initial core’ checkbox. This box should be checked within the debug configuration that establishes the first connection to the target device via S32 Debug Probe. When this box is checked, the Debug Probe Connection interface and GDB Server settings become available. The probe connection only needs to be configured once and only one GDB Server needs to be running for each debug session. Therefore, this box should be checked for standalone debugging or for multicore debugging where A53 core is debugged via Remote Linux. If the A53 and LAX cores are debugged via the S32 Debug Probe, then this box should be checked for the A53 debug configuration and should not be checked for the LAX debug configuration.
If this is a standalone debugging of only the LAX core, setup the Debug Probe Connection. Select either USB or Ethernet, depending upon your hardware setup. If USB is selected, the COM port for the S32 Debug Probe will automatically be detected (unless not connected or more than one probe is connected). If Ethernet is selected, then enter either the hostname (fsl + last 6 digits of MAC address) or IP address. It is highly recommended to press the ‘Test connection’ button to confirm the hardware connection is correctly configured. See the included ‘S32_Debug_Probe_User_Guide.pdf’ for more details on the setup of the S32 Debug Probe.
Check that the GDB Client section has the correct path to the LAX GDB executable. It should point to the variable ‘S32DS_R45_GDB_LAX_PATH’.
Startup tab check the following settings
Load image is checked for standalone debugging, NOT checked for multicore debugging. Basically, if it is loaded by A53 core (contained in A53 ELF file), then it does not need to be loaded.
Load symbols is checked. The only time you would not check this box is if there is no project binary containing symbols available.
Set breakpoint at main and Resume are checked for standalone debugging, NOT checked for multicore debugging.
Now you are ready to start debugging. If debugging Standalone, click ‘Debug’. If debugging Multicore, switch to the A53 debug configuration (either C/C++ Remote Application or S32 Debugger) and start the A53 debug session first. Once the A53 debug session is running, advance the program counter to the line just after LAX is initialized.
Start A Debug Session Starting a LAX debug session are different depending upon whether Standalone or Multi-core debugging is required. The steps for each method are detailed in separate sections below. For convenience, the example project for S32 Design Studio from the RSDK, ‘RSDK_S32DS_template’, will be used to demonstrate multi-core A53/LAX debugging. Note: Unfortunately, this example project is not setup for standalone debugging because there is no main() executing on LAX to call the LaxVectorAddGraph(). So the standalone debugging steps will be presented only to highlight the different setup required. For instructions on loading this example project to your workspace, see ‘HOWTO: Create New Project from Example RSDK_S32DS_template from Radar SDK’.
Standalone If the standalone bareboard debugging of only LAX core was supported by the RSDK_S32DS_template example, here are the steps which would be required.
Click on the LAX project so it is highlighted, then build it to ensure it builds clean and that the executable exists.
From the menu at the top, select Run -> Debug Configurations…
Select the standalone debug configuration for LAX core. In the case of the RSDK_S32DS_template example project, only the multi-core debug configuration is supported. In this case, the standalone configuration will need to be created. Right click on the multi-core configuration and select Duplicate. This will create an identical configuration.
Change the name as desired and then select the Debugger tab.
Click Browse next to Initialization script and navigate to the directory ‘{install_dir}\S32DS.3.4\S32DS\tools\S32Debugger\Debugger\scripts\s32r45’. Select the script ‘s32r45_generic_bareboard_all_cores.py’.
Adjust the Debug Probe Connection settings to match your HW setup. Use the Test connection button to confirm.
Select the Startup tab. For standalone debugging the image file will not be loaded by the A53 core, so it must be loaded by the S32 Debugger. Check the boxes for Load image, Set breakpoint at: and Resume.
Click Debug to start the debug session. All of the settings made will be applied and the debug session will be launched.
A53 / LAX Multi-Core For multi-core debugging, the A53 core is executing an application on the Linux BSP. The EVB should be setup to boot from a flash device which has been loaded with the S32R45 Linux BSP.
Before beginning the debug sessions, be sure to load the driver dependencies (oal_driver, rsdk_spt_driver, and rsdk_lax_driver) as described in the RSDK User Manual, RSDK Offline Example section ‘Running the application’.
Start A53 debug. From the menu at the top, select Run -> Debug Configurations…
In the Debug Configurations menu, from the configuration list, expand the ‘C/C++ Remote Application’ group and select the ‘RSDK_S32DS_template_A53_Debug’ configuration.
On the Main tab, create a new connection for using the IP address of the EVB. The IP address could be determined either by issuing a Linux command over the serial connection, such as ‘ifconfig’, by accessing the local network connected device list, or perhaps the EVB was setup with a static IP address and it is already known.
Click New… in the Connection section.
Select ‘SSH’ for connection type.
Enter the IP address in Host: field, use ‘root’ in User: field, and leave password field empty.
Click Debug to start debugging on the A53 core.
The debugger will launch and execute until the first executable line in main(). See Debugger tab in Debug Configurations menu to adjust this setting.
Now that the A53 is launched, it is necessary to execute the A53 code until just after the LAX core is initialized and buffers are allocated. Open ‘lax_processing.c’ from the ‘src’ folder in the A53 project and set a breakpoint on line 100. One way is by double-click in the space on the left side of source code editor. This is the executable line just after ‘RsdkLaxInit()’ is called.
Now press ‘Resume’ from the toolbar to advance the program counter to the breakpoint.
Wait for the breakpoint to occur.
Return to the Debug Configurations menu, select the ‘RSDK_S32DS_template_LAX_0_attach’ debug configuration and select the Debugger tab.
Adjust the Debug Probe Connection settings to match your HW setup. Use the Test connection button to confirm.
Click Debug to start the LAX debug session.
Wait for the LAX debug session to launch and stop in the disassembly. Set a breakpoint in the source code. For our example, place one in ‘lax_custom_graph.c’ on line 97, where the kernel ‘ Rsdk_LA_add_VV’ is called.
Select the LAX debug thread and press Resume so it will be ready to run to the breakpoint which was just setup.
Select the A53 debug thread and press Resume to allow execution to resume and then wait for the breakpoint to be reached in the LAX code.
The breakpoint in the LAX code has been reached. Now it is possible to perform some debugging activities on the LAX core.
Debugging LAX Once Debug Session is Started
Once the LAX debug session is started, it will be stopped and only disassembly can be viewed. Select the LAX debug thread to see.
Open the C code source file and set a breakpoint within the kernel of interest.
Press Resume on the LAX debug thread.
Now switch back to the A53 debug thread and press Resume.
The breakpoint you set in LAX will be reached and you can now start stepping through and looking at registers, etc.
Multi-thread LAX Debugging: IPPU & VCPU Load a project which uses both IPPU and VCPU and start the debug session on LAX using one of the methods provided.
Once the debug session is started on LAX, set a breakpoint on the line containing RSDK function ‘Rsdk_AU_sync_i()’
Press Resume to advance the program counter to the breakpoint. When the breakpoint is reached, the second thread appears. The first thread contains the VCPU and the second thread contains the IPPU.
Select the second thread to see the IPPU disassembly. Now instruction stepping can be performed on the IPPU. Registers can be viewed as well.
To see the opcodes, do not use the codes shown in the disassembly view. The disassembly view does not handle cases where many opcodes are packed into a single address. Instead, use the Memory Spaces view. If the memory spaces view is not already present, then add it from the menu Window -> Show View -> Memory Spaces. To add a memory space, right click in the panel on the left or click on the + button at the upper right.
Multi-LAX-core Debugging The S32R45 device contains 2 LAX cores: LAX_0 and LAX_1. To debug the additional LAX core, simply add a new debug configuration and setup for LAX_1.
Create a new debug configuration for LAX_1 by first duplicating the existing debug configuration for LAX_0.
Rename the configuration to reference LAX_1, but the project name and application file (ELD) will remain the same.
On the Debugger tab, use ‘Select device and core’ button to change the core to LAX_1, change the initialization script to ‘<device>_attach.py’, and uncheck the box next to Initial core.
Depending on how you started the debug session for LAX_0, you may need to adjust the Startup tab. The settings on Startup tab should be set to match the LAX_0 debug configuration.
Start the LAX_0 debug session first, then the LAX_1 debug session. Stepping within each can be conducted independently.
View full article
