S32 デザインスタジオ・ナレッジベース

ディスカッション

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

This document shows the step-by-step process to create a simple blinking LED application for the S32M2xx family using the S32 RTD AUTOSAR drivers. This example used for the S32M244 EVB, connected to a PC through P&E Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32M2xx development package and the S32M24 RTD AUTOSAR 1.9.0 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 S32M2xx, Select S32M244 Click Next Click '…' button next to SDKs Check box next to PlatformSDK_S32K1_S32M24_2_0_0_S32M244_M4F (or whichever latest SDK for the S32M2xxx is installed). Click OK Click Finish. Wait for project generation wizard to complete, then expand the project within the Project Explorer view to show the contents. To control the LED on the board, some configuration needs to be performed within the Pins Tool. There are several ways to do this. One simple way by double-click on the MEX file. 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, “Port_Ip_1 driver” is the non-AUTOSAR version driver and so it must be replaced. Right click on ‘Port_Ip_1’ and remove it. Keep the BaseNXP driver as it is. Click on the ‘+’ next to the MCAL box. 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 ‘Dio’ 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 : Ignore the error for Port component for now. 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. From that change Dio Port Id to 4 instead of 0 In that, select “+” sign adjacent to Dio Channel. Then edit Name to “DioChannel_0”and “Dio Channel Id” to ‘6’ instead of ‘0’. From the schematic for S32M244 EVB, we can select signal line for user LED from the schematic, channel 6 is connected to user LED signal, so we use channel 6 signal line to the chip on the user LED. Now Select Port tab for Port configuration. And select and open Port Configuration tab, and from that open “PortConfigSet” tab. Edit PortPin Pcr to “134” instead of “0”. Also, change Portpin Direction to “PORT_PIN_OUT” And PortPin Level Value to “PORT_PIN_LEVEL_LOW”. After change it should be as below. At the bottom you will find the “UnTouchedPortPin ’’ . Click on “+’’ and add PortPins. Now add 6 port pins as per below configuration. Pins 0, 1,2,3, 4,5, and 6 should be setup. 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); while ( MCU_PLL_LOCKED != Mcu_GetPllStatus() ) { /* Busy wait until the System PLL is locked */ } Mcu_DistributePllClock(); 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, which will enable the LED blinking for 10 times: You also need to declare and initialize the loop variable uint8 count = 0U Then replace the code as below: /* Logic for blinking LED 10 times */ while (count++ < 10) { /* Get input level of channels */ Dio_WriteChannel(DioConf_DioChannel_DioChannel_0, STD_HIGH); TestDelay(2000000); Dio_WriteChannel(DioConf_DioChannel_DioChannel_0, STD_LOW); TestDelay(2000000); } Before the 'main' function, add a delay function as follows: 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" Now, select and open max file again. Then, select and open peripheral tools. Now, from the toolbar selection menu at the top, select and double click on the symbol as shown as below: Now, from the global settings, for ComponentGenerationMethod from that select “FunctionalGroups” from the drop down menu as shown below: Now. click ‘Update Code’ from the menu bar. 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. Now, you need configuration for P&E MULTILINK Debug Probe. Connect PE Micro debugger to EVB using USB, and to make sure that debugger is connected via USB interface, then the COM port will be detected automatically (in the rare event where 2 or more 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). Now, Select PEMicro Multilink debugger, select “Run”, and select debug configuration tab, then select GDB PE Micro Interface Debugging, and from the option available under it, select option with Debug_FLASH_PNE. Now, in the debug configuration window, select the tab PEmicro Debugger, and in the PEMicro Interface settings, select the interface USB Multilink. Clink apply and debug Click Debug To see the LED blink, click ‘Resume' This code as it is will blink the LED 10 times, you can make changes in for loop condition to blink it infinitely.

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

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

For S32 Design Studio v3.5 and earlier, there is a known issue when the S32 Configuration Tools are invoked from command line from a location outside of the S32DS installation directory. The following error is reported: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.base/java.lang.reflect.Constructor.newInstance(Unknown Source) at com.nxp.swtools.common.utils.runtime.SingletonProvider.getSingletonInstance(SingletonProvider.java:46) at com.nxp.swtools.common.ui.utils.swt.internal.SWTFactory.getSingletonInstance(SWTFactory.java:421) at com.nxp.swtools.common.ui.utils.swt.SWTFactoryProxy.getSingletonInstance(SWTFactoryProxy.java:448) at com.nxp.swtools.dcd.controller.DCDController.getInstance(DCDController.java:84) at com.nxp.swtools.dcd.DCDStartup.earlyStartup(DCDStartup.java:23) at com.nxp.swtools.provider.SWToolsPlatform.initializeAllTools(SWToolsPlatform.java:702) at com.nxp.swtools.framework.Application.start(Application.java:475) at com.nxp.swtools.framework.Application.start(Application.java:445) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.base/java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:654) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1462) Caused by: java.lang.NoClassDefFoundError: javafx/beans/property/SimpleBooleanProperty at com.nxp.swtools.bootimage.controller.ABootController.<init>(ABootController.java:37) at com.nxp.swtools.dcd.dcf.common.DCDCommonController.<init>(DCDCommonController.java:90) at com.nxp.swtools.dcd.controller.DCDController.<init>(DCDController.java:43) ... 24 more Caused by: java.lang.ClassNotFoundException: javafx.beans.property.SimpleBooleanProperty cannot be found by com.nxp.swtools.bootimage_1.0.0.202207251223 at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:519) at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:170) at java.base/java.lang.ClassLoader.loadClass(Unknown Source) Resolution: To resolve the issue: Invoke the command from within the installation directory, for example, from 'C:\NXP\S32DS.3.5\eclipse' OR Change "{S32DS Installation Folder}\eclipse\s32ds.ini" by setting the javafx path from relative to absolute. So, if default installation is used, then: Change -Defxclipse.java-modules.dir=jre/javafx-sdk-11.0.2/lib To -Defxclipse.java-modules.dir=C:/NXP/S32DS.3.5/eclipse/jre/javafx-sdk-11.0.2/lib In addition, if it is desired to suppress unimportant warning messages: go to {S32DS installation folder}\eclipse\configuration, open logging.properties file and change com.nxp.swtools.level = SEVERE

