This simple example shows how to attach GPIO Interrupt handler to particular GPIO Pin. Example is for S32K148 EVB and uses SW4 connected to PTC 13 and Green LED connected to PTE 22. Pressing SW4 invoke interrupt and Interrupt handler toggles Green LED. 

The document describes the steps that need to be done in order to place and execute a library function from a custom memory section - typically RAM using GNU Build tools. The instructions are applicable to any GNU tool-chain. It is demonstrated on a New S32DS Project created in S32 Design Studio for ARM. Lets assume that we'd like to execute memcpy() function from the standard library (NewLib). 1) The first step is to exclude specific library object file(s) from the input section (using EXCLUDE_FILE) so they will not be linked into the standard .text* flash section.  The input section associated with EXCLUDE_FILE shall not interfere with the same input section used later in section list (e.g. with *(.text*) input section deleted from the list below). EXCLUDE_FILE in behaves the same was as *.(text*) rule - it only exclude selected file(s) but places all the remaining (non-excluded) input data. /* The program code and other data goes into internal flash */ .text : { . = ALIGN(4); *(.text) /* .text sections (code) */ /* Exclude file(s) from NewLib libc.a from .text.* section */ *(EXCLUDE_FILE (*libc.a:lib_a-memcpy-stub.o) .text*) *(.rodata) /* .rodata sections (constants, strings, etc.) */ *(.rodata*) /* .rodata* sections (constants, strings, etc.) */ *(.glue_7) /* glue arm to thumb code */ *(.glue_7t) /* glue thumb to arm code */ *(.eh_frame) KEEP (*(.init)) KEEP (*(.fini)) . = ALIGN(4); } > m_text‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 2) Now let's place the memcpy object into a code_ram section which is already defined in the project .ld file. This section is dedicated to a code that shall be executed from RAM (startup routine initializes this section). For more details see HOWTO: Run a routine from RAM in S32 Design Studio  . The following line places the code (.text* section) from the object file (lib_a-memcpy-stub.o) from the standard NewLib (libc.a)  *libc.a:lib_a-memcpy-stub.o (.text*)‍ into .code section: .code : AT(__CODE_ROM) { . = ALIGN(4); __CODE_RAM = .; __code_start__ = .; /* Create a global symbol at code start. */ __code_ram_start__ = .; *(.code_ram) /* Custom section for storing code in RAM */ *libc.a:lib_a-memcpy-stub.o (.text*) /* add memcpy from the NewLib library here*/ . = ALIGN(4); __code_end__ = .; /* Define a global symbol at code end. */ __code_ram_end__ = .; } > m_data‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ After building the project you can check the map file to confirm memcpy is indeed placed into .code section in RAM memory: .code 0x1fff881c 0x18 load address 0x00000d90 0x1fff881c . = ALIGN (0x4) 0x1fff881c __CODE_RAM = . 0x1fff881c __code_start__ = . 0x1fff881c __code_ram_start__ = . *(.code_ram) *libc.a:lib_a-memcpy-stub.o(.text*) .text.memcpy 0x1fff881c 0x16 C:/NXP/S32DS_ARM_v2018.R1/Cross_Tools/gcc-6.3-arm32-eabi/arm-none-eabi/newlib/lib/thumb/v7e-m\libc.a(lib_a-memcpy-stub.o) 0x1fff881c memcpy 0x1fff8834 . = ALIGN (0x4) *fill* 0x1fff8832 0x2 0x1fff8834 __code_end__ = . 0x1fff8834 __code_ram_end__ = . 0x00000da8 __CODE_END = (__CODE_ROM + (__code_end__ - __code_start__)) 0x00000da8 __CUSTOM_ROM = __CODE_END‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Note If you are placing a function into RAM always consider to add sub-functions called by that function (typically located in a different object file).

On reset, all module registers have default values. These settings are typically not ideal for achieving optimal system performance. Also, some peripherals must be configured before they can be used. DCD is the configuration information contained in the DCD image that BootROM uses to configure peripherals on the device. BootROM determines the location of the DCD table from the associated pointer in the IVT.   The main functionality of the DCD Tool is to generate the Device Configuration Data (DCD) image using the format and constraints as specified in the Boot ROM reference manual.   In the steps below, an example process for creating the DCD binary for initializing SRAM is shown. To initialize the SRAM, a logic '1' must be written to the INITREQ bit within the PRAMCR register of the SRAMC and SRAMC_1 peripherals.   Procedure With a project open in project explorer (C/C++ perspective), switch to DCD perspective. Click on the arrow next to the 'Open S32 Configuration' button and select 'Open DCD'. Check that correct project is selected  In DCD Commands panel, select Command Type 'Write', then click 'Set' Click 'Add Register', then set the following settings. Can start typing the names to filter the list for faster setting selection.   For Peripheral setting, select 'SRAMC'. You can search for it by typing the name. Register setting, select 'PRAMCR'. The list is short, so it is not necessary to type the name. In Bitfields, select 'INITREQ' Now click on the highlighted bit to set it. Again using 'New Command' box, repeat settings of steps 3 & 4, however, this time select Peripheral 'SRAMC_1'. If everything was done correctly, in the DCD Binary panel to the right, should appear as shown. If so, click 'Export'. The generated DCD file will be displayed. By default, C format is selected. Select Binary format and click OK. Select a location to save the file (such as the project folder in the workspace directory) and give it a meaningful name. Click Save. You are done! DCD image file is created in binary format and ready to be imported to IVT Tool.  

