To install updates and additional packages to S32 Design Studio: 1) Download the Update from the S32 Design Studio page at NXP.com. 2) From S32 Design Studio, got to Help – S32DS Extensions and Updates. 3) Click on ‘Manage Sites’ link. 4) Select 'Add...' 5) Select 'Archive...', locate the downloaded update: 6) Click OK. 7) Click Apply and Close on the Preferences menu 😎 Notice the S32DS Extensions and Updates menu displays the new content. 9) Check the box next to the new package and click Install/Update. 10) Accept license terms and click Finish. 11) After the installation is complete, restart S32 Design Studio.

How to Download, Install, Activate and 1st time use of S32 Design Studio 3.6.0

Installation & Activation HOWTO: Activate S32 Design Studio  HOWTO: Install Lauterbach TRACE32 debugger plug-in into S32 Design Studio  Create a New Project  HOWTO: Create APEX2 Project From Example in S32DS for Vision  HOWTO: Create An ISP Project From Example in S32DS for Vision  HOWTO: Create A53 Linux Project in S32DS for Vision  HOWTO: Create An ISP Project From Existing VSDK Graph in S32DS for Vision  HOWTO: Create A New Makefile Project With Existing Code From NXP Vision SDK Example Project   HOWTO: Build a Project and Setup a Debug Configuration for debugging in S32 Design Studio  HOWTO: Create A53 APEX2 and/or ISP Linux Project in S32DS for Vision DDR Configuration & Validation and Stress Test Tools HOWTO: Use DDR Configuration and Validation Tool  HOWTO: Use DDR Stress Test Tool  Hardware Setup HOWTO: Setup S32V234 EVB for debugging with S32DS for Vision and Linux BSP HOWTO: Prepare and boot S32V234 EVB from eMMC  HOWTO: Setup static IP address for S32 debug probe  Debugging HOWTO: Setup S32V234 EVB for debugging with S32DS for Vision and Linux BSP  HOWTO: S32V234-EVB debugging with Linux and gdbserver on target machine  HOWTO: Start Debug on an ISP Application Project with S32 Debugger and S32 Debug Probe  HOWTO: Start Debug on an APEX2 Application Project with S32 Debugger and S32 Debug Probe  Debugging the Startup Code with Eclipse and GDB | MCU on Eclipse   VSDK HOWTO: Change Vision SDK root in S32DS for Vision  HOWTO: Create A New Makefile Project With Existing Code From NXP Vision SDK Example Project  HOWTO: Prepare A SD Card For Linux Boot Of S32V234-EVB Using BSP From VSDK  Linux HOWTO: S32V234 EVB Linux - Static IP address configuration  HOWTO: S32V234 EVB Linux - DHCP IP address setup  HOWTO: Prepare A SD Card For Linux Boot Of S32V234-EVB Using BSP From VSDK  HOWTO: Access Linux BSP file system on S32V234-EVB from S32DS for Vision HOWTO: Setup A Remote Linux Connection in S32DS for Vision  General Usage HOWTO: S32 Design Studio Command Line Interface  HOWTO: Add user example into S32DS  HOWTO: Generate S-Record/Intel HEX/Binary file  HOWTO: Update S32 Design Studio  Troubleshooting Help! I just relaunched S32DS for Vision and my visual graph is collapsed!  Help! I just updated to new version of S32DS and now my projects have errors and I can't build!  Troubleshooting: PEmicro Debug Connection: Target Communication Speed  Troubleshooting: Indexer errors on header file  S32 Design Studio Offline activation issue hot fix  https://community.nxp.com/docs/DOC-345238 

