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

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for ARM 2018.R1  Update 1          What is new? This update adds device support for S32K116  and installs the S32 SDK 1.8.7 EAR (Early Access Release) supporting the S32K116 (see attached S32K116 SDK release notes for more details) S32K116 EAR SDK v1.8.7 Examples - "Create S32DS Project from Example" Installation instructions The update is available for online (via Eclipse Updater) or offline installation (direct download link) online installation:  go to menu "Help" -> "Install New Software..." dialog  select predefined update site "S32DesignStudio - http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_ARM_2018.R1/updatesite" select all available items and click "Next" button   offline installation:   go to S32 Design Studio for ARM product page -> Downloads section or use direct link to download the update archive zip file Start S32DS and go to "Help" -> "Install New Software..." Add a new "Archive" repository and browse to select the downloaded update archive zip file you downloaded in the previous step Select all available items and click "Next" button.   This will starts the update installation process.

This document details how to create a new project and build using the existing code and makefile provided within the NXP Vision SDK example projects. If you are creating a new makefile project with code from any other source, the procedure may be different. Before creating a new makefile project from existing code we need to add some paths to the environment variable PATH and a couple of new environment variables. There are 3 main methods for adding these paths and variables. Which method depends upon your needs. Method 1 The paths and variables can be added to each project individually. This is useful if you only want these changes to affect a small number of projects. Or if your projects require different paths and variables. Method 2 The paths and variables can be added to the entire workspace within S32DS . These will not be visible outside of S32DS and therefore will not affect the entire Windows environment. This is useful if you have a large number of projects with common requirements for paths and variables and do not want them visible any tools outside of S32DS. Method 3 The paths and variables can be added globally to the Windows environment and will affect all installed tools. This method is not recommended. Add the following paths to the PATH variable (assuming the default installation settings for S32DS for Vision were used): C:\NXP\S32DS_Vision_v2018.R1\Cross_Tools\gcc-6.3-arm64-eabi\bin C:\NXP\S32DS_Vision_v2018.R1\Cross_Tools\gcc-6.3-arm64-linux\bin C:\NXP\S32DS_Vision_v2018.R1\Cross_Tools\gcc-6.3-arm32-eabi\bin C:\NXP\S32DS_Vision_v2018.R1\utils\msys32\mingw32\bin It is also necessary to add the following Windows system variables: Variable Name: S32V234_SDK_ROOT Variable Value: C:\NXP\S32DS_Vision_v2018.R1\S32DS\s32v234_sdk Variable Name: APU_TOOLS Variable Value: C:\NXP\S32DS_Vision_v2018.R1\S32DS\APUC Now we are ready to create the new project. 1) Launch S32DS for Vision 2) Click New 3) Select 'Makefile Project with Existing Code' 4) Select Next 5) For 'Existing Code Location', select 'Browse...' and then select the directory  C:\NXP\S32DS_Vision_v2018.R1\S32DS\s32v234_sdk\demos\isp\isp_sonyimx224_rgb_yuv_gs8 6) Click OK 7) For 'Toolchain for Indexer Settings', select the option which matches your desired build configuration. Select:    Linux builds: 'Standard S32DS Linux toolchain for ARM Cortex-A'    Standalone builds: 'Standard S32DS toolchain for ARM Cortex-A' This sets up some toolchain paths, but later we will set more for the specific needs of the VSDK examples. 😎 Click Finish 9) Change to C/C++ perspective, click on 'Switch to C/C++ Development' 10) Right-click on the project from the Project Explorer. Select Properties 11) Go to section 'C/C++ Build' and make sure that Generate Makefiles automatically is unchecked:  12) Go to the 'Behavior' tab and in the field next to 'Build', enter:    ISP examples: 'allsub'    APEX examples: 'APU_COMP=nxp allsub' 13) In the field next to 'Clean', enter 'clean' 14) Go to 'Builder Settings' tab, in 'Build location' section change the path for the 'Build directory'. Click on 'Workspace...' button 15) In the Folder selection menu, select the subfolder 'build-v234ce-gnu-linux-d' and click OK 16) Go to section 'Environment' 17) Select the environment variable 'PATH' and click 'Edit...' 18) Add the paths to the value field, each separated by a comma ';' C:\NXP\S32DS_Vision_v2018.R1\Cross_Tools\gcc-6.3-arm64-eabi\bin C:\NXP\S32DS_Vision_v2018.R1\Cross_Tools\gcc-6.3-arm64-linux\bin C:\NXP\S32DS_Vision_v2018.R1\Cross_Tools\gcc-6.3-arm32-eabi\bin C:\NXP\S32DS_Vision_v2018.R1\utils\msys32\mingw32\bin Click OK 19) Click 'Add...' 20) Enter the variable name 'S32V234_SDK_ROOT' and value 'C:\NXP\S32DS_Vision_v2018.R1\S32DS\s32v234_sdk' Click OK 21) Click 'Add...' again and this time enter variable name 'APU_TOOLS' and value 'C:\NXP\S32DS_Vision_v2018.R1\S32DS\APUC' Click OK 22) Click OK to close the Properties menu. 23) Click on 'Build' 24) Once the build is complete, the binary file (ELF) will be created If you like to create release version - add another build configuration and select release build folder. Right click on project name->Properties:  Switch configuration to Release and select build folder:  Exclude release build when Default (you can rename it to Debug) configuration is selected and vice versa.  Right click on Release build folder (that one which ends with -o). Choose Resource configuration and select exclude from build:  Right click on Debug build folder (that one which ends with -d) -> Resource Configuration -> Exclude from build and select Release:  Select Build target to Release and build it: 

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

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

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

