Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture v1.2, Update 3            September 21, 2017   What is new? S32 SDK EAR 0.8.1 supporting MPC5748G & MPC5748C. The new project wizard now offers the new version of S32 SDK: "New S32 Project from Example" offers additional demos and examples. The complete S32 SDK EAR 0.8.1 release notes attached below. Installation instructions This is a cumulative installer - all previous updates (except previous version of S32 SDK EAR 0.8.0) are included so you do not need to install any previous update. The update is available for online (Eclipse Updater) or offline (direct download link) installation. online installation go to menu "Help" -> "Install New Software..." dialog  select predefined NXP S32 Design Studio update repository select all available items http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_POWER_1_2/com.freescale.s32power.updatesite click "Next" button offline installation  go to S32 Design Studio product page -> Downloads section or use the direct download linkand download the "S32 Design Studio for Power v1.2 - Update 3" file. Start S32DS and go to "Help" -> "Install New Software..." Add a new "Archive" repository and browse to select the downloaded Update 3 archive file Select all available items and click "Next" button.

After installation of S32 Flash Tool 2.1, try to start the GUI and get below error : We noticed this behavior on some PCs – either OS setup or security rules do not allow the installer to create a link to the JRE (Java 11) that is installed with Flash Tool. A quick fix is to set the path manually by adding the following lines to “S32FlashTool_2.1\GUI\ s32ft.ini”

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for ARM v2.0 Update 3          What is new? S32 SDK 0.8.6 EAR (Early Access Release)  for S32K142, S32K144, S32K146, S32K148)- see attached release notes for more details Installation instructions The update is available for online (via Eclipse Updater) or offline installation (direct download link) online installation:  go to menu "Help" -> "Install New Software..." dialog  select predefined update site "S32 Design Studio for ARM v2.0 - http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_ARM_2_0/com.freescale.s32arm.updatesite" select all available items and click "Next" button   offline installation:   go to S32 Design Studio for ARM product page -> Downloads section or use this direct link to download the update archive zip file Start S32DS and go to "Help" -> "Install New Software..." Add a new "Archive" repository and browse to select the downloaded update archive zip file you downloaded in the previous step Select all available items and click "Next" button. This will starts the update installation process.