S32 Design Studio (S32DS) for ARM supports IAR Eclipse plug-in that enables users to build and debug a S32DS project with IAR toolchain for ARM. This document describes how to install this plugin and how to enable IAR in the new project wizard. Current version of S32DS for ARM 2018.R1 supports IAR compilers  v7.x and v8.x. After the IAR eclipse plugin installation is finished you should be able to create, build and debug a new S32DS project (including SDKs) using IAR compiler/debugger interface directly under S32DS Eclipse environment.   Installation instructions First of all make sure you have IAR Embedded Workbench installed with a valid license from IAR. Now let's proceed to eclipse plug-in installation.   1. Install IAR Plugin manager  go to menu "Help" -> "Install New Software" and  click on "Add..." button to add a new IAR repository located here: http://eclipse-update.iar.com/plugin-manager/1.0 Tick " I Accept the terms of the license agreement" and click "OK" to accept unsigned content software Finally you proceed to the installation. When the plugin is installed you will be asked to restart S32DS Anytime you create a new workspace you will be asked to enter path to IAR Embedded Workbench IDE   2. Configure IAR plugins in IAR Embedded Workbench plugin manager Run IAR plugin manager (Menu "Help" -> "IAR Embedded Workbench plugin manager...") Select the ARM version (8.x) and click "Install" button.  Select all the IAR components displayed and proceed to installation by clicking "Next" button.   3. New IAR project in the project wizard You can now create a new project in S32DS and select IAR toolchain for ARM instead of default GCC compiler. There should appear a new item it the Debugger selection - "IAR plugin Debugger". Please choose this option if you intend to debug using IAR supported probes (e.g. I-jet) IAR specific panels and settings are now displayed in the project properties for a new S32DS project with the IAR options enabled (see above). There is a new category "IAR C-SPY Application" in the debug configurations panel that contains all the debug configurations for projects with IAR debug plugin option selected. The Debugger perspective now offers several IAR specific Views and features. Enjoy building and debugging with IAR Eclipse plug-in in S32DS!

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture 2017.R1         The Automotive Microcontrollers and Processors’ Embedded Tools Team at NXP Semiconductors, is pleased to announce the release of the S32 Design Studio for Power Architecture version 2017.R1. It is the successor of S32 Design Studio for Power v1.2. - the versioning scheme has changed. Release content (What is new?) Eclipse Neon 4.6 Framework GNU Build Tools for e200 processors (support VLE and BookE ISA, based on gcc 4.9.4 [7.October 2017], binutils 2.28 and gdb 7.8.2) - see the complete GCC release notes Libraries included: newlib, newlib-nano and Freescale EWL2 P&E Multilink/Cyclone/OpenSDA (with P&E GDB Server) - updated (v1.7.2.201709281658) New Project wizard to create application and library projects for supported devices Peripherals Register and Special Purpose Registers View Fully integrated MPC5748G/MPC5746C SDK EAR v.0.8.1. For the details on the feature set of SDK please refer to SDK Release notes attached and Reference Manuals (Please note that SDK has Early Access Release status, which means that there could be some limitations and/or issues. Also note, the SDK is available for Windows host only). SDK management included: o FreeMASTER Serial Communication driver (v2.0 August 31th 2016) o Automotive Math and Motor Control Libraries(v1.1.9) Windriver Diab compiler support by new project wizard Lauterbach, iSystem, and PLS debuggers support by new project wizard (The plugins to support Diab, iSystem, Lauterbach are not included and have to be installed from the corresponding update site or installation. The current version of the GreenHills plugin is not compatible with Eclipse Neon version, so it should not be used with this release) Kernel Aware debugging for FreeRTOS, eCOS, OSEK Devices supported: S32R274 S32R372 MPC5775K, MPC5774K MPC5746R, MPC5745R, MPC5743R MPC5777M MPC5777C MPC5748G, MPC5747G, MPC5746G MPC5744B, MPC5745B, MPC5746B, MPC5744C, MPC5745C, MPC5746C MPC5744P, MPC5743P, MPC5742P, MPC5741P MPC5601P, MPC5602P, MPC5603P, MPC5604P MPC5644B, MPC5644C, MPC5645B, MPC5645C, MPC5646B, MPC5646C MPC5601D, MPC5602B, MPC5602C, MPC5602D, MPC5603B, MPC5603C, MPC5604B, MPC5604C, MPC5605B, MPC5606B, MPC5607B MPC5606S MPC5604E MPC5644A, MPC5642A MPC5643L MPC5676R MPC5632M, MPC5633M, MPC5634M MPC5674F MPC5673K, MPC5674K, MPC5675K Collateral Getting Started page Bug Fixes C preprocessor tool added for C++ projects configuration The makefile generation is updated to fix and issue with building a project on the Korean version of Windows - Code page switch command cannot be executed. The Rename Project functionality is improved to cover referenced projects and launch configurations Complete S32 Design Studio for Power Architecture 2017.R1 release notes are available here Installation Notes To download the installer please visit the S32DS for Power Architecture product page: downloads section. The installer requires the the NEW Activation ID to be entered during the installation. You should receive an email that includes your Activation ID after starting the installer downloading process: Technical Support S32 Design Studio issues are tracked through the S32DS Public NXP Community space: https://community.nxp.com/community/s32/s32ds    

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. 

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for ARM® 2018.R1  Update 7          What is new? S32K1xx SDK BETA 2.9.0 supporting S32K116, S32K118, S32K142, S32K144, S32K146, and S32K148.  Also included is AMMCLIB 1.1.13 for S32K11x and S32K14x. This is a cumulative update - it includes all the content of previous updates (Update 1, Update 2, Update 3, Update 4, Update 5, Update 6) Installation instructions The update is available for  (via Eclipse Updater) or offline installation (direct download link)  installation:  go to menu "Help" -> "Install New Software..." dialog  select predefined update site "S32DesignStudio - http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_ARM_2018.R1/updatesite" select all available items and click "Next" button   offline installation:   go to S32 Design Studio for ARM product page -> Downloads section or use 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.