Requirements:  SD card with installed Linux image connected to EVB (HOWTO: Prepare A SD Card For Linux Boot Of S32V234-EVB Using BSP From VSDK ) Serial link connection between PC and EVB (HOWTO: Setup A Remote Linux Connection in S32DS for Vision ) Static IP address on PC machine Network connection between PC and EVB Use case: This settings is useful when you don't have DHCP server available or for some reason you can't connect EVB into existing network - like on this scenario:  Procedure: Setup static IP address on your PC machine - (Windows 7) click on Start -> Control Panel -> Network and Sharing center. On the left side click on "Change adapter settings" Select network interface connected to EVB ( Local area connection ) and choose "Internet protocol Version 4 (TCP/IPv4)" option and click on Properties button.   Select "Use the Following IP address" radio button and enter IP address for PC side of network connection and click on OK button.    Turn on EVB and connect to EVB via serial link using putty or any other terminal (115200 baud, 8N1). Login as the root user. Edit network interfaces configuration file by command vi /etc/network/interfaces and modify (press INS key to switch vi editor to edit mode) the file by the way as shown on next screenshot. Set IP address from range of your PC machine network settings.  Save new settings by :w command (press ESC key to switch vi editor to command mode) and exit from vi by :q command. Restart network by command /etc/init.d/networking restart  Check the IP address by command ifconfig and try ping to your PC machine.  Troubleshooting: If you can't ping to PC machine and IP address is the same as you requested - check IP address on PC side and cable connection.  If the IP address on EVB is different than you requested - check if you commented out the dhcp configuration. You may also try to reboot EVB instead of restarting network only. 

      Product Release Announcement Automotive Processing S32 Design Studio v3.4 S32K1 Service Pack 1         Austin, Texas, USA Jun 25, 2021  The Automotive Processing' Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the S32 Design Studio v3.4 - S32K1 Service Pack 1. Here are some of major features:​ Support for S32K1 family is updated for latest version of RM and S32K144W 1.1  SDK migration tools for projects created with S32DS for ARM S32 SDK for S32K1xx RTM 4.0.2 included Update is available for online install on update site and for download on flexera. Note that Update 1 (S32DS Platform Package version 3.4.1 and S32DS Platform Tools package version 3.4.1) is required for this Service pack. It is included into archive for download. Installation instructions The update is available for online (via Eclipse Updater) or offline installation   online installation:  go to menu "Help" -> "S32DS Extensions and Updates" dialog  select from available items and click "Install/Update" button   offline installation:   go to S32 Design Studio product download page: S32 Design Studio for S32 Platform -> Downloads, click 'Download' button next to S32 Design Studio S32K1xx Service Pack 1 from the Product Information page, select S32 Design Studio for S32 Platform v3.4 then select 'SW32K1_S32DS_3.4.1_D2106.zip' to download the update archive zip file Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates" Add the downloaded archive as a software site. Click "Add Software Site" and browse to select the archive file downloaded in the prior step        Select from available items and click "Install/Update" button. This will start the update installation process.   Technical Support please use public community for questions https://community.nxp.com/community/s32/s32ds  

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.

