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:     

1. Install S32Design Studio 3.5: S32DS.3.5_b220726_win32.x86_64.exe 2. Download and Install S32 Design Studio 3.5 Update 2 D2302: SW32_S32DS_3.5.2_D2302.zip  (com.nxp.s32ds.update_3.5.2.20230227110156)   3. Click S32K3 Standard Software -> Automotive SW - S32K3 - S32 Design Studio Download and Install S32 Design Studio 3.5.0 Development Package with support for S32K3xx devices(3.5.0_D2303): SW32K3xx_S32DS_3.5.0_D2303.zip  (com.nxp.s32ds.sp1.s32k3xx.update_3.5.0.20230405175452)   4. For users who need to install S32K396 RTD for development, please download and install S32 Design Studio Service Pack 1 RTM with support for S32K39x devices(3.5.0_D2303): SW32K39x_S32DS_3.5.0_D2303.zip (com.nxp.s32ds.sp1.s32k396.update_3.5.0.20230330)   5.a) For users who need to install S32M276 RTD in S32K3 RTD 3.0.0\P01\P01 HF01\P01 HF02 for development, please download and install S32 Design Studio Service Pack 2 CD with support for S32M2xx devices (3.5.0_D2302😞 SW32M2xx_S32DS_3.5.0_D2302.zip(com.nxp.s32ds.s32m2.update_3.5.0.20230222151347)  Note: Please contact your local FAE to enable for you download the S32M276 development package. 5.b) For users who need to install S32M276 RTD in S32K3 RTD 3.0.0 P07 for development, , please download and install S32 Design Studio Service Pack 2 EAR2 with support for S32M2xx devices(3.5.0_D2303😞 SW32M2xx_S32DS_3.5.0_D2303.zip(com.nxp.s32ds.s32m2.update_3.5.0.20230328160305)   6. S32K3 Standard Software -> Automotive SW - S32K3/S32M27x - Real-Time Drivers for Cortex-M Select and install one of the following updatesite for S32K3 RTD 3.0.0: 6.a) Download and install S32K3 Real-Time Drivers Version 3.0.0: SW32K3_RTD_4.4_R21-11_3.0.0_D2303_DS_updatesite.zip   6.b) Download and install S32K3 Real-Time Drivers Version 3.0.0 P01 : SW32K3_RTD_4.4_3.0.0_P01_D2303_DS_updatesite.zip   6.c) Download and install S32K3 Real-Time Drivers Version 3.0.0 P01 HotFix 02 (3.0.0_P01_HF02😞 SW32K3_RTD_4.4_3.0.0_P01_HF02_DS_updatesite_D2305.zip   6.d) Download and install S32K3_M27X Real-Time Drivers Version 3.0.0 P07: SW32K3_RTD_R21-11_3.0.0 _P07_D2307.zip  

