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: BBE32. 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 BBE32 DSP Once Debug Session is Started Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R4xx development package, the Radar extension package for s32R4xx, and the BBE32 DSP Add-On Package for S32R45.   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. The BBE32 DSP debugging requires some additional setup beyond the installation of the BBE32 DSP Add-On Package for S32R45. The BBE32 has a different license from the one for S32 Design Studio. This license must be located using the ‘LM_LICENSE_FILE’ environment variable, as instructed within the provided document "{S32DS Install DIR}\Release_Notes\S32R45_BBE32_DSP_Release_Notes.pdf". Debugging the BBE32 DSP is performed on physical hardware. This is conducted through one of two methods: Standalone: the BBE32 DSP executable is loaded by a debugger over JTAG using a probe and only the BBE32 DSP core is executed and available for debugging. Multi-core: the BBE32 DSP executable is included within A53 executable, the A53 application loads the BBE32 DSP executable to the BBE32 DSP core and both A53 and BBE32 DSP 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 BBE32 DSP 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 BBE32 DSP 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.   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. 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. g 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 BBE32 DSP core and click OK. Now that the device and core are selected, a generic initialization script associated with the BBE32 DSP is selected automatically, however, this may not be the correct one. If debugging Standalone, meaning only BBE32 DSP 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 BBE32 DSP can execute properly. If debugging Multicore, meaning both A53 and BBE32 DSP will be debugged, then the A53 and BBE32 DSP cores will already be initialized by the time the debugging on BBE32 DSP begins. So a different script that doesn't initialize all of the cores is needed. Click ‘Browse’ and navigate to ‘{install_dir}\S32DS.3.5\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 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 BBE32 DSP debugging or for multicore debugging where A53 core is debugged via Remote Linux. If the A53 and BBE32 DSP cores are debugged bareboard (no Linux) via the S32 Debug Probe, then this box should be checked for the A53 debug configuration and should not be checked for the BBE32 DSP debug configuration. If the initial core box is checked, then 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 BBE32 DSP GDB executable. It should point to the variable ‘S32DS_R45_GDB_XTENSA_PY_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. Start A Debug Session For convenience, the example project for S32 Design Studio from the RSDK, ‘RSDK_S32DS_template’, will be used to demonstrate standalone BBE32 DSP and multi-core A53/BBE32 DSP debugging. For instructions on loading this example project to your workspace, see ‘HOWTO: Create New Project from Example RSDK_S32DS_template from Radar SDK’. Standalone For the standalone bareboard debugging of only BBE32 DSP core using the RSDK_S32DS_template example, here are the steps which would be required. Right-click on the BBE32 project and select Build Project 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 BBE32 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.5\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. The BBE32 will execute to the first line in main().   A53 / BBE32 DSP 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.   Once the A53 debug session is running, advance the program counter to a line after the desired DSP kernel is loaded to memory but before the DSP kernel is launched. In the example here, this would be in ‘spt_bbe32_proc.c’, line 355, where ‘ExampleLaunchSptKernel()’ function is called. This is best done by setting a breakpoint on the line and clicking Resume. After the breakpoint is reached, the BBE32 DSP debug session can be started. Return to the Debug Configurations menu, select the BBE32 DSP debug configuration ‘RSDK_S32DS_template_BBE32_attach’, confirm the Debug Probe Connection settings and click Debug. Wait for the BBE32 debug session to launch and stop in the code. Select the BBE32 debug thread to change the context of the Source, Disassembly, Registers and etc.views. Now you can step through the assembly code, access registers, etc. To see this source code, it may be necessary to locate the file from the RSDK installation folder.

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: Signal Processing Toolbox (SPT). Section map: Preparation Setup the software tools Setup the hardware Procedure Create A New Debug Configuration Start A Debug Session Multi-Core 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 SPT 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. Debugging SPT is only conducted through the multi-core method. The SPT executable is included within A53 executable, the A53 application loads the SPT executable to the SPT core and both A53 and SPT 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 SPT 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 SPT 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.   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. 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 SPT31 core and click OK. Now that the device and core are selected, the attach script is selected automatically. The attach script will allow to start debugging on a core that is already initialized. This is correct for the SPT core as it is always launched in multicore scenario. Refer to 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 multicore debugging where A53 core is debugged via Remote Linux. If, however, the A53 and SPT 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 SPT debug configuration. If the ‘Initial core’ box was checked in the previous step, 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 SPT GDB executable. It should point to the variable ‘S32DS_R45_GDB_SPT_PATH’. Startup tab check the following settings Load image is NOT checked for multicore debugging. Basically, if it is loaded by A53 core (SPT executable is contained within A53 ELF file), then it does not need to be loaded. Load symbols is NOT checked. The SPT source file is assembly code, so there are no symbols to load. Set breakpoint at main and Resume are NOT checked for multicore debugging. After saving the new configuration with the ‘Apply’ button, SPT debugging can be performed. Start A Debug Session For convenience, the example project for S32 Design Studio from the RSDK, ‘RSDK_S32DS_template’, will be used to demonstrate multi-core A53/SPT debugging. The SPT core does not support standalone debugging. For instructions on loading this example project to your workspace, see ‘HOWTO: Create New Project from Example RSDK_S32DS_template from Radar SDK’. A53 / SPT 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.   Once the A53 debug session is running, advance the program counter to a line after the desired SPT kernel is loaded to memory but before the SPT kernel is launched. In the example here, this would be in ‘spt_bbe32_proc.c’, line 318, where ‘ExampleLaunchSptKernel()’ function is called. This is best done by setting a breakpoint on the line and clicking Resume. After the breakpoint is reached, the SPT debug session can be started. Return to the Debug Configurations menu, select the SPT debug configuration ‘RSDK_S32DS_template_SPT31_attach’, confirm the Debug Probe Connection settings and click Debug. Wait for the SPT debug session to launch and stop in the disassembly. Select the SPT debug thread to change the context of the Disassembly, Registers and etc.views. Now you can step through the assembly code, access registers, etc.

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.5\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.