S32DS ARM2.2 K144xx fPic Example description. Provided example demonstrate possibility of creation Position Independent Code using  standard  S32DS ARM 2.2 tools.  Example code blink RGB LED using svc interrupt handler. Output  picExample.bin should be loaded via restore gdb command only into existing K144 RAM area(0x1fff8000 – 20007000 for EVB board), then pc set to startup value.(see picExample_Debug_RAM_PNE_fpic  Debug configuration). Note: restore gdb command needs absolute path to *.bin file. Example is based on standard K144 application. Changes: -fPIC option should be set(Project->Properties->C/C++ Build ->Settings->Standard S32DS Compiler->Miscalenous->Position Independent Code). Create flash image checkbox should bes set.( Project->Properties->Cross Settings -> Create flash image). Flash Image output file format  should be set to Raw binary(Project->Properties->C/C++ Build ->Settings->Standard S32DS Create Flash Image ) Add -nostdlib linker option(Project->Properties->C/C++ Build ->Settings->Standard S32DS Linker->General ->No startup or default libs). Existing S was modified(stack pointer was corrected, bl instead of blx for function calls was used. Standard linker script was modified(see example) Interrupts vector table was moved to data area. Due to this vector addresses are corrected on startup by FixGot routine(see SystemInit()c) Common RAM area was declared starting from 0. __got_start and __got_end were declared in Global Offset Table   For an in-depth analysis and step-by-step guide on the topic of implementing position-independent code, please see the following blog at mcuoneclipse.com: Position-Independent Code With GCC for arm Cortex M 

S32 Platform Download and Install S32 Design Studio for S32 Platform v3.4    S32K1 Migrating S32K1 projects from S32DS for ARM and SDK 3.0.x to S32DS 3.4 and SDK 4.0.2 A demonstration of the use of the Migration wizard in S32 Design Studio 3.4 to migrate S32K1 projects from S32 Design Studio for Arm and S32 SDK 3.0.x to S32 Design Studio 3.4 and S32 SDK 4.0.2   S32G2 Getting Started: Pins Tool Getting Started: DCD Tool Getting Started: IVT Tool Getting Started: DDR Tool   S32R45 Install S32R45 Development Package Install S32R45 Radar Extension Package Creating And Building A Project on the S32R45 for A53, LAX and SPT Cores in S32 Design Studio   S32V2 Create From Example 1 | Create an ISP project from example  A demonstration of how to load an example ISP image processing application project featuring RGB, YUV, and GS8 image formats, in the S32 Design Studio. 2 | Create an APEX2 project from example  A demonstration of how to load an example ORB-based APEX2 image processing application project in the S32 Design Studio. Create New Project 3 | Create a new ISP application  A demonstration of how to create a new Debayer-based ISP image processing application project in the S32 Design Studio. 4 | Create a new APEX2 application  A demonstration of how to create a new APEX2 image processing application project featuring upscaling and downscaling in the S32 Design Studio. Debug 5 | ISP Debugging w/S32 Debug Probe   A demonstration of how to setup and debug an ISP application project using S32 Design Studio, S32 Debugger, and S32 Debug Probe. 6 | APEX2 debugging w/S32 Debug Probe  A demonstration of how to setup and debug an APEX2 application project using S32 Design Studio, S32 Debugger, and S32 Debug Probe. 7 | APEX2 debugging with Emulator  A demonstration of how to debug an emulated-APEX2 image processing application project in the S32 Design Studio. 8 | Debug a Linux A53 project  A demonstration of how to debug a Linux A53 application project in the S32 Design Studio for Vision version 2.0. The example shown also includes code for APEX, but currently GDB Remote Linux only supports debug of the A53 code.

This tutorial walks a user through the steps to create a new application for the S32V234 MCU using S32DS for Vision and the built in APEX2 Visual Graph tool. The completed application will take a PNG image, upscale and downscale it using APEX engines and return the processed images. Prerequisites: Some knowledge of the S32V234 System on a Chip (SoC) Have an understanding of the APEX architecture and APEX Core Framework (ACF) Refer to UG-10267-03-14-ACF_User_Guide.pdf to learn about ACF Path: s32ds_installation_directory\S32DS\s32v234_sdk\docs\apex\acf Be familiar with the NXP Vision SDK software Looking for Interactive Tutorial? You can view this tutorial as a video: S32 Design Studio: Getting Started – APEX2 Graph Tool Tutorial

The S32K3 RTD 2.0.0 lacks SIUL2 external interrupt function. Siul2_Icu is part of Icu(Input Capture Unit), the main function of the example should have been: use the Icu and Dio drivers to toggle a LED on a push button. But it doesn't. So this document will show the step-by-step process to add 'SIUL2 external interrupt' function in Siul2_Port_Ip_Example_S32K344 using the S32K3xx RTD LLD(Low Level Driver) and the S32 Configuration Tools. This example is for the S32K3X4EVB-Q257, connected to a PC through USB (OpenSDA) connection. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32K1xx development package and the S32K1 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools. Launch S32 Design Studio for S32 Platform Procedure 1. Import Siul2_Port_Ip_Example_S32K344 example File->New->S32DS Project from Example It can be seen that in the Icu (Input Capture Unit Driver) folder of S32K3 RTD 2.0.0, there are only interrupt routines implemented by the Emios module for the time being, and external interrupt routines for the EIRQ pin of the Siul2 module does not exist. Here we import the Siul2_Port_Ip_Example_S32K344 routine, and add the Siul2_Icu part on this basis.   2. Add push button and LED in Pins tool Add the pins for user buttons (SW4 PTB26 SIUL2 eirq13) according to the S32K3X4EVB-Q257.   3. Add IntCtrl_Ip component Go to Peripherals tool. Here we can see that the ‘Siul2_Dio’ and ‘Siul2_Port’ components are already added. From the Components view, click on ‘Add a new configuration component…’ button from the Drivers category. This will bring up a list of non-AUTOSAR components. Locate and then select the ‘IntCtrl_Ip’ component from the list and click OK. Option 1: Keep the default setting after add ‘IntCtrl_Ip’ component(Here we didn't change the settings of ‘IntCtrl_Ip’, nor use IntCtrl_Ip_Init and IntCtrl_Ip_ConfigIrqRouting API to enable interrupts and install handlers in IntCtrl_Ip).This routine only uses one interrupt, so we will call IntCtrl_Ip_InstallHandler and IntCtrl_Ip_EnableIrq those two APIs to install and enable the SIUL2 EIRQ13 IRQ separately. Option 2: User can enable many interrupts in the Interrupt Controller configuration(Note user can only add one interrupt controller configuration in the RTD); Meanwhile, it can set interrupt’s priority separately. The two APIs IntCtrl_Ip_Init and IntCtrl_Ip_ConfigIrqRouting can initialize these interrupts as a whole. The name of the Handler in the Generic Interrupt Settings tab needs to be the same as the name in peripheral_Ip_Irq.c of the corresponding peripheral. For example, this routine uses the PTB26 SIUL2 EIRQ13 external interrupt, which can be found in RTD/src/Siul2_Icu_Ip_Irq.c: ISR(SIUL2_EXT_IRQ_8_15_ISR) According to the "Table 35" of S32K3XXRM reference manual, we can see the SIUL2 EIRQ13(PTB26) external interrupt used in this routine belongs to SIUL_1_IRQn and the Handler name SIUL2_EXT_IRQ_8_15_ISR.   4. Add Siul2_Icu component Click on ‘Add a new configuration component…’ button from the Drivers category. Locate and then select the ‘Siul2_Icu’ component from the list and click OK. Step 5 select SIUL2_0_IRQ_CH_13 because this routine selects the onboard SW4 PTB26 SIUL2 EIRQ13 external interrupt (the onboard SW5 PTB19 pin has no EIRQ external interrupt function, so I did not added here). Step 6 set DIRER0[EIREn] to enable this external interrupt pin. Step 8 set the IFCPR[IFCP] filter clock prescaler. Step 10 input 13 for the Hardware channel due to we use SIUL2 EIRQ13. Step 11 set IFER0[IFEn] to enable the glitch filter for the external interrupt pin. Step 12 set IFMCRn[MAXCNT] to assign value to the external interrupt filter counter. Step 14 select the IcuSiu2Channel_0 channel configured in the IcuSiul2 tab above. Step 15 select the ICU_RISING_EDGE according to the SW4 button circuit (press to generate a rising edge). Step 16 Because the SIUL2 EIRQ external interrupt is used in this routine, ICU_MODE_SIGNAL_EDGE_DETECT mode must be selected. Step 17 add the corresponding callback function name. That is, it corresponds to the notification after the SIUL2 EIRQ external interrupt pin captures the rising edge (the interrupt flag does not need to be cleared here, the driver has already been implemented it).   5. Include the headers for the drivers used in the application #include "Siul2_Icu_Ip.h" #include "IntCtrl_Ip.h"   6. Add Siul2_Icu LLD APIs Siul2_Icu_Ip_Init is used to initialize all Siul2_Icu channels generated by the S32 Configuration Tools (this routine only configures the channel SW4 PTB26 SIUL2 EIRQ13). Siul2_Icu_Ip_EnableInterrupt enable Siul2 IRQ interrupt for the specified channels. Siul2_Icu_Ip_EnableNotification enable callback function of Siul2 IRQ interrupt for the specified channels. This routine uses the SW4 button to trigger the PTB26 SIUL2 EIRQ13 external interrupt callback function SW4_eirq13_PTB26_Callback to flip the PTB18 D33 red LED.   7. Add IntCtrl LLD APIs IntCtrl_Ip_InstallHandler installs the SIUL2_EXT_IRQ_8_15_ISR interrupt handler generated by the S32 Configuration Tools. IntCtrl_Ip_EnableIrq enables the corresponding interrupt. Why input SIUL_1_IRQn and SIUL2_EXT_IRQ_8_15_ISR has been explained at the end of "4. Adding the IntCtrl_Ip component" above. References - S32K3xx Pins and Clocks with RTD - Training - AN13435: SDK/MCAL to Real-Time Drivers - Integration Manual for S32K3 ICU Driver （RTD_ICU_IM.pdf） - User Manual for S32K3 ICU Driver （RTD_ICU_UM.pdf） - Integration Manual for S32K3 PLATFORM Driver (RTD_PLATFORM_IM.pdf) - User Manual for S32K3 PLATFORM Driver (RTD_PLATFORM_UM.pdf)