This document shows the step-by-step process to create a simple blinking LED application for the S32R45 family using the S32 RTD AUTOSAR drivers. This example used for the S32R45 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R45 development package and the S32R45 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_With_AUTOSAR'. The name must be entered with no space characters. Expand Family S32R45, Select S32R45 Cortex-M7 Click Next Click '…' button next to SDKs   Check box next to PlatformSDK_S32RXX_4_0_0_S32R45_M7_0. (or whichever latest SDK for the S32R45 is installed). Click OK And also, uncheck the other cores Cortex_M7_1 ,  Cortex_M7_2.   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. Select the overview tab and disable Pins tool. Make sure to overview tab windows shows settings shown as below.  Here, we are disabling pin tools and using MCAL driver from peripheral tools for using AUTOSAR drivers. Now from Overview menu, select peripheral tools and double click to open it. In the driver sections, “Siul2_Port_1 driver” is the non-AUTOSAR version driver and so it must be replaced. Right click on ‘Siul2_Port_1’ and remove it. Keep osif_1 driver as it is. Click on the ‘+’ next to the MCAL box. Click on the ‘+’ next to the MCAL box again, and Locate and then select the ‘Dio’ component from the list and click OK. Click on the ‘+’ next to the MCAL box again, and Locate and then select the ‘Mcu’ component from the list and click OK. Click on the ‘+’ next to the MCAL box again, and Locate and then select the ‘Port’ component from the list and click OK. Now components tab should show like below : Now we required to configure the different MCAL drivers that we added. Starting with Dio configuration, open the Dio configuration. Now, open the ‘DioConfig’ tab, and Edit Dio Port id to 3 as shown below: Now, in “Dio Configuration” window only, Select  “+” sign adjacent to DioChannel. Then Edit Name to “Digital_Output_LED” and Dio Channel Id to ‘5’ instead of ‘0’. From the schematic for S32GR45 EVB, checking for user LED from the schematic, channel 5 is connected to user LED signal, so we use channel 5 signal line to the chip for the user LED. So, we select the singal line for Dio channel Id 5 for the user LED connected on the S32R45 EVB. Now Select Port tab for Port configuration. And open the Port Configuration tab, and from that open “PortConfigSet” tab. Change the PortPin Mscr to ‘53’ and slew rate to ‘SRE_208MHZ_1_8V_166MHZ_3_3V’ and, PortPin Direction to PORT_PIN_INOUT as shown below: Now, at the bottom you will find the “UnTouchedPortPin ’’ . Click on “+’’ and add PortPins. Now add port pins 0, 1, 2, 3 as per below configuration Now configure MCU component. Select Mcu component in MCAL, and then open the Mcu configuration. In Mcu configuration click on MCUModuleConfiguration and then select “McuModesettingConf” from the dropdown menu as shown below. From McuModeSettingConf, select McuPartitionConfiguration tab. Then open the “McuPartition0Config” tab. And under the McuCore0Configuration or “McuCoreClockEnable” select checkbox and for “McuCoreResetEnable” uncheck the checkbox. Similarly, And under the McuCore1Configuration for “McuCoreClockEnable” select checkbox  and for “McuCoreResetEnable” uncheck the checkbox. Similarly, And under the McuCore2Configuration for “McuCoreClockEnable” select checkbox and for “McuCoreResetEnable” uncheck  the checkbox. After modification it should be as shown below: Now open the “McuPartition1Config” tab. for " Partition1 Clock Enable" select checkmark to true and for " Partition1 Clock Reset Enable" uncheck the checkmark for " CA53 CORE 0 cluster0 Core Clock Enable" select checkmark to true and for " Cortex-A53 Core 0 cluster 0 Clock Reset Enable" uncheck  the checkmark In the McuCore1Configuration, and for " Cortex-A53 Core 1 cluster 0 Clock Reset Enable" uncheck the checkmark In the McuCore2Configuration, for " Cortex-A53 CORE 0 cluster 1 Core Clock Enable" select checkmark to true and for " Cortex-A53 CORE 0 cluster 1 Clock Reset Enable" uncheck the checkmark In the McuCore3Configuration, for " Cortex-A53 CORE 0 cluster 1 Clock Reset Enable" uncheck the checkmark After modification it should be as shown below: Now open the “McuPartition2Config” tab. for " Partition2 Clock Enable" select checkmark to true and for " Partition2 Clock Reset Enable" uncheck the checkmark Now open the “McuPartition3Config” tab. for " Partition3 Clock Enable" select checkmark to true and for " Partition3 Clock Reset Enable" uncheck the checkmark 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 clock tree and apply PLL as system clock, Apply a mode configuration, Initialize all pins using the Port driver by adding – editing code before write code here comment in main function.        /* Initialize the Mcu driver */        Mcu_Init(&Mcu_Config_BOARD_InitPeripherals);        /* Initialize the clock tree and apply PLL as system clock */        Mcu_InitClock(McuClockSettingConfig_0);        /* Apply a mode configuration */        Mcu_SetMode(McuModeSettingConf_0);        /* Initialize all pins using the Port driver */        Port_Init(NULL_PTR); Now replace the logic of for loop as shown below code section in the main function, which will enable the LED blinking for 10 times: You also need to declare and initialize the loop variable uint8 i = 0U; . Then replace the code as below after write your code comment: /*Logic for blinking LED 10 times*/ while (i++ < 10) {           /* Get input level of channels */           Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED, STD_HIGH);           TestDelay(3000000);           Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED, STD_LOW);           TestDelay(3000000); } Before the 'main' function, add a delay function as follows: void TestDelay(uint32 delay); void TestDelay(uint32 delay) {      static volatile uint32 DelayTimer = 0;      while(DelayTimer<delay)      {             DelayTimer++;      }      DelayTimer=0; } Update the includes lines at the top of the main.c file to include the headers for the drivers used in the application: 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_with_AUTOSAR_Debug_RAM'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist. And make selection as shown in screenshot below. You need to select the ethernet connection for S32 debugger and provide its IP address Click Debug To see the LED blink, click ‘Resume' This code as it will blink the LED 10 times, you can make changes in for loop condition to blink it infinitely.