If your EVB with OpenSDA debugger can't start debug session - you can try to update OpenSDA firmware on your board.  Go to PE Micro web pages - http://www.pemicro.com/opensda/ and get the latest firmware archive.  Extract .SDA file related to your EVB - for example            DEBUG-OPENSDA-E200_Pemicro_v110.SDA for DEVKIT-MPC5748G            MSD-DEBUG-EVB-S32K144_Pemicro_v119.SDA for S32K144EVB  Press and hold SW3 (Reset for S32K144EVB) button and connect OpenSDA connector on EVB to PC. New BOOTLOADER Drive should appear on your PC.  Copy .SDA file in BOOTLOADER drive Reset EVB.   More details you can find in "Updating the OpenSDA Firmware.pdf" file. It is part of downloaded zip file from PE Micro web pages. 

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

PEmicro’s debug configuration allows user to modify JTAG communication shift frequency between debug interface and the target. By default, this frequency is set to a maximum value of 5000KHz, to take advantage of the fastest run control and FLASH programming experience: At the same time, not every PowerPC processor might be able to support highest debug shift frequencies with all PEmicro debug interfaces. For example, debug frequency for MPC5634M board used in conjunction with Multilink Universal FX RevC , needs to be lowered to 4000Khz in order to succeed. Hence, if debug session fails to successfully start up or fails on FLASH programming, lowering a debug shift frequency by a factor of 2 or 4 is the first trouble shooting recommendation. To get to PEmicro’s debug configuration window, one should select “Debug Configuration” from the menu next to a debug icon, and switch over to the Debug tab, within “Debug Configuration” menu pop- up.

The Image Vector Table (IVT) image is a set of pointers to other images which are required by the BootROM. It typically contains the following images, though not all are required to create a valid IVT image: DCD Self-Test DCD HSE Application Bootloader The IVT Tool enables configuration and generation of the IVT image as specified in the BootROM reference manual. Prerequisites Before using the IVT Tool, it will be useful to have already generated the binary image from your application project, it will be an input to the IVT. It may also be necessary to include a DCD image, for example, to initialize the SRAM. For application bootloader image, follow the steps in HOWTO: Generate S-Record/Intel HEX/Binary file, selecting 'Raw binary' option. For DCD image, follow the steps in HOWTO: Use DCD Tool To Create A Device Configuration Data Image . Procedure With desired project open in project explorer (C/C++ perspective), switch to IVT perspective. Click on 'Open IVT'. In the Boot Configuration section, check that the correct Boot Target is selected. For the demonstration here, M7_0 is the correct selection. Check the 'Interface selection' section. If your intended boot device is SD, MMC or eMMC, then change the setting from QuadSPI Serial Flash. If your intended boot device is QuadSPI AND you do not have a QuadSPI parameter file to specify, then uncheck the box for 'Configure QuadSPI parameters'. QuadSPI parameters change some flash registers' settings away from the default setting and are generally required for larger memory sizes (for ex. applications over 1 MB in size, for some supported devices). From the Image Table section, depending on your configuration, turn off all unused images. For the demonstration here, the following will be changed to Reserved: Self-Test DCD, Self-Test DCD (backup), DCD (backup), Application bootloader (backup). The following images will remain enabled: DCD, Application bootloader. In DCD section of the Image Table, click 'Browse File' and select the DCD binary file. Some of the fields may become red shaded after the file is loaded. This is OK as it is showing the memory layout is no longer aligned. This will be resolved in a later step.  Scroll down to the Application bootloader section, again use  'Browse File' and select the application binary. When the application boot image is loaded, the tool processes the file to check if it contains the header for the application bootloader image. If the header is not found, it means that the file is only the raw code (the bin generated by S32 Design Studio) and it will be necessary to provide the values for RAM start & entry addresses (code length is automatically calculated), as noted with the expanded view and red shading. To set the RAM start pointer and entry pointer addresses, from to the C/C++ perspective: From Project Explorer on the C/C++ perspective, open the linker file (in this case: hello_world\Project_Settings\Linker_Files\<device_name>_common_ram.ld) and locate the RAM start address and enter it in both the RAM start pointer AND RAM entry pointer fields in the IVT Tool. Use copy and paste to add the values to the Application Boot Image settings. Since the application binary file which was loaded for this example is just a raw binary file, it is necessary to generate the full application bootloader image. The Export Image function takes the values entered for the RAM start & entry pointers and the automatically calculated Code length, then generates the Application bootloader header. This header is added to the raw binary file producing a new image, the full application bootloader image file. Within the Application bootloader section, click 'Export Image' and enter a meaningful name for the image file. In addition to being a necessary source component of the IVT image, this file can more easily be shared or re-used to as an input to other IVT images. After the file has been generated, you will notice that the address settings section has collapsed. This is because it has replaced the file you originally selected with the newly generated one and the tool has recognized that the file contains the required header information. Before the Blob image can be generated, all of the images must be properly aligned within the memory map. You will likely also see error messages regarding segment overlaps, but even without this error it is good to check that the alignment is correct. In the Automatic Align section, if you have a dedicated area of the memory you can specify the start address and then click 'Align'. If you don't have a dedicated area, then use the default automatic align start address of 0x0 (QSPI), or 0x1000 (SD, MMC, eMMC). Click 'Align' to automatically align the images to this address. Upon successful completion of the alignment, all of the red shading will be removed. Click 'Export Blob Image' to generate the blob image file. This is what will be flashed to the target. Now that the Blob Image is generated, the 'Flash Image' button could be used to program the image to the target over serial connection, or use the S32 Flash Tool.