Purpose   This document holds information about how S32 Design Studio and S32Debugger probe or PE Micro Debug probe can be used to debug applications running on NXP’s S32 family processors from the operating system perspective using FreeRTOS Kernel awareness.   Abbreviations Abbreviation Description RTOS Real Time Operating System RTD Real-Time Drivers   Background FreeRTOS is a market-leading open-source RTOS designed for microcontrollers and small microprocessors. It includes a kernel and a growing set of libraries. In S32 Design Studio, FreeRTOS Kernel awareness allows you to debug your application from the operating system perspective. Hardware Support FreeRTOS OS Awareness support in S32 Design Studio is available for: S32Z S32E S32G (Cortex-M7) -S32R45 (Cortex-M7) S32K1 S32K3 (K3xx and K396) S32M2 (S32M24x)   OS Support OSEK OS Awareness support is available only on Windows.     OS Information The FreeRTOS download includes source code for every processor port, and every demo application. Currently, FreeRTOS support is available only for single-core projects.   The core RTOS code is contained in three files, which are called tasks.c, queue.c and list.c. These three files are in the FreeRTOS/Source directory. The same directory contains two optional files called timers.c and croutine.c which implement software timer and co-routine functionality respectively. Each supported processor architecture requires a small amount of architecture specific RTOS code. This is the RTOS portable layer, and it is located in the FreeRTOS/Source/Portable/[compiler]/[architecture] sub directories, where [compiler] and [architecture] are the compiler used to create the port, and the architecture on which the port runs, respectively.    Document structure The basic workflow for setting up and managing FreeRTOS OS Awareness projects in S32 Design Studio remains consistent, irrespective of the debug probe used. The universal steps are described in “How to use FreeRTOS OS Awareness with S32 Design Studio and S32Debugger probe” section. For FreeRTOS OS Awareness projects utilizing PE Micro debug probe, only the specific considerations will be highlighted.   How to use FreeRTOS OS Awareness with S32 Design Studio and S32Debugger probe   Prerequisites Note: This HOWTo Guide describes the required steps for using FreeRTOS on a single-core example project for S32G399A Cortex-M7 in S32 Design Studio. Prerequisites might differ depending on the project hardware type.   Software environment S32 Design Studio project or example project delivered with FreeRTOS imported in S32 Design Studio Workspace S32G Development Package S32 RTD Autosar 4.4 Version 4.0.0 S32G3 RTD Autosar 4.4 Version 4.0.0 S32G FreeRTOS 10.4.6 version 4.0 Hardware environment Supported boards S32G-PROCEVB-S PCB RevX3 SCH RevB1 (Daughter Board) S32GRV-PLATEVB PCB RevA SCH RevB (Mother Board) S32G-VNP-RDB3 PCB 53060 RevC SCH RevF Connections PB_08 is controlling the LED. Debugger The debugger (S32 Debugger) must be connected to J64 20-pin JTAG Cortex Debug connector.     Project setup While in Design Studio, go to File -> New -> S32DS Project From Example  and select one of the existing single core S32 Design Studio Sample applications delivered with the NXP FreeRTOS or import your own S32 Design Studio project.       Select the desired project from the list of examples and click finish     Generating configuration Before running the example a configuration needs to be generated. First go to Project Explorer View in S32 Design Studio and right-click the current project.         Select the "S32 Configuration Tool" menu then click on the desired configuration tool (Pins, Clocks, Peripherals etc...).         Clicking on any one of those will generate all the components. Make the desired changes (if any) then click on the "S32 Configuration Tool → Update Code" button.     Building the project Select the project in the S32 Design Studio Workspace and click on Build. Clicking this button will start the build using the preset build type.    Debug configuration Click on Debug Configurations     Setup the Debug Probe Connection for the project. 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. See ‘S32_Debug_Probe_User_Guide.pdf’ ({S32DS_installation_directory}/S32DS/tools/S32Debugger/Debugger/Docs/S32_Debug_Probe_User_Guid e.pdf) for more details on the setup of the S32 Debug Probe.      Selecting FreeRTOS OS Awareness and starting debug From the OS Awareness tab select “FreeRTOS” from the OS dropdown list and click Debug.      FreeRTOS views Navigate to go to Window -> Show View -> Other…  and select the FreeRTOS view       Using the Heap Usage, Queue List, Task List and Timer list views, Design Studio can display information about the tasks status on the target. Heap usage view     Queue List view Queues are the primary form of inter-task communications. They can be used to send messages between tasks, and between interrupts and tasks. In most cases they are used as thread safe FIFO (First In First Out) buffers with new data being sent to the back of the queue, although data can also be sent to the front.   Task List view A real time application that uses an RTOS can be structured as a set of independent tasks. Each task executes within its own context with no coincidental dependency on other tasks within the system or the RTOS scheduler itself       Timer List view A software timer (or just a 'timer') allows a function to be executed at a set time in the future. The function executed by the timer is called the timer's callback function. The time between a timer being started, and its callback function being executed, is called the timer's period. Put simply, the timer's callback function is executed when the timer's period expires. Note, a software timer must be explicitly created before it can be used. How to use FreeRTOS OS Awareness with S32 Design Studio and PE Micro Debug probe   Prerequisites Note: This HOWTo Guide describes the required steps for using FreeRTOS on a single-core example project for S32K396 Cortex-M7 in S32 Design Studio. Prerequisites might differ depending on the project hardware type.   Software environment S32 Design Studio project or example project delivered with the NXP FreeRTOS imported in S32 Design Studio Workspace S32 Design Studio 3.5.6 development package with support for S32K396 devices: SW32K39x_S32DS_3.5.6_D2309 S32K396 RTD AUTOSAR 4.4 Version 3.0.0 Code Drop 02 FreeRTOS for S32K396 version 0.8.0 Hardware environment •    Supported boards X-S32K396-BGA-DCConnections PB_08 is controlling the LED - PTH7 is controlling the LED_BLUE in X-S32K396-BGA-DC board - when HIGH LED is ON or when LOW LED is OFF •     Debugger The debugger (PE Micro Debugger) must be connected to J20 20-pin JTAG Cortex Debug connector   Project setup Go to File -> New -> S32DS Project From Example  Select the desired project from the list of examples delivered with PE Micro Debug probe support or import your own S32 Design Studio project and click finish   Generating configuration   Please refer to the steps described in the “Generating configuration” section from “How to use FreeRTOS OS Awareness with S32 Design Studio and S32Debugger probe”.   Building the project Select the project in the S32 Design Studio Workspace and click on Build. Clicking this button will start the build using the preset build type.    Debug configuration Click on Debug Configurations. Select the debug configuration associated with your current build configuration and click on the “PEmicro Debugger” tab. Verify proper interface and port and if the device is properly detected.     Selecting FreeRTOS OS Awareness and starting debug From the OS Awareness tab select “FreeRTOS” from the OS dropdown list and click Debug.      FreeRTOS views Navigate to go to Window -> Show View -> Other…  and select the FreeRTOS view Using the Heap Usage, Queue List, Task List and Timer list views, Design Studio can display information about the tasks status on the target.   Further details can be found in the “FreeRTOS views” section from “How to use FreeRTOS OS Awareness with S32 Design Studio and S32Debugger probe”         Revision history: Revision no. Revision date Description 01 Nov 2023 Created document about how to use FreeRTOS OS Awareness in S32 Design Studio with PE Micro and S32 Debug probes    

