In this document, we show the steps to use the New Project Wizard to create a new application project for APEX2, ISP, or both.   1. Launch S32DS for Vision 2. Select File -> New -> S32DS Application Project 3. Enter a name for the project 4. Select the 'A53 APEX2/ISP Linux' processor option 5. Click Next 6. Select the APEX2/ISP options you need.       a. APEX2 programming - will add support to your project for an APEX2 application, you need this for any new APEX2 project       b. ISP programming - will add support to your project for an ISP application, you need this for any new ISP project       c. ISP visual modeling - will create a separate project for your ISP data flow diagram, you will not need this if you plan to use an existing graph diagram. This can also be created later. 7. Select the SDK(s) as appropriate for your setup. For example, 'VSDK_MODULE_WIN' for Windows OS or 'VSDK_MODULE_LINUX' for Linux OS, the one which corresponds to your OS is selected for you by default. 7. Click Finish 8. You now have a project or set of projects for development on the S32V234.

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”

Has this happened to you? You just launched S32DS for Vision and opened a visual graph but the blocks are collapsed onto one another. Probably looks something like this: There is an easy solution. Just click on the 'Arrange All' button and the graph will automatically expand to a manageable state. Here is the result:

This tutorial walks a user through the steps to create a new application for the S32V234 MCU using S32DS (with S32V2xx development package and Vision extension package for S32V2xx) and the built in ISP Visual Graph tool. The completed application will take an image from camera, processes it on ISP and put the processed image in DDR buffers. Once the image is in DDR buffer, host (A53 core running Linux) will direct the display control unit (DCU) to display it on screen. Prerequisites: Some knowledge of the S32V234 System on a Chip (SoC) Have an understanding of the ISP architecture Be familiar with the NXP Vision SDK software Looking for Interactive Tutorial? You can view this tutorial as a video, go to Getting started with S32 Design Studio IDE including Vision Extension Package for S32V processors | NXP and select '3 | Create a new ISP Application'

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().

S32DS for Vision contains many example projects from which you can learn how S32DS, with the Vision Extension Package for V2xx, can be used with the help of the Vision SDK to develop vision applications. The example projects contain generated and hand-written code, which utilize the Vision SDK to demonstrate a workflow using S32DS. In this document, the procedure for creating a project from one of the provided ISP examples through to execution on the EVB is detailed. Prerequisite Before following the steps in this HOWTO, ensure you have the Vision Extension Package for V2xx (as well as the S32V2xx development package) installed to S32DS. 1) Launch S32DS 2) Select "New S32DS Project from example" 3) Select isp_sonyimx224_csi_dcu project and click Finish.    In this particular project, the ISP graph diagram is included. If you wish to view it, go to the Project Explorer panel and expand 'isp_sonyimx224_csi_dcu_graph'. Then double click on 'ISP data flow : mipi_simple'. The ISP graph diagram will appear in the editor panel. 5) We are ready to build the project, but first, select isp_sonyimx224_csi_dcu: A53 in the Project Explorer panel 6) Build project for A53  7) Start a debug session using method as described in HOWTO: Create S32V234 Cortex-A53 Linux Project in S32DS, beginning at step 10. 😎 Should get results similar to this:

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.    

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 either the A53 or the TEST_A53 build options. 3) The project is now built and the ELF file is ready to be loaded to the EVB for execution. Before a debug session can be started, we must complete HOWTO: Setup A Remote Linux Connection in S32DS (S32V234). Start A53 Debug 4) Select the debug drop-down menu and click Debug Configurations     5) 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     6) The first time you connect to a new IP address (i.e. the first time you debug after creating a new workspace), 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. 7) Once the Linux GDB has started on A53 core and the initial breakpoint is reached in main(), we need to set a breakpoint at the function apu_hal_Enable().    This breakpoint has already been created for you, you just need to enable it! Locate the breakpoint in the Breakpoints view. Due to some known issues with Eclipse CDT, it is necessary to enable->disable->enable the breakpoint so it will work properly. The issue only affects this breakpoint, due to the way it is provided, and will not affect breakpoints which you set elsewhere in the code. 😎 Press Resume twice, so that the breakpoint which was set at apu_hal_enable() is reached for the 2nd time. 9) Open Debug Configurations. You will see a debug configuration within the 'S32 Debugger' group (FAST9COLOR 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) Click Apply then Debug. It may take a few moments for the APEX core debug to launch.   12) It may take a moment or two before the APEX2 debug thread launch is complete, see the Thread listed within the <kernel_name>[S32 Debugger] in the Debug window. Also note, a new breakpoint is listed in the Breakpoints view. This breakpoint is set for you at the start of the APEX2 graph function. 13) The debugger context is still on the A53 thread. Press RESUME and then select the APEX2 thread to see that it has stopped on the graph function break point. Now you can step through the graph. 14) To step through a kernel, locate the call to the kernel function in the graph function and set a break point on the line. 15) Press RESUME to advance the program counter to the new break point 16) Press STEP INTO to advance the program counter into the kernel. It may take several steps as the optimizations performed by the compiler produce some synchronization inconsistencies. 17) You may need to help the IDE to locate the source files. Now you can see the kernel wrapper function... and the kernel! 18) Step through, monitor variables and registers and set breakpoints.

  In some cases FreeRTOS heap can consume huge portion of RAM memory - especially on small devices like S32K312 and for example DTCM memory is unused. FreeRTOS allows user defined heap which can be moved in any section in RAM.  First step - make sure, that in FreeRTOS config is application allocated heap is disabled:   Second step - open linker script file and create new section which points into DTCM memory:     Third step - define ucHeap variable with section attribute:     We are done - FreeRTOS Heap is moved into DTCM memory:    In case, that DTCM memory is used - typically there can be Interrupt Vector Table, stack and so on, you can skip creating new section in linker script file and simply add *(my_head) at the end of existing section mapped into dtcm:    FreeRTOS heap will be placet at the end of used DTCM memory:     