This document shows the step-by-step process to create a simple 'Blinking_LED' application using the S32K1xx RTD and the S32 Configuration Tools. This example is for the S32K144EVB-Q100 EVB, connected to a PC through USB (OpenSDA) connection. Preparation Setup the software tools Install S32 Design Studio for S32 Platform Install the S32K1xx development package and the S32K1 RTD AUTOSAR 4.4. Both of these are required for the S32 Configuration Tools. Launch S32 Design Studio for S32 Platform Procedure New S32DS Project OR Provide a name for the project, for example 'Blinking_LED_RTD_AUTOSAR'. The name must be entered with no space characters. Expand Family S32K1xx, Select S32K144 Under Toolchain, select NXP GCC 9.2 Click Next Click '…' button next to SDKs Check box next to PlatformSDK_S32K1_2022_02_S32K144_M4F. Click OK Click Finish. Wait for project generation wizard to complete, then expand the project within the Project Explorer view to show the contents. To control the LED on the board, some configuration needs to be performed within the Pins Tool. There are several ways to do this. One simple way by double-click on the MEX file. By default, the Pins tool is then presented. Since the AUTOSAR drivers will be used, click the switch to disable this tool from the Overview tab. Once the Pins tool is disabled, the Config Tools Overview menu appears. Select the Peripherals tool. After the Peripherals tool opens, look to the Components tab. By default, new projects are created with the osif and Port_Ip drivers. Leave the osif driver, but remove the Port_Ip driver.  This will be replaced by AUTOSAR version. Right-click on the Port_Ip box and select Remove. Add the AUTOSAR version of the Port driver. Click on the ‘+’ next to the MCAL box. This will bring up a list of AUTOSAR components. Locate then select ‘Port’ and click OK. Do not worry about the warning message. It is only indicating that the driver is not already part of the current project. The associated driver package will be added automatically. There are a couple of other drivers needed. Click the ‘+’ next to MCAL again and this time select ‘Dio’. Once more, click the ‘+’ and select ‘Mcu’. Select the ‘Dio’ component. Now select the DioConfig tab. Under DioPort_0, change the Dio Port Id to 3. Click ‘+’ next to DioChannel to add a channel. Select the ‘Port’ component. Now select the PortConfigSet tabl. Under PortPin, change the setting for PortPin_0, PortPin Pcr from 0 to 96. Then change the setting PortPin Direction from PORT_PIN_IN to PORT_PIN_OUT. Change the setting PortPin Level Value from PORT_PIN_LEVEL_HIGH to PORT_PIN_LEVEL_LOW. Under UnTouchedPortPin, click ‘+’ and add the following 5 PortPin Pcr numbers: 4, 5, 10, 68, 69 Now select the PortGeneral tab, uncheck ‘Port Ci Port Ip Development Error Detect’. Now the device configurations are complete and the RTD configuration code can be generated. Click ‘Update Code’ from the menu bar. To control the output pin which was just configured, some application code will need to be written. Return to the ‘C/C++’ perspective. If not already open, in the project window click the ‘>’ next to the ‘src’ folder to show the contents, then double click ‘main.c’ file to open it. This is where the application code will be added. Before anything else is done, initialize the mcu driver, the clock tree, and apply PLL as system clock. Insert the following line into main, after the comment 'Write your code here': Mcu_Init(&Mcu_Config_BOARD_InitPeripherals); Mcu_InitClock(McuClockSettingConfig_0); while ( MCU_PLL_LOCKED != Mcu_GetPllStatus() )     {         /* Busy wait until the System PLL is locked */     } Mcu_DistributePllClock(); Mcu_SetMode(McuModeSettingConf_0); Before the pin can be controlled, it needs to be initialized using the configuration information that was generated from the S32 Configuration tools. Initialize all pins using the Port driver by adding the following line: Port_Init(NULL_PTR); Turn the pin on and off with some delays in-between to cause the LED to blink. Make the delays long enough to be perceptible. Within the provided for loop, add the following lines: Dio_WriteChannel(DioConf_DioChannel_DioChannel_0, STD_HIGH); TestDelay(2000000); Dio_WriteChannel(DioConf_DioChannel_DioChannel_0, STD_LOW); TestDelay(2000000); Before the 'main' function, add a delay function as follows: voidTestDelay(uint32 delay); voidTestDelay(uint32 delay) {     staticvolatile uint32 DelayTimer = 0;     while(DelayTimer<delay)     {         DelayTimer++;     }     DelayTimer=0; } Update the includes lines at the top of the main.c file to include the headers for the drivers used in the application: Remove #include "Mcal.h" Add #include "Mcu.h" #include "Port.h" #include "Dio.h" Build 'Blinking_LED_RTD_AUTOSAR'. Select the project name in 'C/C++ Projects' view and then press 'Build'. After the build completes, check that there are no errors. Open Debug Configurations and select 'Blinking_LED_RTD_AUTOSAR_Debug_FLASH'. Make sure to select the configuration which matches the build type performed, otherwise it may report an error if the build output doesn’t exist. Confirm the EVB is connected to the PC via USB cable, then check the Debugger tab settings and ensure that 'OpenSDA Embedded Debug - USB Port' is selected for interface. Click Debug To see the LED blink, click ‘Resume'

