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

This document describes how to link a binary file(s) with an existing project in S32 Design Studio using GCC build tools. Let's demonstrate this on S32K144 project in S32DS for ARM. Nevertheless it should work with any other GCC based development tools. The first step is to add the binary file(s) into your project folder in the workspace. In the example below I created two binary files "my_bin.bin" and "my_bin2.bin" and added them into a custom folder "bin_files". I also entered 10 characters into each file. my_bin.bin: 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41 0x41  (represents 10 characters "A") my_bin2.bin: 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42 0x42  (represents 10 characters "B") The next step is to modify the linker configuration file (.ld) in order to specify input file format and path to the binary files (see the line 14-17) /* Specify the memory areas */ MEMORY { /* Flash */ m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000400 m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010 m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0007FBF0 /* SRAM_L */ m_data (RW) : ORIGIN = 0x1FFF8000, LENGTH = 0x00008000 /* SRAM_U */ m_data_2 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00007000 } TARGET(binary) /* specify the file format of binary file */ INPUT (..\bin_files\my_bin.bin) /* first bin file path (relative to the output folder)*/ INPUT (..\bin_files\my_bin2.bin) /* second bin file path (relative to the output folder)*/ OUTPUT_FORMAT(default) /* restore the out file format */ /* Define output sections */ SECTIONS { ... ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Finally, in the SECTIONS block of .ld file specify where to place the binary files (in the example it is placed at the end of .text section - see the line 37,38). /* Define output sections */ SECTIONS { /* The startup code goes first into internal flash */ .interrupts : { __VECTOR_TABLE = .; __interrupts_start__ = .; . = ALIGN(4); KEEP(*(.isr_vector)) /* Startup code */ __interrupts_end__ = .; . = ALIGN(4); } > m_interrupts .flash_config : { . = ALIGN(4); KEEP(*(.FlashConfig)) /* Flash Configuration Field (FCF) */ . = ALIGN(4); }> m_flash_config /* The program code and other data goes into internal flash */ .text : { . = ALIGN(4); *(.text) /* .text sections (code) */ *(.text*) /* .text* sections (code) */ *(.rodata) /* .rodata sections (constants, strings, etc.) */ *(.rodata*) /* .rodata* sections (constants, strings, etc.) */ *(.glue_7) /* glue arm to thumb code */ *(.glue_7t) /* glue thumb to arm code */ *(.eh_frame) KEEP (*(.init)) KEEP (*(.fini)) . = ALIGN(4); ..\bin_files\my_bin.bin /* First binary file */ ..\bin_files\my_bin2.bin /* Second binary file */ } > m_text ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ After successful compilation and link let's check map and s-record file (HOWTO: Generate S-Record/Intel HEX/Binary file ) to confirm the binary files have been linked correctly: .glue_7t 0x0000080c 0x0 linker stubs *(.eh_frame) *(.init) *(.fini) 0x0000080c . = ALIGN (0x4) ..\bin_files\my_bin.bin() .data 0x0000080c 0xa ..\bin_files\my_bin.bin 0x0000080c _binary____bin_files_my_bin_bin_start 0x00000816 _binary____bin_files_my_bin_bin_end ..\bin_files\my_bin2.bin() .data 0x00000816 0xa ..\bin_files\my_bin2.bin 0x00000816 _binary____bin_files_my_bin2_bin_start 0x00000820 _binary____bin_files_my_bin2_bin_end .vfp11_veneer 0x00000820 0x0 .vfp11_veneer 0x00000820 0x0 linker stubs‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ If you need a reference to the binary file block start/end address in your code you can use the linker symbols generated automatically or you can define your own symbols in the linker script. /* declare symbols from linker script file */ extern unsigned int _binary____bin_files_my_bin_bin_start; extern unsigned int _binary____bin_files_my_bin_bin_end; int main(void) { #define COUNTER_LIMIT 100 unsigned int counter = 0; unsigned int * bin_start_ptr; unsigned int * bin_end_ptr; bin_start_ptr = &_binary____bin_files_my_bin_bin_start; bin_end_ptr = &_binary____bin_files_my_bin_bin_end; for(;;) { counter++; counter = *(bin_start_ptr); /*loads 0x4141_4141 into counter*/ if(counter > COUNTER_LIMIT) { counter = 0; } } return 0; }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Note: if it is intended to place the binary file at specific absolute address (e.g. if binary file that represent bootloader) you have to create a separate custom MEMORY and SECTION block in .ld file. /* Specify the memory areas */ MEMORY { /* Flash */ m_bootloader (RX) : ORIGIN = 0x001000, LENGTH = 0x00010000 /* section for bootloadeer*/ m_text (RX) : ORIGIN = 0x00011000, LENGTH = 0x0040000 /*section for application code*/ ... } TARGET(binary) /* specify the file format of binary file */ INPUT (..\bin_files\my_booloader.bin) /* bootloader bin file path (relative to the output folder)*/ OUTPUT_FORMAT(default) /* restore the out file format */ /* Define output sections */ SECTIONS { /* place the bootloader binary into 0x0..0x10000 */ .bootloader : { ..\binary_files\my_bootloader.bin /* place the binary file here */ } > m_bootloader ... ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Enjoy linking binaries in S32 Design Studio!

This document describes two ways how to add a static library file (*.a) into your S32 Design Studio GCC project. These methods differs from each other in sense how a library update is reflected into project build process. Adding a static library WITHOUT dependency to executable (elf) file This approach assumes a library does not change. An update of the library does not trigger project rebuild process. If the library changes the project needs to be manually cleaned (assuming no other source file has changed) and next build links the updated library. The path to the library and the library name shall be entered into Project Properties -> C/C++ Build -> Settings -> Standard S32DS C Linker -> Libraries Please note that GCC adds prefix "lib" and the extension ".a"  to the library name entered into the above dialog by default. GCC linker will search for the library file named: "libtestlib.a" in the folder "c:\my_libs" In the example above. In case a library cannot be found the linker error occurs e.g. one depicted below. The linker library file name option "-ltestlib.a" is expanded into file name "libtestlib.a.a" which does not exist. 10:28:53 **** Incremental Build of configuration Debug for project S32K144_Project_with_library **** make -j8 all Building target: S32K144_Project_with_library.elf Executing target #5 S32K144_Project_with_library.elf Invoking: Standard S32DS C Linker arm-none-eabi-gcc -o "S32K144_Project_with_library.elf" "@S32K144_Project_with_library.args" c:/nxp/s32ds_arm_v2.0/cross_tools/gcc-arm-none-eabi-4_9/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld.exe: cannot find -ltestlib.a collect2.exe: error: ld returned 1 exit status make: *** [makefile:49: S32K144_Project_with_library.elf] Error 1 10:28:54 Build Finished (took 1s.332ms)‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ For a custom library name add colon character ":" at the beginning of the library name to disable the default prefix/extension expansion. GCC linker now searches for file name "testlib.lib" in the example below:   Adding a static library WITH dependency to executable (elf) file If a static library has changed - "touched"  it is sometimes desired to trigger project rebuild. In this scenario the library shall be added into a different project dialog: Project Properties -> C/C++ Build -> Settings -> Standard S32DS C Linker -> Miscellaneous -> Other objects The items from "Other objects" list is propagated into USER_OBJS makefile variable which is prerequisite for auto-generated makefile rule that build the target (elf): Enjoy linking static libraries in S32DS!

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

This document shows, how to set optimization level for whole project and how to edit single files with different optimization level. As soon as the project is created, it has set optimization level to 0 by default. This means, compiler do neither size optimization nor speed optimization. Optimization level can be set for every project according to the project requirements. 1) Optimization level set Right click the project and select project properties. Click C/C++ Build ->Settings->Standard S32DS C Compiler ->Optimization. You can see, optimization level is none -O0. Click the arrow on the right side of the list and choose the required optimization level. There are five options you can choose. Details description of the options are included in S32DS reference manual. Chosen optimization is used for all files in the project. 2) Change optimization level for single file in the project If you want to change optimization level for single file and do no affect another files, select required file, right click on it and select properties. As you can see, there are limited possibilities to set the file itself. Select required optimization level, click apply and close the window. Now, selected file has different options than the rest of the project. Hope it helps. Martin