There are a number of existing ISP Graph diagrams provided within the VSDK. It is possible to import them into S32DS and use them in a new C/C++ project. The steps to do this are detailed within this document. Prerequisite Before following the steps in this HOWTO, ensure you have the Vision Extension Package for V2xx (as well as the S32V2xx development package) installed to S32DS. 1) Launch S32DS 2) Select File -> New -> S32DS Application Project. 3) Enter a project name, such as: ISP_ISP_Generic_demo 4) Select 'A53 APEX/ISP Linux' 5) Click Next 6) Deselect the APEX2 options and 'ISP Visual Modeling' option. 7) Click Finish 😎 Select File -> New -> S32DS Project from Example. 9) Select isp_generic. 10) Select Finish 11) Open isp_generic in the project explorer 12) Double-click ISP data flow ; isp_generic. The ISP data flow graph will appear in the editor 13) Define a new configuration for emitting code from the graph       a) Right-click in the ISP data flow window and select Emit As -> Emit Configurations...       b) Select ISP Emitter       c) Press New Launch Configuration       d) Enter a name       e) To select the graph, press Browse Workspace       f) Expand each item until you can select the .isp file. Click OK       g) Select the location of the emitted output to the application project, select Browse Workspace       h) Select the name of your application project, then press OK       i) Enter 'A53_gen' to the Dynamic sequences sources folder box. This is the folder within the target project that generated code will be stored. Check the box for Emit host code.       j)Now select the location to store the configuration file. Go to the Common tab, select Shared file and click Browse       k) Select the .launches folder inside ISP_ISP_Generic_demo and click OK       l) Click Apply and Emit. Dialog box will appear when code generation is successful              m) Expand the folders within ISP_ISP_Generic_demo, A53_gen, src and inc, to see the newly generated output files 14) Build the project 'ISP_ISP_Generic_demo' for ISP 15) Open file 'ISP_ISP_Generic_demo/A53_inc/isp_user_define.h', by double clicking on it in the Project Explorer. Change '#define DCU_BPP DCU_BPP_YCbCr422' to '#define DCU_BPP DCU_BPP_24' and change '#define __DCU_BPP' to "#undef __DCU_BPP". Before After 16) Using the method detailed in steps 8 - 10, create the example project 'isp_sonyimx224_csi_dcu'. Take from this project the file 'isp_sonyimx224_csi_dcu/A53_src/main.cpp' and use it to replace the file 'ISP_ISP_Generic_demo/A53_src/main.cpp' in the current project. Then make the following modifications:  On line 36, change <#include "mipi_simple_c.h"> to <#include "isp_generic_c.h">. On line 303, change <gpGraph_mipi_simple> to <gpGraph> AND <gGraphMetadata_mipi_simple> to <gGraphMetadata> On line 330, change <FDMA_IX_FastDMA_Out_MIPI_SIMPLE> to <FDMA_IX_ISP_OUTPUT>. Please see C:\NXP\S32DS.3.1\S32DS\software\VSDK_S32V2_RTM_1_3_0\s32v234_sdk\docs\drivers\SDI_Software_User_Guide.pdf for details on what this code is for. 17) In Project Explorer, right-click on "...\A53_gen\src\isp_process.cpp" and select Build path -> Remove from -> A53 18) Select 'ISP_ISP_Generic_demo:A53' in the Project Explorer panel, then Build for A53 19) Run it remotely on the target using the method fromHOWTO: Create S32V234 Cortex-A53 Linux Project in S32DS . Should get results similar to this:

S32DS for Vision contains many example projects from which you can learn how S32DS, with the Vision Extension Package for V2xx, can be used with the help of the Vision SDK to develop vision applications. The example projects contain generated and hand-written code, which utilize the Vision SDK to demonstrate a workflow using S32DS. In this document, the procedure for creating a project from one of the provided APEX2 examples through to execution on the EVB is detailed. Prerequisite Before following the steps in this HOWTO, ensure you have the Vision Extension Package for V2xx (as well as the S32V2xx development package) installed to S32DS. 1) Launch S32DS 2) Select 'New S32DS Project from example' 3) Select apex2_fast9 project 4) Click Finish 5) Select apex2_fast9: A53 in the Project Explorer panel. Build the project using build config 'TEST_A53'. 6) Start a debug session using method as described in HOWTO: Create A53 Linux Project in S32DS for Vision, beginning at step 9. 7) Click Resume  Should see something similar to what is pictured below There are green diamonds at the corners in the image as identified by the fast9 corner detection algorithm

One of the many great features of the S32DS is the ability to access the Linux BSP file system on the SD card in the S32V234-EVB. Once connected, you can drag and drop files between your PC and the EVB. Once you have completed HOWTO: Setup S32V234 EVB2 for debugging with S32DS and Linux BSP  and HOWTO: Setup A Remote Linux Connection in S32DS (S32V234), you are ready to setup the Remote Systems view to connect to the Linux files system to view and access the file system. Prerequisite Before starting this procedure, make sure the BSP is loaded onto the SD Card, the SD Card is inserted into the SD Card Slot, the ethernet cable is connected to both the EVB and the network port, and the EVB is powered up. 1) Go to 'Window -> Show View -> Other' 2) Expand 'Remote Systems', then select "Remote Systems' and click OK 3) Click 'Define a connection to remote system' button OR right-click in the Remote Systems window and select 'New Connection...' from the list Right-click menu 4) Select 'SSH Only' 5) Enter the IP address noted from HOWTO: Setup A Remote Linux Connection in S32DS (S32V234) for Host name, enter a descriptive name for the connection (optional) and click Finish. 6) Right-click on the connection name in the Remote Systems window and select 'Connect' OR expand the folders under the connection name until the login window appears: Connection_name -> Sftp Files -> Root (window appears) 7) Enter "root" for User ID and since the BSP comes with ID root without a set password, leave the password field blank. 😎 Click OK 9) The Linux file system is now visible in the Remote Systems window. You can drag and drop files to and from here. Expand the folders to see the contents.