The Port_Ci_Port_Ip_Example in S32K1 RTD 1.0.1 lacks GPIO interrupt function. Port_Ci is part of Icu(Input Capture Unit), the main function of the example should have been: use the Icu and Dio drivers to toggle a LED on a push button. But it doesn't. So this document will show the step-by-step process to add 'GPIO interrupt' function in Port_Ci_Port_Ip_Example using the S32K1xx RTD and the S32 Configuration Tools. This example is for the S32K144EVB-Q100 EVB, connected to a PC through USB (OpenSDA) connection. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32K1xx development package and the S32K1 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools.   Launch S32 Design Studio for S32 Platform   Procedure 1. Import Port_Ci_Port_Ip_Example_S32K144 example File->New->S32DS Project from Example Although the main function mentions the example use the Icu and Dio drivers to toggle a LED on a push button, it actually just waits in a loop for a delay to blink the LED. Not sure why the implementation of GPIO interrupts(Port_Ci_Icu) is missing.   2. Add push button and LED in Pins tool Add the pins for user buttons (SW2 PTC12 and SW3 PTC13) and LEDRGB_RED (RGB_RED PTD15) according to the S32K144EVB schematic RB1.   3. Add IntCtrl_Ip component Go to Peripherals tool. Here we can see that the ‘Gpio_Dio’ and ‘Port’ components are already added. From the Components view, click on ‘Add a new configuration component…’ button from the Drivers category. This will bring up a list of non-AUTOSAR components. Locate and then select the ‘IntCtrl_Ip’ component from the list and click OK. Keep the default setting after add ‘IntCtrl_Ip’ component, we will call IntCtrl_Ip_InstallHandler and IntCtrl_Ip_EnableIrq those two APIs to install and enable the PORTC IRQ separately. (Here we didn't change the settings of ‘IntCtrl_Ip’, nor use IntCtrl_Ip_Init and IntCtrl_Ip_ConfigIrqRouting API to enable interrupts and install handlers in IntCtrl_Ip.)   4. Add Port_Ci_Icu component Locate and then select the ‘Port_Ci_Icu’ component from the list and click OK. Follow the steps below to configure it. Selecting PORT_2 for ICU Peripheral ISR Name and select IcuIsrEnable at step 6 actually refers to PORT C used in this example. In order to use the GPIO interrupts of the onboard SW2 (PTC12) and SW3 (PTC13) buttons, you need to add one more channel in step 9, and select Port CI Hardware Module and Hardware channel in steps 8 and 10. The button circuit has a pull-down resistor, and it will be pulled high after being pressed, so the rising edge trigger is selected. In step 14, add IcuSignalNotification for PTC12 and PTC13 respectively, that is, the notification after the corresponding GPIO pin input captures the rising edge (there is no need to clear the interrupt flag here, the RTD driver has already done it).   5. Include the headers for the drivers used in the application   6. Add Port_Ci_Icu drivers Port_Ci_Icu_Ip_Init initialize the rising edge of PTC12 and PTC13 set by the S32 Configuration Tools. Port_Ci_Icu_Ip_EnableNotification enable the Callback of PTC12 and PTC13 respectively, and we toggle the blue and red LEDs in the corresponding Callback.   7. Add IntCtrl drivers IntCtrl_Ip_InstallHandler installs the PORT_CI_ICU_IP_C_EXT_IRQ_ISR interrupt handler generated by the S32 Configuration Tools.