The list of S32 Design Studio examples has been moved here: https://community.nxp.com/docs/DOC-341380  S32K144 EXAMPLE: S32K_printf_implementation - S32DS  EXAMPLE: S32k144 UART printf/scanf under FreeRTOS - S32DS  EXAMPLE: S32K SDK  - Function call on configurable period using LPIT timer.  EXAMPLE: FlexNVM used as code/data flash  EXAMPLE: S32K144 EEEPROM usage  EXAMPLE: S32K144 EEEPROM usage - No SDK  EXAMPLE: S32K144 .noinit section usage  For more examples and how to's: S32K1xx document & example list

Hello, the new release of S32DS for ARM v1.3 is available now in the download section of S32DS web page: http://www.nxp.com/s32ds   The Activation code is required to install the product. The activation code is different to previous versions (v1.1/1.2). You should get the appropriate Activation Code by a notification email which is send automatically when you proceed to the downloading: What is new?  New device supported: S32K144 v2.0 ARM64: Linaro GCC 4.9-2015.05 Fully integrated S32 SDK for S32K144 EAR release v0.8.2. including PinMuxing and Processor Expert configuration. FreeMASTER Serial Communication driver for S32K144 family  Highly Assembly Optimized version of Automotive Math and Motor Control Libraries for KEA and S32K devices v1.1.6  IAR debugger support by new project wizard Updated SEGGER and P&E debug plugins to the latest and greatest versions Reset functionality added with P&E debugger for single core projects (KEA, S32K devices) and A5 core for MAC57D54H Flash configuration supported for S32V234 Header files for KEA and MAC57D54H updated Advanced FreeRTOS kernel aware debug support Bug fixes Project Explorer updated to correctly show active build configuration resources     Note: The plugins to support GreenHills, IAR, iSystem, Lauterbach are not included and have to be installed from corresponding update site or installation.

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.

DCD(short for Device Configuration Data) is the configuration information that BootROM uses to configure the peripherals on the device. This video will explain using S32V how DCD works and create a simple example to have RUN1 as default run mode.