The Vision SDK root is contributed to the Design Studio as a dynamic path variable “S32DS_VSDK_DIR”. Several Design Studio services use this variable to access the resources inside the Vision SDK. By default, this variable points to “${eclipse_home}../S32DS/s32v234_sdk”, i.e. to the Vision SDK shipment bundled with Design Studio. Technically you can change this variable to point to another instance of Vision SDK using the following steps: 1. Go to the main menu "Window -> Preferences" 2. Filter the preference dialog with "sub" keyword or just navigate to "Run/Debug -> String Substitution node. 3. Edit Variable "S32DS_VSDK_DIR" to assign another value to be substituted as Vision SDK root 4. Press OK when changes are complete.

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

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    

Purpose This document holds information about how the Design Studio and S32Debugger probe can be used to debug Zephyr OS (Operating System) applications running on NXP’ S32 family processors.    Scope    This document is addressed to the software developer or tester (referred below as user) looking to debug or verify its software using the S32Debugger probe.    The document assumes the user has basic knowledge about Zephyr OS and he can rebuild the image with debug configuration.    The information about the building of the Zephyr application using NXP’s Zephyr distribution is not in the scope of this document. This is part of the user manual delivered with the Zephyr NXP release.    Hardware support    This support is available for Cortex-A53 and Cortex-R52 cores only.    It has been confirmed on S32R41, S32R45 and S32Z/E SoCs (System on Chip).    Software support    This feature is available starting with Design Studio 3.5.3.    It is confirmed with Zephyr OS versions 2.7.2 (S32R41), 3.2.0 (S32Z/E), 3.3.0 (S32R41).    Background    Zephyr is a lightweight RTOS (Real Time Operating System) that supplies support for multiple architectures (aarch64, arm, riscv, x86).    The thread awareness support stands for the capability of the debugger to supply low-level information about OS threads (referred below as standard support) or system-level OS information (referred below as extended support).      Standard support    Design Studio can supply low-level information about Zephyr threads:    Name    State    CPU registers - including FPU (Floating Point Unit)    Call stack    Priority    User options    Core number    Prerequisites    S32Debugger automatically detects the Zephyr OS image using the specific debug symbols.    The Zephyr application image should include the following configuration options:    CONFIG_DEBUG_THREAD_INFO    Mandatory    If this choice is not set, the debugger is not able to parse the kernel internal data.    In debug view, the user will see one thread only and no extra information about this.                                         Debug window    The Zephyr threads are listed in the Debug window when the CPU is stopped.      This is an example about how to follow thread entry can be read:      The Thread with index #15 and thread ID 868402064 (TCB (Thread Control Block) address in decimal format) is running on the CPU core 0 and it is in the Stopped state.    It has running priority 15, the user options 0x01 and its name is “idle 00”.    This is suspended in a breakpoint set in function arch_cpu_idle();    Thread states    The thread states names reported by debugger are accordingly with the output of the kernel function k_thread_state_str() excluding Stopped, that is the active Zephyr thread suspended by debugger.    Thread’s state values:    Stopped    Dummy    Pending    Prestart    Dead    Suspended    Aborting    Queued      CPU registers    The CPU registers of the thread selected in the Debug window can be read from the Registers window. This window is updated automatically when other thread is selected.    Known limitations    The warning message “ccs: Invalid parameter” is printed twice into the Design Studio IDE console (for S32Z/E only).    These can be ignored because the functionality is not affected.      Breakpoint per thread is not supported    Write thread registers is not supported (excluding the thread in state Stopped)    Performance may be affected by high number of Zephyr threads    FPU registers read support requires patch of Zephyr OS to save the offset in the table for ARM64 build. This is the snippet code that must be added in the initialization of _kernel_thread_info_offsets  into file thread_info.c😞    #elif defined(CONFIG_FPU) && defined(CONFIG_FPU_SHARING) && defined(CONFIG_ARM64)     [THREAD_INFO_OFFSET_T_PREEMPT_FLOAT] = offsetof(struct _thread_arch,                          saved_fp_context),        [THREAD_INFO_OFFSET_T_COOP_FLOAT] = THREAD_INFO_UNIMPLEMENTED,        Extended support    Design Studio can supply system-level information about Zephyr OS resources like:    Timer    Semaphore    Mutex    Stack    Message queue    Mailboxes    Pipes    Queues    Threads    This implementation is not CPU architecture specific like standard support.    Prerequisites    The Zephyr application image should include the following configuration options:      CONFIG_DEBUG_THREAD_INFO    Mandatory    If this choice is not set, the debugger is not able to parse kernel internal data and to supply information about resource owners or waiting lists.    CONFIG_TRACING    CONFIG_TRACING_OBJECT_TRACKING    CONFIG_TRACING_NONE    Mandatory    Enable the kernel object tracking. If this is not set, the debugger can show system information about Threads only. Note: This configuration is working on Zephyr version 3.0.0 or higher.    CONFIG_INIT_STACKS    Optional    Enable the fill of stack with a marker that can be used by debugger to report the peak stack usage.    This information might be useful for stack size tunning.    CONFIG_THREAD_STACK_INFO    Recommended    The debugger supplies information about the stack (address, size or usage).        GDB (GNU Debugger)    This support is available through extended GDB commands.    Command name    Description    thread-aware-list-supported-os    List the supported OS types and the detected OS    thread-aware-list-supported-objs    List the supported kernel objects by the detected or specified OS. This is based on types used by the current image only.    thread-aware-read-objs    Read the specified or all objects supported by current image.        These commands can be configured to supply the output in JSON (JavaScript Object Notation) or table format.    Use the help command to get more information about these thread awareness commands.      Figure 2 GDB - Get Thread, Mutex & Semaphore info    Common attributes    Most of the object's attributes are type specific with 2 exceptions:    Attribute name    Description    Format               S32Debugger Zephyr Thread Awareness                                                                       User Manual v1.3                                                                        address    Object data address                     integer                                 name    ELF Symbol name                          string                                    Thread attributes    Attribute name    Description    Format    user_options    User options    integer    state    Thread state – see Thread states    string    prio    Thread priority    integer    stack_addr        integer    stack_delta        integer    stack_size        integer    stack_usage_max    Largest stack usage    float    stack_usage    Current stack usage    float    MemSlab attributes    Attribute name    Description    Format    num_blocks        integer    block_size        integer    buffer        integer    free_list        integer    num_used        integer    locked    Locked by this thread (name)    string    waiting    Threads (name) waiting for this object    string list    Queue attributes    Attribute name    Description    Format    locked    Locked by this thread (name)    string      waiting    Threads (name) waiting for this object    string list    Pipe attributes    Attribute name    Description    Format    buffer        integer    size        integer    bytes_used        integer    read_index        integer    write_index        integer    flags        integer    locked    Locked by this thread (name)    string    waiting_tx    Threads (name) waiting for this object on write    string list    waiting_rx    Threads (name) waiting for this object on read    string list    MBox attributes    Attribute name    Description    Format    locked    Locked by this thread (name)    string    waiting_tx    Threads (name) waiting for this object on write    string list    waiting_rx    Threads (name) waiting for this object on read    string list    Attribute name    Description    Format    timeout        integer      period        integer    MsgQ Attribute name    Description    Format    attributes    Attribute name    Description    Format    msg_size        integer    max_msgs        integer    buffer_start        integer    buffer_end        integer    read_ptr        integer    write_ptr        integer    used_msgs        integer    flags        integer    locked    Locked by this thread (name)    string    waiting    Threads (name) waiting for this object    string list    Stack attributes    Attribute name    Description    Format    base        integer    next        integer    top        integer    flags        integer    locked    Locked by this thread (name)    string    waiting    Threads (name) waiting for this object on write    string list    Timer attributes    status        integer    waiting    Threads (name) waiting for this object on write    string list    Mutex attributes      owner    Own by this thread (name)    string    lock_count        integer    owner_orig_prio        integer    waiting    Threads (name) waiting for this object on write    string list    Semaphore attributes    Attribute name    Description    Format    limit        integer    count        integer    waiting    Threads (name) waiting for this object on write    string list        DS (Design Studio)    The DS version 3.5.3 or higher offers the possibility to display the Thread information only into a dedicated view.    The extended support is still available in DS by running the extended GDB commands directly from the Debugger Console window.            Figure 3 DS - Execute thread awareness GDB commands    Thread view    This window can be accessed from the menu RTOS/Zephyr RTOS/Threads.                  Figure 4 DS IDE - Thread view    Some information can be missing from the view depending on the build configuration used. For example, in the above figure, the Peak stack usage is not available because the CONFIG_INIT_STACKS is not set.    Note the Thread’s field names into DS IDE Thread view can be different than GDB Thread attributes.    Stack    The thread view holds more information about the stack.    The Stack usage stands for the current stack usage, and it is based on SP (Stack Pointer) register while the Peak stack usage stands for the maximum usage of the stack.    Known limitations    Performance may be affected by number of OS resources    Limited configurations tested       

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.

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.   