Included in the Radar Software Development Kit (RSDK) is an example project ‘RSDK_S32DS_template’. This example shows an example radar application which uses the Arm Cortex-A53 and accelerators SPT, LAX and BBE32 DSP. The A53 core is used to execute the Linux application and launches the SPT, LAX, and BBE32 DSP cores. In this HOWTO, we will show how to load the project into the S32 Design Studio workspace and build. Debugging instructions, using the S32 Debugger and S32 Debug Probe are provided in separate documents for each accelerator. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R4xx development package, the Radar extension package for s32R4xx, and the BBE32 DSP Add-On Package for S32R45.   Install the ‘S32R45_RSDK_0.9.4_D2112’ last. It contains the ‘RSDK_S32DS_template’ example project. This package must be downloaded from the NXP website. If the .exe version is used, then the RSDK installer will install an XML file containing the install path of the RSDK into the S32 Design Studio installation directory. A prompt during the installation process will request the user to locate the S32DS installation directory. If the S32DS installation folder doesn’t exist, then it can’t be selected and the file will be missed. So, it is important to install this after installing S32 Design Studio and to use the .exe version. Once installed, S32 Design Studio will be able to locate the project from the New Project from Example wizard. If the .zip version is used, then the XML file must be updated manually and then placed in the S32DS installation folder. For example, with the 0.9.4 version of the RSDK: Locate the XML file in the RSDK installation folder. It is located in the base installation folder: "C:\NXP\S32R45_RSDK__0.9.4\swm.rsdk.s32r45.0.9.4.xml" Edit the following line by inserting the path to the RSDK: <variable name="RSDK_S32R45_0_9_4_DIR" value="${{RSDK_INSTALL_DIR}}" /> change to: <variable name="RSDK_S32R45_0_9_4_DIR" value="C:/NXP/S32R45_RSDK__0.9.4" /> Copy file to S32DS install folder. For example, if S32 Design Studio v3.5 installed: “C:\NXP\S32DS.3.5\S32DS\integration” Procedure Create the Project. Launch S32 Design Studio for S32 Platform and execute the following command: File -> New -> New S32DS Project from Example   OR from the Dashboard Enter search text ‘rsdk’. The RSDK_S32DS_template project will be shown. Select it and click Finish. Examine the project Notice there are separate projects for each core. This project structure is due to the separate compilers, linkers, and assemblers required for each core type. When the A53 project is built, it will automatically build the other projects and then include the executable outputs into the A53 executable output. This way the code for all cores is loaded at one time and each core can be launched by the A53 core.  

