In embedded systems development, attention to memory utilization is universal. In S32 Design Studio, this information can easily be provided at the end of a successful build by invoking a linker option. Right-click on the project name in the Project Explorer panel and select 'Properties' from the menu. Navigate to the C/C++ Build -> Settings ->Standard S32DS C Linker -> Miscellaneous menu. From the Other options section, click Add. In the 'Enter Value' pop-up menu, enter: -print-memory-usage Click OK, then Apply and Close. Now build the project and see the memory usage information displayed in the Console window.

Migrating an SDK project for S32K1xx devices between SDK v4.0.1 and v4.0.2 is not as simple as attach and detaching the SDKs. It is complicated by the fact that SDK v4.0.1 is supported by only S32DS v3.3 and SDK v4.0.2 is supported by only S32DS v3.4. So this means both SDKs will not be present at the same time in one version of S32DS. In addition, the method for attaching the SDKs changed between SDK v4.0.1 and v4.0.2. In v4.0.1, the SDKs were added to the S32DS project via a link. In v4.0.2, the SDK files are added to the S32DS project by copying the actual files into the project. To overcome this, it is necessary to perform some manual operations. The steps required are detailed in this document, along with the necessary steps to adapt the .mex file containing the S32 Configuration Tools settings. Due to differences in projects based on the method of creation, there are 3 scenarios to be covered here which are assumed to be the most common: Project was created by 'New Project from Example' wizard and one of the SDK example projects was selected. Project was created by 'New Application Project' wizard and the SDK was selected for attachment within the wizard. Project was existing one and SDK was attached using the SDK management tool. Due to enough similarities between the projects, the last two will be covered as one scenario, under the heading 'New Application Project'. The first one will be covered under the heading 'New Project from Example'. Prerequisites Install S32 Design Studio IDE 3.4 Install the S32K1xx development package and S32SDK S32K1XX RTM 4.0.2 package Procedure New Project from Example For this demonstration, the S32K1xx SDK v4.0.1 example project 'flexio_i2s_master_s32k144' will be used. Open or create the project within S32DS 3.3 Expand project directory in Project Explorer and look for .mex file If no .mex file is present, then right click on project name and select 'S32 Configuration Tool -> Open Pins' (could select any tool within S32 Configuration Tool). Even though the .mex file contains the settings for S32 Configuration Tools, the same settings are also preserved in YAML code placed into the headers of each of the .c files generated by the S32 Configuration Tools into the 'board' folder in the project. By opening the S32 Configuration Tools, it detects there is no .mex file and scans the generated files for the YAML code. If YAML code is found, then a new .mex file is produced and placed in the project. The perspective is changed to the Pins Tool, nothing more needs to be done, .mex file has been created from the YAML code. If no YAML code had been found, then the user would be presented with a menu to select target device and SDK. Switch back to C/C++ perspective to confirm. Open S32DS 3.4 and import the project. It is important to note that separate workspaces should be used for S32DS 3.3 and S32DS 3.4. The project should be imported into the S32DS 3.4 workspace so the checkbox 'Copy projects into workspace' should be ticked. Right-click on Project -> Properties -> C/C++ Build -> Settings -> Standard S32DS C Compiler -> Includes, then delete all paths which contain 'S32_SDK_PATH' Repeat for Standard S32DS Assembler -> General Apply and Close The files in the SDK folder were included in the project as links and not actual files, and since the SDK 4.0.1 is not installed to S32DS 3.4, the links point to non-existing files. This means the Attach function in the SDK manager will not be able to replace them with the corresponding files from SDK 4.0.2 because it doesn't know how to replace files which don't exist. From Project Explorer, delete folder ' SDK' from the project. Now the project is ready to use the SDK manager to detach the old SDK and attach the new SDK. In Project Explorer, right-click on Project -> SDKs. When the SDK manager launches, it scans the project for any attached SDKs. In the case of this example, an SDK is detected as attached, but since it does not match any installed SDKs, a message appears asking to detach SDK 4.0.1. Since this is a desired action, click OK. With SDK 4.0.1 already detached, select SDK 4.0.2, click 'Attach/Detach...' Click 'Select All' to attach the SDK to all build configurations. This sets up the include paths, and linker paths for the SDK for each build configuration. If desired, the build configurations could be selected individually. Click OK to complete the selections. To apply the changes and exit the SDK manager, click 'Apply and Close'. The SDK Manager detects that some of the files from the new SDK are replacing existing files in the project. By default, all conflicting files are set to replace the existing file. If desired, individual files can be deselected. Please note, with the checkbox for 'Backup project files' ticked, any files replaced will be preserved in a backup folder for future recovery, comparison, etc. In general, it may be wise to allow the file to be replaced and later merge with the customizations in the backup folder. For this example, no modifications were made, so default settings are kept. Click OK to complete the process. The new SDK is attached and the new SDK folder can be identified. The .mex file contains the settings for the S32 Configuration Tools, however, it is still set for the SDK 4.0.1. It must be manually updated so the S32 Configuration Tools can be used to generate the new code for the 'board' folder. Right-click on .mex file and select 'Open With -> Text Editor'. All that is required is to modify the mcu_data section containing the SDK name: 's32sdk_s32k1xx_rtm_401' -> 's32sdk_s32k1xx_rtm_402' Now save the change. Next, the files in the 'board' folder must be regenerated from the S32 Configuration Tools to reflect the new SDK. Right-click on the .mex file and select 'Open With -> S32 Configuration Tools'. A warning message appears indicating that it has detected the mex file was created in an older version of the tool and that once the mex file is saved in the current tool, it may no longer open in an older version of the tool. This is expected. Click OK. Notice the error symbol. Mouse-over to see the details. It is an error with Peripherals tool. Select Peripherals tool. The issue is with edma_config_1, because it is highlighted red. Click on it to see the interface. The interface changed from the previous version to allow for multiple configurations where previously it supported only one. To resolve the error a new configuration must be added to the list. Click on the '+' as shown to add the new configuration. This particular error will only appear for projects which include the EDMA module. The Problem Indicator is now green, this means there are no warnings or errors. It is now time to generate the code, click 'Update Code' A menu appears identifying new and/or updated files. If desired, selecting 'change' on a row will open a comparison tool showing the changes between the existing and the new versions of the associated file. Click OK to proceed. Switch to C/C++ perspective Errors on project are now gone. If the project successfully built before the conversion, then build again to confirm everything was converted properly.   New Application Project For this demonstration, a new project will be created in S32DS 3.3 using the New Application Project wizard and the S32K1xx SDK 4.0.1 will be selected during project creation. Import the project into S32DS 3.4 Use the SDK Manager to detach the old SDK and then attach the new SDK. In Project Explorer, right-click on Project -> SDKs. When the SDK manager launches, it scans the project for any attached SDKs. In the case of this example, an SDK is detected as attached, but since it does not match any installed SDKs, a message appears asking to detach SDK 4.0.1. Since this is a desired action, click OK With SDK 4.0.1 already detached, select SDK 4.0.2, click 'Attach/Detach...' Click 'Select All' to attach the SDK to all build configurations. This sets up the include paths, and linker paths for the SDK for each build configuration. If desired, the build configurations could be selected individually. Click OK to complete the selections. To apply the changes and exit the SDK manager, click 'Apply and Close'. The SDK Manager detects that some of the files from the new SDK are replacing existing files in the project. By default, all conflicting files are set to replace the existing file. If desired, individual files can be deselected. Please note, with the checkbox for 'Backup project files' ticked, any files replaced will be preserved in a backup folder for future recovery, comparison, etc. In general, it may be wise to allow the file to be replaced and later merge with the customizations in the backup folder. For this example, no modifications were made, so default settings are kept. Click OK to complete the process. The .mex file contains the settings for the S32 Configuration Tools, however, it is still set for the SDK 4.0.1. It must be manually updated so the S32 Configuration Tools can be used to generate the new code for the 'board' folder. Right-click on .mex file and select 'Open With -> Text Editor'. All that is required is to modify the mcu_data section containing the SDK name: 's32sdk_s32k1xx_rtm_401' -> 's32sdk_s32k1xx_rtm_402' Now save the change. Next, the files in the 'board' folder must be regenerated from the S32 Configuration Tools to reflect the new SDK. Right-click on the .mex file and select 'Open With -> S32 Configuration Tools'. A warning message appears indicating that it has detected the mex file was created in an older version of the tool and that once the mex file is saved in the current tool, it may no longer open in an older version of the tool. This is expected. Click OK. Check for any errors or warnings by looking for the yield sign. It will change color based on the conditions: Green = No Problems, Yellow = Warnings, Red = Errors. Mouse-over the icon for more information on the location of the error. Aside from resolving warnings and errors, there should be no changes required as the settings have been preserved from the original project. In this example, there are no warnings or errors, so it is possible to proceed with updating the generated files. Click 'Update Code' A menu appears identifying new and/or updated files. If desired, selecting 'change' on a row will open a comparison tool showing the changes between the existing and the new versions of the associated file. Click OK to proceed. Change back to C/C++ perspective. Errors on project are now gone. If the project successfully built before the conversion, then build again to confirm everything was converted properly.

      Product Release Announcement Automotive Processing S32 Design Studio v3.4 Update 1 for S32G2         Austin, Texas, USA Apr 30, 2021 The Automotive Processing' Software Development Tools Engineering Team at NXP Semiconductors is pleased to announce the release of the  S32 Design Studio v3.4 Update 1 for S32G2 Here are some of major features:​ S32 Configuration Tool framework 1.4 with the Pin, Clock, Peripheral, DCD, IVT, DDR and QuadSPI Configuration tools (SDK/RTD packages required to get support for particular device)  Updates S32 Debugger  Updated S32 Flash Tool Update is available for online install on update site and for download on flexera  S32G2 support: (SW32G2_S32DS_3.4.1_D2104.zip) updated version of header files in accordance with RM Rev 3 Update is available for online install on update site and for download on flexera. Note that Update 1 (S32DS Platform Package version 3.4.1 and S32DS Platform Tools package version 3.4.1) is required for the S32G2 support package. It is included into archive for download. Installation instructions The update is available for online (via Eclipse Updater) or offline installation   online installation:  go to menu "Help" -> "S32DS Extensions and Updates" dialog  select from available items and click "Install/Update" button   offline installation:   go to S32 Design Studio product download page: S32 Design Studio for S32 Platform -> Downloads, click 'Download' button next to S32 Design Studio 3.4 -- Windows/Linux from the Product Information page, select S32 Design Studio 3.4 Update 1, support for S32G2 family then select 'SW32G2_S32DS_3.4.1_D2104.zip' to download the update archive zip file Start S32 Design Studio and go to "Help" -> "S32DS Extensions and Updates" Add the downloaded archive as a software site. Click "Add Software Site" and browse to select the archive file downloaded in the prior step        Select from available items and click "Install/Update" button. This will start the update installation process.   Technical Support please use public community for questions https://community.nxp.com/community/s32/s32ds  

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

