S32 Design Studio Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32 Design Studio Knowledge Base

Discussions

Sort by:
      ​S32 Design Studio Version 3.6.0   1. IDE New Features The S32Design Studio 3.6 is delivered with all public NPI's in a single 2.5GB installer to improve first time user experience. Additional packages for alpha customers are available based on Flexera entitlement and can be installed on top of S32Design Studio 3.6.0 using Extension and Updates mechanism as depicted below. New S32Design Studio Installer is faster and lighter (compared to S32Design Studio 3.5) Official support for Window 11 OS and Ubuntu 20.04. Windows 10 OS is tested for compatibility. New Eclipse 2023.12, CDT11.4 and Java 17  Development, Add-Ons and Extension Packages delivered with older S32Design Studio 3.5.x are compatible with version 3.6.0 RTD and Runtime Software releases made on top of S32Design Studio 3.5.x are backward compatible with S32Design Studio 3.6.0 using smart compatibility mechanism New GDB 15.1 for ARM cores New Python 3.10 for ARM cores Improved Extension and Updates mechanism to warn the user when S32Design Studio processes are in use and the installation can not be completed Improved Watch Registers view to expand all registers and export bitfields Improved Dashboard view to include more options for quick access Improvements on UI, update of C/C++ and Debug perspective Improve CLI support to facilitate New Project Creation from command line. For more details please see HOWTO_S32_Design_Studio_Command_Line_Interface.pdf Enable CCS remote for all NPIs 2. S32Debugger New Features New S32Debug Probe OS version 1.1.0 update for resolving WiFi disconnect issue when the probe is connected via USB. Follow the HOWTO_Update_the_S32Debug_Probe_OS.pdf to update the probe firmware to the new version: Expose current exception level in Debug View for ArmV8 cores: New GDB version GDB 15.1 integrated for Arm cores with Python3 interpreter S32K3xx/S32M2xx/S32K14x: S32K14x flash programmer support Enhanced flash programmer to support also programming the Data Flash   3. S32Configuration Tools 1.8.0 New Features Alignment to S32Design Studio: Java 17, Windows 11, Eclipse 2023.12 3.1 DDR features: Intermediate progress report of memory test execution Import log options Access to LPDDR5 DRAM beyond 32bit address space Quickboot, retention support and multicore test execution for LPDDR5    3.2 Scenario Tools features: UI/UX updates for all Boot tools (IVT, DCD, QSPI), allowing quicker access to main tools functions via the built-in toolbar   3.2 GTM Tool features: External Clock for CMU Extended configuration modes and new predefined use-cases for TIM Dynamic channel management for TOM, ATOM, TIM and TBU modules Export HTML report   4. Major features for S32Trace 3.6.0 Added support for all S32G3 Family parts and application cores Added support for Cortex-M7 cores for all S32G2 Family parts   5. Major features for MCU - S32K1, S32K3, S32K37/39 and S32M2 Families: S32Debugger support of S32K14x for FLASH and RAM configuration   S32Debugger support of S32K3xx for FLASH and RAM configuration with multicore support   Now, S32K37/39 Family is part of S32K3 Family distribution S32Debugger support of S32M2xx for FLASH and RAM configuration   Update of 3rd Party Debuggers support: Segger J-Link 8.10c PEmicro v5.9.2 TASKING v9.21.273   6. This release is available: S32Design Studio 3.6.0 can be found on nxp.com and on Flexera   7. The installation instructions: 1. Navigate to S32Design Studio page on nxp.com and click Download 2. Login(if not) and Accept License Agreement. 3. Navigate to License Key tab and copy Activation Code 4. Launch S32Design Studio installer and when asked for Activation code, please provide the one from above step.   ​   ​ `