Perhaps you are just using the S32DS for Power for the first time, and maybe you've seen the provided examples and want to learn a bit more about how they were created. Here are the steps to create a simple application for the MCP5748G MCU which toggles a pin causing one of the user LEDs to blink. This example includes use of the S32 SDK for Power Architecture. Please note: There are options in the steps below to cover the case of either the DEV-KIT(DEVKIT-MPC5748G) or Motherboard(X-MPC574XG-MB) with Daughtercard(X-MPC574XG-324DS) hardware EVBs. 1) Launch S32DS for Power 2) Select File -> New -> New S32DS Project 3) Enter a name for the project, such as 'BlinkingLED' 4) Locate, from the list of processors, Family MPC574xG -> MPC5748G, and select it. 5) Click Next 6) Uncheck the boxes for cores e200z4 and e200z2, leaving just e200z4 (boot) checked. This is because the application will run on the boot core and will not use either of the other two cores. 7) Click on the '…' button next to SDKs, in the column for BlinkingLED_Z4_0. 😎 Check the box next to MPC5748G_SDK_Z4_0_GCC to include support for the SDK within the new project and for the core we have selected. 9) Click OK 10) Click Finish to close the New Project wizard window and start the project generation. 11) Wait a minute or two for the project generation script to complete. 12) Go to the 'Components Library' view then locate and double-click on 'pit' component to add it to the project.  Alternatively, right-click and select Add to project. You can verify it was added by inspecting the 'Components - <project_name>' view. 13) With 'pit' selected in the 'Components - BlinkingLED_Z4_0' view, go to the 'Component Inspector' view to see the configurations for the PIT component. Locate the section for 'Configuration 0'. You may have to scroll down to see it. Change the 'Time period' setting to 500000 microsec(0.5 sec). Note that we are editing the settings for Clock configuration 'clockMan_InitConfig0', you will need the name of this configuration later. 14) Back in the 'Components' view, select 'pin_mux' component and return to the 'Component Inspector' view 15) From the 'Routing' tab, select the 'SIUL2' sub-tab and scroll down the Signals list until 'GPIO_0' (DEV-KIT) or 'GPIO_99' (Motherboard) is shown. 16) Change to the following settings: a. Pin/Signal Selection: PA[0] (DEV-KIT) / PG[3] (Motherboard) b. Direction: Output Pin PA0/PG3 is connected to user LED 2 on the evaluation board. 17) All configuration settings are now complete. Click Generate Processor Expert code button in the 'Components' view or use the menu bar Project-> Generate Processor Expert Code. 18) Wait for the code generation to complete. 19) Now, from the 'Project Explorer' view, the generated code is visible in the folder 'Generated_Code' of the project 'BlinkingLED_Z4_0'. 20) If not already open, in 'Project Explorer' open the file 'BlinkngLED_Z4_0\Sources\main.c' by double-click. This will open the file in the editor view. 21) Scroll down until the following comments are shown: /* Write your code here */ /* For example: for(;;) { } */ We need to add some code here to initialize the clocks, timers and pins. Then we will setup a timer interrupt handler to toggle the pin. 22) First we need to initialize the clocks. From the 'Components' view, expand 'clock_manager' and then drag & drop CLOCK_DRV_Init function into main() of main.c, just after the comments identified in the previous step within the text editor view. 23) Add to the function CLOCK_DRV_Init(), the parameter &clockMan1_InitConfig0 to give it the address of the user configuration structure generated by ProcessorExpert in '.../Generated_Code/clockMan1.c'. This is the clock configuration for which we edited the timer period in an earlier step. 24) Next we need to initialize the pins. Back in the 'Components' view, expand the 'pin_mux' then drag and drop the function PINS_DRV_Init after the clock initialization. 25) Again from the 'Components' view, expand 'interrupt_manager', then drag & drop INT_SYS_InstallHandler in 'main()'. This installs the PIT channel 0 interrupt handler. 26) Enter the parameters: PIT_Ch0_IRQn, &pitCh0Handler, NULL 27) In the User includes section at the start of main.c, add the implementation of the handler a. Create a function called pitCh0Handler b. In the function body: clear the interrupt flag and toggle LED   /* IRQ handler for PIT ch0 interrupt */   void pitCh0Handler(void)   { /* Clear PIT channel 0 interrupt flag */ PIT_DRV_ClearStatusFlags(INST_PIT1, 0U); /* Toggle LED (GPIO 0 connected to user LED 2) */ SIUL2->GPDO[0] ^= SIUL2_GPDO_PDO_4n_MASK; // DEV-KIT /* SIUL2->GPDO[99/4] ^=SIUL2_GPDO_PDO_4n3_MASK;*/ // Motherboard   } Note: Get PIT_DRV_ClearStatusFlags by drag & drop from the 'pit' component. 28) In 'Components' view, expand 'pit' component and then drag & drop PIT_DRV_Init, PIT_DRV_InitChannel & PID_DRV_StartChannel in main() after INT_SYS_InstallHandler(). 29) Fill in the second parameter of the last function(channel number): 0U 30) Build the code. Click the down arrow next to the 'Build' button and select Debug_RAM. Check that there are no build errors. 31) Enter the 'Debug Configurations' menu: a. From the menu bar, Run -> Debug Configurations... b. From the toolbar, down arrow next to Debug button -> Debug Configurations... 32) The Debug Configurations window appears. Select the configuration BlinkingLED_Z4_0_Debug_RAM from within the GDB PEMicro Interface Debugging group. 33) Select the 'Debugger' tab to setup the connection to the debugger hardware device. 34) Select the PEMicro Interface which corresponds to your setup: a. If using the motherboard, you will likely use the USB Multilink, which is connected to your PC via USB cable (type A on one end, type B on the other) and is connected to the motherboard via the 14-pin JTAG cable. b. If using the DEV-KIT board, you will likely choose the OpenSDA, which is integrated into the DEV-KIT board and is connected with just a USB cable (type A on one end, type micro on the other). 35) Click Debug To launch the debugging session. This will also open the Debug perspective. 36) In the Debug perspective, once the debugging session has fully launched, the code will be executed to the start of main(), where a breakpoint was automatically set for you. Press Resume button in the toolbar, Run -> Resume in the menu bar, or F8 on your keyboard to run the application. 37) You should now see the User LED2 on the board blink every 0.5 seconds. 38) To see the value of the output register bit for the output pin connected to the LED: a. Set a breakpoint on a line within pitCh0Handler() b. Go to the EmbSys Registers view, expand the SIUL2 module and scroll down to the GPDO register index which is accessed in the code. Double-click it to read the value. Expand it to see the individual bits. c. Press Resume a few times to see the register value change

        Product Release Announcement Automotive Microcontrollers and Processors S32 Design Studio for Power Architecture v1.2, Update 3            September 21, 2017   What is new? S32 SDK EAR 0.8.1 supporting MPC5748G & MPC5748C. The new project wizard now offers the new version of S32 SDK: "New S32 Project from Example" offers additional demos and examples. The complete S32 SDK EAR 0.8.1 release notes attached below. Installation instructions This is a cumulative installer - all previous updates (except previous version of S32 SDK EAR 0.8.0) are included so you do not need to install any previous update. The update is available for online (Eclipse Updater) or offline (direct download link) installation. online installation go to menu "Help" -> "Install New Software..." dialog  select predefined NXP S32 Design Studio update repository select all available items http://www.nxp.com/lgfiles/updates/Eclipse/S32DS_POWER_1_2/com.freescale.s32power.updatesite click "Next" button offline installation  go to S32 Design Studio product page -> Downloads section or use the direct download linkand download the "S32 Design Studio for Power v1.2 - Update 3" file. Start S32DS and go to "Help" -> "Install New Software..." Add a new "Archive" repository and browse to select the downloaded Update 3 archive file Select all available items and click "Next" button.