This document shows the step-by-step process to create a simple 'Blinking_LED' application using the S32K1xx RTD and the S32 Configuration Tools. This example is for the S32K144EVB-Q100 EVB, connected to a PC through USB (OpenSDA) connection. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32K1xx development package and the S32K1 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_AUTOSAR'. The name must be entered with no space characters. Expand Family S32K1xx, Select S32K144 Under Toolchain, select NXP GCC 9.2 Click Next Click '…' button next to SDKs Check box next to PlatformSDK_S32K1_2022_02_S32K144_M4F. 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. By default, the Pins tool is then presented. Since the AUTOSAR drivers will be used, click the switch to disable this tool from the Overview tab. Once the Pins tool is disabled, the Config Tools Overview menu appears. Select the Peripherals tool. After the Peripherals tool opens, look to the Components tab. By default, new projects are created with the osif and Port_Ip drivers. Leave the osif driver, but remove the Port_Ip driver.  This will be replaced by AUTOSAR version. Right-click on the Port_Ip box and select Remove. Add the AUTOSAR version of the Port driver. Click on the ‘+’ next to the MCAL box. This will bring up a list of AUTOSAR components. Locate then select ‘Port’ 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. There are a couple of other drivers needed. Click the ‘+’ next to MCAL again and this time select ‘Dio’. Once more, click the ‘+’ and select ‘Mcu’. Select the ‘Dio’ component. Now select the DioConfig tab. Under DioPort_0, change the Dio Port Id to 3. Click ‘+’ next to DioChannel to add a channel. Select the ‘Port’ component. Now select the PortConfigSet tabl. Under PortPin, change the setting for PortPin_0, PortPin Pcr from 0 to 96. Then change the setting PortPin Direction from PORT_PIN_IN to PORT_PIN_OUT. Change the setting PortPin Level Value from PORT_PIN_LEVEL_HIGH to PORT_PIN_LEVEL_LOW. Under UnTouchedPortPin, click ‘+’ and add the following 5 PortPin Pcr numbers: 4, 5, 10, 68, 69 Now select the PortGeneral tab, uncheck ‘Port Ci Port Ip Development Error Detect’. 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 anything else is done, initialize the mcu driver, the clock tree, and apply PLL as system clock. Insert the following line into main, after the comment 'Write your code here': Mcu_Init(&Mcu_Config_BOARD_InitPeripherals); Mcu_InitClock(McuClockSettingConfig_0); while ( MCU_PLL_LOCKED != Mcu_GetPllStatus() )     {         /* Busy wait until the System PLL is locked */     } Mcu_DistributePllClock(); Mcu_SetMode(McuModeSettingConf_0); 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: Port_Init(NULL_PTR); 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. Within the provided for loop, add the following lines: Dio_WriteChannel(DioConf_DioChannel_DioChannel_0, STD_HIGH); TestDelay(2000000); Dio_WriteChannel(DioConf_DioChannel_DioChannel_0, STD_LOW); TestDelay(2000000); Before the 'main' function, add a delay function as follows: voidTestDelay(uint32 delay); voidTestDelay(uint32 delay) {     staticvolatile 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 "Mcu.h" #include "Port.h" #include "Dio.h" Build 'Blinking_LED_RTD_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_AUTOSAR_Debug_FLASH'. 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. Confirm the EVB is connected to the PC via USB cable, then check the Debugger tab settings and ensure that 'OpenSDA Embedded Debug - USB Port' is selected for interface. Click Debug To see the LED blink, click ‘Resume'