This short video demonstrates how you can get the RTD version 5.0.0 from your NXP User Account and then install it on top of S32 Design Studio 3.6.0 Afterwords, a simple IO example is shown to exercise the Headers and Source Code configuration & generation & build

In order to improve user experience with S32 Design Studio, in this article you can find some tips and tricks.   Use-Case #1: S32 Design Studio takes to much time to perform some of UI update operations Workaround: Manually update the Eclipse configuration parameters in the s32ds.ini file Use-Case #2: S32 Design Studio takes a lot of time to open waiting for updates checking to finish Solution: Update your environment to use at least Update12 or newer or disable the checking at startup Use-Case #3: Control of package dependencies between RTD and S32DS during install/update flow Solution: Transition to Package Manager as the main/single delivery solution for SW and Tools installation. The concept of “Bundles & Use Cases” guarantee interoperability and come with customer support.    

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio v3.3 Vision Extension Package for S32V234 1.2.0          What is new? Integrated VSDK 1.6.0   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  installation:  go to menu "Help" -> "S32DS Extensions and Updates" dialog  select from available items and click "Install/Update" button offline installation:   go to S32 Design Studio for S32 Platform product page -> Downloads section or use direct link to download the update archive zip file        Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Go to Preferences' link And add a new site "Add..." repository and browse to select the downloaded update archive zip file you downloaded in the previous step       Select the 'S32 Design Studio for Power Architecture Device Package' and 'Update with S32 SDK 3.0.2 for Power Architecture' packages and click "Install/Update" button.   This will start the update installation process.

Condition:  I am trying FreeRTOS using S32K118 EVB and run in DEBUG mode. When I set the break point in vTaskDelay and press Resume for the first time, there is a smooth stop at the break point. The second time I press Resume, the debugger should enter the same break point again, but there is no response. Then I press Suspend and can't press Resume again, at this point I can only leave. However, I am free to run this project with no problem, what's wrong? Analysis: This is due to an access of DDR memory region which is not initialized by default project settings. Solution: To resolve it, a macro initializing the DDR memory should be selected to run at the beginning of a debug session. A user should go to Advanced Options dialog and check "Enable initialization script". Our DDR init macros can be found at the following location within S32DS3.2 layout: eclipse\plugins\com.pemicro.debug.gdbjtag.pne_4.2.8.201909091700\win32\gdi\P&E\supportFiles_ARM\NXP\S32Vxxx\S32V234M100_DDR3_EVB29288.mac. Please note that the type of the macro might depend on the revision of the board and S32V23x device one is working with. I am also attaching a picture of debug configuration and Advanced Options dialog with all the settings in place.