This document shows the step-by-step process to create a simple blinking LED application for the S32R45 device using the S32 RTD non-AUTOSAR drivers. For this example used for the S32R45 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R45 development package and the S32R45 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools. Launch S32 Design Studio for S32 Platform Procedure New S32DS Project OR Provide a name for the project, for example 'Blinking_LED_RTD_No_AUTOSAR'. The name must be entered with no space characters. Expand Family S32R45, Select S32R45 Cortex-M7 Click Next And Click '…' button next to SDKs   Check box next to PlatformSDK_S32RXX_4_0_0_S32R45_M7_0. (or whichever latest SDK for the S32R45 is installed). Click OK Now, uncheck the selection mark for other core, i.e. for Cortex-M7-1 , Cortex-M7-2   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. For the Blinking LED example, one pin must be configured as output. The S32R45 EVB has an user LED connected pin is PD_05. From the Peripheral Signals tab left to the Pins tool perspective layout, locate Open the Siul2_0 from the peripheral signals tab. And from the drop down menu select “gpio,53 PD_05” option as per shown in the following image. We are using PD_05 for the GPIO usage, so we are routing SIUL2_0 GPIO signal to this pin. Select gpio53 -> PD_05 as shown below : The Direction required! menu will appear. Select Output then OK. In Routing Details view, notice a new line has been added and highlighted in yellow. Add ‘LED’ to the Label and Identifier columns for the PORTD 5 pin. Code Preview Go to Peripherals tool and add Siul2_Dio to enable LED blinking, it adjacent to the user LED on S32R45 EVB. Click on the Peripherals Tool icon from the Eclipse Perspective navigation bar. From the Components view, click on ‘Add a new configuration component…’ button from the Drivers category. This will bring up a list of all configuration components. Locate and then select the ‘Siul2_Dio’ component from the list and click OK. Do not worry about the warning message. It is only indicating that the driver is not already part of the current project. The associated driver package will be added automatically. Note: It may be necessary to change the selection at the top from ‘Present in the tool-chain project’ to ‘All’. The DIO driver provides services for reading and writing to/from DIO Channels. The Gpio_Dio driver requires no further configuration. Click Save to store all changes to the .MEX file. Now the device configurations are complete and the RTD configuration code can be generated. Click ‘Update Code’ from the menu bar. To control the output pin which was just configured, some application code will need to be written. Return to the ‘C/C++’ perspective. If not already open, in the project window click the ‘>’ next to the ‘src’ folder to show the contents, then double click ‘main.c’ file to open it. This is where the application code will be added. Before the pin can be controlled, it needs to be initialized using the configuration information that was generated from the S32 Configuration tools. Initialize all pins using the Port driver by adding the following line: Insert the following line into main, after the comment 'Write your code here': /* Initialize all pins using the Port driver */ Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0); Now, add logic for the LED turn and off. To turn the pin on and off with some delays in-between to cause the LED to blink. Make the delays long enough to be perceptible. Add line to initialize variable uint8 i = 0; Change the code within the provided for loop, and add the following lines: //logic for blinking LED 10 times while (i++ < 10) {        Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 1U);        TestDelay(4000000);        Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 0U);        TestDelay(4000000); } Before the 'main' function, add a delay function as follows: void TestDelay(uint32 delay); void TestDelay(uint32 delay) {    static volatile uint32 DelayTimer = 0;    while (DelayTimer<delay)    {        DelayTimer++;    }    DelayTimer=0; } Update the includes lines at the top of the main.c file to include the headers for the drivers used in the application: Remove #include "Mcal.h" Add #include "Siul2_Port_Ip.h" #include "Siul2_Dio_Ip.h" Build 'Blinking_LED_RTD_No_AUTOSAR'. Select the project name in 'C/C++ Projects' view and then press 'Build'. After the build completes, check that there are no errors. Open Debug Configurations and select 'Blinking_LED_RTD_No_AUTOSAR_Debug_RAM'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist. Now, you need to Select the Interface (Ethernet or USB) by which the S32 Debug Probe is connected. If connected via USB and this option is selected for interface, then the COM port will be detected automatically (in the rare event where 2 or more S32 Debug Probes are connected via USB to the host PC, then it may be necessary to select which COM port is correct for the probe which is connected to the EVB) If connected via Ethernet, enter the IP address of the probe. See the S32 Debug Probe User Manual for ways to determine the IP address. Click Debug To see the LED blink, click ‘Resume'. This code as it will blink the LED 10 times, you can make changes in for loop condition to blink it infinitely.

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 NXP device S32R41 has accelerators that can be programmed. The S32 Debugger included within the S32 Design Studio for S32 Platform IDE with the S32 Debug Probe provides the ability to debug these accelerators. The accelerator covered in this document: Signal Processing Toolbox (SPT).   Section map: Preparation             Setup the software tools             Setup the hardware Procedure             Create A New Debug Configuration                                Start A Debug Session                         Multi-Core Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R41 development package and the Radar extension package for S32R41. Both of these are required for the SPT3.5 accelerator. Setup the hardware Confirm the setup of the S32R41 evaluation board. Connect the power supply cable Setup the S32 Debug Probe. Refer to the S32 Debug Probe User Guide for installation instructions. Connect the S32 Debug Probe to the evaluation board via JTAG cable. Connect the S32 Debug Probe to the host PC via USB cable OR via Ethernet cable (via LAN or directly connected and configured for static IP address) and power supply connected to USB port. Launch S32 Design Studio for S32 Platform Open existing project or create a new project and check that it successfully builds. If creating a new project, be sure the S32 Debugger is selected in the New Project Wizard.   Procedure The procedure for starting a debug session and accessing the associated accelerator-specific registers is detailed here. Debugging SPT is only conducted through the multi-core method. The SPT executable is included within A53 executable, the A53 application loads the SPT executable to the SPT core and both A53 and SPT core are available for debugging. The debug connection is made to the two cores through the Baremetal/Bareboard method. The debugger connects to both the A53 and SPT cores using the probe over JTAG. Before a debug session can be started a debug configuration must exist.   Create A New Debug Configuration If the New Project Wizard was used to create the project using the S32DS Application Project option, then there was an opportunity to select the desired debugger from within the wizard. If the desired debugger option was selected at this time, then the needed configuration already exists and will only require adjustments to the hardware connection settings.   If the New Project Wizard was not used to create the project OR the currently desired debugger was not the one selected at the time of project creation, a new debug configuration must be created. With the existing project selected in Project Explorer, open the Debug Configurations Menu: Run -> Debug Configurations Having the existing project selected in the Project Explorer view will make the creation of a new launch configuration easier as many settings will be imported from the selected project. To select a project, click on it so it becomes highlighted. Next, select the debugger for which the new debug configuration will be created. To create the new configuration, either click on the ‘New launch configuration’ button from the toolbar at the top and to the left, or right-click on the ‘S32 Debugger’ and select ‘New Configuration’ from the menu. Once the configuration is created it will be displayed and any errors with the configuration will be shown. If the project was selected in the Project Explorer, then the Name of the debug configuration will contain the project’s name and the Project and C/C++ Application fields may 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. If the C/C++ Application field is empty, just click ‘Browse..’ button (The ‘Search Project…’ button is setup to identify standard executable file types, not the SPT’s ‘aspt’ file type) and navigate to the folder containing the build output <project name>.aspt. If you like, the tool already knows the project directory path, so you could shorten the path to start with from the ‘Debug’ folder, as shown here. 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 S32R41 are listed. Select the SPT35 core and click OK. Now that the device and core are selected, the attach script is selected automatically. The attach script will allow to start debugging on a core that is already initialized. This is correct for the SPT core as it is always launched in multicore scenario. Refer to the document 'README.txt' located in the same folder as these script files for details on all of the provided scripts. Confirm the setting of the ‘Initial core’ checkbox. This box should be checked within the debug configuration that establishes the first connection to the target device via S32 Debug Probe. When this box is checked, the Debug Probe Connection interface and GDB Server settings become available. The probe connection only needs to be configured once and only one GDB Server needs to be running for each debug session. When debugging the SPT3.5 core, the A53 core will always launch first, so this box should be checked for the A53 debug configuration and should not be checked for the SPT debug configuration. Check that the GDB Client section has the correct path to the SPT GDB executable. It should point to the variable ‘S32DS_R41_GDB_SPT_PATH’. Startup tab check the following settings Load image is NOT checked for multicore debugging. Basically, if it is loaded by A53 core (SPT executable is contained within A53 ELF file), then it does not need to be loaded. Load symbols is NOT checked. The SPT source file is assembly code, so there are no symbols to load. Set breakpoint at main and Resume are NOT checked for multicore debugging. After saving the new configuration with the ‘Apply’ button, SPT debugging can be performed. Start A Debug Session For convenience, the S32DS Application Project wizard was used to create a new project for demonstrating multi-core A53/SPT debugging. The SPT core does not support standalone debugging. For instructions on loading this example project to your workspace, see ‘HOWTO: S32 Design Studio - Create New Application Project’, selecting instead the Processor option Family S32R41 -> S32R41xxx Cortex-A53 SPT3 from the wizard menu. A53 / SPT Multi-Core For multi-core debugging, the A53 core is running an executable which also contains the SPT code. The A53 code will make a call into the SPT to load the SPT code to memory and to start the SPT execution. So the A53 must be started first. The EVB settings are irrelevant as the debugger will take control of the target via the JTAG connection. Before beginning the debug sessions, be sure each project is built clean. Start A53 debug. From the menu at the top, select Run -> Debug Configurations… In the Debug Configurations menu, from the configuration list, look for the ‘S32 Debugger’ group and select the A53 Debug_RAM configuration for the project to be debugged. In the case of our example, the ‘New_S32R41_SPT_Project_A53_Debug_RAM_S32Debug’ configuration. On the Debugger tab, check that the Debug Probe Connection settings match with the current hardware connection configuration for the S32 Debug Probe. Use the ‘Test connection’ button to confirm. Click Debug to start debugging on the A53 core. The debugger will launch and execute until the first executable line in main(). See Debugger tab in Debug Configurations menu to adjust this setting. Once the A53 debug session is running, advance the program counter to a line after the desired SPT kernel is loaded to memory but before the SPT kernel is launched. In the example here, this would be in ‘main.c’, line 57, where ‘StartSptProgram()’ function is called. This can be done by setting a breakpoint on the line and clicking Resume.  After the breakpoint is reached, the SPT debug session can be started. Return to the Debug Configurations menu, select the SPT debug configuration. In the case of this example, ‘New_S32R41_SPT_Project_SPT35_Debug_S32Debug’, and click Debug. Wait for the SPT debug session to launch and stop in the disassembly. Use the Step Over command one time in the A53 debug thread to complete the SPT launch. Select the SPT debug thread to change the context of the Disassembly, Registers and etc.views. Notice the SPT code is not loaded yet. Enable Instruction Stepping Mode and step one time. Notice the SPT code is now loaded. Now you can step through the assembly code, access registers, etc.

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”

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