This document details the steps to program external EEPROM with the 32 reset configuration bits in support of the 'Boot from serial RCON' method detailed in the S32G Reference Manual. The Python scripts used for this task are designed and tested to work on the S32G-VNP-EVB with S32G2xx Rev2 and the Atmel AT24C01C it contains.(Serial EEPROM is not implemented on NXP VNP-RDB board)   The RCON can be set by the following: Fuses (internal to the device) Parallel (GPIO pins/DIP Switches on EVB) Serial (EEPROM connected via I2C) The Serial option can be programmed using a debug probe connected via JTAG. This enables the RCON to be controlled remotely, assuming the debug probe is setup to allow remote connections.    Preparation Install S32 Design Studio IDE  Install the Development Package for the device you are debugging. This is important as the S32 Debugger provides access to the EEPROM programming capabilities via I2C of the S32 Debug Probe.  Connect the S32 Debug Probe to the S32G-VNP-EVB and the host PC containing S32 Design Studio installation. Set BOOTMOD pins to boot from RCON Set BOOT_CFG[8]=1 on the S32G-VNP-EVB, for serial RCON mode VNP-EVB shown here with switch BOOT_CFG[8] = 0 See the EVB documentation and device reference manual for more details. Procedure   Open cmd window to the S32 Debugger folder where the device-specific scripts are located. C:\NXP\S32DS.3.4\S32DS\tools\S32Debugger\Debugger\scripts\s32g2xx Set Python path so correct version is used (if not already set in env vars) set PYTHONPATH=C:\NXP\S32DS.3.4\S32DS\build_tools\msys32\mingw32\lib\python2.7;C:\NXP\S32DS.3.4\S32DS\build_tools\msys32\mingw32\lib\python2.7\site-packages Edit the python script to adjust the value to be programmed to RCON, s32g2xx_i2c_RCON.py. Note: The listed examples show only the minimum values required to configure each of the external memory types. Additional settings may be required for your specific application. Adjust the RCON_DATA for the configuration you wish to program.  Do not adjust RCON_ADDR. Adjust the S32DBG_IP for the IP address of your S32 Debug Probe.  Adjust the INTERACTIVE_MODE  Set True, if desired to be prompted to enter RCON_DATA Set False, if desired to have script automatically enter RCON_DATA, based on the value set within the file. Adjust _SOC_NAME as appropriate for the specific S32G2xx device you are using. The valid options are defined in s32g2xx_context.py. Enter the command to start GDB, passing in the RCON Python script: Windows OS: C:\NXP\S32DS.3.4\S32DS\build_tools\gcc_b1620\gcc-6.3-arm32-eabi\bin\arm-none-eabi-gdb-py.exe -x s32g2xx_i2c_RCON.py OR C:\NXP\S32DS.3.4\S32DS\build_tools\gcc_v9.2\gcc-9.2-arm32-eabi\bin\arm-none-eabi-gdb-py.exe -x s32g2xx_i2c_RCON.py Linux OS: arm-none-eabi-gdb-py -x .\s32g274a_i2c_RCON.py If everything worked properly, then the value you programmed will be displayed to the screen. To exit GDB, enter 'quit'.