This document shows the step-by-step process to create a simple blinking LED application for the S32R41 family using the S32 RTD AUTOSAR drivers. This example used for the S32R41 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R41 development package and the S32R41 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools. Launch S32 Design Studio for S32 Platform Procedure New S32DS Project OR Provide a name for the project, for example 'Blinking_LED_RTD_With_AUTOSAR'. The name must be entered with no space characters. Expand Family S32R41, Select S32R418AB Cortex-M7 Click Next Click '…' button next to SDKs Check box next to PlatformSDK_SAF85_S32R41_2022_08_S32R418AB _M7_0. Click OK And also, uncheck the other core Cortex_M7_1 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 BaseNXP driver as it is. Click on the ‘+’ next to the MCAL box. Locate and then select the ‘Dem’ component from the list and click OK. 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. No change is required for Dem configuration. Now, open the ‘DioGeneral’ tab, and select checkmark as per shown below: Now, open the ”DioConfig” tab. In that Select “+” sign adjacent to Dio Channel. Then Edit Name to “Digital_Output_LED_0” and Dio Channel Id to ‘4’ instead of ‘0’. From the schematic for S32R41 EVB, checking for signal line for the user LED, channel 4 is connected to user LED signal, so we use channel 4 for signal line for user LED on the chip. So, we select the signal line for Dio channel Id 4 for the LED connected on the S32R41 EVB. Now Select Port tab for Port configuration. And open the Port Configuration tab, and from that open “PortConfigSet” tab. Change the PortPin Mscr to 36 , 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,4 as per below configuration Now configure MCU component. Select Mcu component in MCAL, and then open the Mcu configuration. In Mcu configuration click MCUModuleConfiguration and then select “McuModesettingConf” from the dropdown menu as shown below. From McuModeSettingConf select McuPartitionConfiguration Now open “McuPartition0Config” tab. And under the McuCore0Configuration for “McuCoreClockEnable” select checkbox and for “McuCoreResetEnable” uncheck the checkbox. Similarly, And under the McuCore1Configuration for “McuCoreClockEnable” select checkbox and for “McuCoreResetEnable” uncheck the checkbox. After modification it should be as shown below: Now open the “McuPartition1Config” tab. for "McuPartitionClockEnable" select checkmark to true and for "McuPartitionResetEnable" uncheck the checkmark And under McuCore0Configuration for "McuCoreClockEnable" select checkmark to true and for "McuCoreResetEnable" uncheck the checkmark After modification it should be as shown below: Now, click on global setting icon as shown below: And, Confirm that ComponentGenerationMethod is set to “FunctionalGroups” 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, 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_0, STD_HIGH); TestDelay(3000000); Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED_0, 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" Now, in open peripheral tools again by clicking on icon as shown below. And then click on global setting icon as shown below: And, Confirm that ComponentGenerationMethod is set to “FunctionalGroups” 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 S32R41 device using the S32 RTD non-AUTOSAR drivers. For this example used for the S32R41 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R41 development package and the S32R41 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools. Launch S32 Design Studio for S32 Platform Procedure New S32DS Project OR Provide a name for the project, for example 'Blinking_LED_RTD_No_AUTOSAR'. The name must be entered with no space characters. Expand Family S32R41, Select S32R418AB Cortex-M7 Click Next Now, uncheck the selection mark for other core, i.e. for Cortex-M7-1 And Click '…' button next to SDKs Check box next to PlatformSDK_SAF85_S32R41_2022_08_S32R418AB _M7_0. (or whichever latest SDK for the S32R41 is installed). Click OK Click Finish. Wait for project generation wizard to complete, then expand the project within the Project Explorer view to show the contents. To control the LED on the board, some configuration needs to be performed within the Pins Tool. There are several ways to do this. One simple way by double-click on the MEX file. The schematic for S32R41 EVB, checking for signal line for the user LED, channel 4 is connected to user LED signal, so we use channel 4 for signal line for user LED on the chip. So, we select the signal line for Dio channel Id 4 for the LED connected on the S32R41 EVB. From the Peripheral Signals tab left to the Pins tool perspective layout, locate Open the Siul2_0 from the peripheral signals tab. And from the drop down menu select “gpio,36 PC_04” option as per shown in the following image. We are using PC_04 for the GPIO usage, so we are routing SIUL2_0 GPIO signal to this pin. The Direction required! menu will appear. Select Output then OK. In Routing Details view, notice a new line has been added and highlighted in yellow. Add ‘LED’ to the Label and Identifier columns for the PC_04 pin. Code Preview Go to Peripherals tool and add Siul2_Dio to enable LED blinking, it adjacent to the Blue LED on S32R41 EVB. Click on the Peripherals Tool icon from the Eclipse Perspective navigation bar. From the Components view, click on ‘Add a new configuration component…’ button from the Drivers category. This will bring up a list of all configuration components. Locate and then select the ‘Siul2_Dio’ component from the list and click OK. Do not worry about the warning message. It is only indicating that the driver is not already part of the current project. The associated driver package will be added automatically. Note: It may be necessary to change the selection at the top from ‘Present in the tool-chain project’ to ‘All’. The DIO driver provides services for reading and writing to/from DIO Channels. Also, select the Siul2_Port tab and uncheck the checkmark against ‘Siul2 IP Port Development Error Detect’ option as below. The Gpio_Dio driver requires no further configuration. Click Save to store all changes to the .MEX file. Now the device configurations are complete and the RTD configuration code can be generated. Click ‘Update Code’ from the menu bar. To control the output pin which was just configured, some application code will need to be written. Return to the ‘C/C++’ perspective. If not already open, in the project window click the ‘>’ next to the ‘src’ folder to show the contents, then double click ‘main.c’ file to open it. This is where the application code will be added. Before the pin can be controlled, it needs to be initialized using the configuration information that was generated from the S32 Configuration tools. Initialize all pins using the Port driver by adding the following line: Insert the following line into main, after the comment 'Write your code here': /* Initialize all pins using the Port driver */ Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0); Now, add logic for the LED turn and off. To turn the pin on and off with some delays in-between to cause the LED to blink. Make the delays long enough to be perceptible. Add line to initialize variable uint8 i = 0; Change the code within the provided for loop, and add the following lines: /* logic for blinking LED 10 times for (i=0; i<10; i++) { Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 1U); level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN); TestDelay(2000000); Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 0U); level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN); TestDelay(2000000); } return (0U); And add this line above the main() function to initialize the variable volatile uint8 level; Before the 'main' function, add a delay function as follows: void TestDelay(uint32 delay); void TestDelay(uint32 delay) { static volatile uint32 DelayTimer = 0; while (DelayTimer<delay) { DelayTimer++; } DelayTimer=0; } Update the includes lines at the top of the main.c file to include the headers for the drivers used in the application: Remove #include "Mcal.h" Add #include "Siul2_Port_Ip.h" #include "Siul2_Dio_Ip.h" Build 'Blinking_LED_RTD_No_AUTOSAR'. Select the project name in 'C/C++ Projects' view and then press 'Build'. After the build completes, check that there are no errors. Open Debug Configurations and select 'Blinking_LED_RTD_No_AUTOSAR_Debug_RAM'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist. Now, you need to Select the Interface (Ethernet or USB) by which the S32 Debug Probe is connected. If connected via USB and this option is selected for interface, then the COM port will be detected automatically (in the rare event where 2 or more S32 Debug Probes are connected via USB to the host PC, then it may be necessary to select which COM port is correct for the probe which is connected to the EVB) If connected via Ethernet, enter the IP address of the probe. See the S32 Debug Probe User Manual for ways to determine the IP address. Click Debug To see the LED blink, click ‘Resume'. This code, as it is, will blink the LED 10 times, you can make changes in for loop condition to blink it infinitely.