When you use the New Project Wizard within S32 Design Studio to create a project, starting a debugging session is easy since the wizard creates the debug configuration for you. In this document, the case for NXP devices supported by the GDB PEMicro Debugging Interface is detailed.    Prerequisites The project to be debugged should be loaded to the workspace and open                 Procedure Build the project. Select the build configuration. (optional) If you already know which build configuration is desired, you can preselect it. If not, one is already selected for you by default. It will be noted with a check mark. Typical options contain choices between RAM and FLASH memory builds and for each a choice between Debug and Release. For debugging purposes the Debug option should be selected.                 Click on Build. Clicking this button will start the build using the preset build type.     Or, select the build type from the pick list. This will start the build for the build type selected, regardless of which one is marked with a check mark.       Check there are no compiler errors.                     Configure the debug configuration to start a debug session. Click ‘Run’ pulldown menu. Select 'Debug Configurations…'     Select the debug configuration associated with your current build configuration.     Select whether to rebuild code each time debug session start is requested.   Click on Debugger tab.     Verify proper interface and port.     Click Debug      

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 OSEK Kernel awareness.   Abbreviations Abbreviation Description OSEK Open Systems and their Interfaces for Automotive Electronics is a standard developed in the automotive industry to define a common architecture for embedded Real-Time Operating Systems (RTOS). NXP RTOS NXP Real Time Operating System compliant with OSEK specification  ORTI OSEK Run Time Interface.  ORTI file is generated based on NXP RTOS configuration *.ort / *.orti OSEK system builder ORTI file extension MSI Microsoft Software Installer   Background OSEK Kernel awareness within S32 Design Studio allows you to debug your application from the operating system perspective. ORTI is a specification that enables OS awareness for external debuggers (e.g NXP S32 Debugger, Lauterbach T32, PEmicro's debug probe).  Most OSEK system builders are able to extract all necessary information of the OS component into a text file, called “ORTI file”. NXP RTOS generates an *.ort file based on the user configuration. Debuggers can load this ORTI file to add support for the operating system. S32Design Studio can load such an ORTI file and adds some special views that will allow the user to inspect the configured OS objects: Tasks, Alarms, Counters, Scheduletable.   Document structure The basic workflow for setting up and managing OSEK OS Awareness projects in S32 Design Studio remains consistent across both single-core and multi-core projects, irrespective of the debug probe used. The focus will be on the universal steps that are described in single-core projects case. For OSEK OS Awareness multi-core projects and for projects utilizing PE Micro debug probes, only the specific considerations will be highlighted.                 Hardware Support OSEK OS Awareness support in S32 Design Studio is available for: S32G27x, S32G39x S32E/Z  S32K396 S32R41 SAF85xx   OS Support OSEK OS Awareness support is available only on Windows.   How to use OSEK OS Awareness with S32 Design Studio and S32Debugger probe   Single core projects   Prerequisites Note: This HOWTo Guide describes the required steps for using OSEK Run Time Interface on a single-core example project for S32R418AA 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 RTOS imported in S32 Design Studio Workspace S32R41 Development Package S32R41 Real-Time Drivers Version 1.0.0 SW32R41 RTOS 4.7.0 version 0.9.0 BETA   !Note: For this example project, NXP RTOS SysGen requires Java Runtime Environment OpenJDK-JRE 11.0.11 installed on your computer. The OpenJDK-JRE can be downloaded from the following URL (please search with exact keyword "jre-11.0.11-x64 MSI" or “jdk-11.0.11-x64 MSI” for correct version): https://developers.redhat.com/products/openjdk/download Using the installer (MSI) is recommended because it creates the HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK registry entry. JAVA_HOME environment variable must be set to point to location of Java Runtime Environment. For example: JAVA_HOME=C:\Program Files\RedHat\java-11-openjdk-jre-11.0.11-1 (Please choose correct path for your machine). Error or unexpected behavior may occur if the version of Java is different than 11.0.11 when NXP RTOS SysGen is executed (steps that are described Chapter III – “Generating Configuration”). If Java version is not found in the HKEY_LOCAL_MACHINE (HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft) a warning is reported.    Hardware environment Silicon: - Chip P/S32R418AAU(K1)MUFT (rev 1.1) Board: - X-S32R41-EVB PCB 48194 RevD SCH RevD Debug Probe: S32 Debug Probe       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 RTOS 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 select the current project.   Right click and select the "S32 Configuration Tool" menu then click "Open Peripherals".  Click on the "Update Code" button.   Click on Select directory under "Generate" field to select the directory which contains example project (E.g.: D:\WorkspaceS32DS\RTOS_example_S32R418AA_SC1_M7) then click on Generate Configuration.  Click "Update Code" again.   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.      Loading the ORTI file and starting debug From the OS Awareness tab select “OSEK” from the OS dropdown list. Browse and select from local system or Workspace the required *.ort file Click the Debug button.     OS Details Browser view Navigate to go to Window -> Show View -> Other…  and select the OS Details Browser view     Using the OS Details Browser view, Design Studio can display information about the tasks status on the target.   Tasks tab In the “Tasks”  tab from the OS Details Browser view you can see information about the operating system (the number of tasks, current task states, system objects):   Implementation tab Switch to the “Implementation” tab to see more detailed information gathered from the .ort file:   OS – current state Tasks – priority, state and assigned stack Stacks – usage and attributes Other OS resources defined and declared through ORTI Detailed info about ORTI data object Customize data presentation (HEX format, re-arrange the table columns) Colored presentation of data: -   White fields are static Blue fields are non-static Yellow fields are fields that changed their values from the last time they were inspected/checked.   OS information: Tasks information:   Stacks information:   Multi-core projects Prerequisites Note: This HOWTo Guide describes the required steps for using OSEK Run Time Interface on a multi-core example project for S32Z270 Cortex-R52 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 RTOS imported in S32 Design Studio Workspace S32Z2/E2 Development Package S32Z/E Real Time Drivers Version 0.9.0 S32ZE RTOS R21-11 version 0.9.0   !Note: For this multi-core example project, NXP RTOS SysGen requires Java Runtime Environment OpenJDK-JRE 1.8 installed on your computer. The OpenJDK-JRE can be downloaded from the following URL (please search with exact keyword "jdk-8u372-x86 MSI" for correct version): https://developers.redhat.com/products/openjdk/download - Using the JDK 1.8 installer (MSI) is recommended. JAVA_HOME environment variable must be set to point to location of Java Runtime Environment. For example: JAVA_HOME= C:\Program Files (x86)\Java\java-1.8.0-openjdk-1.8.0.372-1 (Please choose correct path for your machine). Error or unexpected behavior may occur if the version of Java is different than 1.8 when NXP RTOS SysGen is executed (steps that are described in Chapter III – “Generating Configuration”).   Please notice that SysGen is not stable in JRE 1.8 64 bit. Using SG with JRE 1.8 32 bit is recommended.     Hardware environment:             Boards: S32Z27X-DC PCB 50588 RevA1 SCH RevB (DC2)             Silicon chip: P32Z270ADCK0MJFT P65C ATTJ2151A (E2). (21x21, 594 BGA) Debug Probe: S32 Debug Probe               Boards: S32Z270-DC PCB 50912 RevA SCH RevA (DC1)             Silicon chip: S32Z270ADCK0MJET (17x17, 400 BGA) Debug Probe: S32 Debug Probe   Project setup Go to File -> New -> S32DS Project From Example  and select one of the existing multi-core S32 Design Studio Sample applications delivered with the NXP RTOS or import your own S32 Design Studio project.      Generating configuration The steps for generating configuration must be performed for all projects: RTOS_example_S32Z270_SC1_multi_instance_R52_0_0, RTOS_example_S32Z270_SC1_multi_instance_R52_0_1, RTOS_example_S32Z270_SC1_multi_instance_R52_0_2, RTOS_example_S32Z270_SC1_multi_instance_R52_0_3.   Building the projects Before running, you must build all projects: RTOS_example_S32Z270_SC1_multi_instance_R52_0_0, RTOS_example_S32Z270_SC1_multi_instance_R52_0_1, RTOS_example_S32Z270_SC1_multi_instance_R52_0_2, RTOS_example_S32Z270_SC1_multi_instance_R52_0_3.     Debug configuration Click on Debug Configurations. Click the initial core under S32 Debugger in Debug configurations menu.  Setup the Debug Probe Connection.    Loading the ORTI file   Loading the ORTI file must be done for all the project configurations:  RTOS_example_S32Z270_SC1_multi_instance_R52_0_0 RTOS_example_S32Z270_SC1_multi_instance_R52_0_1 RTOS_example_S32Z270_SC1_multi_instance_R52_0_2 RTOS_example_S32Z270_SC1_multi_instance_R52_0_3   Starting debug on multi core project From the Debug Configuration menu, click on Launch Group for S32 Debugger. Check all the cores that you want to debug. Click the Debug button.   OS Details Browser view Compared with single core projects, when debugging multi core projects you can switch between the debugging sessions and information from all debugged cores   Tasks tab     Implementation tab The information displayed in Implementation tab is the same as in single-core projects case, but you can switch between the debugged cores       How to use OSEK OS Awareness with S32 Design Studio and PE Micro Debug probe Prerequisites Note: This HOWTo Guide describes the required steps for using OSEK Run Time Interface 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 RTOS imported in S32 Design Studio Workspace S32 Design Studio 3.5.6 development package with support for S32K396 devices S32K3 Real-Time Drivers Version 3.0.0 P01 SW32K396 RTOS version 0.9.0 BETA   !Note: check the note from S32 Debugger – multi-core projects and install requires Java Runtime Environment OpenJDK-JRE 1.8   Hardware environment: Board:             Mini-module: XS32K396-BGA-DC PCB 54614 RevX1 SCH RevA              Silicon: Chip P32K396EHMJBS OP40E QAD2222F  Debug Probe: PE Micro Debug Probe     Project setup 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 For this How To Guide, RTOS_example_S32K396_SC1_M7_0_0 was used   Generating configuration     Building the projects Select the project in the S32 Design Studio Workspace and click on Build.    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.   Loading the ORTI file and starting debug From the OS Awareness tab select “OSEK” from the OS dropdown list. Browse and select from local system or Workspace the required *.ort file Click the Debug button.   OS Details Browser view Go to Window -> Show View -> Other…  and select the OS Details Browser view   Tasks tab In the “Tasks”  tab from the OS Details Browser view you can see information about the operating system (the number of tasks, current task states, system objects):   Implementation tab  “Implementation” tab displays more detailed information gathered from the .ort file:   Revision history: Revision no. Revision date Description 01 Nov 2023 Created document about how to use OSEK OS Awareness in S32 Design Studio on single and multi core projects with PE Micro and S32 Debug probes