The list of S32 Design Studio examples has been moved here: https://community.nxp.com/docs/DOC-329623  MPC5644A Example MPC5644A BookE PinToggle - S32DS Power 2017.R1 MPC5744P Example MPC5744P PinToggleStationery S32DS_1.0  Example MPC5744P LINFlex UART with DMA S32DS_1.0  Example MPC5744P ETimerCountMode S32DS_1.0  MPC5777M Example MPC5777M PinToggleStationery S32DS_1.0 Processor Expert RAppID Suite for MPC5777M and S32 Design Studio Integration Multicore Example  MPC5775K Example MPC5775K PinToggleStationery S32DS_1.0  Example MPC5775K-DMA_Transfer S32DS_1.0  Example MPC5775K UART_with_DMA S32DS_1.0  Example MPC5775K-UART_with_Interrupts S32DS_1.0  Example MPC5775K FlexCAN_with_interrupts_v1.1 S32DS_1.1  Example MPC5775K Semaphores S32DS_1.0  Example MPC5775K eTimer_PWM S32DS_1.0  Example MPC5775K ADC_example S32DS_1.0  Example MPC5775K IIC Communication with RTC PCA8565TS/1 S32DS_1.0  Example MPC5775K DSPI_with_interrupts S32DS_1.0  MPC5748G Example MPC5748G-FlexCAN_with_interrupts S32DS_1.0  Example MPC5748G PretendedNetworkingCAN S32DS_1.0  MPC5746R Example MPC5746R FlexCAN_with_interrupts S32DS Example MPC5746R PinToggleStationery - S32DS Power 2017.R1 S32R274 Example S32R274 FlexCAN_with_Interrupts S32DS_1.1  Example S32R274 Watchdog_example S32DS_1.1  Example S32R274 multi-core shared memory - S32DS Power v1.2  MPC5777C Example MPC5777C Single ELF multi-core Pin Toggling - S32DS Power v1.2

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture 2017.R1 Update 9          What is new? S32 SDK for Power Architecture 2.0.0 RTM supporting  MPC5741P, MPC5742P, MPC5743P, MPC5744P, MPC5744B, MPC5745B,  MPC5746B, MPC5744C, MPC5745C, MPC5746C, MPC5747C, MPC5748C, MPC5746G, MPC5747G, MPC5748G, S32R274, S32R372 (see the S32 SDK release notes) AMMCLIB version 1.1.14 (see the AMMCLIB MPC574xP example release notes) Radar SDK RTM, version 1.2.0 (see the RSDK release notes) This is a cumulative update - it includes all of the content of previous updates (Update 1, Update 2, Update 3, Update 4, Updates 5 and 6, Update 7, Update 8 ). Installation instructions The update is available for online installation (via S32DS Eclipse Updater) or offline installation (direct download link)  installation:  go to menu "Help" -> "Install New Software..." dialog  select predefined update site "S32DesignStudio - http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_POWER_2017.R1/updatesite" select all available items and click "Next" button offline installation:   go to S32 Design Studio for Power product page -> Downloads section or use direct link to download the update archive zip file Start S32DS and go to "Help" -> "Install New Software..." Add a new "Archive" repository and browse to select the downloaded update archive zip file you downloaded in the previous step Select all available items and click "Next" button.   This will start the update installation process.

S32 Design Studio (S32DS) for Power architecture supports PLS UDE Eclipse plug-in to debug S32DS projects via a PLS probe directly in S32DS Eclipse IDE. This feature is supported by all versions of S32DS for Power.   This plug-in supports the features below: Seamless integration of complete functionality of Universal Debug Engine inside of the Eclipse IDE UDE provides an own perspective of the Eclipse IDE and integrates UDE workspace in Eclipse workspace Code breakpoint can be set either by C/C++ editors or by UDE specific functions For more details about the plugin read  "UDE Eclipse datasheet" located in the download section of PLS web site.   Installation instructions First of all make sure you have PLS UDE debugger installed on your computer. Then let's proceed to eclipse plug-in installation.   1. go to menu "Help" -> "Install New Software" and  click on "Add..." button and search PLS UDE installation folder for the archive file named "UDEEclipse4Integration.zip" 2. select the Universal Debug Engine component and click "Next"     3. Finally you proceed to the installation. You will be asked to confirm installation of unsigned content. The UDE plugin requires restart after the installation.     Create a new project with UDE  You should be able to create a new S32DS project via S32DS new project wizard where PLS UDE Debugger support is now available. The UDE plugin enables a new group of UDE eclipse debug configurations to manage (create, delete, adjust) The UDE debug configuration created with a new project requires some changes before you can proceed to debugging. 1. Enter a new UDE workspace name under "<Project>\.ude" folder by clicking on "New Workspace" button 2. Create a new UDE Target configuration file. click on "Create Configuration" button and select "Use a default target configuration" and your target MCU. (in this example MPC5744P). Save the configuration file into your project folder e.g. "<Project>\Project_Settings\Debugger\nxp_mpc5744p_cut2_debug_jtag.cfg" Running the debugger opens UDE specific debug eclipse view where you can benefit from many advanced debugging features including tracing, scripting... Enjoy debugging with PLS UDE Eclipse plug-in in S32DS!