IVT - short for Image Vector Table, is an image with a set of pointers to other images which are required at boot by the embedded BootROM. This video will explain using S32V chip how IVT tool works and covers create and flash SDK's PIT example.

        Product Release Announcement Automotive Processing S32 Design Studio for S32 Platform v3.3         Austin, Texas, USA Sep 22, 2019   The Automotive Processing's Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the  S32 Design Studio v3.3 Here are some of major features: Eclipse Neon 4.6 Framework GNU tools: GCC version 6.3.1 20170509, build 1620 revision g01b30c3 GCC version 9.2.0 20190812, build 1649 revision gaf57174 NPW support for GCC 9.2 toolchain (available for selected devices only) S32 Configuration Tool framework 1.1 update 1 with the Pin, Clock, Peripheral, DCD, IVT, DDR and QuadSPI Configuration tools  The wizards for creating application, library projects and projects from project examples for the supported processor families The S32DS Extensions and Updates tool S32 Trace Tool S32 Debugger support PEMicro® debugger support Lauterbach Trace32® support Green Hills compiler support S32 Flash Tool Peripheral Registers view and EmbSys Registers view SDK management Support for importing MCAL configuration to a custom SDK Support for migration: project with GCC 6.3.1 toolchain to GCC 9.2 toolchain S32DS for ARM  projects for S32K1 device to S32DS 3.3, including SDK* * available with S32K1 package, not yet released Release is available for download on NXP web and from S32DS 3.3. Please make sure that you get new activation ID for this version. Support for S32S247TV and S32V23x is available on public update site and release location. S32V23x support: S32SDK S32V234 RTM 1.0.1  S32 Configuration tools - Pins, CLocks, Peripheral (installed with SDK package) S32 Debugger (with S32 Debug Probe) support for ARM cores S32 Trace for A53 cores GCC version 6.3.1 20170509, build 1574 S32 Flash Tool support AMMCLIB 1.1.20 P&E and Lauterbach debuggers support Note: Vision Extension package 1.0.0 is not compatible with S32 Design Studio 3.3, if you need to work with VSDK and Vision tools - it is recommended to stay on S32DS 3.2 untill a new version of Vision Extension package is released   S32S247TV support: Support for S32S247TV new project wizards, GCC 6.3.1 and GHS compilers S32SDK S32S247TV EAR 0.8.1  S32 Configuration tools - Pins, CLocks, Peripheral, DCD, IVT (installed with SDK package) S32 Debugger (with S32 Debug Probe) support  S32 Flash Tool support Lauterbach support P&E and Lauterbach debuggers support S32 Design Studio Versions   S32DS IDE for S32 Platform S32DS IDE for Arm® S32DS IDE for Power Architecture® S32DS IDE for Vision Devices Supported S32V23x S32K1xx MPC56xx S32V234 S32S247TV KEA MPC57xx   S32 Platform Devices MAC57D54H S32R2xx/S32R3xx   Integrated NXP Tools S32 Flash Tool FreeMASTER FreeMASTER DDR stress tool DDR stress tool     Integrated Configuration Tools S32 Configuration Tools Processor Expert Configuration Tool Processor Expert Configuration Tool  DDR configuration tool Pins Wizard Pins Wizard Pins Wizard Clocks configuration Peripheral/Drivers configuration   Peripheral/Drivers configuration   Peripheral/Drivers configuration   DCD/IVT configuration       DDR configuration tool       Integrated NXP Software S32 SDK S32K1 SDK S32 SDK Vision SDK FreeRTOS FreeRTOS FreeRTOS Linux BSP AMMCLib for S32V23x AMMCLib for KEA and S32K AMMCLib for MPC56xx and MPC57xx MCUs   Vision SDK KEA SDK Radar SDK Linux BSP MQX OS/MQX Drivers for MAC57D54H     Compilers: NXP GCC 6.3.1* NXP GCC 9.2 NXP GCC 6.3.1* NXP GCC 4.9* NXP GCC 6.3.1* GreenHills GreenHills GreenHills   IAR IAR Diab     GCC 4.9*     DEBUGGERS Built-in GDB interface: S32 Debugger/S32 Debug Probe P&E Multilink/Cyclone/OpenSDA P&E Multilink/Cyclone/OpenSDA S32 Debugger/S32 Debug Probe P&E Multilink/Cyclone/OpenSDA Segger J-Link   P&E Multilink/Cyclone/OpenSDA DEBUGGERS supported: Lauterbach Lauterbach Lauterbach Lauterbach   iSystem iSystem   IAR PLS   Host Operating Systems: Microsoft Windows® 7/8/10 64-bit OS (with 32-bit binaries)  – Ubuntu 14.04, 16.04 (64 bit) – Debian 8 (64 bit) – CentOS 7 (64 bit) Microsoft Windows® 7/8/10 32/64-bit OS (with 32-bit binaries)  – Ubuntu 14.04, 16.04 (64 bit) – Debian 8 (64 bit) – CentOS 7 (64 bit) Microsoft Windows® 7/8/10 32/64-bit OS (with 32-bit binaries)  – Ubuntu 14.04, 16.04 (64 bit) – Debian 8 (64 bit) – CentOS 7 (64 bit) Microsoft Windows® 7/8/10 32/64-bit OS (with 32-bit binaries)  – Ubuntu 14.04, 16.04 (64 bit) – Debian 8 (64 bit) – CentOS 7 (64 bit) Vision specific tools : NXP APU Compiler     NXP APU Compiler ISP assembler     ISP assembler ISP and APEX graph tools     ISP and APEX graph tools Radar specific tools :     SPT assembler       SPT Explorer/ SPT graph tool   Complete S32 Design Studio for S32 Platform v3.3 release notes are attached.   Installation To download the installer please visit the S32 Design Studio product page download section or click the direct here.     The installer requires the Activation ID to be entered. You should receive a notification email including the Activation ID after the download of the installation package starts. The installer installs just the base tools/package. In order to start development it is necessary to install at least one Development package. Currently the only development packages available are S32S2xxTV and S32V2xx. The application packages are managed by S32DS Extensions and Updates. Technical Support S32 Design Studio issues are tracked through the S32DS Public NXP Community space. https://community.nxp.com/community/s32/s32ds  

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

