Hi: I just wonder whether I can use S32 debug probe for S32K3 EVB in S32DS 3.4? I couldn't locate script and algorism for S32K3xx. Thanks.

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 S32R4xx development package. This package is important as it contains the S32 Debugger support component 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 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.

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio v3.4 Vision Extension Package for S32V23x 1.3.0          What is new? Integrated VSDK 1.7.0   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  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 for S32 Platform product page -> Downloads section or use direct link to download the update archive zip file        Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Add Update Sites' link Select the downloaded update archive zip file you downloaded in the previous step       Select the 'Vision extension package for S32V23x' package and click "Install/Update" button.   This will start the update installation process.

          Product Release Announcement Automotive Processing S32 Design Studio for S32 Platform v3.4           Austin, Texas, USA Dec 22, 2020   The Automotive Processing's Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the  S32 Design Studio v3.4 Here are some of the major features: Eclipse Neon 2019.12 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.3 with the Pin, Clock, Peripheral, DCD, IVT, DDR and QuadSPI Configuration tools (SDK/RTD packages required to get support for particular device)  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 and System 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, more details could be found in Release Notes  Release is available for download on NXP web and from S32DS 3.4. 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.2.0 with support for S32 Design Studio 3.4 is not yet available, if you need to work with VSDK and Vision tools - it is recommended to stay on S32DS 3.3 until 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 S32K1 support: Support for S32K1xx new project wizards, GCC 6.3.1, IAR and GHS compilers NXP GCC version 6.3.1 20170509, build 2017 S32SDK S32K1xx RTM 4.0.1 AMMCLIB 1.1.22 S32 Configuration tools - Pins, CLocks, Peripheral (installed with SDK package) PEmicro, iSystem, Segger, IAR, Lauterbach  debuggers support Support for S32V23x, S32S247TC, S32K1xx is provided on update site and archive SW32_S32DS_3.4.0_D2012.zip for offline use    Complete S32 Design Studio for S32 Platform v3.4 release notes and Installation Guide 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  

Project created by S32 Design Studio (S32DS) new project wizard typically contains the debugger configurations to load  and debug the project into the code memory (Flash/RAM). However there might be situations that require also to load a content/data (e.g. calibration values) into a special on-chip memory (such as shadow flash, data flash, utest flash...) or an external memory (QSPI). This document describes how to program multiple memory types (using different programming algorithms) just by single click on the debug button. The decription applies to PEMICRO probes (Multilink Universal, Multilink FX or OpenSDA) anyway a similar approach might be applicable for other vendor probes. The process can be splitted into two steps: 1. create a separate debugger configurations to program a specific memory modules(QSPI,  data flash,..) 2. associate the program and debug configurations into the single launch group  - this alows to execute multiple actions by invoking the single debug launch . Let's demonstrate this on MPC5744P and program code and data flash memory using S32DS for Power v2.1 (similar approach can be applied also to other architectures/versions of S32DS). •  Create a new empty project for MPC5744P. Such a project typically contains Debug/Debug_RAM debugger configuration. First we will add a dummy code  (see below) that creates a record to be stored into the data flash memory (different to code flash memory block). • The project linker file (MPC57xx_flash.ld) should have the data flash memory block and a linker section associated with data flash (.dflash) defined: MEMORY { dflash : org = 0x00800000, len = 0x1F /* not entire dflash - just for test*/ flash_rchw : org = 0x00FA0000, len = 0x4 cpu0_reset_vec : org = 0x00FA0004, len = 0x4 m_text : org = 0x1000000, len = 2048K m_data : org = 0x40000000, len = 384K local_dmem : org = 0x50800000, len = 64K } SECTIONS { .dflash : { KEEP(*(.dflash)) } > dflash … •Add a test code into main.c that results in creating a dummy data record in data flash memory (0x0800000) __attribute__((section(".dflash"))) volatile char dflash_data[]="DTEST String"; // place the string into .dflash segment int main(void) { volatile int counter = 0; volatile char test_str[10]; test_str[0] = dflash_data[0]; // use DFLASH data (to avoid deadstripping) /* Loop forever */ for(;;) { counter++; } } Now if you build the project you can see the data that belong to dflash and code flash in the .map or srec file. If you debug the project using the default debug configuration data flash (DFLASH) memory is not programmed. To program DFLASH you should create another debug configuration simply by duplicating the existing one and changing the programming algorithm to dflash one: nxp_mpc5744p_1x32x20k_dflash.pcp. Note: There are many flash programming algorithms available in PEMICRO eclipse plugin folder typically located here (version of plugin may vary): "C:\NXP\S32DS_Power_v2.1\eclipse\plugins\com.pemicro.debug.gdbjtag.ppc_2.0.2.202005132054\win32\gdi\P&E\" S32DS: Duplicate Debug Configuration S32DS: Load parameters S32DS: Choose alternative programming algorithmNow the new debug configuration (MPC5744P_code_dflash_Debug_DFLASH) is able to program data flash memory. The final step is to create a launch group configuration and associate it with all the programming/debugging configurations that should be executed once debug is started. Add the debug configuration used just for programming purpose as flash type and code debug configuration as debug type. In order to avoid interference between programming of various memories select post launch action -> "Wait until terminated" Finally as soon as the debug session is established by launching the launch group created above - all the memories are programmed and you can debug the code. Note: There is an information about executed flash configurations in the debug context view. Since the programming has alredy finished the thread is terminated and could be cleared by double cross icon. Enjoy single click programming&debugging in S32 Design Studio!

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture v2.1 Update 14          What is new? S32R294 support updated for rev 2 Integrated S32 SDK for S32R294 RTM 1.0.0 This is a cumulative update - it includes all the content of previous updates (Update 1,Update 2, Update 7, Update 8, Update 10, Update 12, Update 13)   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  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 for Power product page -> Downloads section or use direct link to download the update archive zip file        Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Go to Preferences' link And add a new site "Add..." repository and browse to select the downloaded update archive zip file you downloaded in the previous step   Select the 'S32R294 development package' and 'Update with S32 SDK 1.0.0 RTM for S32R294 for Power Architecture' packages and click "Install/Update" button.   This will start the update installation process.