This document shows the step-by-step process to create a simple blinking LED application for the S32G family using the S32 RTD AUTOSAR drivers. This example used for the S32G-VNP-RDB2 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32G development package and the S32 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 S32G2, Select S3G274A_Rev2 Cortex-M7 Click Next Click '…' button next to SDKs Check box next to PlatformSDK_S32XX_2022_07_S32G274A_Rev2_M7_0. 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 the osif_1 driver as it is. Click on the ‘+’ next to the MCAL box. 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 ‘Dio’ 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 ‘DioGeneral’ tab, and select checkmark as per shown below: Now, open the ”DioConfig” tab. In that, select “+” sign adjacent to Dio Channel. Then edit Name to Digital_Output_LED and “Dio Channel Id” to ‘6’ instead of ‘0’. From the schematic for S32G-VNP-RDB2 EVB, we can select signal line based on your choice for the LED color for the multicolor RGB LED. Now, checking for blue user LED from the schematic, channel 6 is connected to blue LED signal, so we use channel 6 signal line to the chip on the blue LED. Similarly, so you can select signal line based on LED color you select. Now Select Port tab for Port configuration. And open the Port Configuration tab, and from that open “PortConfigSet” tab. Change the PortPin Mscr to 6 , PortPin Direction to PORT_PIN_INOUT. After change it should be as below. At the bottom you will find the “UnTouchedPortPin ’’ . Click on “+’’ and add PortPins. Now add 4 port pins as per below configuration. Pins 0, 1, 4, and 5 should be setup. Now configure MCU component. Select Mcu component in MCAL, and then open the Mcu configuration. In Mcu configuration select “McuModesettingConf” from the dropdown menu as shown below. Select ‘McuPartition0Config’ and deselect checkbox for CM7_0 Under MCU Control, CM7_1 Under MCU Control, CM7_2 Under MCU Control as marked below. And it should show as below Now select the Mcupartition1Config and uncheck checkmarks from the selection boxes as shown below 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. 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, which will enable the LED blinking for 10 times: First define the variable volatile uint8 level; globally above the main function. You also need to declare and initialize the loop variable uint8 i = 0U. Then replace the code as below: while (i++ < 10) { Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED, STD_HIGH); level = Dio_ReadChannel(DioConf_DioChannel_Digital_Output_LED); TestDelay(2000000); Dio_WriteChannel(DioConf_DioChannel_Digital_Output_LED, STD_LOW); level = Dio_ReadChannel(DioConf_DioChannel_Digital_Output_LED); TestDelay(2000000); } 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 is 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 S32G family using the S32 RTD non-AUTOSAR drivers. For this example used for the S32G-VNP-RDB2 EVB, connected via ethernet connection through S32 Debugger. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32G development package and the S32 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 S32G2, Select S32G274A_Rev2 Cortex-M7 Click Next Now, uncheck the selection mark for other two cores. Click '…' button next to SDKs Check box next to PlatformSDK_S32XX_2022_07_S32G274A_Rev2_M7_0. (or whichever latest SDK for the S32G is installed). Click OK Click Finish. Wait for project generation wizard to complete, then expand the project within the Project Explorer view to show the contents. To control the LED on the board, some configuration needs to be performed within the Pins Tool. There are several ways to do this. One simple way by double-click on the MEX file. By default, the Pins tool is then presented. For the Blinking LED example, one pin must be configured as output. The S32G-VNP-RDB2 EVB has an RGB LED for which each color is connect to a separate pin on the S32G-VNP-RDB2 EVB. For the blue LED the desired pin is PA_06. 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,6 PA_06” option as per shown in the following image. We are using PA_06 for the GPIO usage, so we are routing the SIUL2_0 GPIO signal to this pin. (This pin is also available for other modules like -FR, FTM, SPI_1) . 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 0 pin. Code Preview Go to Peripherals tool and add Siul2_Dio to enable LED blinking, it adjacent to the Blue LED on S32G-VNP-RDB2 EVB. Click on the Peripherals Tool icon from the Eclipse Perspective navigation bar. From the Components view, click on ‘Add a new configuration component…’ button from the Drivers category. This will bring up a list of all configuration components. Locate and then select the ‘Siul2_Dio’ component from the list and click OK. Do not worry about the warning message. It is only indicating that the driver is not already part of the current project. The associated driver package will be added automatically. Note: It may be necessary to change the selection at the top from ‘Present in the tool-chain project’ to ‘All’. The DIO driver provides services for reading and writing to/from DIO Channels. Also, select the Siul2_Port_1 tab and select the check mark against ‘Siul2 IP Port Development Error Detect’ option as below. The Gpio_Dio driver requires no further configuration. Click Save to store all changes to the .MEX file. Now the device configurations are complete and the RTD configuration code can be generated. Click ‘Update Code’ from the menu bar. To control the output pin which was just configured, some application code will need to be written. Return to the ‘C/C++’ perspective. If not already open, in the project window click the ‘>’ next to the ‘src’ folder to show the contents, then double click ‘main.c’ file to open it. This is where the application code will be added. Before the pin can be controlled, it needs to be initialized using the configuration information that was generated from the S32 Configuration tools. Initialize all pins using the Port driver by adding the following line: Insert the following line into main, after the comment 'Write your code here': /* Initialize all pins using the Port driver */ Siul2_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0); Now, add logic for the LED turn and off. To turn the pin on and off with some delays in-between to cause the LED to blink. Make the delays long enough to be perceptible. Add line to initialize variable uint8 i = 0; Change the code within the provided for loop, and add the following lines: //logic for blinking LED 10 times for (i=0; i<10; i++) { Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 1U); level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN); TestDelay(2000000); Siul2_Dio_Ip_WritePin(LED_PORT, LED_PIN, 0U); level = Siul2_Dio_Ip_ReadPin(LED_PORT, LED_PIN); TestDelay(2000000); } return (0U); And add this line above the main() function to initialize the variable volatile uint8 level; Before the 'main' function, add a delay function as follows: void TestDelay(uint32 delay); void TestDelay(uint32 delay) { static volatile uint32 DelayTimer = 0; while (DelayTimer<delay) { DelayTimer++; } DelayTimer=0; } Update the includes lines at the top of the main.c file to include the headers for the drivers used in the application: Remove #include "Mcal.h" Add #include "Siul2_Port_Ip.h" #include "Siul2_Dio_Ip.h" Build 'Blinking_LED_RTD_No_AUTOSAR'. Select the project name in 'C/C++ Projects' view and then press 'Build'. After the build completes, check that there are no errors. Open Debug Configurations and select 'Blinking_LED_RTD_No_AUTOSAR_Debug_RAM'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist. Now, you need to Select the Interface (Ethernet or USB) by which the S32 Debug Probe is connected. If connected via USB and this option is selected for interface, then the COM port will be detected automatically (in the rare event where 2 or more S32 Debug Probes are connected via USB to the host PC, then it may be necessary to select which COM port is correct for the probe which is connected to the EVB) If connected via Ethernet, enter the IP address of the probe. See the S32 Debug Probe User Manual for ways to determine the IP address. Click Debug To see the LED blink, click ‘Resume'. This code as it will blink the LED times, you can make changes in for loop condition to blink it infinitely.

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