S32 Design Studio (S32DS) supports Eclipse plug-in of Green Hills Software (GHS) compiler to compile S32DS projects via GHS compiler. This document describes how to install this plug-in and enable GHS in the new project wizard. After the GHS Eclipse plug-in is installed successfully, you can be able to create and build S32DS project using GHS compiler under S32DS Eclipse environment if the device and SDKs support GHS compiler.   Installation instructions To able to use GHS compiler, you need to make sure that GHS compiler is installed with a valid license. Follow the steps below to install eclipse plugin: Install GHS Eclipse plug-in On S32DS graphical user interface, go to menu "Help" -> "Install New Software"   In the "Install" dialog appears, click on "Add" button. In the "Add Repository" dialogappears, click on "Local". Navigate to the eclipse directory located in your MULTI compiler installation(eg: C:\ghs\comp_202114\eclipse) In the Name box, enter "GHS Eclipse". Click on "Add" button.  In the Name/Version list, expand the Green Hills MULTI for Eclipse item. Select GreenHills MULTI for Eclipse corresponding to your target architecture(eg: Green Hills MULTI for Eclipse(ARM) and Green Hills MULTI for Eclipse(ARM64)). If you have MULTI licenses for more than one architecture, you can select all the targets you are licensed for. Click Next until you see the license acceptance page.  If you accept the terms of the feature license, select I accept the terms in the license agreement. And click on "Finish" button.   If the Security Warning window appears, click on "Install anyway".   In the "Software Updates" dialog box appears, click on "Restart Now" to restart S32DS.- Go to "Window" -> select "Preference" -> "S32 Design Studio for S32 Platform" -> "S32DS Variables". Set your GHS installation path for S32DS_GHS_PATH variable (ex "C:\ghs\comp_202114").   Create new S32DS project using GHS in the project wizard. Now you can create a new S32DS project and select GHS toolchain for the device andSDKs support GHS toolchain.   And you can see the GHS settings are showed in the S32DS project properties.    

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