Requirements: SD card with installed Linux image connected to EVB (https://community.nxp.com/docs/DOC-335023 ) Serial link connection between PC and EVB (HOWTO: Setup A Remote Linux Connection in S32DS for Vision )  EVB connected to network   Procedure: Turn on EVB and connect to EVB via serial link using putty or any other terminal (115200 baud, 8N1). Login as the root user. Edit network interfaces configuration file by command vi /etc/network/interfaces and modify (press INS key to switch vi editor to edit mode) the file by the way as shown on next screenshot. Set IP address from range of your PC machine network settings.      The vi /etc/network/interfaces string is cutoff, because the OS acts during typing. The OS-printed line. [    29.817839] random: nonblocking pool is initialized (it varies with each boot). is written automatically by the OS a few seconds after login.  These characters do not make a difference.  Just enter the string as instructed and press Enter.  You will see the screen as follows.   Save new settings by :w command (press ESC key to switch vi editor to command mode) and exit from vi by :q command.   Restart network by command /etc/init.d/networking restart         Check the IP address by command ifconfig and try ping to your PC machine.        Troubleshooting: If you can't ping to PC machine and IP address is the same as you requested - check IP address on PC side and cable connection. If the IP address on EVB is different than you requested - check if you commented out the dhcp configuration. You may also try to reboot EVB instead of restarting network only.

This instruction details the steps to create an image vector table, then subsequently generate a blob image which can be written to external flash on the S32R45 EVB. For this, the 'hello_world_s32r45' example project from the S32R45 SDK installed to S32 Design Studio IDE. This instruction shows the process for QSPI, however, SD, MMC, and eMMC are also supported.   The Image Vector Table (IVT) image is a set of pointers to other images which are required by the BootROM. It typically contains the following images, though not all are required to create a valid IVT image: DCD Self-Test DCD HSE Application Bootloader   The IVT Tool enables configuration and generation of the IVT image as specified in the BootROM reference manual.   Prerequisites Before using the IVT Tool, it will be useful to have already generated the binary image from your application project, it will be an input to the IVT. It may also be necessary to include a DCD image, for example, to initialize the SRAM. For application bootloader image, follow the steps in HOWTO: Generate S-Record/Intel HEX/Binary file, selecting 'Raw binary' option. For DCD image, follow the steps in HOWTO: Use DCD Tool To Create A Device Configuration Data Image .     Procedure With desired project open in project explorer (C/C++ perspective), switch to IVT perspective. Click on 'Open IVT'. In the Boot Configuration section, check that the correct Boot Target is selected. For the demonstration here, M7_0 is the correct selection. Check the 'Interface selection' section. If your intended boot device is SD, MMC or eMMC, then change the setting from QuadSPI Serial Flash. If your intended boot device is QuadSPI AND you do not have a QuadSPI parameter file to specify, then uncheck the box for 'Configure QuadSPI parameters'. QuadSPI parameters change some flash registers' settings away from the default setting and are generally required for larger memory sizes (for ex. applications over 1 MB in size, for some supported devices). From the Image Table section, depending on your configuration, turn off all unused images. For the demonstration here, the following will be changed to Reserved: Self-Test DCD, Self-Test DCD (backup), DCD (backup), Application bootloader (backup). The following images will remain enabled: DCD, Application bootloader. In DCD section of the Image Table, click 'Browse File' and select the DCD binary file. Ignore the red shading on the Start address and Size in bytes fields for now. Now the red shading should be resolved. This is appearing because when the DCD section was enabled, it added a block to the Memory Layout map. But the other blocks in the map are unchanged resulting in overlaps. To resolve this, click on the ‘Align’ button from within the Automatic Align section.. After the Memory Map has been aligned, a confirmation message will be displayed and the red shading will disappear. In Application bootloader section, again use  'Browse File' and select the application binary. When the application boot image is loaded, the tool processes the file to check if it contains the header for the application bootloader image. If the header is not found, it means that the file is only the raw code (the bin generated by S32 Design Studio) and it will be necessary to provide the values for RAM start & entry addresses (code length is automatically calculated), as noted with the expanded view and red shading. To set the RAM start pointer and entry pointer addresses, from to the C/C++ perspective: From Project Explorer on the C/C++ perspective, open the linker file (hello_world_s32r45\Project_Settings\Linker_Files\S32R45_common_ram.ld) and locate the RAM start address and enter it in both the RAM start pointer AND RAM entry pointer fields in the IVT Tool. Since the application binary file which was loaded is just a raw binary file, it is necessary to generate the full application bootloader image. The Export Image function takes the values entered for the RAM start & entry pointers and Code length, then generates the Application bootloader header. This header is added to the raw binary file producing a new image, the full application bootloader image file. Within the Application bootloader section, click 'Export Image' and enter a meaningful name for the image file. In addition to being a necessary source component of the IVT image, this file can more easily be shared or re-used to as an input to other IVT images. After the file has been generated, you will notice that the address settings section has collapsed. This is because it has replaced the file you originally selected with the newly generated one and the tool has recognized that the file contains the required header information. Click 'Export Blob Image' to generate the blob image file. This is what will be flashed to the target. Now that the Blob Image is generated, the 'Flash Image' button could be used to program the image to the target over serial connection, use the S32 Flash Tool, or over the JTAG connection using the Flash Programmer within the S32 Debugger (QSPI only).

The following article describes how to add FreeRTOS thread aware debugging to the Eclipse Debug view using SEGGER J-Link: Show FreeRTOS Threads in Eclipse Debug View with SEGGER J-Link and NXP S32 Design Studio | MCU on Eclipse  I hope this is useful, Erich

This short video discuss the main features introduced with the S32 Design Studio 3.6.0 A comparison between S32DS 3.5 and 3.6 in regards to the product architecture & release changes is shown, followed by a quick overview of the main features introduced that impact everyone using the new version of the toolset

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.   

Requirements: SD card with installed Linux image connected to EVB (HOWTO: Prepare A SD Card For Linux Boot Of S32V234-EVB Using BSP From VSDK ) Configured network connection between EVB and PC machine (HOWTO: S32V234 EVB Linux - Static IP address configuration ) S32DS for Vision Procedure: Build your Linux project. On main menu bar click Run->Debug configurations. Select C/C++ Remote Application in debug window main tab. Create new connection by clicking on New... button.  Select SSH connection type and fill connection details - IP address and user  name.    When done - click to apply and start debug session. Your elf file will be upload to SD card and executed by gdbserver on target machine. 

This document shows the step-by-step process to create a simple blinking LED application for the S32R41 device using the S32 RTD non-AUTOSAR drivers. For this example used for the S32R41 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R41 development package and the S32R41 RTD AUTOSAR 4.4. 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 Family S32R41, Select S32R418AB Cortex-M7 Click Next Now, uncheck the selection mark for other core, i.e. for Cortex-M7-1   And Click '…' button next to SDKs   Check box next to PlatformSDK_SAF85_S32R41_2022_08_S32R418AB _M7_0. (or whichever latest SDK for the S32R41 is installed). Click OK Click Finish. Wait for project generation wizard to complete, then expand the project within the Project Explorer view to show the 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 by double-click on the MEX file. The schematic for S32R41 EVB, checking for signal line for the user LED, channel 4 is connected to user LED signal, so we use channel 4 for signal line for user LED on the chip. So, we select the signal line for Dio channel Id 4 for the LED connected on the S32R41 EVB. From the Peripheral Signals tab left to the Pins tool perspective layout, locate Open the Siul2_0 from the peripheral signals tab. And from the drop down menu select “gpio,36 PC_04” option as per shown in the following image. We are using PC_04 for the GPIO usage, so we are routing SIUL2_0 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 PC_04 pin. Code Preview Go to Peripherals tool and add Siul2_Dio to enable LED blinking, it adjacent to the Blue LED on S32R41  EVB. Click on the Peripherals Tool icon from the Eclipse Perspective navigation bar. From the Components view, click on ‘Add a new configuration component…’ button from the Drivers category. This will bring up a list of all configuration components. Locate and then select the ‘Siul2_Dio’ component from the list and click OK. Do not worry about the warning message. It is only indicating that the driver is not 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 tool-chain project’ to ‘All’. The DIO driver provides services for reading and writing to/from DIO Channels. Also, select the Siul2_Port tab and uncheck the checkmark against ‘Siul2 IP Port Development Error Detect’ option as below. The Gpio_Dio driver requires no further configuration. Click Save to store all changes to the .MEX file. 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 not already open, in the project window click the ‘>’ next to the ‘src’ folder to show the contents, then double click ‘main.c’ file to open it. This is where the application code will be added. Before the pin can be controlled, it needs to be initialized using the configuration information that was generated from the S32 Configuration tools. Initialize all pins using the Port driver by adding the following line: Insert the following line into main, 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 for the LED turn and off. To turn the pin on and off with some delays in-between to cause the LED to blink. Make the delays long enough to be perceptible. Add line to initialize variable uint8 i = 0; Change the code within the provided for loop, and add the following lines: /* logic for blinking LED 10 times for (i=0; i<10; i++) {       Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 1U);       level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN);       TestDelay(2000000);       Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 0U);       level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN);       TestDelay(2000000); } return (0U); And add this line above the main() function to initialize the variable volatile uint8 level; 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 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.

1) Prepare the evaluation board hardware You can use the S32 Debug Probe to download code to target Connect S32 Debug Probe to S32V234 EVB using JTAG connector Connect S32 Debug Probe to PC via USB cable OR ethernet (if connected via ethernet, then USB power cable must also be connected) Connect the S32V234 EVB to PC via ethernet (typically via LAN) Connect power cable to evaluation board and switch on the power     2) Build the project using the A53 build option. 3) Start debug on A53 core. Project is now built, ELF file is read to be loaded to EVB for execution. 4) Before a debug session can be started, we must complete HOWTO: Setup A Remote Linux Connection in S32DS for Vision. 5) Select the debug drop-down menu and click Debug Configurations     6) Make sure the Debug_Remote_Linux debug configuration is selected and the connection setup in step 4 is selected (points to the IP address of your EVB). Click Debug     7) The first time you connect to a new IP address (i.e. the first time you debug after booting the board), you will receive a warning message, Click Yes and proceed.     The executable file is copied to Linux file system and gdbserver starts.   You may get an error message on the first try, this is normal. Just try it again and it will work. 😎 Once the Linux GDB has started on A53 core and the initial break point is reached in main(), it is almost ready for to start debug on ISP. Click Resume as the A53 must be running before we can attach the ISP debug thread. 9) Locate the ISP debug configuration from the Debug Configurations menu. You will see a debug configuration within the 'S32 Debugger' group (in our example, isp_sonyimx224_csi_dcu_ISP as shown below). This is the debug configuration we will use, however, it will require some setup.     10) You should notice the error message at the top of the window, just below the title and a red 'X' on the Debugger tab. Click on the Debugger tab to select it. We must setup the Debug Probe Connection before we can proceed. There are two options: Ethernet USB   If connecting the Probe via Ethernet, please refer to the Quick Start Guide or S32 Debug Probe User Guide provided with the S32 Debug Probe for instructions on how to connect it and determine the Hostname or IP address.     If connecting the Probe via USB, then the COM port will appear in the Port selection setting. If you have more than one S32 Debug Probe connected, you will need to determine which COM port is the correct one, otherwise, only the COM port for your S32 Debug Probe will appear.   11) This is already done for our example, but for your application, it may be necessary to setup the symbols for the ISP engine. Go to the Startup tab and:    a) Check the box for 'Load symbols'    b) Select the option for 'Use file', click Workspace... and locate the object file (.opius) for the ISP engine you wish to debug.   12) Click Apply then Debug. It may take a few moments for the APEX core debug to launch.   13) Wait for the ISP debug launch to complete. You may notice the A53 thread has terminated. This is normal and expected since the camera input cannot be suspended. When the launch completes, the context of the Debug window will switch to the ISP debug thread. 14) Enable Instruction Stepping mode and then step one time to load the object file which was setup in step 6. 15) The ISP debugging is now running and you can step through the ISP engine, look at registers, set a break point, etc. Note: only one hardware break point is supported for ISP.

While the S32V234-EVB2 comes shipped with an SD card preloaded with a Linux Board Support Package(BSP), it does not support the Vision Software Development Kit(VSDK). This you will have to load yourself. There are two methods for installing the S32V234 BSP for VSDK to your SD card: 1) Download the image file from your Software Account on nxp.com and write the file to the SD card, or 2) Create the image on the SD card from ubuntu installed on a PC or virtual machine Download the image file and write it to SD card This is the simplest method, but does not allow for much customization. It is an excellent choice for those users who do not have much experience with Linux or just need something quick to get up and running with S32 Design Studio, try out the application examples, etc. Procedure 1) Login to your account on NXP.COM (if you do not already have an account, then just register for one) 2) Go to Vision SDK Software  3) Accept the license agreement 4) Select the version of VSDK you wish to use 5) Check the box next to 'VisionSDK RTM x.x.x pre-built SD Card image based on Yocto rootfs' and click 'Download selected files'. This will download the .gz file to your PC. 6) Unpack the VisionSDK_S32V2_RTM_x_x_x_img_yocto.tar.gz archive file 7) Unpack the VisionSDK_S32V2_RTM_x_x_x_img_yocto.tar archive file 😎 Navigate to the '\build_content\v234_linux_build\s32v234evb' folder, then unpack the sdcard-evb.tar.bz2 file 9) Unpack the sdcard-evb.tar file 10) The resulting file is sdcard-evb.img. You can use an image writing tool (such as Win32 Disk Imager download | SourceForge.net) to write this image file to the SD card. You will need to use the SD card adapter to insert the microSD card into the SD card slot on your PC, if available. If you do not have an SD card slot on your PC, there are many SD card-to-USB adapters available on the market. 11) The SD card is now ready to inserted into the SD card slot on the S32V234-EVB2 SD card slot. Create the image on SD card from ubuntu This is a better choice for more advanced users who wish to customize the BSP. To prepare an SD card for a Linux boot, it is necessary to connect the SD card to a machine with Linux OS. If a Linux OS machine is not available, then a virtual machine installed to a Windows OS machine may be used. If you have access to a Linux OS machine, skip to step 4. Procedure 1) Download and install a virtual machine VMware Workstation Player Virtual Box 2) Download Ubuntu. This tutorial uses the Ubuntu version 14.04.5.  The image will be ubuntu-14.04.5-desktop-amd64.iso. 3) Launch VMware or Virtual Box and create a new virtual machine Use downloaded Ubuntu image when requested for installer disc image file Hit Next and select Linux as the guest operating system and select Ubuntu for the version. Hit Next and name your virtual machine and specify where you want to store it. Increase the disk size to 40 GB Hit Finish and install VMware Tools for Linux, if asked 4) Within C:\NXP\S32DS_Vision_v2.0\S32DS\s32v234_sdk\os extract 'build_content.tar.gz', then extract 'build_content.tar' and navigate to the 'v234_linux_build' folder 5) Start virtual machine May need to manually connect USB-mounted SD card reader Log in to virtual machine 6) In files, go to 'Home' directory and create a folder "VSDK" 7) Within VSDK folder, copy the files image, u-boot.s32, s32v234-evb.dtb, and rootfs.tar from the 'v234_linux_build' folder.  Note: The file s32v234-evb.dtb and u-boot.s32 will have names with XXXXX-suffix for the schematic number printed on the evaluation board (EVB) you are using. Be sure to use the files which correspond to your EVB. 😎 Load the card into the reader. If you are using a virtual machine, it is recommended to use a USB adapter instead of a built-in reader in the PC. 9) Within the virtual machine, launch the terminal program 10) Within the terminal program, enter command 'cat /proc/partitions' to view the names of the partitions and identify the names of the partitions on your SD card. Perhaps it is named 'sdb'. 11) Delete all existing partitions.    a) Enter command 'sudo fdisk /dev/sdb'.    b) Enter command 'd' and then the number of the partition to delete. Repeat as necessary until all partitions have been deleted 12) Create new partitions    a) Enter command 'n' for new    b) Enter 'p' (or just hit <enter>, as this is the default) for primary    c) Enter '1' (or just hit <enter>, as this is the default) for partition number 1.    d) Press <enter> to select the default value for the First sector    e) Enter '+255M' to set the size    f) Enter command 'n' again, for partition number 2, however, press <enter> to select the default value for the 'Last sector' 13) Set the partition type    a) Enter command 't' for type    b) Enter '1' for partition number 1    c) Enter 'c' for partition type FAT32    d) Enter command 't' again, for partition number 2, however, enter '83' for partition type LINUX If you get error 16: Device or resource busy, as shown above, use commands 'umount /dev/sdb1' and 'umount /dev/sdb2' to free the pre-existing partitions. Then try again and should be ok now 14) Write the new configuration, enter 'w' 15) Try to setup the filesystems. Enter 'sudo mkfs.vfat -n boot /dev/sdb1'. If you get the error '/dev/sdb1 contains a mounted filesystem', you will need to unmount the partition first. To save time, unmount both /dev/sdb1 and /dev/sdb2. Enter 'umount /dev/sdb1' and then 'umount /dev/sdb2' Now try 'sudo mkfs.vfat -n boot /dev/sdb1' again 16) It worked, so now enter 'sudo mkfs.ext3 -L rootfs /dev/sdb2'. It will take a minute or two for this to complete. Wait until you get the command prompt again. 17) Now it's time to load the BSP content from the VSDK. But first, change the directory to the one we created earlier for the BSP files. Enter 'cd /home/user/VSDK' or 'cd VSDK'. Enter the following commands: sudo dd if=u-boot.s32 of=/dev/sdb bs=512 seek=8 conv=fsync sudo cp Image /media/user/boot sudo cp s32v234-evb.dtb /media/user/boot 18) Now we need to extract the root filesystem, change the directory to its location 19) Enter command 'sudo tar -xvf /home/user/VSDK/rootfs.tar' 20) Once the files are extracted, enter command 'sync'   Now the SD card is ready to be used in the S32V234-EVB.

Hi,     Hope this will be helpful and useful for you. Cheers! Oliver

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 S32R45 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 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 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\s32r45\s32r45_generic_bareboard_all_cores.py Uncomment the following lines: # _JTAG_SPEED = 50 # _PROBE_IP = "10.81.18.242" # _GDB_SERVER_HOST = 'localhost' # _GDB_SERVER_PORT = 45000 # _CORE_NAME = 'A53_0' # _RESET_TYPE = "default" # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 100 # _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 s32r45_context.py for complete list of supported cores. Save the file with a new name to preserve the original. For example, s32r45_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\\s32r45\\s32r45_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 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\s32r45\s32r45_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 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 s32r45_context.py for complete list) _RESET_DELAY = 1 -> _REMOTE_TIMEOUT = 60 (add this line) _CMD_TIMEOUT = 7200 -> _IS_LOGGING_ENABLED = True (add this line) Save the file with a new name to preserve the original. For example, s32r45_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 {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) 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\\s32r45\\s32r45_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}\\S32R45_Multicore\\S32R45_Multicore_M7_1\\Debug_RAM\\S32R45_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\s32r45\s32r45_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 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 s32r45_context.py for complete list) _RESET_DELAY = 1 -> _REMOTE_TIMEOUT = 60 (add this line) _CMD_TIMEOUT = 7200 -> _IS_LOGGING_ENABLED = True (add this line) Save the file with a new name to preserve the original. For example, s32r45_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\\s32r45\\s32r45_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}\\S32R_Multicore\\S32R_Multicore_M7_0\\Debug_RAM\\S32R_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.