Bare-metal project migration from an older version of S32DS into a newer one is typically pretty straightforward. Despite of that the migration into S32DS Power v1.2+ requires more attention due the fact it includes a new version of GCC compiler + GCC binutils (see the GCC release notes - here). This version of GCC is now fully EABI VLE compliant  (in contrast to previous versions of S32DS Power  v1.0 and v1.1) and it has several consequences for the project migration object code/libraries are not backward compatible - if you have an object code/library built by a previous version of S32DS Power v1.x you have to rebuild it in new S32DS v1.2+ compiler. default compiler setup has changed - bitfield access is not volatile anymore. This may have a impact on a peripheral registers access via standard header file bitfield structures. Such access may require a specific load/store instruction e.g. "stw" but if compiler is allowed to optimize the access (e.g. use "stb" instead of "stw") an exception may occur. Therefore it is recommended to add  -fstrict-volatile-bitfields  flag into your project GCC compiler settings: linker script file (*.ld) requires some additional linker sections - Linker script file in S32DS Power v1.2+ must contain the sections below: •  KEEP for .init and .fini sections • .ctors and .dtors sections • .preinit array .init array and .fini array sections If the linker script file is not updated and the linker warnings are ignored you may experience an exception at the runtime - typically when __init routine is executed. Missing .init section causes that an invalid instructions is fetched and causes the core IVOR exception. There is an easy way how to automatically fix the linker script file issue directly in IDE. If you import and build an older project in S32DS Power v1.2 the linker issues these linker script related warnings: Right click on the warning and select Quick Fix: Select "Add missed section in linker script"  + "Select All" and press "Finish". Repeat these steps until all the linker script warnings disappears. If you don't use IDE project you have to add the sections below into your linker script manually: .text_vle : { INPUT_SECTION_FLAGS (SHF_PPC_VLE) *(.text.startup) *(.text) *(.text.*) KEEP (*(.init)) KEEP (*(.fini)) . = ALIGN(16); } > m_text /* that will force pick VLE .text sections */ .ctors : { __CTOR_LIST__ = .; /* gcc uses crtbegin.o to find the start of the constructors, so we make sure it is first. Because this is a wildcard, it doesn't matter if the user does not actually link against crtbegin.o; the linker won't look for a file to match a wildcard. The wildcard also means that it doesn't matter which directory crtbegin.o is in. */ KEEP (*crtbegin.o(.ctors)) KEEP (*crtbegin?.o(.ctors)) /* We don't want to include the .ctor section from from the crtend.o file until after the sorted ctors. The .ctor section from the crtend file contains the end of ctors marker and it must be last */ KEEP (*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) __CTOR_END__ = .; } > m_text .dtors : { __DTOR_LIST__ = .; KEEP (*crtbegin.o(.dtors)) KEEP (*crtbegin?.o(.dtors)) KEEP (*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) __DTOR_END__ = .; } > m_text .preinit_array : { PROVIDE_HIDDEN (__preinit_array_start = .); KEEP (*(.preinit_array*)) PROVIDE_HIDDEN (__preinit_array_end = .); } > m_text .init_array : { PROVIDE_HIDDEN (__init_array_start = .); KEEP (*(SORT(.init_array.*))) KEEP (*(.init_array*)) PROVIDE_HIDDEN (__init_array_end = .); } > m_text .fini_array : { PROVIDE_HIDDEN (__fini_array_start = .); KEEP (*(SORT(.fini_array.*))) KEEP (*(.fini_array*)) PROVIDE_HIDDEN (__fini_array_end = .); } > m_text‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ This may help you to avoid time consuming debugging to figure out the root cause of the core exception. 