Users can now get the AMMCLib for S32K3 in S32DS 3.4 if they manually add the following URL to the list of “Available S32DS Software Sites”: http://www.nxp.com/lgfiles/updates/Eclipse/AMMCLIB/S32DS_3.5 (the URL will be auto-added with the upcoming S32DS 3.5 release). From within S32 Design Studio for S32 Platform 3.4, launch S32DS Extensions and Updates menu (Help -> S32DS Extensions and Updates), then select 'Add Update Sites'. Please note that the S32K3XXMCLUG.pdf User’s Guide incorrectly indicates that the library is available as a standalone SDK, which is incorrect. AMMCLib for S32K3 is part of the “PlatformSDK” system which means that users must use the RTD for S32K3 in their S32DS project to gain access to AMMCLib: Then they must activate the „S32 Configuration Tool“ (CT): Within the CT, they must click on the „Peripherals“, then „Libraries“, and select „AMMCLib“ from the list: Then they must click on „Update code“, to update the paths in the project:

This document shows the step-by-step process to create a simple 'Blinking_LED' application using the S32K1xx RTD and the S32 Configuration Tools. This example is for the S32K144EVB-Q100 EVB, connected to a PC through USB (OpenSDA) connection. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32K1xx development package and the S32K1 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools. Launch S32 Design Studio for S32 Platform Procedure New S32DS Project OR Provide a name for the project, for example 'Blinking_LED_RTD_No_AUTOSAR'. The name must be entered with no space characters. Expand Family S32K1xx, Select S32K144 Under Toolchain, select NXP GCC 9.2 Click Next Click '…' button next to SDKs Check box next to PlatformSDK_S32K1_2022_02_S32K144_M4F. Click OK Click Finish. Wait for project generation wizard to complete, then expand the project within the Project Explorer view to show the contents. To control the LED on the board, some configuration needs to be performed within the Pins Tool. There are several ways to do this. One simple way by double-click on the MEX file. By default, the Pins tool is then presented. For the Blinking LED example, one pin must be configured as output. The S32K144 EVB has an RGB LED for which each color is connect to a separate pin on the S32K144 device. For the blue LED the desired pin is PTD0. From the Peripheral Signals tab in the view to the upper left in the standard Pins tool perspective layout, locate PORTD, then PTD0 and check the box next to it. 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 0 pin. Notice the changes which appear in the following views: Peripherals Signals Package Code Preview Go to Peripherals tool and add Gpio_Dio. 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 non-AUTOSAR components. Locate and then select the ‘Gpio_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. 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 anything else is done, initialize the clock driver. Insert the following line into main, after the comment 'Write your code here': Clock_Ip_InitClock(Clock_Ip_aClockConfig); Before the pin can be controlled, it needs to be initialized using the configuration information that was generated from the S32 Configuration tools. Initialize all pins using the Port driver by adding the following line: Port_Ci_Port_Ip_Init(NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0); Turn the pin on and off with some delays in-between to cause the LED to blink. Make the delays long enough to be perceptible. Within the provided for loop, add the following lines: Gpio_Dio_Ip_WritePin(LED_PORT, LED_PIN, 1U); delay(720000); Gpio_Dio_Ip_WritePin(LED_PORT, LED_PIN, 0U); delay(720000); Before the 'main' function, add a delay function as follows: voiddelay(volatileint cycles) { /* Delay function - do nothing for a number of cycles */ while(cycles--); } 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 "Port_Ci_Port_Ip.h" #include "Gpio_Dio_Ip.h" #include "Clock_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_FLASH'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist. Confirm the EVB is connected to the PC via USB cable, then check the Debugger tab settings and ensure that 'OpenSDA Embedded Debug - USB Port' is selected for interface. Click Debug To see the LED blink, click ‘Resume'