The NXP device S32R45 has accelerators that can be programmed. The S32 Debugger included within the S32 Design Studio for S32 Platform IDE with the S32 Debug Probe provides the ability to debug these accelerators. The accelerator covered in this document: Linear Algebra Accelerator (LAX).      Section map:           Preparation               Setup the software tools                              Setup the hardware             Procedure                Create A New Debug Configuration                             Simulator                             Physical Hardware                Start A Debug Session                             Standalone                             Multi-Core                Debugging LAX Once Debug Session is Started               Multi-thread LAX Debugging: IPPU & VCPU                     Multi-LAX core Debugging                     Preparation   Setup the software tools   Install S32 Design Studio for S32 Platform    Install the S32R4xx development package and the Radar extension package for S32R4xx. Both of these are required for the LAX accelerator.      Setup the hardware   Confirm the setup of the S32R45 evaluation board. Connect the power supply cable   Setup the S32 Debug Probe. Refer to the S32 Debug Probe User Manual for installation instructions. Connect the S32 Debug Probe to the evaluation board via JTAG cable. Connect the S32 Debug Probe to the host PC via USB cable OR via Ethernet cable (via LAN or directly connected and configured for static IP address)  and power supply connected to USB port.   Launch S32 Design Studio for S32 Platform   Open existing project or create a new project and check that it successfully builds. If creating a new project, be sure the S32 Debugger is selected in the New Project Wizard.     Procedure   The procedure for starting a debug session and accessing the associated accelerator-specific registers is detailed here.    Application code executing on the LAX accelerator can be debugged using a simulation as well as on physical hardware.   Debugging using simulation occurs entirely on the PC and no physical hardware is required.      When debugging LAX on physical hardware, this is primarily conducted through one of two methods:   Standalone: the LAX executable is loaded by a debugger over JTAG using a probe and only the LAX core is executed and available for debugging.   Multi-core: the LAX executable is included within A53 executable, the A53 application loads the LAX executable to the LAX core and both A53 and LAX core are available for debugging. The debug connection is made to the two cores through one of two methods:   Baremetal/Bareboard: the debugger connects to both the A53 and LAX cores using the probe over JTAG.   Linux BSP: the debugger connects to the A53 core, which is running Linux BSP, using a remote Linux connection over Ethernet and then connects to the LAX core using the debug probe over JTAG.      Before a debug session can be started a debug configuration must exist.       Create A New Debug Configuration   If the New Project Wizard was used to create the project using the S32DS Application Project option, then there was an opportunity to select the desired debugger from within the wizard. If the desired debugger option was selected at this time, then the needed configuration already exists and will only require adjustments to the hardware connection settings (no hardware settings for LAX Simulator).     If the New Project Wizard was not used to create the project OR the currently desired debugger was not the one selected at the time of project creation, a new debug configuration must be created.       With the existing project selected in Project Explorer, open the Debug Configurations Menu: Run -> Debug Configurations     Having the existing project selected in the Project Explorer view will make the creation of a new launch configuration easier as many settings will be imported from the selected project. To select a project, click on it so it becomes highlighted.   Next, select the debugger for which the new debug configuration will be created.                    Simulator   To create the new configuration, either click on the ‘New launch configuration’ button from the toolbar at the top and to the left, or right-click on the ‘LAX Simulator’ and select ‘New Configuration’ from the menu.     Once the configuration is created it will be displayed and any errors with the configuration will be shown. If the project was selected in the Project Explorer, then the Name of the debug configuration will contain the project’s name and the Project and C/C++ Application fields will be populated as well. The C/C++ Application field will only be populated if the build output executable exists. Confirm these values are correct before moving on.     There is an error showing that the Device core ID is not specified on the Debugger tab. Switch to the Debugger tab and click on the button ‘Select device and core’.     From the Select Target Device and Core window, expand the listing until all cores are listed. Since the LAX Simulator only supports LAX cores on the S32R45, that is all which is listed. Select the desired LAX core and click OK.     Now that the device and core are selected, the only correct initialization script associated with the LAX is selected automatically.     No further changes are required. Click Apply to save the changes or if you are ready to debug with the LAX Simulator, then click Debug and the changes will be saved and the debug session will launch.      Physical Hardware   To create the new configuration, either click on the ‘New launch configuration’ button from the toolbar at the top and to the left, or right-click on the ‘S32 Debugger’ and select ‘New Configuration’ from the menu.     Once the configuration is created it will be displayed and any errors with the configuration will be shown. If the project was selected in the Project Explorer, then the Name of the debug configuration will contain the project’s name and the Project and C/C++ Application fields will be populated as well. The C/C++ Application field will only be populated if the build output executable exists. Confirm these values are correct before moving on.     There is an error showing that the Device core ID is not specified on the Debugger tab. Switch to the Debugger tab and click on the button ‘Select device and core’.     From the Select Target Device and Core window, expand the listing until all cores are listed. Notice that all supported cores on the S32R45 are listed. Select the desired LAX core and click OK.     Now that the device and core are selected, a generic initialization script associated with the LAX is selected automatically, however, this may not be the correct one. If debugging Standalone, meaning only LAX core will be debugged, then the automatic selection   ‘s32r45_generic_bareboard_all_cores.py’ is correct. This script will initialize all of the cores so the LAX can execute properly. If debugging Multicore, meaning both A53 and LAX will be debugged, then the A53 and LAX cores will already be initialized by the time the debugging on LAX begins. So a different script that doesn't initialize all of the cores is needed. Click ‘Browse’ and navigate to ‘{install_dir}\S32DS.3.5\S32DS\tools\S32Debugger\Debugger\scripts\s32r45’ and select the script ‘s32r45_attach.py’. The attach script will allow to start debugging on a core that is already initialized. Refer to the S32 Debugger User Guide, or the document 'README.txt' located in the same folder as these script files for details on all of the provided scripts.     Confirm the setting of the ‘Initial core’ checkbox. This box should be checked within the debug configuration that establishes the first connection to the target device via S32 Debug Probe. When this box is checked, the Debug Probe Connection interface and GDB Server settings become available. The probe connection only needs to be configured once and only one GDB Server needs to be running for each debug session. Therefore, this box should be checked for standalone debugging or for multicore debugging where A53 core is debugged via Remote Linux. If the A53 and LAX cores are debugged via the S32 Debug Probe, then this box should be checked for the A53 debug configuration and should not be checked for the LAX debug configuration.   If this is a standalone debugging of only the LAX core, setup the Debug Probe Connection. Select either USB or Ethernet, depending upon your hardware setup. If USB is selected, the COM port for the S32 Debug Probe will automatically be detected (unless not connected or more than one probe is connected). If Ethernet is selected, then enter either the hostname (fsl + last 6 digits of MAC address) or IP address. It is highly recommended to press the ‘Test connection’ button to confirm the hardware connection is correctly configured. See the included ‘S32_Debug_Probe_User_Guide.pdf’ for more details on the setup of the S32 Debug Probe.     Check that the GDB Client section has the correct path to the LAX GDB executable. It should point to the variable ‘S32DS_R45_GDB_LAX_PATH’.     Startup tab check the following settings   Load image is checked for standalone debugging, NOT checked for multicore debugging. Basically, if it is loaded by A53 core (contained in A53 ELF file), then it does not need to be loaded.   Load symbols is checked. The only time you would not check this box is if there is no project binary containing symbols available.   Set breakpoint at main and Resume are checked for standalone debugging, NOT checked for multicore debugging.     Now you are ready to start debugging. If debugging Standalone, click ‘Debug’. If debugging Multicore, switch to the A53 debug configuration (either C/C++ Remote Application or S32 Debugger) and start the A53 debug session first. Once the A53 debug session is running, advance the program counter to the line just after LAX is initialized.       Start A Debug Session   Starting a LAX debug session are different depending upon whether Standalone or Multi-core debugging is required. The steps for each method are detailed in separate sections below.   For convenience, the example project for S32 Design Studio from the RSDK, ‘RSDK_S32DS_template’, will be used to demonstrate multi-core A53/LAX debugging. Note: Unfortunately, this example project is not setup for standalone debugging because there is no main() executing on LAX to call the    LaxVectorAddGraph(). So the standalone debugging steps will be presented only to highlight the different setup required. For instructions on loading this example project to your workspace, see ‘HOWTO: Create New Project from Example  RSDK_S32DS_template from Radar SDK’.      Standalone   If the standalone bareboard debugging of only LAX core was supported by the RSDK_S32DS_template example, here are the steps which would be required.   Click on the LAX project so it is highlighted, then build it to ensure it builds clean and that the executable exists.     From the menu at the top, select Run -> Debug Configurations…     Select the standalone debug configuration for LAX core. In the case of the RSDK_S32DS_template example project, only the multi-core debug configuration is supported. In this case, the standalone configuration will need to be created. Right click on the multi-core configuration and select Duplicate.  This will create an identical configuration.      Change the name as desired and then select the Debugger tab.     Click Browse next to Initialization script and navigate to the directory   ‘{install_dir}\S32DS.3.4\S32DS\tools\S32Debugger\Debugger\scripts\s32r45’. Select the script  ‘ s32r45_generic_bareboard_all_cores.py’.     Adjust the Debug Probe Connection settings to match your HW setup. Use the Test connection button to confirm.      Select the Startup tab. For standalone debugging the image file will not be loaded by the A53 core, so it must be loaded by the S32 Debugger. Check the boxes for Load image, Set breakpoint at: and Resume.     Click Debug to start the debug session. All of the settings made will be applied and the debug session will be launched.      A53 / LAX Multi-Core   For multi-core debugging, the A53 core is executing an application on the Linux BSP. The EVB should be setup to boot from a flash device which has been loaded with the S32R45 Linux BSP.   Before beginning the debug sessions, be sure to load the driver dependencies (oal_driver, rsdk_spt_driver, and rsdk_lax_driver) as described in the RSDK User Manual, RSDK Offline Example section ‘Running the application’.   Start A53 debug. From the menu at the top, select Run -> Debug Configurations…     In the Debug Configurations menu, from the configuration list, expand the ‘C/C++ Remote Application’ group and select the ‘RSDK_S32DS_template_A53_Debug’ configuration.     On the Main tab, create a new connection for using the IP address of the EVB. The IP address could   be determined either by issuing a Linux command over the serial connection, such as ‘ifconfig’, by accessing the local network connected device list, or perhaps the EVB was setup with a static IP address and it is already known.     Click New… in the Connection section.   Select ‘SSH’ for connection type.   Enter the IP address in Host: field, use ‘root’ in User: field, and leave password field empty        Click Debug to start debugging on the A53 core.     The debugger will launch and execute until the first executable line in main(). See Debugger tab in Debug Configurations menu to adjust this setting.     Now that the A53 is launched, it is necessary to execute the A53 code until just after the LAX core is  initialized and buffers are allocated. Open ‘lax_processing.c’ from the ‘src’ folder in the A53 project and set a breakpoint on line 100. One way is by double-click in the space on the left side of source code editor. This is the executable line just after ‘RsdkLaxInit()’ is called.     Now press ‘Resume’ from the toolbar to advance the program counter to the breakpoint.     Wait for the breakpoint to occur.     Return to the Debug Configurations menu, select the ‘RSDK_S32DS_template_LAX_0_attach’ debug configuration and select the Debugger tab.     Adjust the Debug Probe Connection settings to match your HW setup. Use the Test connection button to confirm.     Click Debug to start the LAX debug session.   Wait for the LAX debug session to launch and stop in the disassembly. Set a breakpoint in the source code. For our example, place one in ‘lax_custom_graph.c’ on line 97, where the kernel ‘ Rsdk_LA_add_VV’ is called.     Select the LAX debug thread and press Resume so it will be ready to run to the breakpoint which was just setup.     Select the A53 debug thread and press Resume to allow execution to resume and then wait for the breakpoint to be reached in the LAX code.       The breakpoint in the LAX code has been reached. Now it is possible to perform some debugging activities on the LAX core.        Debugging LAX Once Debug Session is Started   Once the LAX debug session is started, it will be stopped and only disassembly can be viewed. Select the LAX debug thread to see.     Open the C code source file and set a breakpoint within the kernel of interest.     Press Resume on the LAX debug thread.   Now switch back to the A53 debug thread and press Resume.   The breakpoint you set in LAX will be reached and you can now start stepping through and looking at registers, etc.         Multi-thread LAX Debugging: IPPU & VCPU    Load a project which uses both IPPU and VCPU and start the debug session on LAX using one of the methods provided.   Once the debug session is started on LAX, set a breakpoint on the line containing RSDK function ‘Rsdk_AU_sync_i()’     Press Resume to advance the program counter to the breakpoint. When the breakpoint is reached, the second thread appears. The first thread contains the VCPU and the second thread contains the IPPU.     Select the second thread to see the IPPU disassembly. Now instruction stepping can be performed on the IPPU. Registers can be viewed as well.     To see the opcodes, do not use the codes shown in the disassembly view. The disassembly view does not handle cases where many opcodes are packed into a single address. Instead, use the Memory Spaces view.        If the memory spaces view is not already present, then add it from the menu Window -> Show View -> Memory Spaces.   To add a memory space, right click in the panel on the left or click on the + button at the upper right.      Multi-LAX-core Debugging   The S32R45 device contains 2 LAX cores: LAX_0 and LAX_1. To debug the additional LAX core, simply add a new debug configuration and setup for LAX_1.   Create a new debug configuration for LAX_1 by first duplicating the existing debug configuration for LAX_0.      Rename the configuration to reference LAX_1, but the project name and application file (ELD) will remain the same.     On the Debugger tab, use ‘Select device and core’ button to change the core to LAX_1, change the initialization script to ‘<device>_attach.py’, and uncheck the box next to Initial core.    Depending on how you started the debug session for LAX_0, you may need to adjust the Startup tab. The settings on Startup tab should be set to match the LAX_0 debug configuration.   Start the LAX_0 debug session first, then the LAX_1 debug session. Stepping within each can be conducted independently.

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 as well as M7 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', or the M7 variant. For this example, we are using the A53 screenshots 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). Switch the initialization from the default s32g2xx_generic_bareboard.py script to s32g2xx_generic_bareboard_all_cores.py in order to make the trace modules accessible. 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.  From the dropdown with the XML configuration files, select one matching your debug project name. A configuration is generated if none is present for your debug launch the first time you open it in the debug configuration view. 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. It is recommended to disable all cores that are not required to be traced, as they may funnel in the same buffer, occupying the limited memory. 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.

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

**************************************************************************************** IDE: S32 Design Studio Version 3.4 Workspace: C:\Projects\S32DS_3_4 Project name: S32K314_00_blank_00 Project location: C:\Projects\S32DS_3_4\S32K314_00_blank_00 **************************************************************************************** 1. After you finish the edit on your codes, please close S32DS 2. Input the command(as below) at your clean_and_build_s32k3_commandLine.bat 3. Run command prompt with Administrator right. 4. Run clean_and_build_s32k3_commandLine.bat at command prompt   You will get the *.elf under the folder of C:\Projects\S32DS_3_4\S32K314_00_blank_00\Debug_FLASH Cheers! Oliver

This short video is a presentation of DDR tool. It contains a minimum requirement and troubleshooting for starting with DDR and S32G and an initialization training for S32G2-EVB

Pin muxing is the process of assigning a peripheral function to a physical pin. This video will explain how fast and easy is to a configured pin muxing using Pins Tool from S32 Configuration Tool suite. Example is a UART project from S32V microcontroller SDK.