A typical debug session will begin by downloading code to Flash and then debugging from main() onwards. However, to explore an already running system a debug connection (attach) can be made to the target MCU without affecting the code execution (at least until the user chooses to halt the MCU!).   Note: Source level debug of a running target is only possible if the sources of the project to be attached exactly match the binary code running on the target.   Click the (Debug As) button on the toolbar, then click Debug Configurations from the drop-down menu. In the left pane of the Debug Configurations dialog box, expand the debugging interface specified in the project settings and click the required launch configuration. After you click the configuration in the left pane, the configuration settings appear in the right pane grouped in tabs. PEmicro Select the Startup tab, then set the ‘Attach to Running Target’ check box as below: When a debug connection is made, the target will continue running until it is paused.   SEGGER J-Link Select the Debugger tab, then set the ‘Connect to running target’ check box as below: Unfortunately, this feature currently not supported.

Watchpoints are Breakpoints for Data and are often referred to as Data Breakpoints. Watchpoints are a powerful aid to debugging and work by allowing the monitoring of global variables, peripheral accesses, stack depth etc. The number of watchpoints that can be set varies with the MCU family and implementation. Watchpoints are implemented using watchpoints units which are data comparators within the debug architecture of an MCU/CPU and sit close to the processor core. When configured they will monitor the processor’s address lines and other signals for the specific event of interest. This hardware is able to monitor data accesses performed by the CPU and force it to halt when a particular data event has occurred. The method for setting Watchpoints is rather more hidden within the IDE than some other debugging features. One of the easiest ways to set a Watchpoint is to use the Outline View. From this view you can locate global and static variables then simply select Toggle Watchpoints.     Once set, they will appear within the Breakpoints pane alongside any breakpoints that have been set.    Watchpoints can be configured to halt the CPU on a Read (or Load), Write (or Store), or both. Since watchpoints ‘watch’ accesses to memory, they are suitable for tracking accesses to global or static variables, and any data accesses to memory including those to memory mapped peripherals.  Note : To easily distinguish between Breakpoints and Watchpoints within the Breakpoint view, you can choose to group entries by Breakpoint type. From within the Breakpoints view, click the Eclipse Down Arrow Icon Menu, then you can select to Group By Breakpoint Types as shown below:   As you can see from the above graphic, the option to set a Watchpoint is also available directly from the Breakpoint view.   When set from here, you will be offered an unpopulated dialogue – simply entering an address will cause a watchpoint to be created, monitoring accesses to that location.     Another place to set Watchpoints within the IDE is from the context sensitive menu within a Memory view.   Unfortunately, the conditional watchpoints in S32 Design Studio for S32 Platform 3.3 may not work in some cases.

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture v2.1 Update 13          What is new? Integrated Radar SDK RTM 1.5.0 (replacing 1.4.0) This is a cumulative update - it includes all the content of previous updates (Update 1,Update 2, Update 7, Update 8, Update 10, Update 12)   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  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 for Power product page -> Downloads section or use direct link to download the update archive zip file      Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Go to Preferences' link And add a new site "Add..." repository and browse to select the downloaded update archive zip file you downloaded in the previous step   Select the 'S32 Design Studio for Power Architecture Device Package' and 'Update with S32 SDK 3.0.2 for Power Architecture' packages and click "Install/Update" button.   This will start the update installation process.

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio v3.3 Vision Extension Package for S32V234 1.2.0          What is new? Integrated VSDK 1.6.0   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  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 for S32 Platform product page -> Downloads section or use direct link to download the update archive zip file        Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Go to Preferences' link And add a new site "Add..." repository and browse to select the downloaded update archive zip file you downloaded in the previous step       Select the 'S32 Design Studio for Power Architecture Device Package' and 'Update with S32 SDK 3.0.2 for Power Architecture' packages and click "Install/Update" button.   This will start the update installation process.