This Example demonstrates an alternative way to multi-core projects. This is basically a single eclipse project that generates the single elf file for dual core MCU (MPC5777C) See the project structure below where the sources for each core are separated into a core specific source folder: Main core0 [e200z7_0] performs basic initialization (Clocks, ports..) Each core initializes the interrupt controller in order to service interrupts generated by PIT (Periodic Interrupt Timer): Core 0 (e200z7_0) services PIT channel 0 interrupts generated once per second. Core 1 (e200z7_1) services PIT channel 2 interrupts generated once per two seconds.

Before you can start debugging an S32DS for Vision project for S32V234 Cortex-A53 APEX2/ISP Linux target on the S32V234-EVB, we must first setup the hardware connections and start the Linux BSP OS. 1) Connect (1) S32V234 USB Micro B port to (2) USB A port on your PC. This allow you to connect to the Linux BSP OS via a terminal program to issue commands and to obtain the IP address. 2) Insert microSDHC card (with U-boot, Linux kernel, devicetree, and root file system loaded*) into (3) the S32V234 SD card slot   3) Connect (1) Ethernet port on S32V234 daughter card to (2) LAN**. This will allow S32DS to communicate with the Linux BSP OS for flashing and GDB debugging.   4) Connect the power supply to (3) S234V234 EVB 5) Turn on the (4) power switch, this will start the Linux BSP OS *Instructions for preparing the SD card are provided in the VisionSDK document: ..\S32DS_Vision_v2.0\S234DS\s234v234_sdk\docs\vsdk\S32V234-EVB_SetupGuide.pdf or refer to https://community.nxp.com/docs/DOC-335023  **Ensure PC is connected to LAN as well (either hardwired or wireless)

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 S32G2xx 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 S32G274A evaluation board.  Configure the JTAG. The S32G274A evaluation board supports both 10- and 20- pin JTAG connections. The default board configuration is set to 20-pin, change the position of the jumper J59 from 2-3(default)  to 1-2, if you are using the 10 Pin JTAG interface. Both are supported by the S32 Debugger and S32 Debug Probe. 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. Use the JTAG connection as was confirmed in the previous step. 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\s32g2xx\s32g2xx_generic_bareboard_all_cores.py Uncomment the following lines: #_JTAG_SPEED = 16000 #_PROBE_IP = "10.112.101.91" #_GDB_SERVER_PORT = 45000 #_CORE_NAME = 'M7_0' #_RESET_TYPE = "default" #_RESET_DELAY = 1 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True 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 s32g2xx_context.py for complete list of supported cores. Save the file with a new name to preserve the original. For example, s32g2xx_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\\s32g2xx\\s32g2xx_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_S32G_Project\\New_S32G_Project_M7_0\\Debug_RAM\\New_S32G_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 set *0x34200000 = 0x34300000 set *0x34200004 = 0x34200025 set *0x34200024 = 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\s32g2xx\s32g2xx_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 = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" Make the following changes to the lines: _JTAG_SPEED = 14000 ->  None _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> None _CORE_NAME = 'M7' -> 'M7_1' (this should be set to match the name of the core to be debugged, see s32g2xx_context.py for complete list) _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" Save the file with a new name to preserve the original. For example, s32g2xx_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\\s32g2xx\\s32g2xx_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}\\S32G_MultiCore\\S32G_MultiCore_M7_1\\Debug_RAM\\S32G_MultiCore_M7_1.elf load   Repeat 3-6 for each additional core. 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\s32g2xx\s32g2xx_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 = 14000 #_GDB_SERVER_PORT = "127.0.0.1:45000" #_RESET_TYPE = "default" #_PROBE_IP = "s32dbg:10.222.24.64" #_CORE_NAME = 'M7' #_RESET_DELAY = 1 #_CMD_TIMEOUT = 7200 #_REMOTE_TIMEOUT = 60 #_IS_LOGGING_ENABLED = True #_SOC_NAME = "S32G274A" Make the following changes to the lines: _JTAG_SPEED = 14000 _GDB_SERVER_PORT = "127.0.0.1:45000" -> 45000 _RESET_TYPE = "default" _PROBE_IP = "s32dbg:10.222.24.64" -> (enter the IP address of your probe) _CORE_NAME = 'M7' -> 'M7_0' (this should be set to match the name of the core to be debugged, see s32g2xx_context.py for complete list) _RESET_DELAY = 1 _CMD_TIMEOUT = 7200 _REMOTE_TIMEOUT = 60 _IS_LOGGING_ENABLED = True _SOC_NAME = "S32G274A" Save the file with a new name to preserve the original. For example, s32g2xx_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\\s32g2xx\\s32g2xx_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}\\S32G_Multicore\\S32G_Multicore_M7_0\ \Debug_RAM\\S32G_Multicore_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.

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