The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via GTA command line and the GDB. This instruction details the steps to perform flash programming of the S32R41 EVB via the JTAG interface with the S32 Debug Probe. Note: currently only QSPI flashing is supported. Preparation Setup the software tools Install S32 Design Studio IDE Install the Development Package for the device you are debugging. In this case, the S32R41 development package. This is important as the S32 Debugger support within it contains the device-specific Python scripts required for initialization of the cores. Setup the hardware Confirm the setup of the S32R41 evaluation board. Connect the power supply cable Setup the S32 Debug Probe Connect the S32 Debug Probe to the evaluation board via JTAG cable. Refer to the S32 Debug Probe User Manual for installation instructions. Connect the S32 Debug Probe to the host PC via USB, or Ethernet (via LAN or directly connected and configured for static IP address) and power supply connected to USB port. Launch S32 Design Studio for S32 Platform Create new or open existing project and check that it successfully builds. If creating a new project, be sure the S32 Debugger is selected in the New Project Wizard. Procedure Launch GTA server. From command prompt or Windows File Explorer run the command:{S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this: Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: Configure the EVB's Boot Mode switches for Serial Boot. Issue the following commands, replacing the PROBE_IP address and FLASH_NAME, as appropriate: source {S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/gdb_extensions/flash/s32flash.py py _FLASH_TYPE = "qspi" py _PROBE_IP="10.81.64.66" py _JTAG_SPEED=20000 py _GDB_SERVER_PORT=45000 py _GDB_TIMEOUT=7200 py _REMOTE_TIMEOUT=30 py _RESET_DELAY=1 py _RESET_TYPE="default" py _INIT_SCRIPT="{S32DS Install Path}/S32DS/tools/S32Debugger/Debugger/scripts/s32r41/s32r41_generic_bareboard.py" py _FLASH_NAME="W25Q64J" py _IS_LOGGING_ENABLED=False py flash() Note: Replace the {S32DS Install Path} in the commands above with the actual path to your installation of S32 Design Studio. Now flash commands may be used. fl_blankcheck -- blank check fl_close -- close command fl_current -- current device command fl_dump -- dump command fl_erase -- erase section of memory command, will erase whole sectors starting from 'offset' through 'size' contiguously, so to erase only one sector, ensure that the 'offset' address is within the desired sector and 'size' does not extend into the following sector fl_erase_all -- erase all memory command fl_info -- info command, shows list of registered devices fl_protect -- protect section of memory command fl_unprotect -- unprotect section of memory command fl_write -- write memory command, hex or binary are supported, options to erase first and verify after write fl_write_elf -- write elf file to memory command, options to erase first, verify after, and rearrange flash base Type 'help fl_<command>' to print the help info on the specified command Type 'help support' to print a list of the fl_ commands For example, you may wish to write a binary file: fl_write -e 0x0 C:\\Users\\<userid_folder>\\workspaceS32DS\\hello_world\\Debug_RAM\\hello_world_blob.bin Happy flashing with S32DS Flash Programmer!

The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the ability to access the flash programming and debugging of the S32 Debug Probe via GDB command line. This document provides only the necessary commands specific to launching a debug session on NXP devices. It does not cover general GDB command line operations, these are covered in detail in the GNU communities and other public websites which are not associated with NXP. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the Development Package for the device you are debugging. In this case, the S32R41 development package. This package is important as the S32 Debugger support component contains the device-specific Python scripts required for initialization of the cores. Setup the hardware Confirm the setup of the S32R41 evaluation board. Connect the power supply cable Setup the S32 Debug Probe. Refer to the S32 Debug Probe User Manual for installation instructions. Connect the S32 Debug Probe to the evaluation board via JTAG cable. Connect the S32 Debug Probe to the host PC via USB OR via Ethernet (via LAN or directly connected, and configured for static IP address) and power supply connected to USB port. Launch S32 Design Studio for S32 Platform Create new or open existing project and check that it successfully builds. If creating a new project, be sure the S32 Debugger is selected in the New Project Wizard Procedure As separate debug threads need to be started for each core to be debugged, and the method for launching a debug thread differs depending upon whether it is a primary core or secondary core and if the executable image will be loaded or if the executable is already running and the debugger just needs to be attached. These scenarios will be covered by the following 3 sections: Primary Core Load Image and Run: The application image will be loaded directly to memory by the debugger and then initialized and started. The primary core will launch any secondary cores used by the application. Secondary Cores: The primary core has launched a secondary core, it is now running and the debugger will connect through the attach method. Primary Core Image Already In Memory and Running: The primary core has already been initialized and launched by other means, such as via a Linux OS on the target, so the debugger will connect through the attach method without initializing or loading the image to memory. Please proceed with the section which applies to the core for which you are starting a debug thread. Primary Core Load Image and Run Prepare the initialization script for the core(s) to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32r41\s32r41_generic_bareboard_all_cores.py Uncomment the following lines: # _JTAG_SPEED = 16000 # _GDB_SERVER_PORT = 45000# _RESET_TYPE = "default" # _PROBE_IP = "s32dbg" # _CORE_NAME = 'M7_0' # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 110 # _IS_LOGGING_ENABLED = False # _SOC_NAME = "S32R41" This file is used by the S32 Debugger within the S32 Design Studio IDE where the settings are provided from the GUI, so these lines are commented out in order to allow the GUI settings to have control. The commented lines are provided so the script could more easily be run by the command line method. Update the IP address line (_PROBE_IP) to match the IP address of the S32 Debug Probe which is connected to your PC. See the user guide for the S32 Debug Probe for details on how to obtain the IP address. Update the core name (_CORE_NAME), if necessary. See s32r41_context.py for complete list of supported cores. Save the file with a new name to preserve the original. For example, s32r41_gen_bb_all_c_my_probe.py. This ensures the S32 Debugger will still function correctly. Launch GTA server. From command prompt or Windows File Explorer run the command: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this: Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32r41\\s32r41_gen_bb_all_c_my_probe.py This specifies the script for initialization. py board_init() This initializes the board. It should only be called for the initial core. In a multicore debugging workflow, the debugger launch for additional cores would omit this step. py core_init() This initializes the core specified in the initialization script in step 1. Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\New_S32R_Project_M7_0\\Debug_RAM\\New_S32R_Project_M7_0.elf load Secondary Cores After completing the launch of debug for the primary core, it is possible to perform multicore debug by launching GDB debugging on the secondary cores. Some additional steps will need to be performed from within the primary core GDB session, enter the following commands: set *0x34100000 = 0x34200000 set *0x34100004 = 0x34100025 set *0x34100024 = 0xFFFEF7FF b main c These lines prepare the environment for launching debugging on secondary cores. This will allow for multicore debugging in the case of separate ELF files for each core. These can be found in the Run Commands field of the Startup tab on the Debug Configuration for the primary core within S32 Design Studio IDE, of any multicore project created from the New Application Project Wizard. Note: If there is just one ELF file for all cores, then these 'set *0x... = 0x...' commands should be skipped. In general, it will be correct to set the break-point at main, as shown, but this might need to be changed depending on when the secondary cores are started within the project. Prepare the initialization script for the secondary core to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32r41\s32r41_attach.py This is a different script than the one used for the primary core. It is designed to launch a debug session on a core which is already initialized and running. Edit the script for the secondary core to be debugged. Since this script is setup for the primary core, some adjustments need to be made to setup for a secondary core Uncomment the following lines: # _JTAG_SPEED = 16000 # _GDB_SERVER_PORT = 45000 # _RESET_TYPE = "default" # _PROBE_IP = "s32dbg" # _CORE_NAME = 'M7_0' # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 110 # _IS_LOGGING_ENABLED = False # _SOC_NAME = "S32R41" Make the following changes to the lines: _JTAG_SPEED = 16000 -> None _GDB_SERVER_PORT = 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg" -> None _CORE_NAME = 'M7_0' -> 'M7_1' (this should be set to match the name of the core to be debugged, see s32r41_context.py for complete list) _RESET_DELAY = 1 _REMOTE_TIMEOUT = 110 _IS_LOGGING_ENABLED = False -> ‘True’ _SOC_NAME = "S32R41" Save the file with a new name to preserve the original. For example, s32r41_attach_my_probe_core1.py. This ensures the S32 Debugger will still function correctly. The existing GTA server is used, so do not launch a new one. Open an new command window and follow similar steps as done for the primary core. Setup the Python environment variable, if not done globally set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: From (gdb) prompt, enter the following commands (in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32r41\\s32r41_attach_my_probe_core1.py This specifies the script for initialization. We will not execute the py board_init() as this was already done for the primary core. py core_init() This initializes the core specified in the initialization script in step 2. Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\S32R_Multicore\\S32R_Multicore_M7_1\ \Debug_RAM\\S32R_Multicore_M7_1.elf load Primary Core Image Already in Memory and Running The core is running and does not need to be initialized. Prepare the initialization script for the core to be debugged. Open the core initialization Python script: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\scripts\s32r41\s32r41_attach.py This is a different script than the one used for the primary core. It is designed to launch a debug session on a core which is already initialized and running. Edit the script for the secondary core to be debugged. Since this script is setup for the primary core, some adjustments need to be made to setup for a secondary core Uncomment the following lines: # _JTAG_SPEED = 16000 # _GDB_SERVER_PORT = 45000 # _RESET_TYPE = "default" # _PROBE_IP = "s32dbg" # _CORE_NAME = 'M7_0' # _RESET_DELAY = 1 # _REMOTE_TIMEOUT = 110 # _IS_LOGGING_ENABLED = False # _SOC_NAME = "S32R41" Make the following changes to the lines: _JTAG_SPEED = 16000 _GDB_SERVER_PORT = 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg" -> (enter the IP address of your probe) _CORE_NAME = 'M7_0' (this should be set to match the name of the core to be debugged, see s32r41_context.py for complete list) _RESET_DELAY = 1 _REMOTE_TIMEOUT = 110 _IS_LOGGING_ENABLED = False -> ‘True’ _SOC_NAME = "S32R41" Save the file with a new name to preserve the original. For example, s32r41_attach_my_probe_core0.py. This ensures the S32 Debugger will still function correctly. Launch GTA server. From command prompt or Windows File Explorer run the command: {S32DS Install Path}\S32DS\tools\S32Debugger\Debugger\Server\gta\gta.exe Should see a window appear like this: Ensure Environment Variable for Python is set. From command prompt, run the command: set PYTHONPATH={S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7;{S32DS Install Path}\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Start GDB. In a command window, run the command: Windows OS: {S32DS Install Path}\S32DS\tools\gdb-arm\arm32-eabi\bin\arm-none-eabi-gdb-py.exe (for arm32) OR {S32DS Install Path}\S32DS\tools\gdb-arm\arm64-eabi\bin\aarch64-none-elf-gdb-py.exe (for arm64) Linux OS: arm-none-eabi-gdb-py A (gdb) prompt should now be displayed in the command window: From (gdb) prompt, enter the following commands(in this order): source {S32DS Install Path}\\S32DS\\tools\\S32Debugger\\Debugger\\scripts\\s32r41\\s32r41_attach_my_probe_core0.py This specifies the script for debugger initialization. Do not execute the py board_init() as this will initialize the board, and reset the currently executing application, which is not desired for this case. py core_init() This initializes the debugger connection to the core specified in the initialization script in step 1. Now standard GDB commands may be used. For example, you may wish to load an ELF file: file {S32DS Workspace Path}\\ New_S32R41_Project\\New_S32R41_Project_M7_0\\Debug_RAM\\New_S32R41_Project_M7_0.elf load After completing the launch of debug for the primary core, it is possible to perform multicore debug by launching GDB debugging on the secondary cores. See section ‘Secondary Cores’ for each additional core to be debugged.

Included in the Radar Software Development Kit (RSDK) is an example project ‘RSDK_S32DS_template’. This example shows an example radar application which uses the Arm Cortex-A53 and accelerators SPT, LAX and BBE32 DSP. The A53 core is used to execute the Linux application and launches the SPT, LAX, and BBE32 DSP cores. In this HOWTO, we will show how to load the project into the S32 Design Studio workspace and build. Debugging instructions, using the S32 Debugger and S32 Debug Probe are provided in separate documents for each accelerator. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32R4xx development package, the Radar extension package for s32R4xx, and the BBE32 DSP Add-On Package for S32R45. Install the ‘S32R45_RSDK_0.9.4_D2112’ last. It contains the ‘RSDK_S32DS_template’ example project. This package must be downloaded from the NXP website. If the .exe version is used, then the RSDK installer will install an XML file containing the install path of the RSDK into the S32 Design Studio installation directory. A prompt during the installation process will request the user to locate the S32DS installation directory. If the S32DS installation folder doesn’t exist, then it can’t be selected and the file will be missed. So, it is important to install this after installing S32 Design Studio and to use the .exe version. Once installed, S32 Design Studio will be able to locate the project from the New Project from Example wizard. If the .zip version is used, then the XML file must be updated manually and then placed in the S32DS installation folder. For example, with the 0.9.4 version of the RSDK: Locate the XML file in the RSDK installation folder. It is located in the base installation folder: "C:\NXP\S32R45_RSDK__0.9.4\swm.rsdk.s32r45.0.9.4.xml" Edit the following line by inserting the path to the RSDK: <variable name="RSDK_S32R45_0_9_4_DIR" value="${{RSDK_INSTALL_DIR}}" /> change to: <variable name="RSDK_S32R45_0_9_4_DIR" value="C:/NXP/S32R45_RSDK__0.9.4" /> Copy file to S32DS install folder. For example, if S32 Design Studio v3.5 installed: “C:\NXP\S32DS.3.5\S32DS\integration” Procedure Create the Project. Launch S32 Design Studio for S32 Platform and execute the following command: File -> New -> New S32DS Project from Example OR from the Dashboard Enter search text ‘rsdk’. The RSDK_S32DS_template project will be shown. Select it and click Finish. Examine the project Notice there are separate projects for each core. This project structure is due to the separate compilers, linkers, and assemblers required for each core type. When the A53 project is built, it will automatically build the other projects and then include the executable outputs into the A53 executable output. This way the code for all cores is loaded at one time and each core can be launched by the A53 core.

A vulnerability in the Apache Log4j was identified in the articles posted: CVE-2021-44228 and CVE-2021-45046 NXP has performed an analysis of this vulnerability with regard to the S32 Design Studio. Our conclusion is that the S32 Design Studio (all versions) is NOT IMPACTED. Although the Log4j is used by S32 Design Studio, the version used is 1.x and the vulnerability was introduced in version 2.12 with a combination of Java versions 9/10/11 where LDAP policy is enabled by default (CVE-2021-45046). The S32Design Studio installation environment is independent and based on Java 8 version, which is common for all tools running under S32Design Studio IDE. In addition, the S32 Design Studio does not use JMSAppender, so it is not affected by the identified log4j 1.x usage concern (CVE-2021-44228). When we determine an upgrade of the Log4j and/or Java version is required for a future release of S32 Design Studio, then this vulnerability will be addressed. Please see the attached presentation for details on other tools owned by NXP Automotive Processing Software Tools.

特集記事

S32 デザインスタジオ・ナレッジベース

S32 Design Studio Knowledge Base

ディスカッション

HOWTO Use OSEK OS Awareness with S32Debugger and PEMicro

HOWTO Use FreeRTOS OS Awareness with S32Debugger and PEMicro

HOWTO: Create a Blinking LED application project for S32M2xx using S32 RTD with AUTOSAR

S32Debugger Zephyr Thread Awareness User Manual

S32Design Studio 3.5 Tips and Tricks

Troubleshooting: Java Error When Config Tools Used From Command Line

HOWTO: Create a Blinking LED application project for S32R41 using S32 RTD AUTOSAR

HOWTO: Create a Blinking LED application project for S32R41 using S32 RTD No AUTOSAR

HOWTO: Create a Blinking LED application project for S32G using S32 RTD with AUTOSAR

HOWTO: Create a Blinking LED application project for S32G using S32 RTD No AUTOSAR

HOWTO : Install IAR Eclipse plug-in into S32 Design Studio 3.4

RAppID Bootloader rbf file for S32K116

RAppID Bootloader rbf file for S32K144W

Troubleshooting: Can't See AMMCLib for S32K3 in S32DS 3.4, S32DS Extensions and Updates

Troubleshooting: Incompatible JVM Error When Launching S32 Flash Tool v2.1

HOWTO: Create a Blinking LED example project using S32K1xx RTD without AUTOSAR

HOWTO: Command Line JTAG flash programming with S32 Debug Probe on S32R41 EVB

HOWTO: Command Line GDB Debugging with S32 Debug Probe for S32R41

HOWTO: Create New Project from Example ‘RSDK_S32DS_template’

S32 Design Studio and the Apache Log4j CVE-2021-45046 vulnerability

How To Download, Install, Activate and Use the S32 Design Studio

S32 Design Studio and the Apache Log4j CVE-2021-45046 vulnerability