A vulnerability in the Apache Log4j was identified in the articles posted: CVE-2021-44228 and CVE-2021-45046 NXP has performed an analysis of this vulnerability with regard to the S32 Design Studio. Our conclusion is that the S32 Design Studio (all versions) is NOT IMPACTED. Although the Log4j is used by S32 Design Studio, the version used is 1.x and the vulnerability was introduced in version 2.12 with a combination of Java versions 9/10/11 where LDAP policy is enabled by default (CVE-2021-45046). The S32Design Studio installation environment is independent and based on Java 8 version, which is common for all tools running under S32Design Studio IDE. In addition, the S32 Design Studio does not use JMSAppender, so it is not affected by the identified log4j 1.x usage concern (CVE-2021-44228). When we determine an upgrade of the Log4j and/or Java version is required for a future release of S32 Design Studio, then this vulnerability will be addressed. Please see the attached presentation for details on other tools owned by NXP Automotive Processing Software Tools.

      Product Release Announcement Automotive Processing S32 Design Studio v3.4 Update 1 for S32G2         Austin, Texas, USA Apr 30, 2021 The Automotive Processing' Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the  S32 Design Studio v3.4 Update 1 for S32G2 Here are some of major features:​ S32 Configuration Tool framework 1.4 with the Pin, Clock, Peripheral, DCD, IVT, DDR and QuadSPI Configuration tools (SDK/RTD packages required to get support for particular device)  Updates S32 Debugger  Updated S32 Flash Tool Update is available for online install on update site and for download on flexera  S32G2 support: (SW32G2_S32DS_3.4.1_D2104.zip) updated version of header files in accordance with RM Rev 3 Update is available for online install on update site and for download on flexera. Note that Update 1 (S32DS Platform Package version 3.4.1 and S32DS Platform Tools package version 3.4.1) is required for the S32G2 support package. It is included into archive for download. Installation instructions The update is available for online (via Eclipse Updater) or offline installation   online installation:  go to menu "Help" -> "S32DS Extensions and Updates" dialog  select from available items and click "Install/Update" button   offline installation:   go to S32 Design Studio product download page: S32 Design Studio for S32 Platform -> Downloads, click 'Download' button next to S32 Design Studio 3.4 -- Windows/Linux from the Product Information page, select S32 Design Studio 3.4 Update 1, support for S32G2 family then select 'SW32G2_S32DS_3.4.1_D2104.zip' to download the update archive zip file Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates" Add the downloaded archive as a software site. Click "Add Software Site" and browse to select the archive file downloaded in the prior step        Select from available items and click "Install/Update" button. This will start the update installation process.   Technical Support please use public community for questions https://community.nxp.com/community/s32/s32ds  

      Product Release Announcement Automotive Processing S32 Design Studio v3.4 S32K1 Service Pack 1         Austin, Texas, USA Jun 25, 2021  The Automotive Processing' Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the  S32 Design Studio v3.4 - S32K1 Service Pack 1 Here are some of major features:​ Support for S32K1 family is updated for latest version of RM and S32K144W 1.1  SDK migration tools for projects created with S32DS for ARM S32 SDK for S32K1xx RTM 4.0.2 included Update is available for online install on update site and for download on flexera. Note that Update 1 (S32DS Platform Package version 3.4.1 and S32DS Platform Tools package version 3.4.1) is required for this Service pack. It is included into archive for download. Installation instructions The update is available for online (via Eclipse Updater) or offline installation   online installation:  go to menu "Help" -> "S32DS Extensions and Updates" dialog  select from available items and click "Install/Update" button   offline installation:   go to S32 Design Studio product download page: S32 Design Studio for S32 Platform -> Downloads, click 'Download' button next to S32 Design Studio S32K1xx Service Pack 1 from the Product Information page, select S32 Design Studio for S32 Platform v3.4 then select 'SW32K1_S32DS_3.4.1_D2106.zip' to download the update archive zip file Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates" Add the downloaded archive as a software site. Click "Add Software Site" and browse to select the archive file downloaded in the prior step        Select from available items and click "Install/Update" button. This will start the update installation process.   Technical Support please use public community for questions https://community.nxp.com/community/s32/s32ds  