View full article
To install updates and additional packages to S32 Design Studio: 1) Download the Update from the S32 Design Studio page at NXP.com. 2) From S32 Design Studio, got to Help – S32DS Extensions and Updates. 3) Click on ‘Manage Sites’ link. 4) Select 'Add...' 5) Select 'Archive...', locate the downloaded update: 6) Click OK. 7) Click Apply and Close on the Preferences menu 😎 Notice the S32DS Extensions and Updates menu displays the new content. 9) Check the box next to the new package and click Install/Update. 10) Accept license terms and click Finish. 11) After the installation is complete, restart S32 Design Studio.
View full article
The release notes of S32K RTD usually mention which dependent software packages need to be installed. Taking SW32K1_S32M24x_RTD_R21-11_2.0.0_P04_D2404_ReleaseNotes.pdf as an example, we can see that the following software packages need to be installed: You must be logged into your account on NXP.com to gain access to the download link. 1. Download and install S32Design Studio 3.5: Click S32 Design Studio 3.5 – Windows/Linux -> 3.5 S32 Design Studio for S32 Platform v.3.5 -> S32DS.3.5_b220726_win32.x86_64.exe Note: For Windows OS, the user account designated for installing S32 Design Studio for the S32 Platform must be a member of the local Administrators security group. 2. Download and Install S32 Design Studio 3.5 Update 4 D2307: SW32_S32DS_3.5.4_D2307.zip (com.nxp.s32ds.update_3.5.4.20230707034206.zip) Since the SW32K1_S32DS_3.5.4_D2307.zip downloaded in step3 already contains the files of the SW32_S32DS_3.5.4_D2307.zip in the step2, we will skip this step here. 3. Download and Install S32 Design Studio 3.5 development packages for offline use, support for S32K1 (3.5.4_D2307): SW32K1_S32DS_3.5.4_D2307.zip  (com.nxp.s32ds.s32k1.dev.repository_1.0.0.202307062245.zip) Unchecking Contact all update sites during install to find required software can complete offline installation faster. 4. Click Real-Time Drivers for S32K1 -> Automotive SW - EB tresos Studio / AUTOSAR Configuration Tool Select and install one of the following updatesite.zip for S32K1 RTD 2.0.0: The latest S32K1 RTD version is usually recommended. However, if you need to use Reference Software or Premium Software (such as FreeRTOS, LIN Stack, TCP/IP Stack Structural , Core Self-Test (SCST), Automotive Math and Motor Control Library (AMMCLib), S32K ISELED), it is recommended to install the specific version of S32K1 RTD according to their release notes. 4.a) Download and install S32K1_S32M24X Real Time Drivers AUTOSAR 4.4 & R21-11 Version 2.0.0: SW32K1_S32M24x_RTD_4.4_R21-11_2.0.0_D2308_DS_Updatesite.zip 4.b) Download and install S32K1_S32M24X Real Time Drivers AUTOSAR 4.4 Version 2.0.0 P01: SW32K1_S32M24x_RTD_4.4_R21-11_2.0.0_P01_D2308_DS_Updatesite.zip 4.c) Download and install S32K1_S32M24X Real Time Drivers AUTOSAR R21-11 Version 2.0.0 P04: SW32K1_S32M24x_RTD_R21-11_2.0.0_P04_D2404_DS_updatesite.zip
View full article
The release notes of S32K RTD usually mention which dependent software packages need to be installed. Taking SW32K3_S32M27x_RTD_R21-11_4.0.0_D2311_ReleaseNotes.pdf as an example, we can see that the following software packages need to be installed: You must be logged into your account on NXP.com to gain access to the download link. 1. Download and install S32Design Studio 3.5: Click S32 Design Studio 3.5 – Windows/Linux -> 3.5 S32 Design Studio for S32 Platform v.3.5 -> S32DS.3.5_b220726_win32.x86_64.exe Note: For Windows OS, the user account designated for installing S32 Design Studio for the S32 Platform must be a member of the local Administrators security group.   2. Download and Install S32 Design Studio 3.5 Update 8 D2311: SW32_S32DS_3.5.8_D2311.zip (com.nxp.s32ds.update_3.5.8.20231116041033.zip) Since the SW32K3_S32DS_3.5.8_D2311.zip downloaded in step3 already contains the files of the SW32_S32DS_3.5.8_D2311.zip in the step2, we will skip this step here.   3. Click S32K3 Standard Software -> Automotive SW - S32K3 - S32 Design Studio Download and Install S32 Design Studio 3.5.8 Development Package with support for S32K3xx devices (3.5.8_D2311): SW32K3_S32DS_3.5.8_D2311.zip  (com.nxp.s32ds.s32k3xx.update_3.5.8.20231116045533.zip) Unchecking Contact all update sites during install to find required software can complete offline installation faster.   4. Download and install S32 Design Studio 3.5.6 RTM with support for S32K39x devices(3.5.6_D2309): SW32K39x_S32DS_3.5.6_D2309.zip   5. For users who need to use S32M27x(Otherwise, go to step 6), please click S32M2 Standard Software -> Automotive SW - S32M2 - S32 Design Studio Download and Install S32 Design Studio 3.5.8 Development Package with support for S32M2xx devices(3.5.8_D2311): SW32M2_S32DS_3.5.8_D2311.zip (com.nxp.s32ds.s32m2.update_3.5.8.20231116044631.zip)   6. Click S32K3 Standard Software -> Automotive SW - S32K3/S32M27x - Real-Time Drivers for Cortex-M Select and install one of the updatesite for S32K3 RTD 4.0.0.  The latest S32K3 RTD version is usually recommended. However, if you need to use Reference Software or Premium Software (such as FreeRTOS, LIN Stack, TCP/IP Stack, AWS Libraries for S32K3, S32 Safety Software Framework (SAF) for S32K3xx, Structural Core Self-Test (SCST), HSE Premium Firmware, ISELED Driver), it is recommended to install the specific version of S32K3 RTD according to their release notes. Since there are many versions of S32K3 RTD 4.0.0, only one version of RTD will be installed here. Download and install S32K3_S32M27x Real-Time Drivers AUTOSAR R21-11 Version 4.0.0: SW32K3_S32M27x_RTD_R21-11_4.0.0_D2311_DS_updatesite.zip Then in S32DS v3.5, click File -> New -> S32DS Project from Examples and you should be able to see the example projects for S32K3 RTD 4.0.0.
View full article
Installation & Activation HOWTO: Activate S32 Design Studio   HOWTO: S32 Design Studio - Offline Install of Extensions and Updates  S32DS Extensions & Updates: Explanation and How To Use  HOWTO: Install Lauterbach TRACE32 debugger plug-in into S32 Design Studio HOWTO: Install GHS Compiler Plugin    Getting Started S32DS Quick Start Guide  S32 Design Studio 3.5 Tips and Tricks HOWTO: S32 Design Studio - Create a New S32DS Project from Example  HOWTO: S32 Design Studio - Create a New Application Project  HOWTO: Create a Blinking LED example project using S32K1xx RTD with AUTOSAR HOWTO: Create a Blinking LED example project using S32K1xx RTD without AUTOSAR HOWTO: Create a Blinking LED application project for S32G using S32 RTD No AUTOSAR HOWTO: Create a Blinking LED application project for S32G using S32 RTD with AUTOSAR HOWTO: Create a Blinking LED application project for S32M2xx using S32 RTD with AUTOSAR  HOWTO: Create a Blinking LED application project for S32M2xx using S32 RTD No AUTOSAR  HOWTO: Create a Blinking LED application project for S32R45 using S32 RTD No AUTOSAR HOWTO: Create a Blinking LED application project for S32R45 using S32 RTD with AUTOSAR HOWTO: Create a Blinking LED application project for S32R41 using S32 RTD No AUTOSAR  HOWTO: Create a Blinking LED application project for S32R41 using S32 RTD AUTOSAR HOWTO: Create a simple blinking LED project using S32 Config Tool (S32V2xx)  HOWTO: Create a Blinking LED application project for S32Z27x using S32 RTD No AUTOSAR  HOWTO: Create APEX2 Project From Example in S32DS for S32 Platform  HOWTO: Create An ISP Project From Example in S32DS for S32 Platform HOWTO: Create New Project from Example ‘RSDK_S32DS_template’    Build tools & Standard libraries  HOWTO: Add a static library file into S32 Design Studio GCC project HOWTO: Link a binary file(s) into the application project using GNU build tools   HOWTO: Display Percentage Of Memory Usage At End Of Build    Debug  & Flash Programming HOWTO: Setup S32V234 EVB for debugging with S32DS for Vision and Linux BSP  Using GDB Server Monitor Commands from Eclipse GDB Console HOWTO Build a Project and Setup Debugging with GDB PEMicro Debugging Interface  HOWTO: Setup static IP address for S32 debug probe  HOWTO: Start S32 Debugger from S32 Design Studio on S32G274A EVB HOWTO: Start S32 Debugger from S32 Design Studio on S32R45 EVB  HOWTO: Start S32 Debugger from S32 Design Studio on S32R41 EVB HOWTO: Command Line GDB Debugging with S32 Debug Probe for S32G2xx HOWTO: Command Line GDB Debugging with S32 Debug Probe for S32R45  HOWTO: Command Line GDB Debugging with S32 Debug Probe for S32R41 HOWTO: JTAG Flash Programming with S32 Debugger and S32 Debug Probe for S32G274A EVB HOWTO: JTAG Flash Programming with S32 Debugger and S32 Debug Probe for S32R45 EVB  HOWTO: JTAG Flash Programming with S32 Debugger and S32 Debug Probe for S32R41 EVB  HOWTO: Secure Debugging from S32DS IDE with S32 Debugger and S32Debug Probe  HOWTO: Start Trace with S32 Debugger and S32 Debug Probe on S32G2xx HOWTO: Start Trace with S32 Debugger and S32 Debug Probe on S32R45  HOWTO: Start Trace with S32 Debugger and S32 Debug Probe on S32V2xx  Sharing Debug Configuration with Eclipse Debugging the Startup Code with Eclipse and GDB  HOWTO: Add a new debugger configuration to an existing project  HOWTO: Command Line JTAG flash programming with S32 Debug Probe on S32G274A EVB HOWTO: Command Line JTAG flash programming with S32 Debug Probe on S32R45 EVB  HOWTO: Command Line JTAG flash programming with S32 Debug Probe on S32R41 EVB HOWTO: Use FlashSDK to add support for QuadSPI flash memory devices for S32 Flash Tool  HOWTO: Program Serial RCON using S32 Debug Probe  Secure Debug Support on S32K3 | PEmicro  HOWTO: Debugging LAX on S32R45 Using S32 Debugger HOWTO: Debugging SPT on S32R45 Using S32 Debugger HOWTO: Debugging BBE32 DSP on S32R45 Using S32 Debugger HOWTO: Debugging SPT on S32R41 Using S32 Debugger S32Debugger Zephyr Thread Awareness User Manual    S32 Configuration Tools HOWTO: Use DCD Tool To Create A Device Configuration Data Image  HOWTO: Use IVT Tool To Create A Blob Image HOWTO: Use IVT Tool To Create A Blob Image S32G274A HOWTO: Use IVT Tool To Create A Blob Image S32R45    Real-Time Drivers (RTD), S32 SDK & Other SDKs HOWTO: Working with AMMCLib SDKs  HOWTO: Add custom SDK into existing project  HOWTO: Migrate S32K1xx SDK project from SDK v4.0.1 to v4.0.2  HOWTO Use FreeRTOS OS Awareness with S32Debugger and PEMicro  Implementing FreeRTOS Performance Counters on ARM Cortex-M | MCU on Eclipse  HOWTO: Move FreeRTOS Heap into DTCM memory - S32K3xx + RTD   General Usage HOWTO: S32 Design Studio Command Line Interface  HOWTO: Generate S-Record/Intel HEX/Binary file  HOWTO: Migrate Application Projects from S32DS for Vision 2018.R1 to S32DS 3.x  HOWTO: Add user example into S32DS   Troubleshooting Troubleshooting: Incompatible JVM Error When Launching S32 Flash Tool v2.1 Troubleshooting: PEmicro Debug Connection: Target Communication Speed  Troubleshooting: Indexer errors on header file  Troubleshooting: PEMicro Debugging: PIT and STM modules cannot count when Debug Mode is entered  Troubleshooting: PEMicro Debugging: Problems resuming from breakpoint in vTaskDelay  Troubleshooting: Quick Fix Option in Problems View  Troubleshooting: S32 Design Studio exits unexpectedly or Installer rolls back immediately following activation code entry  Troubleshooting: Activation fails with error message FNP ERROR 0  Troubleshooting: Can't See AMMCLib for S32K3 in S32DS Extensions and Updates Troubleshooting: Java Error When Config Tools Used From Command Line    
View full article
This document shows the step-by-step process for creating a simple blinking LED application for the S32Z27x family using the S32 RTD non-AUTOSAR drivers. This example used for the S32Z27x-DC EVB, which is connected via an Ethernet connection through the S32 Debugger.   Preparation  Setup the software tools  Install S32 Design Studio for S32 Platform   Install the S32Z2/E2 development package and the S32ZE RTD AUTOSAR R21-11 Version 0.9.0 P01 Both of these are required for the S32 Configuration Tools.    Launch S32 Design Studio for S32 Platform  Procedure    New S32DS Project    OR                    Provide a name for the project, for example 'Blinking_LED_RTD_No_AUTOSAR'. The name must be entered with no space characters.     Expand the Family ‘S32Z27x’, and Select ‘S32Z270 (Boot core_ R52_0_0)’      Click '…' button next to SDKs    Check box next to PlatformSDK_S32ZE_2022_10_S32Z270_R52_0_0_LS (or whichever latest SDK for the S32M27x is installed). Click OK     Click "Finish" and wait for the project generation wizard to complete. Then, expand the project within the "Project Explorer" view to show its contents.      To control the LED on the board, some configuration needs to be performed within the Pins Tool. There are several ways to do this. One simple way is to double-click on the .MEX file.    By default, the Pins Tool will be presented. The S32Z27x DC EVB has user D12 LED connected to the PA_01 pin on the S32Z270 device.    To configure this pin, select the "Peripheral Signals" tab to the left of the Pins Tool perspective layout. Locate and open the SIUL2_0 from the peripheral signals tab, and from the drop-down menu, select the "gpio,1 PA_01" option as shown in the following image.  We are using Siul2_0 for GPIO usage, so we are routing the gpio,1 –> PA_01 GPIO signal to this pin.       The Direction required! menu will appear. Select Output then OK.    In Routing Details view, notice a new line has been added and highlighted in yellow.    Add ‘LED’ to the Label and Identifier columns for the Siul2_0, gpio-1 pin.    Code Preview    Go to Peripherals tool and add Gpio_Dio to enable LED blinking, it adjacent to the user LED on S32Z270 EVB.    Click on the Peripherals Tool icon in the Eclipse Perspective navigation bar.  In the Components view, click on the ‘Add a new configuration component…' button in the Drivers category. This will bring up a list of all configuration components.    Locate and select the 'Siul2_Dio' component from the list and click OK. Don't worry about the warning message – it's only indicating that the driver isn't already part of the current project. The associated driver package will be added automatically.   Note: it may be necessary to change the selection at the top from 'Present in the toolchain project' to 'All'.  The Siul2_Dio driver provides services for reading and writing to/from DIO Channels.     Now, form the toolbar selection menu at the top, select and double click on the symbol as shown as below:     Then, from the global settings window, for ComponentGenerationMethod from the drop down menu select “FunctionalGroups” from the drop down menu as shown below:     The Siul2_Dio driver requires no further configuration. Click Save to store all changes to the .MEX file.       Now. click ‘Update Code’ from the menu bar.  Now the device configurations are complete and the RTD configuration code can be generated. Click ‘Update Code’ from the menu bar.     To control the output pin which was just configured, some application code will need to be written. Return to the ‘C/C++’ perspective.    If the 'src' folder is not already open in the project window, click the '>' symbol next to it to show its contents. Then, double-click the 'main.c' file to open it. This is where you will add the application code.    To control the pin, it needs to be 'initialized' using the configuration information generated from the S32 Configuration tools. To do this, add the following line to the 'main' function after the comment 'Write your code here':         /* Initialize all pins using the Port driver */       Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0);        Now, add logic to turn the LED on and off with some delays in between to make it visible blinking. Make sure the delays are long enough to be perceptible.     Add line to initialize variable uint8 i = 0;  Add line to declare variable level: volatile uint8 level;  Change the code within the provided for loop, and add the following lines:     /*logic for blinking LED 10 times*/     for (; i<10; i++)       {           Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 1U);         level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN);           TestDelay(480000);           Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 0U);         level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN);           TestDelay(480000);       }     Before the 'main' function, add a delay function as follows:  void TestDelay (uint32 delay);   void TestDelay (uint32 delay)   {     static volatile uint32 DelayTimer = 0;    while (DelayTimer<delay)      {          DelayTimer++;      }      DelayTimer=0;   }     Update the includes lines at the top of the main.c file to include the headers for the drivers used in the application:    Remove   #include "Mcal.h"  Add   #include "Siul2_Port_Ip.h"   #include "Siul2_Dio_Ip.h"         Build 'Blinking_LED_RTD_No_AUTOSAR'. Select the project name in 'C/C++ Projects' view and then press 'Build'.    After the build completes, check that there are no errors.       Open Debug Configurations and select 'Blinking_LED_RTD_No_AUTOSAR_Debug_RAM'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist.       Now, you need to Select the Interface (Ethernet or USB) by which the S32 Debug Probe is connected.     If connected via USB and this option is selected for interface, then the COM port will be detected automatically (in the rare event where 2 or more S32 Debug Probes are connected via USB to the host PC, then it may be necessary to select which COM port is correct for the probe which is connected to the EVB)    If connected via Ethernet, enter the IP address of the probe. See the S32 Debug Probe User Manual for ways to determine the IP address.    Click apply and Debug  To see the LED blink, click ‘Resume'.     This code as it is will blink the LED 10 times, you can make changes in for loop condition to blink it infinitely.     
View full article
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.
View full article
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.
View full article
1. Install S32Design Studio 3.5: S32DS.3.5_b220726_win32.x86_64.exe 2. Download and Install S32 Design Studio 3.5 Update 2 D2302: SW32_S32DS_3.5.2_D2302.zip  (com.nxp.s32ds.update_3.5.2.20230227110156)   3. Click S32K3 Standard Software -> Automotive SW - S32K3 - S32 Design Studio Download and Install S32 Design Studio 3.5.0 Development Package with support for S32K3xx devices(3.5.0_D2303): SW32K3xx_S32DS_3.5.0_D2303.zip  (com.nxp.s32ds.sp1.s32k3xx.update_3.5.0.20230405175452)   4. For users who need to install S32K396 RTD for development, please download and install S32 Design Studio Service Pack 1 RTM with support for S32K39x devices(3.5.0_D2303): SW32K39x_S32DS_3.5.0_D2303.zip (com.nxp.s32ds.sp1.s32k396.update_3.5.0.20230330)   5.a) For users who need to install S32M276 RTD in S32K3 RTD 3.0.0\P01\P01 HF01\P01 HF02 for development, please download and install S32 Design Studio Service Pack 2 CD with support for S32M2xx devices (3.5.0_D2302😞 SW32M2xx_S32DS_3.5.0_D2302.zip(com.nxp.s32ds.s32m2.update_3.5.0.20230222151347)  Note: Please contact your local FAE to enable for you download the S32M276 development package. 5.b) For users who need to install S32M276 RTD in S32K3 RTD 3.0.0 P07 for development, , please download and install S32 Design Studio Service Pack 2 EAR2 with support for S32M2xx devices(3.5.0_D2303😞 SW32M2xx_S32DS_3.5.0_D2303.zip(com.nxp.s32ds.s32m2.update_3.5.0.20230328160305)   6. S32K3 Standard Software -> Automotive SW - S32K3/S32M27x - Real-Time Drivers for Cortex-M Select and install one of the following updatesite for S32K3 RTD 3.0.0: 6.a) Download and install S32K3 Real-Time Drivers Version 3.0.0: SW32K3_RTD_4.4_R21-11_3.0.0_D2303_DS_updatesite.zip   6.b) Download and install S32K3 Real-Time Drivers Version 3.0.0 P01 : SW32K3_RTD_4.4_3.0.0_P01_D2303_DS_updatesite.zip   6.c) Download and install S32K3 Real-Time Drivers Version 3.0.0 P01 HotFix 02 (3.0.0_P01_HF02😞 SW32K3_RTD_4.4_3.0.0_P01_HF02_DS_updatesite_D2305.zip   6.d) Download and install S32K3_M27X Real-Time Drivers Version 3.0.0 P07: SW32K3_RTD_R21-11_3.0.0 _P07_D2307.zip  
View full article
This document details the steps to program external EEPROM with the 32 reset configuration bits in support of the 'Boot from serial RCON' method detailed in the device reference manual. The Python scripts used for this task are designed and tested to work on the EVBs, where EEPROM hardware is connected via I2C.(Serial EEPROM is not implemented on all boards).   The RCON can be set by the following:    Fuses (internal to the device)  Parallel (GPIO pins/DIP Switches on EVB)  Serial (EEPROM connected via I2C)    The Serial option can be programmed using a debug probe connected via JTAG. This enables the RCON to be controlled remotely, assuming the debug probe is setup to allow remote connections.  The images shown throughout this document are of the S32G274A device implementation and are provided for illustration purposes.               Preparation    Install S32 Design Studio IDE  Use the S32DS Extensions and Updates menu to install the Development Package for the device subject to debugging. This is important as the Development Packages add the S32 Debugger support which provides access to the EEPROM programming capabilities via I2C of the S32 Debug Probe.  Connect the S32 Debug Probe to the EVB and the host PC containing S32 Design Studio installation.  Set BOOTMOD pins to boot from RCON    Set BOOT_CFG[8]=1 on the EVB, for serial RCON mode   Procedure    Depending on the way the device used and how the {device name}_i2c_RCON.py is edited, user must use the old procedure on the new one. Both detailed below. To choose between the Old procedure and the new procedure, you must check in the {device_name}_i2c_RCON.py if variables like “INTERACTIVE_MODE” and “RCON_DATA” exist. The {device_name}_i2c_RCON.py can be found in: {INSTALL_DIR}…S32DS/tools/S32Debugger/Debugger/scripts/{device_name}/ {device_name_part_name}_i2c_RCON.py If the variables exist, please use the old procedure. If the variables were removed, please use the new procedure. I.  Old procedure ( If “INTERACTIVE_MODE” variable still exists)   Open cmd window to the S32 Debugger folder where the device-specific scripts are located. ../S32Debugger/Debugger/Scripts/{device_name/part_number} Set Python path so correct version is used (if not already set in env vars)   set PYTHONPATH=C:\NXP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7;C:\N XP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages   Edit the python script to adjust the value to be programmed to RCON, {device_name}_i2c_RCON.py. Note: The listed examples show only the minimum values required to configure each of the external memory types. Additional settings may be required for your specific application.   Adjust RCON_DATA for the configuration you wish to program. Do not adjust RCON_ADDR. Adjust S32DBG_IP for the IP address of your S32 Debug Probe. Adjust INTERACTIVE_MODE i. Set True, if desired to be prompted in the command window to enter RCON_DATA      ii. Set False, if desried to have script automatically enter RCON_DATA, based on the value set     within the file. Adjust _SOC_NAME as appropriate for the specific device you are using. The valid options are defined in {device_name}_context.py Enter the command to start GDB, passing in the RCON Python script:   Windows OS: ../ S32DS\tools\gdb-arm\arm32-eabi\bin/arm-none-eabi-gdb-py.exe -x {device_name}_i2c_RCON.py OR ../ S32DS\tools\gdb-arm\arm64-eabi\bin/arm-none-eabi-gdb-py.exe -x {device_name}_i2c_RCON.py Linux OS: arm-none-eabi-gdb-py -x {device_name}_i2c_RCON.py   If everything worked properly, then the value you programmed will be displated to the screen.   To exit GDB, enter ‘quit’. II.  New Procedure ( If “INTERACTIVE_MODE” variable was deleted)   Set Python path so correct version is used (if not already set in env vars)  set PYTHONPATH=C:\NXP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7;C:\N XP\S32DS.3.5\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages  Start GDB Server. (…\S32Debugger\Debugger\Server\gta\gta.exe)   Start Command Prompt and enter the command to start GDB with python: Example:   C:\NXP\S32DS.3.5_230912_devpck\S32DS\tools\gdb-arm\arm32eabi\bin\arm-none-eabi-gdb-py.exe Linux OS: arm-none-eabi-gdb-py     In s32rcon.py ( C:\NXP\S32DS.3.5_230912_devpck\S32DS\tools\S32Debugger\Deb ugger\scripts\gdb_extensions\rcon\s32rcon.py😞 Edit connection parameters (Probe IP, GDB server port, JTAG speed, etc.) Edit _RCON_SCRIPT parameter with absolute path to the desired I2C RCON script for the desired board: Example: _RCON_SCRIPT = " C:/NXP/S32DS.3.5_230912_devpck/S32DS/tools/S32Debugger/Deb ugger/scripts/s32g2xx/ s32g274a_i2c_RCON.py"      c. Source s32rcon.py in GDB. Example: source C:/NXP/S32DS.3.5_230912_devpck/S32DS/tools/S32Debugger/Deb ugger/scripts/gdb_extensions/rcon/s32rcon.py     d. Run command py rcon() in GDB. OBS:  Steps a, b can be done after c directly from GDB, using GDB py commands: Examples:  py _GDB_SERVER_PORT=45000  py _RCON_SCRIPT="C:/NXP/S32DS.3.5_230912_devpck/S32DS/tools/S32Debugger/Debu gger/scripts/s32g2xx/ s32g274a_i2c_RCON.py"   User can now use the available commands, like rcon_help, rcon_read, rcon_write to interact with the EEPROM.   User can write [command] -h for more information and mandatory parameters of the command.   User can write ‘quit’ to exit the S32 RCON services.
View full article
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. The images shown throughout this document are of the S32R45 device implementation and are provided for illustration purposes. Preparation Setup the software tools Install S32 Design Studio for S32 Platform  Install the Development Package for the device you are debugging. This package is important as it contains the S32 Debugger support component           Setup the hardware Confirm the setup of the evaluation board.  i     Connect the power supply cable Setup the S32 Debug Probe. Refer to the S32 Debug Probe User Manual for installation instructions. i      Connect the S32 Debug Probe to the evaluation board via JTAG cable.  ii     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 Secure Keys Registry must be used. From the S32DS menu bar, select Window -> Show View -> Other -> ‘Secure Keys Registry’.   The Secure Keys Registry will now appear in the current perspective.   Since there is no current key stored in the Secure Keys local storage, a new key must be registered. Click on ‘Register Key’. This will bring up the Secure Keys Registry command dialog.   Now enter the ADKP value (Application Debug Key/Password) which is correct for the SoC to be debugged.                  The Secure Keys Registry 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 load the UID (Device Unique ID) from the SoC. The UID is associated with the ADKP when it is registered within the Secure Keys 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.   Smart Card Authentication   When using a smart card, the user will need to authenticate with it. IDE has a mechanism to provide the user password for this purpose.    This mechanism is available from any S32 Debug Configuration, as well as Secure Key Registry views, and will be triggered anytime the IDE will call a command that requires authentication on the connected smart card (e.g.: registering a key, fetching the registered keys and trying to perform secure debug with challenge & response.)   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. Make sure you have selected the appropriate authentication scheme and provided the correct value for the security asset corresponding to that authentication scheme. E.g. For password - provide the correct password.   For challenge & response, have the correct debug key registered on the smart card.   Note: you may be required to power cycle the board before attempting to debug again after failing to authenticate properly.   Configuration Settings     SDAF (Secure Debug Authorization Framework) – the framework for which the Secure Keys Registry view serves as a graphical interface, is configurable in various aspects and the UI can be used to update the configuration. From the Secure Key Registry interface, click on Settings:   The configuration parameters that can be updated with this view are the following: Working mode: This configuration parameter is used for selecting the working mode regarding the smart card connection. There are two possible values for this:   Managed: volkano.dll (SDAF component) iterates through all the PC/SC readers locally connected to the PC where volkano is running and identifies if a smart card with the volkano applet installed is present. If such a smart card is identified, volkano will connect and interact with it accordingly.      Client: volkano will try to connect to another instance of volkano running in server mode (be it remotely or on the same PC where S32DS is running). Note: Due to the fact that all the commands sent by volkano to the smart card will go through the network via TCP, some latency is expected.       Host: Specifies the hostname/IP address of the PC on which a volkano instance is running in server mode.   Port: Determines the port of the remote volkano instance (running in server mode) that the client will try to connect to. Logging_Verbosity: This config parameter controls the level of detail in the program’s log output. The available verbosity levels are: ERROR: Provides messages that indicate exceptions that have occurred during the execution and data transmission errors. This is the default value of the config parameter.       INFO: Provides informational messages that contains details about the normal execution flow.   DEBUG: Provides detailed debugging information.   
View full article
The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via GTA command line and the GDB. This instruction details the steps to perform flash programming of the S32G274A EVB via the JTAG interface with the S32 Debug Probe.   Note: currently only QSPI flashing is supported.   Preparation Install S32 Design Studio IDE  Install the Development Package for the device you are debugging. In this case, the S32G2xx development package. This is important as the S32 Debugger support within it contains the device-specific Python scripts required for initialization of the cores.    Setup the hardware Confirm the setup of the S32G274A evaluation board.  Configure the JTAG. The S32G274A evaluation board supports both 10- and 20- pin JTAG connections. The default board configuration is set to 20-pin, change the position of the jumper J59 from 2-3(default)  to 1-2, if you are using the 10 Pin JTAG interface. Both are supported by the S32 Debugger and S32 Debug Probe. Connect the power supply cable Setup the S32 Debug Probe Connect the S32 Debug Probe to the evaluation board via JTAG cable. Refer to the S32 Debug Probe User Manual for installation instructions. Use the JTAG connection as was confirmed in the previous step. Connect the S32 Debug Probe to the host PC via USB OR via Ethernet (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 Create new or open existing 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 Launch GTA server. From command prompt or Windows File Explorer run the command:  {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this:   Ensure Environment Variable for Python is set. From command prompt, run the command:  set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages   Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window.   Configure the EVB's Boot Mode switches for Serial Boot. Issue the following commands, replacing the PROBE_IP address and FLASH_NAME, as appropriate: source {S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/gdb_extensions/flash/s32flash.py py _FLASH_TYPE = "qspi" py _PROBE_IP="10.81.64.66" py _JTAG_SPEED=20000 py _GDB_SERVER_PORT=45000 py _GDB_TIMEOUT=7200 py _REMOTE_TIMEOUT=30 py _RESET_DELAY=1 py _RESET_TYPE="default" py _INIT_SCRIPT="{S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/s32g2xx/s32g274a_generic_bareboard.py" py _FLASH_NAME="MX25UM51245G" py _IS_LOGGING_ENABLED=False py flash()   Note: Replace the {S32DS Install Path} in the commands above with the actual path to your installation of S32 Design Studio. Now flash commands may be used. fl_blankcheck -- blank check fl_close -- close command fl_current -- current device command fl_dump -- dump command fl_erase -- erase section of memory command, will erase whole sectors starting from 'offset' through 'size' contiguously, so to erase only one sector, ensure that the 'offset' address is within the desired sector and 'size' does not extend into the following sector fl_erase_all -- erase all memory command fl_info -- info command, shows list of registered devices fl_protect -- protect section of memory command fl_unprotect -- unprotect section of memory command fl_write -- write memory command, hex or binary are supported, options to erase first and verify after write fl_write_elf -- write elf file to memory command, options to erase first, verify after, and rearrange flash base Type 'help fl_<command>' to print the help info on the specified command Type 'help support' to print a list of the fl_ commands For example, you may wish to write a binary file: fl_write -e 0x0 C:\\Users\\<userid_folder>\\workspaceS32DS\\hello_world\\Debug_RAM\\hello_world_blob.bin Happy flashing with S32DS Flash Programmer!
View full article
  The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via the S32 Debugger. Note: currently only QSPI flashing is supported. Preparation Install S32 Design Studio IDE  Install the Development Package for the device you are debugging. In this case, the S32G2xx development package. This package is important as the S32 Debugger support component contains the device-specific Python scripts required for performing the flash programming operations.   Open the application project containing the application to be programmed to the flash memory device. Follow the steps in HOWTO: Generate S-Record/Intel HEX/Binary file , selecting the 'Raw Binary' option. Build the project, generating the binary executable. This will be our application binary input to the IVT Tool. The IVT Tool must be used to generate the BLOB image which can be programmed to flash memory device and loaded to the RAM by the BootROM. Follow the steps in HOWTO: Use IVT Tool To Create A BLOB Image S32G274A. The resulting BLOB image file is what can be flashed to the device.   Procedure Open Debug Configuration menu Select 'S32 Debugger Flash Programmer', then right-click and select New. Enter an name for the new configuration and click Add... to add the file to be flashed. Click Browse... to select the project from the workspace where the application binary is located Select the project and click OK By default, the ELF file is found. Click Search in project to select the binary file. Select the .bin file and click OK Now we must enter the base address. Typically, this could be 0, but you may have other requirements. Click OK. Just the memory required by the new image needs to be cleared, so only check the box 'Erase all flash memory' if truly needed. Now we are ready to configure the debugger connection settings. Click on the Debugger tab. Starting from the top and working our way down, click on Select device. Select the device and click OK The correct Initialization script will automatically be set. Set the Debug Probe Connection settings to match your setup. When done, click Apply To start the flashing, click Debug When complete, the Debug perspective will show at terminated thread.   Happy flashing with GDB!   Note, to debug this application since it will be subsequently started by the BootROM: use 's32gxx_attach.py' in the Initialization script field on the debugger tab of the Debug Configurations menu Make the following adjustments on the Startup tab within the Debug Configurations menu: Uncheck "Load image"  Check "Set program counter at:" and enter the value "Reset_Handler"  
View full article
The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the ability to access the flash programming and debugging of the S32 Debug Probe via GDB command line. This document provides only the necessary commands specific to launching a debug session on NXP devices. It does not cover general GDB command line operations, these are covered in detail in the GNU communities and other public websites which are not associated with NXP.   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 the S32 Debugger support component contains the device-specific Python scripts required for initialization of the cores. Setup the hardware Confirm the setup of the S32G274A evaluation board.  Configure the JTAG. The S32G274A evaluation board supports both 10- and 20- pin JTAG connections. The default board configuration is set to 20-pin, change the position of the jumper J59 from 2-3(default)  to 1-2, if you are using the 10 Pin JTAG interface. Both are supported by the S32 Debugger and S32 Debug Probe. Connect the power supply cable Setup the S32 Debug Probe Connect the S32 Debug Probe to the evaluation board via JTAG cable. Refer to the S32 Debug Probe User Manual for installation instructions. Use the JTAG connection as was confirmed in the previous step. Connect the S32 Debug Probe to the host PC via USB OR via Ethernet (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 Create new or open existing 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 As separate debug threads need to be started for each core to be debugged, and the method for launching a debug thread differs depending upon whether it is a primary core or secondary core and if the executable image will be loaded or if the executable is already running and the debugger just needs to be attached. These scenarios will be covered by the following 3 sections: Primary Core Load Image and Run: The application image will be loaded directly to memory by the debugger and then initialized and started. The primary core will launch any secondary cores used by the application. Secondary Cores: The primary core has launched a secondary core, it is now running and the debugger will connect through the attach method. Primary Core Image Already In Memory and Running: The primary core has already been initialized and launched by other means, such as via a Linux OS on the target, so the debugger will connect through the attach method without initializing or loading the image to memory.   Please proceed with the section which applies to the core for which you are starting a debug thread.   Primary Core Load Image and Run Prepare the initialization script for the core(s) to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_generic_bareboard_all_cores.py Uncomment the following lines: #_JTAG_SPEED = 16000 #_PROBE_IP = "10.112.101.91" #_GDB_SERVER_PORT = 45000 #_CORE_NAME = 'M7_0' #_RESET_TYPE = "default" #_RESET_DELAY = 1 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True This file is used by the S32 Debugger within the S32 Design Studio IDE where the settings are provided from the GUI, so these lines are commented out in order to allow the GUI settings to have control. The commented lines are provided so the script could more easily be run by the command line method. Update the IP address line (_PROBE_IP) to match the IP address of the S32 Debug Probe which is connected to your PC. See the user guide for the S32 Debug Probe for details on how to obtain the IP address.  Update the core name (_CORE_NAME), if necessary. See s32g2xx_context.py for complete list of supported cores. Save the file with a new name to preserve the original. For example, s32g2xx_gen_bb_all_c_my_probe.py. This ensures the S32 Debugger will still function correctly.   Launch GTA server. From command prompt or Windows File Explorer run the command: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe  Should see a window appear like this:   Ensure Environment Variable for Python is set. From command prompt, run the command:  set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages   Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window:   From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_gen_bb_all_c_my_probe.py This specifies the script for initialization. py board_init() This initializes the board. It should only be called for the initial core. In a multicore debugging workflow, the debugger launch for additional cores would omit this step. py core_init() This initializes the core specified in the initialization script in step 1.   Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\New_S32G_Project\\New_S32G_Project_M7_0\\Debug_RAM\\New_S32G_Project_M7_0.elf load   Secondary Cores After completing the launch of debug for the primary core, it is possible to perform multicore debug by launching GDB debugging on the secondary cores. Some additional steps will need to be performed from within the primary core GDB session, enter the following commands: set *0x34100000 = 0x34200000  set *0x34100004 = 0x34100025 set *0x34100024 = 0xFFFEF7FF set *0x34200000 = 0x34300000 set *0x34200004 = 0x34200025 set *0x34200024 = 0xFFFEF7FF b main c   These lines prepare the environment for launching debugging on secondary cores. This will allow for multicore debugging in the case of separate ELF files for each core. These can be found in the Run Commands field of the Startup tab on the Debug Configuration for the primary core within S32 Design Studio IDE, of any multicore project created from the New Application Project Wizard. Note: If there is just one ELF file for all cores, then these 'set *0x... = 0x...' commands should be skipped. In general, it will be correct to set the break-point at main, as shown, but this might need to be changed depending on when the secondary cores are started within the project. Prepare the initialization script for the secondary core to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_attach.py This is a different script than the one used for the primary core. It is designed to launch a debug session on a core which is already initialized and running. Edit the script for the secondary core to be debugged. Since this script is setup for the primary core, some adjustments need to be made to setup for a secondary core Uncomment the following lines: #_JTAG_SPEED = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" Make the following changes to the lines: _JTAG_SPEED = 14000 ->  None _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> None _CORE_NAME = 'M7' -> 'M7_1' (this should be set to match the name of the core to be debugged, see s32g2xx_context.py for complete list) _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" Save the file with a new name to preserve the original. For example, s32g2xx_attach_my_probe_core1.py. This ensures the S32 Debugger will still function correctly. The existing GTA server is used, so do not launch a new one. Open an new command window and follow similar steps as done for the primary core. Setup the Python environment variable, if not done globally set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window:   From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_attach_my_probe_core1.py This specifies the script for initialization. We will not execute the py board_init() as this was already done for the primary core. py core_init() This initializes the core specified in the initialization script in step 2.   Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\S32G_MultiCore\\S32G_MultiCore_M7_1\\Debug_RAM\\S32G_MultiCore_M7_1.elf load   Repeat 3-6 for each additional core. Primary Core Image Already in Memory and Running The core is running and does not need to be initialized. Prepare the initialization script for the core to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx\s32g2xx_attach.py This is a different script than the one used for the primary core. It is designed to launch a debug session on a core which is already initialized and running. Edit the script for the secondary core to be debugged. Since this script is setup for the primary core, some adjustments need to be made to setup for a secondary core Uncomment the following lines: #_JTAG_SPEED = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" Make the following changes to the lines: _JTAG_SPEED = 14000 _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> (enter the IP address of your probe) _CORE_NAME = 'M7' -> 'M7_0' (this should be set to match the name of the core to be debugged, see s32g2xx_context.py for complete list) _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" Save the file with a new name to preserve the original. For example, s32g2xx_attach_my_probe_core0.py. This ensures the S32 Debugger will still function correctly.   Launch GTA server. From command prompt or Windows File Explorer run the command: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this:   Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages   Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window:   From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32g2xx\\s32g2xx_attach_my_probe_core0.py This specifies the script for debugger initialization. Do not execute the py board_init() as this will initialize the board, and reset the currently executing application, which is not desired for this case. py core_init() This initializes the debugger connection to the core specified in the initialization script in step 1.   Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\S32G_Multicore\\S32G_Multicore_M7_0\ \Debug_RAM\\S32G_Multicore_M7_0.elf load   After completing the launch of debug for the primary core, it is possible to perform multicore debug by launching GDB debugging on the secondary cores. See section ‘Secondary Cores’ for each additional core to be debugged.
View full article
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.  
View full article
The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via the S32 Debugger.   Note: currently only QSPI flashing is supported. Preparation Install S32 Design Studio IDE Install the Development Package for the device you are debugging. In this case, the S32R41 development package. This package is important as the S32 Debugger support component contains the device-specific Python scripts required for initialization of the cores. Open the application project from which the flash image will be generated. Follow the steps in HOWTO: Generate S-Record/Intel HEX/Binary file, selecting the 'Raw Binary' option. Build the project, generating the binary executable. This will be our application binary input to the IVT Tool. The IVT Tool must be used to generate the BLOB image which can be programmed to flash memory device and loaded to the RAM by the BootROM. Follow the steps in HOWTO: Use IVT Tool To Create A BLOB Image S32R41. The resulting BLOB image file is what can be flashed to the device. Procedure Open Debug Configuration menu Select 'S32 Debugger Flash Programmer', then right-click and select New. Enter an name for the new configuration and click Add... to add the file to be flashed. Click Browse... to select the project from the workspace where the application binary is located Select the project and click OK By default, the ELF file is found. Click Search in project to select the binary file. Select the .bin file and click OK Now we must enter the base address. Typically, this could be 0, but you may have other requirements. Click OK. Now we are ready to configure the debugger connection settings. Click on the Debugger tab. Starting from the top and working our way down, click on Select device. Select the device and click OK The correct Initialization script will automatically be set. Set the Debug Probe Connection settings to match your setup. When done, click Apply To start the flashing, click Debug Flashing progress will be displayed. When complete, the Debug perspective will show at terminated thread. Happy flashing with GDB! Note, to debug this application since it will be subsequently started by the BootROM: use 's32r41_attach.py' in the Initialization script field on the debugger tab of the Debug Configurations menu Make the following adjustments on the Startup tab within the Debug Configurations menu: Uncheck "Load image" Check “Set program counter at:” and enter the value “Reset_Handler”
View full article
The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via GTA command line and the GDB. This instruction details the steps to perform flash programming of the S32R41 EVB via the JTAG interface with the S32 Debug Probe.   Note: currently only QSPI flashing is supported.   Preparation Setup the software tools Install S32 Design Studio IDE Install the Development Package for the device you are debugging. In this case, the S32R41 development package. This is important as the S32 Debugger support within it contains the device-specific Python scripts required for initialization of the cores. Setup the hardware Confirm the setup of the S32R41 evaluation board. Connect the power supply cable Setup the S32 Debug Probe Connect the S32 Debug Probe to the evaluation board via JTAG cable. Refer to the S32 Debug Probe User Manual for installation instructions. Connect the S32 Debug Probe to the host PC via USB, or Ethernet (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 Create new or open existing 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 Launch GTA server. From command prompt or Windows File Explorer run the command:{S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this: Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: Configure the EVB's Boot Mode switches for Serial Boot. Issue the following commands, replacing the PROBE_IP address and FLASH_NAME, as appropriate: source {S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/gdb_extensions/flash/s32flash.py py _FLASH_TYPE = "qspi" py _PROBE_IP="10.81.64.66" py _JTAG_SPEED=20000 py _GDB_SERVER_PORT=45000 py _GDB_TIMEOUT=7200 py _REMOTE_TIMEOUT=30 py _RESET_DELAY=1 py _RESET_TYPE="default" py _INIT_SCRIPT="{S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/s32r41/s32r41_generic_bareboard.py" py _FLASH_NAME="W25Q64J" py _IS_LOGGING_ENABLED=False py flash() Note: Replace the {S32DS Install Path} in the commands above with the actual path to your installation of S32 Design Studio. Now flash commands may be used. fl_blankcheck -- blank check fl_close -- close command fl_current -- current device command fl_dump -- dump command fl_erase -- erase section of memory command, will erase whole sectors starting from 'offset' through 'size' contiguously, so to erase only one sector, ensure that the 'offset' address is within the desired sector and 'size' does not extend into the following sector fl_erase_all -- erase all memory command fl_info -- info command, shows list of registered devices fl_protect -- protect section of memory command fl_unprotect -- unprotect section of memory command fl_write -- write memory command, hex or binary are supported, options to erase first and verify after write fl_write_elf -- write elf file to memory command, options to erase first, verify after, and rearrange flash base Type 'help fl_<command>' to print the help info on the specified command Type 'help support' to print a list of the fl_ commands For example, you may wish to write a binary file: fl_write -e 0x0 C:\\Users\\<userid_folder>\\workspaceS32DS\\hello_world\\Debug_RAM\\hello_world_blob.bin Happy flashing with S32DS Flash Programmer!
View full article
The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via GTA command line and the GDB. This instruction details the steps to perform flash programming of the S32R45 EVB via the JTAG interface with the S32 Debug Probe.   Note: currently only QSPI flashing is supported.   Preparation Install S32 Design Studio IDE  Install the Development Package for the device you are debugging. In this case, the S32R4xx development package. This is important as the S32 Debugger support within it contains the device-specific Python scripts required for initialization of the cores.    Setup the hardware Confirm the setup of the S32R45 evaluation board.  Confirm the JTAG connection. The S32R45 evaluation board supports both 10- and 20- pin JTAG connections. Both are supported by the S32 Debugger and S32 Debug Probe. Connect the power supply cable Setup the S32 Debug Probe Connect the S32 Debug Probe to the evaluation board via JTAG cable. Refer to the S32 Debug Probe User Manual for installation instructions. Use the JTAG connection as was confirmed in the previous step. Connect the S32 Debug Probe to the host PC via USB OR via Ethernet (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 Create new or open existing 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 Launch GTA server. From command prompt or Windows File Explorer run the command:  {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this:   Ensure Environment Variable for Python is set. From command prompt, run the command:   set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages   Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window:     Configure the EVB's Boot Mode switches for Serial Boot. Issue the following commands, replacing the PROBE_IP address and FLASH_NAME, as appropriate: source {S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/gdb_extensions/flash/s32flash.py py _FLASH_TYPE = "qspi" py _PROBE_IP="10.81.64.66" py _JTAG_SPEED=20000 py _GDB_SERVER_PORT=45000 py _GDB_TIMEOUT=7200 py _REMOTE_TIMEOUT=30 py _RESET_DELAY=1 py _RESET_TYPE="default" py _INIT_SCRIPT="{S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/s32r45/s32r45_generic_bareboard.py" py _FLASH_NAME="MX25UW51245G" py _IS_LOGGING_ENABLED=False py flash() Note: Replace the {S32DS Install Path} in the commands above with the actual path to your installation of S32 Design Studio. Now flash commands may be used. fl_blankcheck -- blank check fl_close -- close command fl_current -- current device command fl_dump -- dump command fl_erase -- erase section of memory command, will erase whole sectors starting from 'offset' through 'size' contiguously, so to erase only one sector, ensure that the 'offset' address is within the desired sector and 'size' does not extend into the following sector fl_erase_all -- erase all memory command fl_info -- info command, shows list of registered devices fl_protect -- protect section of memory command fl_unprotect -- unprotect section of memory command fl_write -- write memory command, hex or binary are supported, options to erase first and verify after write fl_write_elf -- write elf file to memory command, options to erase first, verify after, and rearrange flash base Type 'help fl_<command>' to print the help info on the specified command Type 'help support' to print a list of the fl_ commands For example, you may wish to write a binary file: fl_write -e 0x0 C:\\Users\\<userid_folder>\\workspaceS32DS\\hello_world\\Debug_RAM\\hello_world_blob.bin Happy flashing with S32DS Flash Programmer!
View full article
The S32 Design Studio for S32 Platform supports the S32R41 device with the S32 Debugger. This document provides the details on how to setup and begin a debugging session on the S32R41 EVB (X-S32R45-EVB). Preparation Setup the software tools Install S32 Design Studio IDE Use the Extensions and Updates menu within S32 Design Studio for S32 Platform to add the S32R41 Development Package. Setup the hardware Confirm the setup of the S32R41 evaluation board.        Connect the power supply cable Setup the S32 Debug Probe        Connect the S32 Debug Probe to the evaluation board via JTAG cable. Refer to the S32 Debug Probe User Manual for installation instructions.        Connect the S32 Debug Probe to the host PC via USB, or Ethernet (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 Create new or open existing 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 Open the Debug Configurations menu, then follow the steps depending on whether an S32 Debugger configuration exists for your project. If the project was created using the New Project Wizard in S32 Design Studio for S32 Platform, and the S32 Debugger was selected as the debugger, then it likely has existing debug configuration(s). S32 Debugger Configuration(s) Exist If existing S32 Debugger configuration, proceed with probe configuration. Otherwise, skip to the next section. Below is shown the debug configuration which appears for the provided RTD example project Port_ToggleLed_S32R41_M7'. The suffixes 'debug', 'ram', and 's32debugger' refer to how the project was built and the debugger the configuration is for. Select the debug configuration which corresponds to the project, build type debug, and primary core (if a multicore project) Select the Debugger tab Select the Interface (Ethernet/USB) by which the S32 Debug Probe is connected. If connected via USB and this option is selected for interface, then the COM port will be detected automatically (in the rare event where 2 or more S32 Debug Probes are connected via USB to the host PC, then it may be necessary to select which COM port is correct for the probe which is connected to the EVB) If connected via Ethernet, enter the IP address of the probe. See the S32 Debug Probe User Manual for ways to determine the IP address. Proceed to section ‘Start Debugger’ S32 Debugger Configuration(s) Do Not Exist There might be no existing debug configuration if the project is being ported from another IDE or was created to use another debugger. Select the S32 Debugger heading and click New Launch configuration (or double click on the S32 Debugger heading, or right click on the S32 Debugger heading and select New from the context menu) A new debug configuration appears with the name set to the name of the active project in the Project Explorer window(this can be set by opening a file from the project or selecting an already opened file from the project in the editor), and the build type which was used to build it. If this is not matching your intended project then it can either be modified to match or deleted and recreated after the active project has been changed to the desired project. Adjust the name of the project as desired. From the Main tab, check that the Project field is set to the correct project name, as listed in the Project Explorer, and that the C/C++ Application is set to the ELF file which was built. The name of the project can be customized, but '_' must be used instead of spaces. If the Project field is not set or incorrect, click Browse... and then select the correct project name from the list. If more than one project is open in the workspace, then each will be listed. This shows how, regardless of which project is active in the C/C++ perspective, any available workspace project could be associated. This can be useful when reusing a debug configuration from one project in another. If the C/C++ Application is not set or incorrect, click Search Project... and then select the correct binary file (will only work if Project field is correct and project was successfully built). Switch to the Debugger tab. Click 'Select device and core' and then select the correct core from the list. In the case of our example, the M7_0 core is correct. If this is not the primary core, then uncheck the box next to 'Initial core'. This is done only for multicore projects for the non-boot cores. This causes the scripts to skip the initialization of the core as the boot core will launch the other cores so additional initialization will not be required. Select the Interface (Ethernet/USB) by which the S32 Debug Probe is connected. If connected via USB and this option is selected for interface, then the COM port will be detected automatically (in the rare event where 2 or more S32 Debug Probes are connected to the host PC, then it may be necessary to select which COM port is correct for the probe which is connected to the EVB) If connected via Ethernet, enter the IP address of the probe. See the S32 Debug Probe User Manual for ways to determine the IP address. Click Apply, then proceed to next section ‘Start Debugger’. Start Debugger Click Debug. This will launch the S32 Debugger. When the debugger has been successfully started, the Debug perspective is opened and the application is executed until a breakpoint is reached on the first line in main().
View full article
The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the ability to access the flash programming and debugging of the S32 Debug Probe via GDB command line. This document provides only the necessary commands specific to launching a debug session on NXP devices. It does not cover general GDB command line operations, these are covered in detail in the GNU communities and other public websites which are not associated with NXP. 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 S32R41 development package. This package is important as the S32 Debugger support component contains the device-specific Python scripts required for initialization of the cores. Setup the hardware Confirm the setup of the S32R41 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 OR via Ethernet (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 Create new or open existing 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 As separate debug threads need to be started for each core to be debugged, and the method for launching a debug thread differs depending upon whether it is a primary core or secondary core and if the executable image will be loaded or if the executable is already running and the debugger just needs to be attached. These scenarios will be covered by the following 3 sections: Primary Core Load Image and Run: The application image will be loaded directly to memory by the debugger and then initialized and started. The primary core will launch any secondary cores used by the application. Secondary Cores: The primary core has launched a secondary core, it is now running and the debugger will connect through the attach method. Primary Core Image Already In Memory and Running: The primary core has already been initialized and launched by other means, such as via a Linux OS on the target, so the debugger will connect through the attach method without initializing or loading the image to memory. Please proceed with the section which applies to the core for which you are starting a debug thread. Primary Core Load Image and Run Prepare the initialization script for the core(s) to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32r41\s32r41_generic_bareboard_all_cores.py Uncomment the following lines: # _JTAG_SPEED = 16000 # _GDB_SERVER_PORT = 45000# _RESET_TYPE = "default" # _PROBE_IP = "s32dbg" # _CORE_NAME = 'M7_0' # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 110 # _IS_LOGGING_ENABLED = False # _SOC_NAME = "S32R41" This file is used by the S32 Debugger within the S32 Design Studio IDE where the settings are provided from the GUI, so these lines are commented out in order to allow the GUI settings to have control. The commented lines are provided so the script could more easily be run by the command line method. Update the IP address line (_PROBE_IP) to match the IP address of the S32 Debug Probe which is connected to your PC. See the user guide for the S32 Debug Probe for details on how to obtain the IP address. Update the core name (_CORE_NAME), if necessary. See s32r41_context.py for complete list of supported cores. Save the file with a new name to preserve the original. For example, s32r41_gen_bb_all_c_my_probe.py. This ensures the S32 Debugger will still function correctly. Launch GTA server. From command prompt or Windows File Explorer run the command: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this: Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32r41\\s32r41_gen_bb_all_c_my_probe.py This specifies the script for initialization. py board_init() This initializes the board. It should only be called for the initial core. In a multicore debugging workflow, the debugger launch for additional cores would omit this step. py core_init() This initializes the core specified in the initialization script in step 1. Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\New_S32R_Project_M7_0\\Debug_RAM\\New_S32R_Project_M7_0.elf load Secondary Cores After completing the launch of debug for the primary core, it is possible to perform multicore debug by launching GDB debugging on the secondary cores. Some additional steps will need to be performed from within the primary core GDB session, enter the following commands: set *0x34100000 = 0x34200000 set *0x34100004 = 0x34100025 set *0x34100024 = 0xFFFEF7FF b main c These lines prepare the environment for launching debugging on secondary cores. This will allow for multicore debugging in the case of separate ELF files for each core. These can be found in the Run Commands field of the Startup tab on the Debug Configuration for the primary core within S32 Design Studio IDE, of any multicore project created from the New Application Project Wizard. Note: If there is just one ELF file for all cores, then these 'set *0x... = 0x...' commands should be skipped. In general, it will be correct to set the break-point at main, as shown, but this might need to be changed depending on when the secondary cores are started within the project. Prepare the initialization script for the secondary core to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32r41\s32r41_attach.py This is a different script than the one used for the primary core. It is designed to launch a debug session on a core which is already initialized and running. Edit the script for the secondary core to be debugged. Since this script is setup for the primary core, some adjustments need to be made to setup for a secondary core Uncomment the following lines: # _JTAG_SPEED = 16000 # _GDB_SERVER_PORT = 45000 # _RESET_TYPE = "default" # _PROBE_IP = "s32dbg" # _CORE_NAME = 'M7_0' # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 110 # _IS_LOGGING_ENABLED = False # _SOC_NAME = "S32R41" Make the following changes to the lines: _JTAG_SPEED = 16000 ->  None _GDB_SERVER_PORT = 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg" -> None _CORE_NAME = 'M7_0' -> 'M7_1' (this should be set to match the name of the core to be debugged, see s32r41_context.py for complete list) _RESET_DELAY = 1 _REMOTE_TIMEOUT = 110 _IS_LOGGING_ENABLED = False -> ‘True’ _SOC_NAME = "S32R41" Save the file with a new name to preserve the original. For example, s32r41_attach_my_probe_core1.py. This ensures the S32 Debugger will still function correctly. The existing GTA server is used, so do not launch a new one. Open an new command window and follow similar steps as done for the primary core. Setup the Python environment variable, if not done globally set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: From (gdb) prompt, enter the following commands (in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32r41\\s32r41_attach_my_probe_core1.py This specifies the script for initialization. We will not execute the py board_init() as this was already done for the primary core. py core_init() This initializes the core specified in the initialization script in step 2. Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\S32R_Multicore\\S32R_Multicore_M7_1\ \Debug_RAM\\S32R_Multicore_M7_1.elf load Primary Core Image Already in Memory and Running The core is running and does not need to be initialized. Prepare the initialization script for the core to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32r41\s32r41_attach.py This is a different script than the one used for the primary core. It is designed to launch a debug session on a core which is already initialized and running. Edit the script for the secondary core to be debugged. Since this script is setup for the primary core, some adjustments need to be made to setup for a secondary core Uncomment the following lines: # _JTAG_SPEED = 16000 # _GDB_SERVER_PORT = 45000 # _RESET_TYPE = "default" # _PROBE_IP = "s32dbg" # _CORE_NAME = 'M7_0' # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 110 # _IS_LOGGING_ENABLED = False # _SOC_NAME = "S32R41" Make the following changes to the lines: _JTAG_SPEED = 16000 _GDB_SERVER_PORT = 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg" -> (enter the IP address of your probe) _CORE_NAME = 'M7_0' (this should be set to match the name of the core to be debugged, see s32r41_context.py for complete list) _RESET_DELAY = 1 _REMOTE_TIMEOUT = 110 _IS_LOGGING_ENABLED = False -> ‘True’ _SOC_NAME = "S32R41" Save the file with a new name to preserve the original. For example, s32r41_attach_my_probe_core0.py. This ensures the S32 Debugger will still function correctly. Launch GTA server. From command prompt or Windows File Explorer run the command: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this: Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32r41\\s32r41_attach_my_probe_core0.py This specifies the script for debugger initialization. Do not execute the py board_init() as this will initialize the board, and reset the currently executing application, which is not desired for this case. py core_init() This initializes the debugger connection to the core specified in the initialization script in step 1. Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\ New_S32R41_Project\\New_S32R41_Project_M7_0\\Debug_RAM\\New_S32R41_Project_M7_0.elf load After completing the launch of debug for the primary core, it is possible to perform multicore debug by launching GDB debugging on the secondary cores. See section ‘Secondary Cores’ for each additional core to be debugged.
View full article