UART communication is supported in the KEA64 Bootloader .rbf file  + Supported UART0: PTA2-PTA3 pins(Speed: 115200b/s) Tested on the dev board:   Development Board TRK-KEA64 Processor PKEAZN64 MLH 2N22J

      Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture v2.1 Update 12          What is new? Integrated S32 SDK for Power Architecture RTM 3.0.3 (replacing 3.0.2) Integrated AMMCLIB 1.1.21 This is a cumulative update - it includes all the content of previous updates (Update 1,Update 2, Update 7, Update 8, Update 10)   Installation instructions The update is available for online installation (via S32DS Extensions and Updates) or offline installation (direct download link)  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 for Power product page -> Downloads section or use direct link to download the update archive zip file      Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates", then click 'Go to Preferences' link And add a new site "Add..." repository and browse to select the downloaded update archive zip file you downloaded in the previous step   Select the 'S32 Design Studio for Power Architecture Device Package' and 'Update with S32 SDK 3.0.2 for Power Architecture' packages and click "Install/Update" button.     This will start the update installation process.

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.

This short video will present an overview of S32 Configuration Tool. Tools that are briefly overviewed: Pins tool, clock tool, peripheral tool, DCD tool and IVT tool.

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.

Has this happened to you? You just launched S32DS for Vision and opened a visual graph but the blocks are collapsed onto one another. Probably looks something like this: There is an easy solution. Just click on the 'Arrange All' button and the graph will automatically expand to a manageable state. Here is the result:

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. https://www.nxp.com/support/training-events/getting-started-with-s32-design-studio-ide-for-vision-2018.r1:TIP-S32DS Create New Project 3 | Create a New ISP Project 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 Project A demonstration of how to create a new APEX2 image processing application project featuring upscaling and downscaling in the S32 Design Studio. https://www.nxp.com/support/training-events/getting-started-with-s32-design-studio-ide-for-vision-2018.r1:TIP-S32DS 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 bare-board APEX2 Project A demonstration of how to debug a bareboard APEX2 image processing application project in the S32 Design Studio with Lauterbach TRACE32. 9 | 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. 10 | Debug a bare-board A53 Project A demonstration of how to debug a bareboard A53 image processing application project in the S32 Design Studio for Vision version 2.0 using PEMicro GDB interface. The example shown also includes code for APEX, but currently PEMicro only supports debug of the A53 code.

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.

Condition: Enable Stopindebug bit for PIT and STM module. Counter could be stop when debug project, but when i set debug mode on, counter not count, project can't be run. Analysis: In order for PIT timer to count when a FRZ bit is enabled, all cores on S32V23x devices need to be running. The reason why it does not work out of the box with current plugin configuration, is because we halt all device cores, which is especially necessary for RAM based projects. Solution: We created a start-up macro to keep all cores running when S32V232M80 or S32V234M100 debug sessions are launched. In order to use it, please go to the following directory without your S32DS3.2 IDE: eclipse\plugins\com.pemicro.debug.gdbjtag.pne_4.2.8.201909091700\win32\gdi\P&E\supportFiles_ARM\NXP\S32Vxxx. Please rename S32V234M100_All_Cores_Running.mac or S32V232M80_All_Cores_Running.mac to default macro names, saving existing default macros in renamed form, or a separate location: S32V234M100.mac or S32V232M80.mac.separate location: S32V234M100.mac or S32V232M80.mac.

Requirements: SD card with installed Linux image connected to EVB (https://community.nxp.com/docs/DOC-335023 ) Serial link connection between PC and EVB (HOWTO: Setup A Remote Linux Connection in S32DS for Vision )  EVB connected to network   Procedure: 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.      The vi /etc/network/interfaces string is cutoff, because the OS acts during typing. The OS-printed line. [    29.817839] random: nonblocking pool is initialized (it varies with each boot). is written automatically by the OS a few seconds after login.  These characters do not make a difference.  Just enter the string as instructed and press Enter.  You will see the screen as follows.   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.