S32DS ARM2.2 K144xx fPic Example description. Provided example demonstrate possibility of creation Position Independent Code using  standard  S32DS ARM 2.2 tools.  Example code blink RGB LED using svc interrupt handler. Output  picExample.bin should be loaded via restore gdb command only into existing K144 RAM area(0x1fff8000 – 20007000 for EVB board), then pc set to startup value.(see picExample_Debug_RAM_PNE_fpic  Debug configuration). Note: restore gdb command needs absolute path to *.bin file. Example is based on standard K144 application. Changes: -fPIC option should be set(Project->Properties->C/C++ Build ->Settings->Standard S32DS Compiler->Miscalenous->Position Independent Code). Create flash image checkbox should bes set.( Project->Properties->Cross Settings -> Create flash image). Flash Image output file format  should be set to Raw binary(Project->Properties->C/C++ Build ->Settings->Standard S32DS Create Flash Image ) Add -nostdlib linker option(Project->Properties->C/C++ Build ->Settings->Standard S32DS Linker->General ->No startup or default libs). Existing S was modified(stack pointer was corrected, bl instead of blx for function calls was used. Standard linker script was modified(see example) Interrupts vector table was moved to data area. Due to this vector addresses are corrected on startup by FixGot routine(see SystemInit()c) Common RAM area was declared starting from 0. __got_start and __got_end were declared in Global Offset Table   For an in-depth analysis and step-by-step guide on the topic of implementing position-independent code, please see the following blog at mcuoneclipse.com: Position-Independent Code With GCC for arm Cortex M 

Hi,     With S32DS and multilink, you can try the follow steps to dump flash or RAM data into file.  1. Attach    (https://community.nxp.com/t5/S32-Design-Studio/How-attach-to-running-program/m-p/1030375) 2. Export the data which you need    (https://community.nxp.com/t5/S32-Design-Studio/S32DS-how-to-properly-dump-RAM-in-debug-session/m-p/649974#M1089) Cheers! Oliver

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

The S32 Flash Tool is provided with support for a few QuadSPI flash memory devices which are typically the devices provided as part of the standard NXP EVB for each of the support NXP Automotive Processors. This will work for most users, but some may select a device for which support is not included with the tool. The FlashSDK was created to provide an easy method for adding support for additional QuadSPI flash memory devices to the S32 Flash Tool. First, a brief explanation of how the S32 Flash Tool works. The S32 Flash Tool programs external flash devices such as QuadSPI, SD, MMC, and eMMC. For each external flash device, there is a flash device-specific flash algorithm file. This flash algorithm file is downloaded by S32 Flash Tool to the target device SRAM, where it will be executed by the target device BootROM. The S32 Flash Tool then sends commands to the flash algorithm along with the image to be programmed to external flash. The flash algorithm will perform the programming of the image to the external flash device. The Flash SDK provides the capability to produce new flash algorithm files, which could then be uploaded to the target device by the S32 Flash Tool and then used to program images to the associated external flash device. The FlashSDK is provided in the form of a S32 Design Studio for S32 Platform v3.x project. This example project, as provided, will build and output a binary file similar to the MX25UM51245G.bin, MX25UW51245G.bin files included in the S32 Flash Tool. The project is designed to build for the Arm M7 core. It is located within the S32 Flash Tool installation directory and inside the folder 'FlashSDK_Ext'. For example, since the S32 Flash Tool is included within the S32 Design Studio 3.x, if the default installation settings were used, this could be found at the path: C:\NXP\S32DS.3.x\S32DS\tools\S32FlashTool\FlashSDK_Ext There is some limited documentation included with the FlashSDK, it can be found by navigating to the '...\FlashSDK_Ext\doc\html' directory and then open 'index.html' with your web browser. In this document, an example process for using the FlashSDK to produce a new binary file will be detailed. Prerequisites Install S32 Design Studio Locate or prepare an image file to be programmed to flash memory Setup hardware to Serial Boot mode Procedure Launch the S32 Design Studio Import the FlashSDK project, using copy to workspace option to preserve the original project. File -> Import Select 'Existing Projects from Workspace' Click 'Browse', locate and then select the 'FlashSDK_Ext' folder, check the box for 'Copy projects into the workspace' Open source files. The files in the project which should be modified for a new flash device are: ...\FlashSDK\Algo\Generic\qSPI_Algorithm.c and qSPI_chip_commands.h Locate the files within the Project Explorer and double click them to open them in the editor. Edit source files. The header file 'qSPI_chip_commands.h' contains many #defines for the flash memory chip which should be adjusted to your new device. Please refer to the reference manual provided by the flash device manufacturer for details on the correct values. As you can see, it is currently setup for the MX25UM51245G device from Macronix. Build the project. The project is setup for 2 build types for you, Debug and Release. The Release build type is more efficient and will run faster, and the Debug build type will allow you to run the debugger in attach mode to investigate issues with the changes you've made. Test new binary on the target and flash memory device. Follow the usual steps to use the S32 Flash Tool.

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

This instruction details the steps to create an image vector table, then subsequently generate a blob image which can be written to external flash on the S32R45 EVB. For this, the 'hello_world_s32r45' example project from the S32R45 SDK installed to S32 Design Studio IDE. This instruction shows the process for QSPI, however, SD, MMC, and eMMC are also supported.   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. Ignore the red shading on the Start address and Size in bytes fields for now. Now the red shading should be resolved. This is appearing because when the DCD section was enabled, it added a block to the Memory Layout map. But the other blocks in the map are unchanged resulting in overlaps. To resolve this, click on the ‘Align’ button from within the Automatic Align section.. After the Memory Map has been aligned, a confirmation message will be displayed and the red shading will disappear. In 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 (hello_world_s32r45\Project_Settings\Linker_Files\S32R45_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. Since the application binary file which was loaded 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 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. 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, use the S32 Flash Tool, or over the JTAG connection using the Flash Programmer within the S32 Debugger (QSPI only).

On reset, all module registers have default values. These settings are typically not ideal for achieving optimal system performance. Also, some peripherals must be configured before they can be used. DCD is the configuration information contained in the DCD image that BootROM uses to configure peripherals on the device. BootROM determines the location of the DCD table from the associated pointer in the IVT.   The main functionality of the DCD Tool is to generate the Device Configuration Data (DCD) image using the format and constraints as specified in the Boot ROM reference manual.   In the steps below, an example process for creating the DCD binary for initializing SRAM is shown. To initialize the SRAM, a logic '1' must be written to the INITREQ bit within the PRAMCR register of the SRAMC and SRAMC_1 peripherals.   Procedure With a project open in project explorer (C/C++ perspective), switch to DCD perspective. Click on the arrow next to the 'Open S32 Configuration' button and select 'Open DCD'. Check that correct project is selected  In DCD Commands panel, select Command Type 'Write', then click 'Set' Click 'Add Register', then set the following settings. Can start typing the names to filter the list for faster setting selection.   For Peripheral setting, select 'SRAMC'. You can search for it by typing the name. Register setting, select 'PRAMCR'. The list is short, so it is not necessary to type the name. In Bitfields, select 'INITREQ' Now click on the highlighted bit to set it. Again using 'New Command' box, repeat settings of steps 3 & 4, however, this time select Peripheral 'SRAMC_1'. If everything was done correctly, in the DCD Binary panel to the right, should appear as shown. If so, click 'Export'. The generated DCD file will be displayed. By default, C format is selected. Select Binary format and click OK. Select a location to save the file (such as the project folder in the workspace directory) and give it a meaningful name. Click Save. You are done! DCD image file is created in binary format and ready to be imported to IVT Tool.  

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

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

Trace functionality is supported in the S32 Debugger for A53 cores on the S32R, RAM-target builds. With Trace, you can record some execution data on an application project and then review it to determine the actions and data surrounding an event of interest.   This document outlines the method to begin using Trace on the S32R45 device. We start by creating a project on which to execute the trace, however, you may start at step 2, if you are starting with an existing project. Please note, you will need to have debug configurations for the S32 Debugger setup for each core which you intend to capture trace. If you do not already have such configurations, you may copy them from another project and adapt them to the new project as shown in HOWTO: Add a new debugger configuration to an existing project.   Create a new application project, selecting the 'S32R45 Cortex-A53' processor and 'S32 Debugger' options.  There should now be 4 new application projects in your workspace. One for each A53 core. The first core of the S32R45, A53_0_0, is also a possible boot core, so this project will have build configurations for RAM and FLASH. The other A53 cores (0_1, 1_0, 1_1) will not. Build all projects for Debug_RAM and check that they build clean before proceeding. Open 'Debug Configurations...' and select the 'Debug_RAM' configuration for the first core (A53_0_0_Debug_RAM_S32Debug). Select the 'Debugger' tab. Enter the Debug Probe Connection settings as appropriate for your hardware setup. Click Apply. Now select the Launch Group configuration for 'Debug_RAM'. It is important to use the launch group to start the debug for each core, not just because it makes it easier, but also because it is necessary to allow for some delay after the first A53 core is started before bringing the other A53 cores from reset to debug state. Press Debug Once the code is loaded to the target and the debugger has started each core and executed to the first line within main(), then it is ready to perform any of the standard debug functions including Trace. Trace does not start automatically, it must be turned on before it will start logging data. To do this, it is necessary to add the view 'Trace Commander'. It can be found by either Window -> Show View -> Other, then search for 'Trace Commander' or enter 'Trace Commander' in the Quick Access field of the toolbar and select Trace Commander from the list. The Trace Commander view will show in the panel with the Console, Problems, etc. Double-click on the tab to enlarge it. Click on the configure button to change settings. Click on the Advanced Trace Generators configuration button For each core to be logged, set the associated ELF file. Select the core, click Add, then '...', and select the elf file for that core. Select Data Streams. Now it is possible to change how the data is captured. Since the buffers have finite memory, they can be set to collect data until full, or to overwrite. If set to One buffer, the data will be collected until the buffer is full, then data collection stops. It is useful to gather data when starting logging from a breakpoint to gather data during execution of a specific section of code. If set to Overwrite, the data collection continues and starts overwriting itself once the buffer is full. This is useful when trying to gather data prior to a breakpoint triggered by a condition.  To turn on the Trace logging, click on the 'Close this trace stream' button. The Trace is now enabled. To collect trace data, the cores must be executing. First double-click the Trace Commander tab to return to the normal Debug Perspective view. Then, one by one, select the main() thread on each core and press Resume to start them all. If collecting from a breakpoint, start the code first with Trace disabled, wait for the breakpoint to be reached, then enable the Trace. Allow the cores to run for a period of time to gather the data, then press Suspend on each one until they are all suspended. Look to the Trace Commander tab to see that the data icon is no longer shaded and click on it to upload the trace data. A new tab, Analysis Results, has appeared. Double-click this tab to see it better. Click on the arrow next to ETF 0 to show the data collected in the trace buffer. Notice there are 5 separate views on the captured data: Trace (raw data), Timeline, Code Coverage, Performance, and Call Tree. Trace - this is the fully decoded trace data log Timeline - displays the functions that are executed in the application and the number of cycles each function takes, separate tabs for each core Code Coverage - displays the summarized data of a function in a tabular form, separate tabs for each core Performance - displays the function performance data in the upper summary table and the call pair data for the selected function and it's calling function Call Tree - shows the call tree for identification of the depth of stack utilization See the S32DS Software Analysis Documentation for more details on settings, ways to store the logged data, etc.

Trace functionality is supported in the S32 Debugger for A53 cores on the S32V, RAM-target builds. With Trace, you can record some execution data on an application project and then review it to determine the actions and data surrounding an event of interest.   This document outlines the method to begin using Trace on the S32V234 device. We start by creating a project on which to execute the trace, however, you may start at step 2, if you are starting with an existing project. Please note, you will need to have debug configurations for the S32 Debugger setup for each core which you intend to capture trace. If you do not already have such configurations, you may copy them from another project and adapt them to the new project as shown in HOWTO: Add a new debugger configuration to an existing project.   Create a new application project, selecting the 'S32V234 Cortex-A53' processor and 'S32 Debugger' options.  There should now be 4 new application projects in your workspace. One for each A53 core. The first core of the S32V234, A53_0_0, is also a possible boot core, so this project will have build configurations for RAM and FLASH. The other A53 cores (0_1, 1_0, 1_1) will not. Build all projects for Debug_RAM and check that they build clean before proceeding. Open 'Debug Configurations...' and select the 'Debug_RAM' configuration for the first core (A53_0_0_Debug_RAM_S32Debug). Select the 'Debugger' tab. Enter the Debug Probe Connection settings as appropriate for your hardware setup. Now select the Launch Group configuration for 'Debug_RAM'. It is important to use the launch group to start the debug for each core, not just because it makes it easier, but also because it is necessary to allow for some delay after the first A53 core is started before bringing the other A53 cores from reset to debug state. Press Debug Once the code is loaded to the target and the debugger has started each core and executed to the first line within main(), then it is ready to perform any of the standard debug functions including Trace. Trace does not start automatically, it must be turned on before it will start logging data. To do this, it is necessary to add the view 'Trace Commander'. It can be found by either Window -> Show View -> Other, then search for 'Trace Commander' or enter 'Trace Commander' in the Quick Access field of the toolbar and select Trace Commander from the list. The Trace Commander view will show in the panel with the Console, Problems, etc. Double-click on the tab to enlarge it. Click on the configure button to change settings. Click on the Advanced Trace Generators configuration button For each core to be logged, set the associated ELF file. Select the core, click Add, then '...', and select the elf file for that core. Select Data Streams. Now it is possible to change how the data is captured. Since the buffers have finite memory, they can be set to collect data until full, or to overwrite. If set to One buffer, the data will be collected until the buffer is full, then data collection stops. It is useful to gather data when starting logging from a breakpoint to gather data during execution of a specific section of code. If set to Overwrite, the data collection continues and starts overwriting itself once the buffer is full. This is useful when trying to gather data prior to a breakpoint triggered by a condition.  To turn on the Trace logging, click on the 'Close this trace stream' button. The Trace is now enabled. To collect trace data, the cores must be executing. First double-click the Trace Commander tab to return to the normal Debug Perspective view. Then, one by one, select the main() thread on each core and press Resume to start them all. If collecting from a breakpoint, start the code first with Trace disabled, wait for the breakpoint to be reached, then enable the Trace. Allow the cores to run for a period of time to gather the data, then press Suspend on each one until they are all suspended. Look to the Trace Commander tab to see that the data icon is no longer shaded and click on it to upload the trace data. A new tab, Analysis Results, has appeared. Double-click this tab to see it better. Click on the arrow next to ETF 0 to show the data collected in the trace buffer. Notice there are 5 separate views on the captured data: Trace (raw data), Timeline, Code Coverage, Performance, and Call Tree. Trace - this is the fully decoded trace data log Timeline - displays the functions that are executed in the application and the number of cycles each function takes, separate tabs for each core Code Coverage - displays the summarized data of a function in a tabular form, separate tabs for each core Performance - displays the function performance data in the upper summary table and the call pair data for the selected function and it's calling function Call Tree - shows the call tree for identification of the depth of stack utilization See the S32DS Software Analysis Documentation for more details on settings, ways to store the logged data, etc.

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 S32R4xx development package. This package is important as the S32 Debugger support component contains the device-specific Python scripts required for initialization of the cores. Open the application project from which the flash image will be generated. Follow the steps in HOWTO: Generate S-Record/Intel HEX/Binary file , selecting the 'Raw Binary' option. Build the project, generating the binary executable. This will be our application binary input to the IVT Tool. The IVT Tool must be used to generate the BLOB image which can be programmed to flash memory device and loaded to the RAM by the BootROM. Follow the steps in HOWTO: Use IVT Tool To Create A BLOB Image S32R45. The resulting BLOB image file is what can be flashed to the device.   Procedure Open Debug Configuration menu Select 'S32 Debugger Flash Programmer', then right-click and select New. Enter an name for the new configuration and click Add... to add the file to be flashed. Click Browse... to select the project from the workspace where the application binary is located Select the project and click OK By default, the ELF file is found. Click Search in project to select the binary file. Select the .bin file and click OK Now we must enter the base address. Typically, this could be 0, but you may have other requirements. Click OK. Now we are ready to configure the debugger connection settings. Click on the Debugger tab. Starting from the top and working our way down, click on Select device. Select the device and click OK The correct Initialization script will automatically be set. Set the Debug Probe Connection settings to match your setup. When done, click Apply To start the flashing, click Debug Flashing progress will be displayed. When complete, the Debug perspective will show at terminated thread. Happy flashing with GDB! Note, to debug this application since it will be subsequently started by the BootROM: use 's32r45_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”

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.

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