Sometimes you would like to share sources between projects and - even better - between platforms. Let's say that we are developing software with the very same functionality for S32K144 and MPC5744P. In this case, we can identify platform independent functions - generic, platform specific functions - not related to MCU itself, but related to the way some peripheral works (for example different ADC result range) - and MCU dependent functions like clock init. In attachment is a very simple SDK which can be shared with S32K144 and MPC5744P (each in different S32DS editions).  Unzip my_sdk.zip archive (for example C:\NXP folder). You can import example projects, but instead let's start from the beginning. Create a new S32DS Application project and choose MCU: You can use default project configurations and click through to finish: Right click on project name -> Properties and select SDKs -> Add Complete the Name, Version and Description fields in New SDK dialog and click on Change button next to Location field. In Change SDK Location dialog, leave Define new variable setting selected, click Browse and find the my_sdk path: Now we can select files (sources, headers...) from selected SDK, you can select all available files. If you select a folder, then all files in that folder will be selected as well. Don't forget to select header files too: If you choose Copy - the files will be copied into project folder and you can do local changes. Without this option (default) - changes will be shared between all projects depended on this particular SDK. The ability to individually select the files to be included from the SDK as well as to copy into the project folder, provides much flexibility to customize SDK usage in your projects. Click on OK, then Attach/Detach... to attach this SDK into your project:  If you like to use your SDK for newly created projects (as an option in SDK select list) - click on Make global button: Now you can see changes in your project: As well, the SDK can be viewed in SDK Explorer (Window -> Show View -> Other...), where functions and macros are available for drag and drop functionality into your code: Platform specific code is filtered by preprocessor-defined macro. So - let's define if we are working with S32K144 or MPC5744P. Right click on project name -> Properties -> C/C++ Build -> Settings -> <Standard S32DS C Compiler OR name of your compiler> -> Preprocessor: We are done - now we can use SDK functions - S32K144:  and MPC5744P (enabling interrupts is default part of empty project for MPC5744P - that's only difference):

  The S32 Debugger included within the S32 Design Studio for S32 Platform IDE provides the capability to access the flash programming capabilities of the S32 Debug Probe via the S32 Debugger. Note: currently only QSPI flashing is supported. Preparation Install S32 Design Studio IDE  Install the Development Package for the device you are debugging. In this case, the S32G2xx development package. This package is important as the S32 Debugger support component contains the device-specific Python scripts required for performing the flash programming operations.   Open the application project containing the application to be programmed to the flash memory device. Follow the steps in HOWTO: Generate S-Record/Intel HEX/Binary file , selecting the 'Raw Binary' option. Build the project, generating the binary executable. This will be our application binary input to the IVT Tool. The IVT Tool must be used to generate the BLOB image which can be programmed to flash memory device and loaded to the RAM by the BootROM. Follow the steps in HOWTO: Use IVT Tool To Create A BLOB Image S32G274A. The resulting BLOB image file is what can be flashed to the device.   Procedure Open Debug Configuration menu Select 'S32 Debugger Flash Programmer', then right-click and select New. Enter an name for the new configuration and click Add... to add the file to be flashed. Click Browse... to select the project from the workspace where the application binary is located Select the project and click OK By default, the ELF file is found. Click Search in project to select the binary file. Select the .bin file and click OK Now we must enter the base address. Typically, this could be 0, but you may have other requirements. Click OK. Just the memory required by the new image needs to be cleared, so only check the box 'Erase all flash memory' if truly needed. Now we are ready to configure the debugger connection settings. Click on the Debugger tab. Starting from the top and working our way down, click on Select device. Select the device and click OK The correct Initialization script will automatically be set. Set the Debug Probe Connection settings to match your setup. When done, click Apply To start the flashing, click Debug When complete, the Debug perspective will show at terminated thread.   Happy flashing with GDB!   Note, to debug this application since it will be subsequently started by the BootROM: use 's32gxx_attach.py' in the Initialization script field on the debugger tab of the Debug Configurations menu Make the following adjustments on the Startup tab within the Debug Configurations menu: Uncheck "Load image"  Check "Set program counter at:" and enter the value "Reset_Handler"  

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for ARM® 2018.R1  Update 9          What is new? S32K1xx SDK RTM 3.0.0 supporting S32K116, S32K118, S32K142, S32K144, S32K146, and S32K148  (S32K1xx SDK release notes) AMMCLIB version 1.1.15  (AMMCLIB S32K14x release notes) Segger J-Link drivers v6.42a (J-Link release notes) This is a cumulative update - it includes all the content of previous updates (Update 1, Update 2, Update 3, Update 4, Update 5, Update 6, Update 7, Update 8) Installation instructions The update is available for online (via Eclipse Updater) or offline installation (direct download link)  installation:  go to menu "Help" -> "Install New Software..." dialog  select predefined update site "S32DesignStudio - http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_ARM_2018.R1/updatesite" select all available items and click "Next" button   offline installation:   go to S32 Design Studio for ARM product page -> Downloads section or use direct link to download the update archive zip file Start S32DS and go to "Help" -> "Install New Software..." Add a new "Archive" repository and browse to select the downloaded update archive .zip file you downloaded in the previous step Select all available items and click "Next" button.   This will starts the update installation process.

Build your project and choose Debug Configuration option  On the left side select Launch Group of your choice (Flash/RAM) and press Debug button Wait while debug session is fully started. If you left default startup configuration - all cores has active break-point at the beginning of main() function. You can chose any core for debugging just by clicking on the core's thread. Sometimes are init functions - including startup of other cores - inside main() of boot core (for S32R274 is boot core Z4). In this case you should let boot core perform init sequence first and then try debug other cores. On next picture are all cores halted.  On this picture are core 1 (Z4) and 2 (Z7_0) running - and third one is stopped. You can perform any debug operation on this core (memory/registers view, instruction step...) without effect on other cores.  On the last picture are running cores 1 (Z4) and 3 (Z7_1) and second core (Z7_0) is stopped and any debug operation can be performed on this core. 

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