When a new application project is created using the New Project Wizard, it is possible to select the debugger to be used. This results in the associated debugger configurations being created within the new project. But what if support for multiple debuggers is required or it is desired to switch to a different debugger? There are easy ways to resolve this. One is as simple as creating a new debug configuration. Another method is by creating new application project, selecting the new debugger to be supported. Then either repurposing the associated debug configuration or duplicating then modifying the debug configuration to support instead the previously existing project. This minimizes the effort by benefiting from the automation of the New Project Wizard.   Detailed below are the steps to add a new debug configuration.  Create A New S32 Debugger Configuration Load the existing project. For this demonstration, the SDK project ‘hello_world_s32v234’ will be used. Select the project so it appears highlighted in blue. Notice that the other project, ‘New_App_Project’, is bold text. This is because the main.c file open in the editor window to the right is the currently selected source file and is from this project. This has no effect on the process detailed in this document. Check that the existing project has been build and the executable is present. If the executable is not present, then an error will be displayed within the Debug Configurations menu and the executable file will need to be selected in a later additional step after it has been created. Open the Debug Configurations menu. Run -> Debug Configurations   Now select the Debugger Group for which you wish to create the new configuration. In this case, we will select ‘S32 Debugger’. Next, click ‘New Launch Configuration’ Now a new Debug Configuration has been created for your project and for the S32 Debugger. Most of the fields are already completed for you. Select the Debugger tab to see the source of the error message. The error message indicates ‘Specify Device and Core’. So click on ‘Select device and core’. Now expand the lists until the Device and Core are visible. Select the correct core for your project. In the demonstration example, the correct Device and Core are ‘S32V234’ and ‘M4’, respectively. Click OK, when done. If you have a debug probe connected, it may have been detected. If not, the Debug Probe Connection section will need to be completed. Now select the ‘Common’ tab to setup the storage location for this new Debug Configuration. Select ‘Shared file’ and then ‘Browse…’ Expand the lists until ‘Project_Settings/Debugger’ is open. Select ‘Debugger’, then click OK. Now the basic debug configuration settings are complete. It is now ready to be used and the Debug button could be clicked to start debug. Otherwise, you may have more customizations to make, such as for Attach Mode. Repurpose S32 Debugger Configuration From A New Project Create new project New -> S32DS Application Project New Project Wizard, processor and toolchain page Enter a project name Select the device and core to match the existing project If necessary, select the toolchain to match the existing project Click Next New Project Wizard, cores and parameters page Select the number of cores to match the existing project Select the debugger, S32 Debugger If necessary, select other parameters to match the existing project Click Finish   Open existing project which does not already have the S32 Debugger debug configurations (for this demonstration, we will use the hello_world_s32v234 example project from the S32 SDK) Copy debug configurations and modify settings to adapt to existing project Run -> Debug Configurations... Debug Configurations window Within the S32 Debugger grouping, select the debug configuration for the new project which corresponds to the build configuration and core of the existing project Change the name of the debug configuration. Change the portion of the name containing the project name to match the name of the existing project. Main tab Project field Click Browse... Select existing project C/C++ Application Click Search Project... Select the Elf file Common tab Save as field Click Browse... Select {existing_project_name}\Project_Settings\Debugger Debugger tab, Debug Probe Connection Setup connection parameters Click Apply Repeat as needed for all core/build config options The existing project now has the S32 Debugger configurations and is ready for debug with the S32 Debug Probe.

The ability to reset target MCU via debugger (also known as "in-target reset") is one of the essential feature when it comes to e.g. debugging of a code that is getting into an Exception/Fault Handler or situations like "...why my code works fine in the debugger, but fails without debug..." S32 Design Studio offers this feature for all Pemicro debug interfaces (Multilink Universal/FX, OpenSDA) and it is available in all S32 Design studio flavors (S32DS ARM, S32DS Power, S32DS Vision) Reset button icon is active only in the active debug session (debug perspective) and in the root debug context only.  By default the reset icon is inactive during project debugging: To activate the reset icon change the Debug view context to the root one. After reset is completed the execution stops at the application reset vector and the information about reset that has just occurred is displayed in GDB server console. It is also possible to execute initialization script (.mac) which is triggered by the reset action. The reset script can be selected in the  Debug Configuration (Debugger Tab -> Advanced Options -> Enable Initialization Script) For more information about initialization scripting capabilities please contact www.pemicro.com