The NXP device S32R45 has accelerators that can be programmed. The S32 Debugger included within the S32 Design Studio for S32 Platform IDE with the S32 Debug Probe provides the ability to debug these accelerators. The accelerator covered in this document: BBE32. Section map: Preparation Setup the software tools Setup the hardware Procedure Create A New Debug Configuration Simulator Physical Hardware Start A Debug Session Standalone Multi-Core Debugging BBE32 DSP Once Debug Session is Started Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R4xx development package, the Radar extension package for s32R4xx, and the BBE32 DSP Add-On Package for S32R45. Setup the hardware Confirm the setup of the S32R45 evaluation board. Connect the power supply cable Setup the S32 Debug Probe. Refer to the S32 Debug Probe User Manual for installation instructions. Connect the S32 Debug Probe to the evaluation board via JTAG cable. Connect the S32 Debug Probe to the host PC via USB cable OR via Ethernet cable (via LAN or directly connected and configured for static IP address) and power supply connected to USB port. Launch S32 Design Studio for S32 Platform Open existing project or create a new project and check that it successfully builds. If creating a new project, be sure the S32 Debugger is selected in the New Project Wizard. Procedure The procedure for starting a debug session and accessing the associated accelerator-specific registers is detailed here. The BBE32 DSP debugging requires some additional setup beyond the installation of the BBE32 DSP Add-On Package for S32R45. The BBE32 has a different license from the one for S32 Design Studio. This license must be located using the ‘LM_LICENSE_FILE’ environment variable, as instructed within the provided document "{S32DS Install DIR}\Release_Notes\BBE32_DSP_Release_Notes.pdf". Debugging the BBE32 DSP is performed on physical hardware. This is conducted through one of two methods: Standalone: the BBE32 DSP executable is loaded by a debugger over JTAG using a probe and only the BBE32 DSP core is executed and available for debugging. Multi-core: the BBE32 DSP executable is included within A53 executable, the A53 application loads the BBE32 DSP executable to the BBE32 DSP core and both A53 and BBE32 DSP core are available for debugging. The debug connection is made to the two cores through one of two methods: Baremetal/Bareboard: the debugger connects to both the A53 and BBE32 DSP cores using the probe over JTAG. Linux BSP: the debugger connects to the A53 core, which is running Linux BSP, using a remote Linux connection over Ethernet and then connects to the BBE32 DSP core using the debug probe over JTAG. Before a debug session can be started a debug configuration must exist. Create A New Debug Configuration If the New Project Wizard was used to create the project using the S32DS Application Project option, then there was an opportunity to select the desired debugger from within the wizard. If the desired debugger option was selected at this time, then the needed configuration already exists and will only require adjustments to the hardware connection settings. If the New Project Wizard was not used to create the project OR the currently desired debugger was not the one selected at the time of project creation, a new debug configuration must be created. With the existing project selected in Project Explorer, open the Debug Configurations Menu: Run -> Debug Configurations Having the existing project selected in the Project Explorer view will make the creation of a new launch configuration easier as many settings will be imported from the selected project. To select a project, click on it so it becomes highlighted. Next, select the debugger for which the new debug configuration will be created. To create the new configuration, either click on the ‘New launch configuration’ button from the toolbar at the top and to the left, or right-click on the ‘S32 Debugger’ and select ‘New Configuration’ from the menu. g configuration will contain the project’s name and the Project and C/C++ Application fields will be populated as well. The C/C++ Application field will only be populated if the build output executable exists. Confirm these values are correct before moving on. There is an error showing that the Device core ID is not specified on the Debugger tab. Switch to the Debugger tab and click on the button ‘Select device and core’. From the Select Target Device and Core window, expand the listing until all cores are listed. Notice that all supported cores on the S32R45 are listed. Select the desired BBE32 DSP core and click OK. Now that the device and core are selected, a generic initialization script associated with the BBE32 DSP is selected automatically, however, this may not be the correct one. If debugging Standalone, meaning only BBE32 DSP core will be debugged, then the automatic selection ‘s32r45_generic_bareboard_all_cores.py’ is correct. This script will initialize all of the cores so the BBE32 DSP can execute properly. If debugging Multicore, meaning both A53 and BBE32 DSP will be debugged, then the A53 and BBE32 DSP cores will already be initialized by the time the debugging on BBE32 DSP begins. So a different script that doesn't initialize all of the cores is needed. Click ‘Browse’ and navigate to ‘{install_dir}\S32DS.3.4\S32DS\tools\S32Debugger\Debugger\scripts\s32r45’ and select the script ‘s32r45_attach.py’. The attach script will allow to start debugging on a core that is already initialized. Refer to the document 'README.txt' located in the same folder as these script files for details on all of the provided scripts. Confirm the setting of the ‘Initial core’ checkbox. This box should be checked within the debug configuration that establishes the first connection to the target device via S32 Debug Probe. When this box is checked, the Debug Probe Connection interface and GDB Server settings become available. The probe connection only needs to be configured once and only one GDB Server needs to be running for each debug session. Therefore, this box should be checked for standalone BBE32 DSP debugging or for multicore debugging where A53 core is debugged via Remote Linux. If the A53 and BBE32 DSP cores are debugged bareboard (no Linux) via the S32 Debug Probe, then this box should be checked for the A53 debug configuration and should not be checked for the BBE32 DSP debug configuration. If the initial core box is checked, then setup the Debug Probe Connection. Select either USB or Ethernet, depending upon your hardware setup. If USB is selected, the COM port for the S32 Debug Probe will automatically be detected (unless not connected or more than one probe is connected). If Ethernet is selected, then enter either the hostname (fsl + last 6 digits of MAC address) or IP address. It is highly recommended to press the ‘Test connection’ button to confirm the hardware connection is correctly configured. See the included ‘S32_Debug_Probe_User_Guide.pdf’ for more details on the setup of the S32 Debug Probe. Check that the GDB Client section has the correct path to the BBE32 DSP GDB executable. It should point to the variable ‘S32DS_R45_GDB_XTENSA_PY_PATH’. Startup tab check the following settings Load image is checked for standalone debugging, NOT checked for multicore debugging. Basically, if it is loaded by A53 core (contained in A53 ELF file), then it does not need to be loaded. Load symbols is checked. The only time you would not check this box is if there is no project binary containing symbols available. Set breakpoint at main and Resume are checked for standalone debugging, NOT checked for multicore debugging. Now you are ready to start debugging. Start A Debug Session For convenience, the example project for S32 Design Studio from the RSDK, ‘RSDK_S32DS_template’, will be used to demonstrate standalone BBE32 DSP and multi-core A53/BBE32 DSP debugging. For instructions on loading this example project to your workspace, see ‘HOWTO: Create New Project from Example RSDK_S32DS_template from Radar SDK’. Standalone For the standalone bareboard debugging of only BBE32 DSP core using the RSDK_S32DS_template example, here are the steps which would be required. Click on the BBE32 project so it is highlighted, then build it to ensure it builds clean and that the executable exists. From the menu at the top, select Run -> Debug Configurations… Select the standalone debug configuration for BBE32 core. In the case of the RSDK_S32DS_template example project, only the multi-core debug configuration is supported. In this case, the standalone configuration will need to be created. Right click on the multi-core configuration and select Duplicate. This will create an identical configuration. Change the name as desired and then select the Debugger tab. Click Browse next to Initialization script and navigate to the directory ‘{install_dir}\S32DS.3.4\S32DS\tools\S32Debugger\Debugger\scripts\s32r45’. Select the script ‘s32r45_generic_bareboard_all_cores.py’. Adjust the Debug Probe Connection settings to match your HW setup. Use the Test connection button to confirm. Select the Startup tab. For standalone debugging the image file will not be loaded by the A53 core, so it must be loaded by the S32 Debugger. Check the boxes for Load image, Set breakpoint at: and Resume. Click Debug to start the debug session. All of the settings made will be applied and the debug session will be launched. The BBE32 will execute to the first line in main(). A53 / BBE32 DSP Multi-core For multi-core debugging, the A53 core is executing an application on the Linux BSP. The EVB should be setup to boot from a flash device which has been loaded with the S32R45 Linux BSP. Before beginning the debug sessions, be sure to load the driver dependencies (oal_driver, rsdk_spt_driver, and rsdk_lax_driver) as described in the RSDK User Manual, RSDK Offline Example section ‘Running the application’. Start A53 debug. From the menu at the top, select Run -> Debug Configurations… In the Debug Configurations menu, from the configuration list, expand the ‘C/C++ Remote Application’ group and select the ‘RSDK_S32DS_template_A53_Debug’ configuration. On the Main tab, create a new connection for using the IP address of the EVB. The IP address could be determined either by issuing a Linux command over the serial connection, such as ‘ifconfig’, by accessing the local network connected device list, or perhaps the EVB was setup with a static IP address and it is already known. Click New… in the Connection section. Select ‘SSH’ for connection type. Enter the IP address in Host: field, use ‘root’ in User: field, and leave password field empty. Click Debug to start debugging on the A53 core. The debugger will launch and execute until the first executable line in main(). See Debugger tab in Debug Configurations menu to adjust this setting. Once the A53 debug session is running, advance the program counter to a line after the desired DSP kernel is loaded to memory but before the DSP kernel is launched. In the example here, this would be in ‘spt_bbe32_proc.c’, line 355, where ‘ExampleLaunchSptKernel()’ function is called. This is best done by setting a breakpoint on the line and clicking Resume. After the breakpoint is reached, the BBE32 DSP debug session can be started. Return to the Debug Configurations menu, select the BBE32 DSP debug configuration ‘RSDK_S32DS_template_BBE32_attach’, confirm the Debug Probe Connection settings and click Debug. Wait for the BBE32 debug session to launch and stop in the code. Select the BBE32 debug thread to change the context of the Source, Disassembly, Registers and etc.views. Now you can step through the assembly code, access registers, etc. To see this source code, it may be necessary to locate the file from the RSDK installation folder.