Hi,     With S32DS and multilink, you can try the follow steps to dump flash or RAM data into file.  1. Attach    (https://community.nxp.com/t5/S32-Design-Studio/How-attach-to-running-program/m-p/1030375) 2. Export the data which you need    (https://community.nxp.com/t5/S32-Design-Studio/S32DS-how-to-properly-dump-RAM-in-debug-session/m-p/649974#M1089) Cheers! Oliver

The S32 Flash Tool is provided with support for a few QuadSPI flash memory devices which are typically the devices provided as part of the standard NXP EVB for each of the support NXP Automotive Processors. This will work for most users, but some may select a device for which support is not included with the tool. The FlashSDK was created to provide an easy method for adding support for additional QuadSPI flash memory devices to the S32 Flash Tool. First, a brief explanation of how the S32 Flash Tool works. The S32 Flash Tool programs external flash devices such as QuadSPI, SD, MMC, and eMMC. For each external flash device, there is a flash device-specific flash algorithm file. This flash algorithm file is downloaded by S32 Flash Tool to the target device SRAM, where it will be executed by the target device BootROM. The S32 Flash Tool then sends commands to the flash algorithm along with the image to be programmed to external flash. The flash algorithm will perform the programming of the image to the external flash device. The Flash SDK provides the capability to produce new flash algorithm files, which could then be uploaded to the target device by the S32 Flash Tool and then used to program images to the associated external flash device. The FlashSDK is provided in the form of a S32 Design Studio for S32 Platform v3.x project. This example project, as provided, will build and output a binary file similar to the MX25UM51245G.bin, MX25UW51245G.bin files included in the S32 Flash Tool. The project is designed to build for the Arm M7 core. It is located within the S32 Flash Tool installation directory and inside the folder 'FlashSDK_Ext'. For example, since the S32 Flash Tool is included within the S32 Design Studio 3.x, if the default installation settings were used, this could be found at the path: C:\NXP\S32DS.3.x\S32DS\tools\S32FlashTool\FlashSDK_Ext There is some limited documentation included with the FlashSDK, it can be found by navigating to the '...\FlashSDK_Ext\doc\html' directory and then open 'index.html' with your web browser. In this document, an example process for using the FlashSDK to produce a new binary file will be detailed. Prerequisites Install S32 Design Studio Locate or prepare an image file to be programmed to flash memory Setup hardware to Serial Boot mode Procedure Launch the S32 Design Studio Import the FlashSDK project, using copy to workspace option to preserve the original project. File -> Import Select 'Existing Projects from Workspace' Click 'Browse', locate and then select the 'FlashSDK_Ext' folder, check the box for 'Copy projects into the workspace' Open source files. The files in the project which should be modified for a new flash device are: ...\FlashSDK\Algo\Generic\qSPI_Algorithm.c and qSPI_chip_commands.h Locate the files within the Project Explorer and double click them to open them in the editor. Edit source files. The header file 'qSPI_chip_commands.h' contains many #defines for the flash memory chip which should be adjusted to your new device. Please refer to the reference manual provided by the flash device manufacturer for details on the correct values. As you can see, it is currently setup for the MX25UM51245G device from Macronix. Build the project. The project is setup for 2 build types for you, Debug and Release. The Release build type is more efficient and will run faster, and the Debug build type will allow you to run the debugger in attach mode to investigate issues with the changes you've made. Test new binary on the target and flash memory device. Follow the usual steps to use the S32 Flash Tool.

Trace functionality is supported in the S32 Debugger for A53 cores on the S32R, RAM-target builds. With Trace, you can record some execution data on an application project and then review it to determine the actions and data surrounding an event of interest.   This document outlines the method to begin using Trace on the S32R45 device. We start by creating a project on which to execute the trace, however, you may start at step 2, if you are starting with an existing project. Please note, you will need to have debug configurations for the S32 Debugger setup for each core which you intend to capture trace. If you do not already have such configurations, you may copy them from another project and adapt them to the new project as shown in HOWTO: Add a new debugger configuration to an existing project.   Create a new application project, selecting the 'S32R45 Cortex-A53' processor and 'S32 Debugger' options.  There should now be 4 new application projects in your workspace. One for each A53 core. The first core of the S32R45, A53_0_0, is also a possible boot core, so this project will have build configurations for RAM and FLASH. The other A53 cores (0_1, 1_0, 1_1) will not. Build all projects for Debug_RAM and check that they build clean before proceeding. Open 'Debug Configurations...' and select the 'Debug_RAM' configuration for the first core (A53_0_0_Debug_RAM_S32Debug). Select the 'Debugger' tab. Enter the Debug Probe Connection settings as appropriate for your hardware setup. Click Apply. Now select the Launch Group configuration for 'Debug_RAM'. It is important to use the launch group to start the debug for each core, not just because it makes it easier, but also because it is necessary to allow for some delay after the first A53 core is started before bringing the other A53 cores from reset to debug state. Press Debug Once the code is loaded to the target and the debugger has started each core and executed to the first line within main(), then it is ready to perform any of the standard debug functions including Trace. Trace does not start automatically, it must be turned on before it will start logging data. To do this, it is necessary to add the view 'Trace Commander'. It can be found by either Window -> Show View -> Other, then search for 'Trace Commander' or enter 'Trace Commander' in the Quick Access field of the toolbar and select Trace Commander from the list. The Trace Commander view will show in the panel with the Console, Problems, etc. Double-click on the tab to enlarge it. Click on the configure button to change settings. Click on the Advanced Trace Generators configuration button For each core to be logged, set the associated ELF file. Select the core, click Add, then '...', and select the elf file for that core. Select Data Streams. Now it is possible to change how the data is captured. Since the buffers have finite memory, they can be set to collect data until full, or to overwrite. If set to One buffer, the data will be collected until the buffer is full, then data collection stops. It is useful to gather data when starting logging from a breakpoint to gather data during execution of a specific section of code. If set to Overwrite, the data collection continues and starts overwriting itself once the buffer is full. This is useful when trying to gather data prior to a breakpoint triggered by a condition.  To turn on the Trace logging, click on the 'Close this trace stream' button. The Trace is now enabled. To collect trace data, the cores must be executing. First double-click the Trace Commander tab to return to the normal Debug Perspective view. Then, one by one, select the main() thread on each core and press Resume to start them all. If collecting from a breakpoint, start the code first with Trace disabled, wait for the breakpoint to be reached, then enable the Trace. Allow the cores to run for a period of time to gather the data, then press Suspend on each one until they are all suspended. Look to the Trace Commander tab to see that the data icon is no longer shaded and click on it to upload the trace data. A new tab, Analysis Results, has appeared. Double-click this tab to see it better. Click on the arrow next to ETF 0 to show the data collected in the trace buffer. Notice there are 5 separate views on the captured data: Trace (raw data), Timeline, Code Coverage, Performance, and Call Tree. Trace - this is the fully decoded trace data log Timeline - displays the functions that are executed in the application and the number of cycles each function takes, separate tabs for each core Code Coverage - displays the summarized data of a function in a tabular form, separate tabs for each core Performance - displays the function performance data in the upper summary table and the call pair data for the selected function and it's calling function Call Tree - shows the call tree for identification of the depth of stack utilization See the S32DS Software Analysis Documentation for more details on settings, ways to store the logged data, etc.

Trace functionality is supported in the S32 Debugger for A53 cores on the S32G, RAM-target builds. With Trace, you can record some execution data on an application project and then review it to determine the actions and data surrounding an event of interest.   This document outlines the method to begin using Trace on the S32G2xx device. We start by creating a project on which to execute the trace, however, you may start at step 2, if you are starting with an existing project. Please note, you will need to have debug configurations for the S32 Debugger setup for each core which you intend to capture trace. If you do not already have such configurations, you may copy them from another project and adapt them to the new project as shown in HOWTO: Add a new debugger configuration to an existing project.   Create a new application project, selecting the 'S32G274A_Rev2 Cortex-A53' processor and 'S32 Debugger' options.    There should now be 4 new application projects in your workspace. One for each A53 core. The first core of the S32G274A, A53_0_0, is also a possible boot core, so this project will have build configurations for RAM and FLASH. The other A53 cores (0_1, 1_0, 1_1) will not. Build all projects for Debug_RAM and check that they build clean before proceeding. Building the A53_0_0 project will build all projects and the resulting ELF file will contain the output of all 4. Open 'Debug Configurations...' and select the 'Debug_RAM' configuration for the first core (A53_0_0_Debug_RAM_S32Debug). Select the 'Debugger' tab. Enter the Debug Probe Connection settings as appropriate for your hardware setup. Click Apply. Now select the Launch Group configuration for 'Debug_RAM'. It is important to use the launch group to start the debug for each core, not just because it makes it easier, but also because it is necessary to allow for some delay after the first A53 core is started before bringing the other A53 cores from reset to debug state. Press Debug Once the code is loaded to the target and the debugger has started each core and executed to the first line within main(), then it is ready to perform any of the standard debug functions including Trace. Trace does not start automatically, it must be turned on before it will start logging data. To do this, it is necessary to add the view 'Trace Commander'. It can be found by either Window -> Show View -> Other, then search for 'Trace Commander' or enter 'Trace Commander' in the Quick Access field of the toolbar and select Trace Commander from the list. The Trace Commander view will show in the panel with the Console, Problems, etc. Double-click on the tab to enlarge it. Click on the configure button to change settings. Click on the Advanced Trace Generators configuration button For each core to be logged, set the associated ELF file. Select the core, click Add, then '...', and select the elf file for that core. Select Data Streams. Now it is possible to change how the data is captured. Since the buffers have finite memory, they can be set to collect data until full, or to overwrite. If set to One buffer, the data will be collected until the buffer is full, then data collection stops. It is useful to gather data when starting logging from a breakpoint to gather data during execution of a specific section of code. If set to Overwrite, the data collection continues and starts overwriting itself once the buffer is full. This is useful when trying to gather data prior to a breakpoint triggered by a condition.  To turn on the Trace logging, click on the 'Close this trace stream' button. The Trace is now enabled. To collect trace data, the cores must be executing. First double-click the Trace Commander tab to return to the normal Debug Perspective view. Then, one by one, select the main() thread on each core and press Resume to start them all. If collecting from a breakpoint, start the code first with Trace disabled, wait for the breakpoint to be reached, then enable the Trace. Allow the cores to run for a period of time to gather the data, then press Suspend on each one until they are all suspended. Look to the Trace Commander tab to see that the data icon is no longer shaded and click on it to upload the trace data. A new tab, Analysis Results, has appeared. Double-click this tab to see it better. Click on the arrow next to ETF 0 to show the data collected in the trace buffer. Notice there are 5 separate views on the captured data: Trace (raw data), Timeline, Code Coverage, Performance, and Call Tree. Trace - this is the fully decoded trace data log Timeline - displays the functions that are executed in the application and the number of cycles each function takes, separate tabs for each core Code Coverage - displays the summarized data of a function in a tabular form, separate tabs for each core Performance - displays the function performance data in the upper summary table and the call pair data for the selected function and it's calling function Call Tree - shows the call tree for identification of the depth of stack utilization See the S32DS Software Analysis Documentation for more details on settings, ways to store the logged data, etc.

Hi: I just wonder whether I can use S32 debug probe for S32K3 EVB in S32DS 3.4? I couldn't locate script and algorism for S32K3xx. Thanks.

NXP devices can be secured either with password or challenge and response authentication scheme. The S32 Debugger included within the S32 Design Studio for S32 Platform IDE with the S32 Debug Probe provides the ability to debug a secured device. This document provides only the necessary commands specific to launching a debug session on secured NXP devices.. Once the device is unsecured, it will remain so until a power-on-reset or destructive reset occurs. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the Development Package for the device you are debugging. In this case, the S32G2xx development package. This package is important as it contains the S32 Debugger support component Setup the hardware Confirm the setup of the S32G274A 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 Before starting a secure debug session, first confirm that the device is indeed secure. Once one core is unlocked, all cores are unlocked and will remain so until a power-on-reset or destructive reset occurs. After confirming the device is secured, then select the procedure which applies to the lifecycle of the SoC to be debugged.   Check the state of the SoC Open a command window from the installation directory containing the GTA server: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\ Execute the following command: gta.exe -t s32dbg This will invoke a utility that launces a new GTA server instance and then communicates with the target via the S32 Debug Probe and will request a set of properties of the SoC. These properties are available to be read regardless of security state. The GTA server will close once the information is returned. As is shown above, the Debug state is ‘Locked’. This means it is secured and the secure debug steps outlined within this document must be used. There is no way to determine the security enabled on the SoC, so this should be known by the user in order to select the correct authentication scheme. Proceed from here using the method (Password or Challenge & Response) which applies for your SoC security configuration. Password From S32DS, open the Debug Configurations menu, select the configuration for the project you wish to debug, select the ‘Debugger’ tab and scroll down until the ‘Secure debugging’ section is visible. Check the box for ‘Enable secure debugging’ and then select the Debugging type ‘Password’. Click Debug. When the debug session initialization reaches the stage where the password must be entered to unsecure the SoC, the following menu will appear. Enter the password. This is a 16-byte value entered as a hexadecimal without the leading ‘0x’. If you choose to check the box for ‘Store keyword in secure storage’, the value entered will be stored within the Eclipse secure storage and will remain available for the duration of the current S32DS instance. This saves the user from having to enter the password again, should the security state of the SoC becomes once again secured. Now the debug session initialization will complete and debug activities may be executed as with any SoC which is not secured. After terminating the debug session, the GTA utility can be used again to see the new state of the SoC. This utility cannot be executed while the debug session is running. It launches a new instance of the GTA server, which would be blocked by the already running debug session. Challenge & Response For the Challenge & Response security scheme, the included Volkano Browser must be used. From the S32DS menu bar, select Window -> Show View -> Other -> ‘Volkano Browser’. The Volkano Browser will now appear in the current perspective. Since there is no current key stored in the Volkano local storage, a new key must be registered. Click on ‘Register Key’ to register a new key. This will bring up the Volkano command dialog. Now enter the ADKP value (Application Debug Key/Password) which is correct for the SoC to be debugged. The Volkano utility uses the same functionality as the command-line GTA utility shown earlier to check the state of the SoC. This will read the UID from the Soc. Click Connect to the SoC and load the UID (Device Unique ID). The UID is associated with the ADKP when it is registered within the Volkano local storage for easier access in the future. Click OK to complete the registration of the new key. Now the key is registered, the debug session can be setup and started. Open the Debug Configurations menu, select the configuration for the project you wish to debug, select the ‘Debugger’ tab and scroll down until the ‘Secure debugging’ section is visible. Check the box for ‘Enable secure debugging’ and then select the Debugging type ‘Challenge & Response’. Click Debug. Now the debug session initialization will complete and debug activities may be executed as with any SoC which is not secured. During debug session initialization, the key that was registered will be used to unsecure the SoC. After terminating the debug session, the GTA utility used earlier can be used again to see the new state of the SoC. This utility cannot be executed while the debug session is running. It launches a new instance of the GTA server, which would be blocked by the already running debug session. Troubleshooting There are some messages displayed when things go wrong that can help to identify the cause of the issue. Due to the sensitive nature of the Secure Debug, the error indications detailed below are inherently general and are provided as a guide for interpreting them to determine the likely cause. Debug session started when SoC is still secured There is an error message reported in the S32 Debugger Console to indicate the SoC is still secure. To see this message the GDB Server log must be enabled in Debug Configurations -> Debugger tab, GDB Server section: When this error is incurred, first indication is popup error message for Error code 102: Next, the following text will be displayed in the S32 Debugger console window: If needed, select this view from the menu: In addition, if GDB Traces log is enabled, the following error message can be found in the gdb traces console view: Enable the GDB Traces log in Window->Preferences, then search on GDB: To select the view from console: Incorrect Challenge/Response Or Password If the SoC is setup for Challenge & Response security scheme, but Password security scheme is selected in Debug Configuration, or Challenge & Response is correctly selected but the wrong ADKP value is provided, below are the expected error messages. The result is same if the SoC is setup for Password and either Challenge & Response or wrong password is used. First error message is Error code 601: Next, the gdb traces console displays the following error: There is no error displayed in the S32 Debugger console.

NXP devices can be secured either with password or challenge and response authentication scheme. The S32 Debugger included within the S32 Design Studio for S32 Platform IDE with the S32 Debug Probe provides the ability to debug a secured device. This document provides only the necessary commands specific to launching a debug session on secured NXP devices.. Once the device is unsecured, it will remain so until a power-on-reset or destructive reset occurs. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the Development Package for the device you are debugging. In this case, the S32R4xx development package. This package is important as it contains the S32 Debugger support component 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 Before starting a secure debug session, first confirm that the device is indeed secure. Once one core is unlocked, all cores are unlocked and will remain so until a power-on-reset or destructive reset occurs. After confirming the device is secured, then select the procedure which applies to the lifecycle of the SoC to be debugged.   Check the state of the SoC Open a command window from the installation directory containing the GTA server: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\ Execute the following command: gta.exe -t s32dbg This will invoke a utility that launces a new GTA server instance and then communicates with the target via the S32 Debug Probe and will request a set of properties of the SoC. These properties are available to be read regardless of security state. The GTA server will close once the information is returned. As is shown above, the Debug state is ‘Locked’. This means it is secured and the secure debug steps outlined within this document must be used. There is no way to determine the security enabled on the SoC, so this should be known by the user in order to select the correct authentication scheme. Proceed from here using the method (Password or Challenge & Response) which applies for your SoC security configuration. Password From S32DS, open the Debug Configurations menu, select the configuration for the project you wish to debug, select the ‘Debugger’ tab and scroll down until the ‘Secure debugging’ section is visible. Check the box for ‘Enable secure debugging’ and then select the Debugging type ‘Password’. Click Debug. When the debug session initialization reaches the stage where the password must be entered to unsecure the SoC, the following menu will appear. Enter the password. This is a 16-byte value entered as a hexadecimal without the leading ‘0x’. If you choose to check the box for ‘Store keyword in secure storage’, the value entered will be stored within the Eclipse secure storage and will remain available for the duration of the current S32DS instance. This saves the user from having to enter the password again, should the security state of the SoC becomes once again secured. Now the debug session initialization will complete and debug activities may be executed as with any SoC which is not secured. After terminating the debug session, the GTA utility can be used again to see the new state of the SoC. This utility cannot be executed while the debug session is running. It launches a new instance of the GTA server, which would be blocked by the already running debug session. Challenge & Response For the Challenge & Response security scheme, the included Volkano Browser must be used. From the S32DS menu bar, select Window -> Show View -> Other -> ‘Volkano Browser’. The Volkano Browser will now appear in the current perspective. Since there is no current key stored in the Volkano local storage, a new key must be registered. Click on ‘Register Key’ to register a new key. This will bring up the Volkano command dialog. Now enter the ADKP value (Application Debug Key/Password) which is correct for the SoC to be debugged. The Volkano utility uses the same functionality as the command-line GTA utility shown earlier to check the state of the SoC. This will read the UID from the Soc. Click Connect to the SoC and load the UID (Device Unique ID). The UID is associated with the ADKP when it is registered within the Volkano local storage for easier access in the future. Click OK to complete the registration of the new key. Now the key is registered, the debug session can be setup and started. Open the Debug Configurations menu, select the configuration for the project you wish to debug, select the ‘Debugger’ tab and scroll down until the ‘Secure debugging’ section is visible. Check the box for ‘Enable secure debugging’ and then select the Debugging type ‘Challenge & Response’. Click Debug. Now the debug session initialization will complete and debug activities may be executed as with any SoC which is not secured. During debug session initialization, the key that was registered will be used to unsecure the SoC. After terminating the debug session, the GTA utility used earlier can be used again to see the new state of the SoC. This utility cannot be executed while the debug session is running. It launches a new instance of the GTA server, which would be blocked by the already running debug session. Troubleshooting There are some messages displayed when things go wrong that can help to identify the cause of the issue. Due to the sensitive nature of the Secure Debug, the error indications detailed below are inherently general and are provided as a guide for interpreting them to determine the likely cause. Debug session started when SoC is still secured There is an error message reported in the S32 Debugger Console to indicate the SoC is still secure. To see this message the GDB Server log must be enabled in Debug Configurations -> Debugger tab, GDB Server section: When this error is incurred, first indication is popup error message for Error code 102: Next, the following text will be displayed in the S32 Debugger console window: If needed, select this view from the menu: In addition, if GDB Traces log is enabled, the following error message can be found in the gdb traces console view: Enable the GDB Traces log in Window->Preferences, then search on GDB: To select the view from console: Incorrect Challenge/Response Or Password If the SoC is setup for Challenge & Response security scheme, but Password security scheme is selected in Debug Configuration, or Challenge & Response is correctly selected but the wrong ADKP value is provided, below are the expected error messages. The result is same if the SoC is setup for Password and either Challenge & Response or wrong password is used. First error message is Error code 601: Next, the gdb traces console displays the following error: There is no error displayed in the S32 Debugger console.

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio v3.4 Vision Extension Package for S32V23x 1.3.0          What is new? Integrated VSDK 1.7.0   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  installation:  go to menu "Help" -> "S32DS Extensions and Updates" dialog  select from available items and click "Install/Update" button offline installation:   go to S32 Design Studio for S32 Platform product page -> Downloads section or use direct link to download the update archive zip file        Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Add Update Sites' link Select the downloaded update archive zip file you downloaded in the previous step       Select the 'Vision extension package for S32V23x' package and click "Install/Update" button.   This will start the update installation process.

          Product Release Announcement Automotive Processing S32 Design Studio for S32 Platform v3.4           Austin, Texas, USA Dec 22, 2020   The Automotive Processing's Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the  S32 Design Studio v3.4 Here are some of the major features: Eclipse Neon 2019.12 Framework GNU tools: GCC version 6.3.1 20170509, build 1620 revision g01b30c3 GCC version 9.2.0 20190812, build 1649 revision gaf57174 NPW support for GCC 9.2 toolchain (available for selected devices only) S32 Configuration Tool framework 1.3 with the Pin, Clock, Peripheral, DCD, IVT, DDR and QuadSPI Configuration tools (SDK/RTD packages required to get support for particular device)  The wizards for creating application, library projects and projects from project examples for the supported processor families The S32DS Extensions and Updates tool S32 Trace Tool S32 Debugger support PEMicro® debugger support Lauterbach Trace32® support Green Hills compiler support S32 Flash Tool Peripheral and System Registers view SDK management Support for importing MCAL configuration to a custom SDK Support for migration: project with GCC 6.3.1 toolchain to GCC 9.2 toolchain S32DS for ARM  projects for S32K1 device to S32DS 3.3, including SDK* * available with S32K1 package, not yet released, more details could be found in Release Notes  Release is available for download on NXP web and from S32DS 3.4. Please make sure that you get new activation ID for this version. Support for S32S247TV and S32V23x is available on public update site and release location. S32V23x support: S32SDK S32V234 RTM 1.0.1  S32 Configuration tools - Pins, Clocks, Peripheral (installed with SDK package) S32 Debugger (with S32 Debug Probe) support for ARM cores S32 Trace for A53 cores GCC version 6.3.1 20170509, build 1574 S32 Flash Tool support AMMCLIB 1.1.20 P&E and Lauterbach debuggers support Note: Vision Extension package 1.2.0 with support for S32 Design Studio 3.4 is not yet available, if you need to work with VSDK and Vision tools - it is recommended to stay on S32DS 3.3 until a new version of Vision Extension package is released   S32S247TV support: Support for S32S247TV new project wizards, GCC 6.3.1 and GHS compilers S32SDK S32S247TV EAR 0.8.1  S32 Configuration tools - Pins, CLocks, Peripheral, DCD, IVT (installed with SDK package) S32 Debugger (with S32 Debug Probe) support  S32 Flash Tool support Lauterbach support S32K1 support: Support for S32K1xx new project wizards, GCC 6.3.1, IAR and GHS compilers NXP GCC version 6.3.1 20170509, build 2017 S32SDK S32K1xx RTM 4.0.1 AMMCLIB 1.1.22 S32 Configuration tools - Pins, CLocks, Peripheral (installed with SDK package) PEmicro, iSystem, Segger, IAR, Lauterbach  debuggers support Support for S32V23x, S32S247TC, S32K1xx is provided on update site and archive SW32_S32DS_3.4.0_D2012.zip for offline use    Complete S32 Design Studio for S32 Platform v3.4 release notes and Installation Guide are attached.   Installation To download the installer please visit the S32 Design Studio product page download section or click the direct here.     The installer requires the Activation ID to be entered. You should receive a notification email including the Activation ID after the download of the installation package starts.   The installer installs just the base tools/package. In order to start development it is necessary to install at least one Development package. Currently the only development packages available are S32S2xxTV and S32V2xx. The application packages are managed by S32DS Extensions and Updates.         Technical Support S32 Design Studio issues are tracked through the S32DS Public NXP Community space. https://community.nxp.com/community/s32/s32ds  

Project created by S32 Design Studio (S32DS) new project wizard typically contains the debugger configurations to load  and debug the project into the code memory (Flash/RAM). However there might be situations that require also to load a content/data (e.g. calibration values) into a special on-chip memory (such as shadow flash, data flash, utest flash...) or an external memory (QSPI). This document describes how to program multiple memory types (using different programming algorithms) just by single click on the debug button. The decription applies to PEMICRO probes (Multilink Universal, Multilink FX or OpenSDA) anyway a similar approach might be applicable for other vendor probes. The process can be splitted into two steps: 1. create a separate debugger configurations to program a specific memory modules(QSPI,  data flash,..) 2. associate the program and debug configurations into the single launch group  - this alows to execute multiple actions by invoking the single debug launch . Let's demonstrate this on MPC5744P and program code and data flash memory using S32DS for Power v2.1 (similar approach can be applied also to other architectures/versions of S32DS). •  Create a new empty project for MPC5744P. Such a project typically contains Debug/Debug_RAM debugger configuration. First we will add a dummy code  (see below) that creates a record to be stored into the data flash memory (different to code flash memory block). • The project linker file (MPC57xx_flash.ld) should have the data flash memory block and a linker section associated with data flash (.dflash) defined: MEMORY { dflash : org = 0x00800000, len = 0x1F /* not entire dflash - just for test*/ flash_rchw : org = 0x00FA0000, len = 0x4 cpu0_reset_vec : org = 0x00FA0004, len = 0x4 m_text : org = 0x1000000, len = 2048K m_data : org = 0x40000000, len = 384K local_dmem : org = 0x50800000, len = 64K } SECTIONS { .dflash : { KEEP(*(.dflash)) } > dflash … •Add a test code into main.c that results in creating a dummy data record in data flash memory (0x0800000) __attribute__((section(".dflash"))) volatile char dflash_data[]="DTEST String"; // place the string into .dflash segment int main(void) { volatile int counter = 0; volatile char test_str[10]; test_str[0] = dflash_data[0]; // use DFLASH data (to avoid deadstripping) /* Loop forever */ for(;;) { counter++; } } Now if you build the project you can see the data that belong to dflash and code flash in the .map or srec file. If you debug the project using the default debug configuration data flash (DFLASH) memory is not programmed. To program DFLASH you should create another debug configuration simply by duplicating the existing one and changing the programming algorithm to dflash one: nxp_mpc5744p_1x32x20k_dflash.pcp. Note: There are many flash programming algorithms available in PEMICRO eclipse plugin folder typically located here (version of plugin may vary): "C:\NXP\S32DS_Power_v2.1\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_2.0.2.202005132054\win32\gdi\P&E\" S32DS: Duplicate Debug Configuration S32DS: Load parameters S32DS: Choose alternative programming algorithmNow the new debug configuration (MPC5744P_code_dflash_Debug_DFLASH) is able to program data flash memory. The final step is to create a launch group configuration and associate it with all the programming/debugging configurations that should be executed once debug is started. Add the debug configuration used just for programming purpose as flash type and code debug configuration as debug type. In order to avoid interference between programming of various memories select post launch action -> "Wait until terminated" Finally as soon as the debug session is established by launching the launch group created above - all the memories are programmed and you can debug the code. Note: There is an information about executed flash configurations in the debug context view. Since the programming has alredy finished the thread is terminated and could be cleared by double cross icon. Enjoy single click programming&debugging in S32 Design Studio!