In embedded systems development, attention to memory utilization is universal. In S32 Design Studio, this information can easily be provided at the end of a successful build by invoking a linker option. Right-click on the project name in the Project Explorer panel and select 'Properties' from the menu. Navigate to the C/C++ Build -> Settings ->Standard S32DS C Linker -> Miscellaneous menu. From the Other options section, click Add. In the 'Enter Value' pop-up menu, enter: -print-memory-usage Click OK, then Apply and Close. Now build the project and see the memory usage information displayed in the Console window.

Migrating an SDK project for S32K1xx devices between SDK v4.0.1 and v4.0.2 is not as simple as attach and detaching the SDKs. It is complicated by the fact that SDK v4.0.1 is supported by only S32DS v3.3 and SDK v4.0.2 is supported by only S32DS v3.4. So this means both SDKs will not be present at the same time in one version of S32DS. In addition, the method for attaching the SDKs changed between SDK v4.0.1 and v4.0.2. In v4.0.1, the SDKs were added to the S32DS project via a link. In v4.0.2, the SDK files are added to the S32DS project by copying the actual files into the project. To overcome this, it is necessary to perform some manual operations. The steps required are detailed in this document, along with the necessary steps to adapt the .mex file containing the S32 Configuration Tools settings. Due to differences in projects based on the method of creation, there are 3 scenarios to be covered here which are assumed to be the most common: Project was created by 'New Project from Example' wizard and one of the SDK example projects was selected. Project was created by 'New Application Project' wizard and the SDK was selected for attachment within the wizard. Project was existing one and SDK was attached using the SDK management tool. Due to enough similarities between the projects, the last two will be covered as one scenario, under the heading 'New Application Project'. The first one will be covered under the heading 'New Project from Example'. Prerequisites Install S32 Design Studio IDE 3.4 Install the S32K1xx development package and S32SDK S32K1XX RTM 4.0.2 package Procedure New Project from Example For this demonstration, the S32K1xx SDK v4.0.1 example project 'flexio_i2s_master_s32k144' will be used. Open or create the project within S32DS 3.3 Expand project directory in Project Explorer and look for .mex file If no .mex file is present, then right click on project name and select 'S32 Configuration Tool -> Open Pins' (could select any tool within S32 Configuration Tool). Even though the .mex file contains the settings for S32 Configuration Tools, the same settings are also preserved in YAML code placed into the headers of each of the .c files generated by the S32 Configuration Tools into the 'board' folder in the project. By opening the S32 Configuration Tools, it detects there is no .mex file and scans the generated files for the YAML code. If YAML code is found, then a new .mex file is produced and placed in the project. The perspective is changed to the Pins Tool, nothing more needs to be done, .mex file has been created from the YAML code. If no YAML code had been found, then the user would be presented with a menu to select target device and SDK. Switch back to C/C++ perspective to confirm. Open S32DS 3.4 and import the project. It is important to note that separate workspaces should be used for S32DS 3.3 and S32DS 3.4. The project should be imported into the S32DS 3.4 workspace so the checkbox 'Copy projects into workspace' should be ticked. Right-click on Project -> Properties -> C/C++ Build -> Settings -> Standard S32DS C Compiler -> Includes, then delete all paths which contain 'S32_SDK_PATH' Repeat for Standard S32DS Assembler -> General Apply and Close The files in the SDK folder were included in the project as links and not actual files, and since the SDK 4.0.1 is not installed to S32DS 3.4, the links point to non-existing files. This means the Attach function in the SDK manager will not be able to replace them with the corresponding files from SDK 4.0.2 because it doesn't know how to replace files which don't exist. From Project Explorer, delete folder ' SDK' from the project. Now the project is ready to use the SDK manager to detach the old SDK and attach the new SDK. In Project Explorer, right-click on Project -> SDKs. When the SDK manager launches, it scans the project for any attached SDKs. In the case of this example, an SDK is detected as attached, but since it does not match any installed SDKs, a message appears asking to detach SDK 4.0.1. Since this is a desired action, click OK. With SDK 4.0.1 already detached, select SDK 4.0.2, click 'Attach/Detach...' Click 'Select All' to attach the SDK to all build configurations. This sets up the include paths, and linker paths for the SDK for each build configuration. If desired, the build configurations could be selected individually. Click OK to complete the selections. To apply the changes and exit the SDK manager, click 'Apply and Close'. The SDK Manager detects that some of the files from the new SDK are replacing existing files in the project. By default, all conflicting files are set to replace the existing file. If desired, individual files can be deselected. Please note, with the checkbox for 'Backup project files' ticked, any files replaced will be preserved in a backup folder for future recovery, comparison, etc. In general, it may be wise to allow the file to be replaced and later merge with the customizations in the backup folder. For this example, no modifications were made, so default settings are kept. Click OK to complete the process. The new SDK is attached and the new SDK folder can be identified. The .mex file contains the settings for the S32 Configuration Tools, however, it is still set for the SDK 4.0.1. It must be manually updated so the S32 Configuration Tools can be used to generate the new code for the 'board' folder. Right-click on .mex file and select 'Open With -> Text Editor'. All that is required is to modify the mcu_data section containing the SDK name: 's32sdk_s32k1xx_rtm_401' -> 's32sdk_s32k1xx_rtm_402' Now save the change. Next, the files in the 'board' folder must be regenerated from the S32 Configuration Tools to reflect the new SDK. Right-click on the .mex file and select 'Open With -> S32 Configuration Tools'. A warning message appears indicating that it has detected the mex file was created in an older version of the tool and that once the mex file is saved in the current tool, it may no longer open in an older version of the tool. This is expected. Click OK. Notice the error symbol. Mouse-over to see the details. It is an error with Peripherals tool. Select Peripherals tool. The issue is with edma_config_1, because it is highlighted red. Click on it to see the interface. The interface changed from the previous version to allow for multiple configurations where previously it supported only one. To resolve the error a new configuration must be added to the list. Click on the '+' as shown to add the new configuration. This particular error will only appear for projects which include the EDMA module. The Problem Indicator is now green, this means there are no warnings or errors. It is now time to generate the code, click 'Update Code' A menu appears identifying new and/or updated files. If desired, selecting 'change' on a row will open a comparison tool showing the changes between the existing and the new versions of the associated file. Click OK to proceed. Switch to C/C++ perspective Errors on project are now gone. If the project successfully built before the conversion, then build again to confirm everything was converted properly.   New Application Project For this demonstration, a new project will be created in S32DS 3.3 using the New Application Project wizard and the S32K1xx SDK 4.0.1 will be selected during project creation. Import the project into S32DS 3.4 Use the SDK Manager to detach the old SDK and then attach the new SDK. In Project Explorer, right-click on Project -> SDKs. When the SDK manager launches, it scans the project for any attached SDKs. In the case of this example, an SDK is detected as attached, but since it does not match any installed SDKs, a message appears asking to detach SDK 4.0.1. Since this is a desired action, click OK With SDK 4.0.1 already detached, select SDK 4.0.2, click 'Attach/Detach...' Click 'Select All' to attach the SDK to all build configurations. This sets up the include paths, and linker paths for the SDK for each build configuration. If desired, the build configurations could be selected individually. Click OK to complete the selections. To apply the changes and exit the SDK manager, click 'Apply and Close'. The SDK Manager detects that some of the files from the new SDK are replacing existing files in the project. By default, all conflicting files are set to replace the existing file. If desired, individual files can be deselected. Please note, with the checkbox for 'Backup project files' ticked, any files replaced will be preserved in a backup folder for future recovery, comparison, etc. In general, it may be wise to allow the file to be replaced and later merge with the customizations in the backup folder. For this example, no modifications were made, so default settings are kept. Click OK to complete the process. The .mex file contains the settings for the S32 Configuration Tools, however, it is still set for the SDK 4.0.1. It must be manually updated so the S32 Configuration Tools can be used to generate the new code for the 'board' folder. Right-click on .mex file and select 'Open With -> Text Editor'. All that is required is to modify the mcu_data section containing the SDK name: 's32sdk_s32k1xx_rtm_401' -> 's32sdk_s32k1xx_rtm_402' Now save the change. Next, the files in the 'board' folder must be regenerated from the S32 Configuration Tools to reflect the new SDK. Right-click on the .mex file and select 'Open With -> S32 Configuration Tools'. A warning message appears indicating that it has detected the mex file was created in an older version of the tool and that once the mex file is saved in the current tool, it may no longer open in an older version of the tool. This is expected. Click OK. Check for any errors or warnings by looking for the yield sign. It will change color based on the conditions: Green = No Problems, Yellow = Warnings, Red = Errors. Mouse-over the icon for more information on the location of the error. Aside from resolving warnings and errors, there should be no changes required as the settings have been preserved from the original project. In this example, there are no warnings or errors, so it is possible to proceed with updating the generated files. Click 'Update Code' A menu appears identifying new and/or updated files. If desired, selecting 'change' on a row will open a comparison tool showing the changes between the existing and the new versions of the associated file. Click OK to proceed. Change back to C/C++ perspective. Errors on project are now gone. If the project successfully built before the conversion, then build again to confirm everything was converted properly.

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