Hey everyone! If you are looking for concise steps to create and apply a patch in a yocto build, this article will serve you well. The reference taken in this article is of iMX93EVK yocto build. For this exercise, we are modifying a lpspi dts file in the BSP and creating a patch file but you may apply the same steps to other files in the BSP as well. Step-1 Make changes to the dts file in your directory example - arch/arm64/boot/dts/freescale/imx93-11x11-evk-lpspi.dts Step-2 In your yocto build, go to the git folder  cd imx-yocto-bsp-home/build_11x11/tmp/work/imx93_11x11_lpddr4x_evk-poky-linux/linux-imx/6.1.36+gitAUTOINC+04b05c5527-r0/git Step-3 Execute 'git diff' to check the difference between your changes and the default ones    Check the status by executing 'git status'     Step-4 Execute 'git add <file>'  , 'git commit -m <message>', and 'git format-patch -1' to add a file and create a git format patch file for your changes.   copy the generated patch file to a location which yocto build look for the patches Example- My yocto build looks for the patch in various locations, one of them is this one :- sources/meta-imx/meta-bsp/recipes-kernel/linux/files, so after creating the directory 'files', we can move the patch file to this folder    Step-5 Edit the .bb file for linux recipes-kernel for example - Open  /home/nxg06361/imx-yocto-bsp-home/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_6.1.bb  for editing Append the patch file name to the SRC_URI variable     You can also verify that your patch has been successfully applied or not by doing 'git log'   Voila ! that's all you need to do in order to create and apply a git patch for your yocto build.

The new NXP Pins Tool for i.MX Applications Processors which has been showcased at FTF 2016 in Austin is now available as desktop application: The Pins Tool makes configuring, muxing and routing of pins very easy and fast. It provides real-time feedback of conflicts and provides an intuitive graphical interface with several views. The tool generates device tree (.dtsi) and sources files which can be directly integrated into C/C++ applications. The following devices are supported: - i.MX 6Dual/Quad - i.MX 6DualPlus/QuadPlus - i.MX 6DualLite - i.MX 6Solo - i.MX 6SoloLite - i.MX 6SoloX - i.MX 6UltraLite - i.MX 7Dual - i.MX 7Solo The Pins Tool is available as download from http://www.nxp.com/pinsimx (Windows, Mac OS X and Linux 64bit) under the 'Software' category. There are two different installer types: 'offline' is a 140 MByte download. This method is recommended for slower internet connections or for installation on multiple machines. 'online' is a smaller download, all the other installation data will be loaded from the internet during installation. Mac OS X and Linux installers are 64bit. For Windows there are both 32bit and 64bit installers available. It is recommended to download the additional header files if not already installed/provided by your BSP because they are referenced by the initialization code. The header files are available in the following download under 'Headers': Documentation is available under the documentation section, as well attached to this article: For installation, check out the installation guide. For first steps, use the Getting started document. We hope you find this tool useful! i.MX Community | NXP Community: http://www.imxcommunity.org

An update is availale for Processor Expert for i.MX which updates i.MX6D and i.MX6Q support. Download PEx_i.MX_6DQ_ServicePack_Eclipse_Update_b150828.zip from the Downloads section on Processor Expert for i.MX|Freescale After the download, use the menu Help > Install New Software and point to the downloaded archive file: Press 'Next' and go through the installation process. This updates support for i.MX Dual and Quad support. Release Note Information Incremental update of Processor Expert Software for i.MX Processors v1.x i.MX 6Dual/Quad Service Pack Update Product Content * CPUs  iMX 6Dual, 6Quad - iMX6D processor in a single SoC component - iMX6Q processor in a single SoC component * Boards supported - Sabre AI Rev.A based on the i.MX 6Quad or 6Dual processors - Sabre AI Rev.B based on the i.MX 6Quad or 6Dual processors - Sabre Lite Rev.A based on the i.MX 6Quad or 6Dual processors - Smart Device SDB Rev.A based on the i.MX 6Quad or 6Dual processors - Smart Device SDB Rev.B based on the i.MX 6Quad or 6Dual processors - EVB Rev.X3 based on the i.MX 6Quad or 6Dual processors * PinMux configuration data for a PinSettings component based on the following sources - IMX6DQRM.pdf            Rev 3, 07/2015 - IMX6DQCEC.pdf        Rev 4, 07/2014 * Known problems and limitations - None. * Revision history Changes in device support since the PEx for i.MX v1.1.0, May 4th 2015 - Updated 6Dual/Quad device registers and functional properties configuration options according to the latest RM Rev.3, 07/2015. - Updated information and package ball names according to the latest datasheet Rev.4, 07/2015 http://www.freescale.com/peximx http://www.freescale.com Freescale Support Department: support@freescale.com

This document describes the creation of the Processor Expert LwIP demo application in KDS 3.0.0  (Processor Expert with KSDK 1.2.0) that allows communication via UDP/IP protocol within local network. There is also used DHCP protocol for leasing of the IP address in the local network (DHCP server must be available). This demo application demonstrates how to communicate with a user application on the target board via Ethernet. This demo project can be used a starting point for user’s application. The demo application provides the following functionality: LwIP stack initialization including the DHCP (DHCP is started to lease the IP address). The UDP is initialized and bind to port number 7 (receiving of broadcast is enabled) When a UDP packet is received the content is processed (a command is executed): There are supported following commands: LED GREEN ON – switch the green led on (the RGB led) on the FRDM-K64F board LED GREEN OFF – switch the green led off (the RGB led) on the FRDM-K64F board LED BLUE ON – switch the blue led on (the RGB led) on the FRDM-K64F board LED BLUE OFF – switch the blue led off (the RGB led) on the FRDM-K64F board LED RED ON – switch the red led on (the RGB led) on the FRDM-K64F board LED RED OFF – switch the red led off (the RGB led) on the FRDM-K64F board K64FIPRQ – send the IP address that is leased by DHCP in the message “IP addr: N.N.N.N” EXIT – exit the demo and stop the DHCP The debug logs are enabled and accessible by using a serial terminal (UART, baudrate 115200, data 8 bits, one stop bit, no flow control). Preparation First of all the KDS 3.0.0 and KSDK 1.2.0 must be installed. You can find instructions in the document Kinetis Design Studio Videos, Part 1: Installation of KDS and Kinetis SDK. LwIP stack 1.3.0 introduction LwIP is a small independent implementation of the TCP/IP protocol suite that has been developed by Adam Dunkels at the Computer and Networks Architectures (CNA) lab at the Swedish Institute of Computer Science (SICS). The focus of the LwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This making LwIP suitable for use in embedded systems with tens of kilobytes of free RAM and room for around 40-100 kilobytes of code ROM. LwIP features:     IP (Internet Protocol) including packet forwarding over multiple network interfaces     ICMP (Internet Control Message Protocol) for network maintenance and debugging     IGMP (Internet Group Management Protocol) for multicast traffic management     UDP (User Datagram Protocol) including experimental UDP-lite extensions     TCP (Transmission Control Protocol) with congestion control, RTT estimation and fast recovery/fast retransmit     raw/native API for enhanced performance     Optional Berkeley-like socket API     DNS (Domain names resolver)     SNMP (Simple Network Management Protocol)     DHCP (Dynamic Host Configuration Protocol)     AUTOIP (for IPv4, conform with RFC 3927)     PPP (Point-to-Point Protocol)     ARP (Address Resolution Protocol) for Ethernet The UDP packets are processed through the LwIP by the following way: You can find LwIP documentation on webpage http://www.nongnu.org/lwip/ or LwIP wiki pages http://lwip.wikia.com/wiki/LwIP_Wiki. New project The project is created in the KDS 3.0.0 by the following way: New Kinetis project (KSDK 1.2.0 and Processor Expert selected) for the FRDM-K64F target board is created. Clock configuration: System Oscillator 0 – external oscillator 50MHz New Clock configuration 6 – PEE, Core Clock 100Mhz, Bus Clock 50 MHz, External Bus Clock 25Mhz, Flash clock 25MHz LwIP library (stack) is linked to the project fsl_phy_driver.c/h driver is added into the project (from MQX RTCS) fsl_enet component added into the PEx project fsl_debug_console component added into the PEx project. It provides debug output and it is configured by the following way: fsl_hwtimer component added into the PEx project. It is configured for PIT timer to provide LwIP timing functionality. It is configured by the following way: fsl_gpio_hal component added into the PEx project to provide GPIO access for pins driving RGB LED on the FRDM_K64F board. The whole project contains following libraries, drivers and components: For  compilation and linking of the project are necessary also following LwIP library paths: "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\port" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\port\arch" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\ipv4" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\ipv4\lwip" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\ipv6" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\ipv6\lwip" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\lwip" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\netif" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include\posix" "${PROJECT_KSDK_PATH}\middleware\tcpip\lwip\src\include" This project can be built and can be used for the LwIP demo application design. Note: This application has been created by using KSDK UDP echo demo project source code. The UDP K64F app demo application code The UDP K64F app demo project contains the following initialization code for UDP and DHCP: /* initialization of LwIP stack */ /* Perform Sanity check of user-configurable values, and initialize all modules. */ lwip_init(); /* default IP addresses - DHCP is used */ IP4_ADDR(&fsl_netif0_ipaddr, 0,0,0,0); IP4_ADDR(&fsl_netif0_netmask, 0,0,0,0); IP4_ADDR(&fsl_netif0_gw, 0,0,0,0); /* Add a network interface to the list of lwIP netifs. */ netif_add(&fsl_netif0, &fsl_netif0_ipaddr, &fsl_netif0_netmask, &fsl_netif0_gw, NULL, ethernetif_init, ethernet_input); /* Set the network interface as the default network interface. */ netif_set_default(&fsl_netif0); /* obtain the IP address, default gateway and subnet mask by using DHCP*/ if (dhcp_start(&fsl_netif0) != ERR_OK) {          LWIP_DEBUGF(LWIP_DBG_ON, ("DHCP failed")); } /* initialize UDP on the port 7 */ udp_demo_init(); The udp_demo_init() initialize the pcb (protocol control block), bind the pcb to the port number 7 and set the callback function for receiving of UDP packets. The demo application can be closed by using the exit command. When the command is executed the UDP is disconnected (unbound) and DHPC is stopped (leased IP address is released). The following code is executed: /* UDP disconnect */ udp_demo_deinit(); /* finish the lease of the IP address */ dhcp_release(&fsl_netif0); Please note, that the exit command does not cause the restart of the demo application. The application finish in a infinite loop and it does not reply on any command that is send by using UDP packet. The reset is necessary for restarting of this application. The udp_echo_recv() callback function is used for receiving of UDP packets. This function process received data and execution of the following commands: LED GREEN ON – switch the green led on (the RGB led) on the FRDM-K64F board LED GREEN OFF – switch the green led off (the RGB led) on the FRDM-K64F board LED BLUE ON – switch the blue led on (the RGB led) on the FRDM-K64F board LED BLUE OFF – switch the blue led off (the RGB led) on the FRDM-K64F board LED RED ON – switch the red led on (the RGB led) on the FRDM-K64F board LED RED OFF – switch the red led off (the RGB led) on the FRDM-K64F board K64FIPRQ – send the IP address that is leased by DHCP in the message “IP addr: N.N.N.N” EXIT – exit the demo and stop the DHCP Note: The K64FIPRQ (K64F IP Request) command can be used for finding of this device in a local network. When a packet with this command is broadcasted the demo application sends the response “IP addr: N.N.N.N” and the device can communicate with demo application by using the leased IP address. See also the chapter Client demo application. Configuration of LwIP The default configuration of LwIP stack is available in the header file /UDP K64F app/lwip/src/include/lwip/opt.h. The UDP K64F demo application configuration parameters are available in the header file /UDP K64F app/lwip/port/lwipopts.h. There is enabled debug output (the fsl_debug_console is used) and also detailed debug for NETIF, UDP and DHCP, see the following part of the options in the lwipopts.h header file: /* ------------------------------------ ---------- Debugging options ---------- ------------------------------------ */ #define LWIP_DEBUG . . . /* detailed debug info for DHCP, UDP and NETIF */ #define NETIF_DEBUG                     LWIP_DBG_ON #define UDP_DEBUG                       LWIP_DBG_ON #define DHCP_DEBUG                      LWIP_DBG_ON If you need not this debug output you can undefined the LWIP_DEBUG symbol and/or define the detailed debug info symbols as: /* detailed debug info for DHCP, UDP and NETIF */ #define NETIF_DEBUG                     LWIP_DBG_OFF #define UDP_DEBUG                       LWIP_DBG_OFF #define DHCP_DEBUG                      LWIP_DBG_OFF The disabling of the debug output has also impact on the code size. The default configuration with debug output has the following code size: 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "UDP K64F app.elf" text         data          bss          dec          hex      filename 95308 180        75300 170788        29b24      UDP K64F app.elf 'Finished building: UDP K64F app.siz' Teh code size without debug output is following: arm-none-eabi-size --format=berkeley "UDP K64F app.elf" text         data          bss          dec          hex      filename 83024 180        75252 158456        26af8      UDP K64F app.elf 'Finished building: UDP K64F app.siz' Client demo application The UDP client application can be created by using Eclipse Java EE IDE. I have implemented a simple client terminal application the support UDP K64F demo application commands. This terminal application use the subnet mask and host IP address to create a broadcast IP address and send the K64FIPRQ message (command) in the UDP packet. If the FRDM-K64F target board with the demo application is connect to the local network the device send the response with IP address back to the UDP Client application. The received IP address is used for further communication by this application. When you select a command (write number and press the Enter in the terminal window) the selected command is sent and response text displayed. Note: You can run the application by using the Test UDP Client\Executable\TestClient_FRDM-K64F_demo.jar file or you can run the batch file Test UDP Client\Executable\TestClient_FRDM-K64F_demo.bat. Conclusion The LwIP stack library can be used as a static library in a Processor Expert project with embedded components (device drivers) that provides required functionality for the stack (physical layer of TCP/IP, timing and debug output). The Processor Expert allows using embedded components for rapid application development by using KSDK and therefore the demo application can be also used a starting point for customers' projects based on the K64 derivatives.

Introduction This document describes migration steps of CW MCU 10.6 projects with Processor Expert into KDS 3.0.0. Note: We strongly recommend backup of your original CodeWarrior application. If you want to use default configuration of compiler and debugger (toolchain) in KDS 3.0.0 use instructions described in the document Processor Expert project (CW MCU 10.6) migration into new project in KDS 3.0.0 The following document describes conversion of the whole project (toolchain configuration, source code files, Processor Expert configuration). Steps of the conversion by using CodeWarrior Converter and KDS Upgrade Assistant 1. Create a new workspace in KDS 3.0.0 (it is a workaround for KDS Upgrade Assistant that does not allow selection of migrated project in non-empty workspaces) 2. Import the project by using File > Import command, see below. Select File > Import, from the IDE menu.           The import dialog appears. Expand the General tree and select Existing Projects into Workspace. Click Next. The Import projects screen appears. Click Browse and select the root directory to search for an existing Eclipse project Select the projects you want to import in your Workspace Check Copy project into workspace if want to create a copy of the project in the workspace (otherwise the project is linked into the workspace only). Click Finish - the imported project appears in the Project Explorer view. 3 Convert CodeWarrior Project file by using command Convert CodeWarrior project file… in the context menu of the project in Project Explorer window, see detailed steps below. Select the recently imported legacy project you want to convert. Right-click and select Convert CodeWarrior Project file. Note: The context menu Convert CodeWarrior project file... will only work with GNU/gcc CodeWarrior project and not for CodeWarrior projects using the legacy Freescale compiler (for this compiler use instructions described in the chapter Steps of the conversion by manual configuration of the toolchain or Processor Expert project (CW MCU 10.6) migration into new project in KDS 3.0.0​). The CodeWarrior to KDS project migration assistant dialog appears and prompts whether you want to convert the project. Click Yes. The CodeWarrior to KDS project migration assistant will prompt that the conversion has completed and a backup of the original *cproject file has been created in .cproject_backup. Click to OK to close the CodeWarrior to KDS project migration assistant dialog. Note: To see the conversion process log, navigate to the project's root directory and open the KDSConverter.log file. 4. Process update of the project by using Project > KDS Upgrade Assistant… Select the project: Select settings for conversion (for details see the document Kinetis Design Studio: Migrating KDS V2.0.0 Projects to GNU Tools for ARM Embedded (Launchpad, KDS V3.0.0). For CodeWarrior project can be used following settings. Click on the Finish button to process the upgrade. Known Issues: The converter does not distinguish between Executable projects and Static Library projects. In the latter case the options for converting Newlib-nano and adding semihosting should be suppressed. When selecting options to add _exit() implementation and semihosting=rdimon on projects from KSDK_1.1.0demos\hello_world\kds a Cross ARM C Linker errors reports "multiple definition of _isatty". It is necessary to remove the user definition of _isatty. When you want to upgrade a converted CodeWarrior project you must use a new empty workspace otherwise the KDS Upgrade Assistant may not find the project in the workspace (the project is not displayed in the list of projects for the upgrade). GNU ARM Embedded (launchpad) on Linux - because the GNU ARM Embedded tools are 32-bit only for Linux, on Ubuntu 14.04 64-bit (and others) you may see error messages suggesting that arm-none-eabi-gcc could not be found. The tools do exist, however the system doesn't know how to run them. This is because the 32-bit compatibility packages need to be installed: See http://gnuarmeclipse.livius.net/blog/toolchain-install for details and suggested solution. 5. Remove all CW MCU 10.6 startup code (delete all files in the Project_Settings/Startup_Code project folder) and add a new Startup file by using Build options of CPU component: 6. Generate code (a new startup source code file is added into Project Settings/Startup_Code folder in the project). 7.Build the application. If the application is built without errors you can use it and debug it. If there are errors (e.g. linker error) check the Console window of the compiler and linker. There can be for example missing parameter of the selected target CPU – the toolchain settings (the configuration) is damaged and cannot be used due to the following issues: C/C++ Development Toolkit issues Editing the toolchain may damage the project In certain conditions, changing the toolchain for a project in the C/C++ Build → Tool Chain Editor page from another plug-in to GNU ARM Eclipse plug-in might not work; even worse, there are cases when the project is permanently damaged. There is not known way to repair such a broken project; you have to create a new project and copy the content (this is a CDT bug, not a plug-in bug). See the website http://gnuarmeclipse.livius.net/blog/known-problems/#Editing_the_toolchain_may_damage_the_project. Toolchain configuration Issue When you use the latest version of the GNU ARM Eclipse plugin you can get message "Orphaned CDT build configuration [org.eclipse.cdt.cross.arm.gnu.sourcery.windows.elf.debug.1561998926.1100932005.1237614533.626146708.187750101.514251714]: parent extension cfg [org.eclipse.cdt.cross.arm.gnu.sourcery.windows.elf.debug] not found". The “org.eclipse.cdt.cross.arm.gnu.sourcery.windows.elf.debug” ID comes from a project generated with the old version of the plug-in, no longer supported. Recreate the project with the latest version and it will work. See also http://sourceforge.net/p/gnuarmeclipse/support-requests/6/ In this case you must create a new configuration from a template and set all options manually. Skip following steps and continue below in the chapter Steps of the conversion by manual configuration of the toolchain. 8. Open the context menu of the project in the Project window and select Debug As > Debug Configurations. Add a new debug configuration, e.g. GDB SEGGEER J-Link Debugging. 9. Verify the settings of the debugger (for example select the Device Name). 10. Click on the Apply button and then on the Debug button. Steps of the conversion by manual configuration of the toolchain When the previous conversion process fails you can follow these instructions. Delete the converted project (that has been damaged) from the workspace and follow these steps. 1. Import the project by using File > Import command, see detailed steps in the previous chapter – Step number 2. 2. Select the C/C++ Build / Tool Chain Editor in the Properties of the project (see following screenshot). You see the warning message “Orphaned configuration ….”.  You must create a new configuration for this project (the current configuration is created by a previous version of plugins and it is not compatible). 3. Click on the Manage Configurations… 4. Click on the New button 5. Write the name of the new configuration and select the Copy Settings from. You can copy configuration from an existing project or you can use default template (the following description  suppose default configuration). 6. Click on the OK button. New configuration is created. 7. Select the old configuration and click on the Delete button. 8. Click on the OK button. 9. The new configuration is selected in the Properties window, see below: 10. Click on the Apply button. 11. Select the C/C++ Build/Settings, Tools Settings tab (in the same Properties window). 12. On the Target Processor page select the correct target Processor, the ARM family e.g. cortex-m0plus for KL25Z. Click on the Apply button. 13. On the Optimization page select the Optimization Level: None (-O0). Click on the Apply button. 14. On the Debugging page select the Debug level: Maximum (-g3). Click on the Apply button. 15. On the Cross ARM C Linker / General page add the following script:      Script files (-T): "${ProjDirPath}/Project_Settings/Linker_Files/ProcessorExpert.ld" 16. On the Cross ARM C Linker / Libraries page add the following script:      Library search path (-L): "${ProjDirPath}/Project_Settings/Linker_Files/" 17. On the Cross ARM C Linker / Miscellaneous page add the following script:       Check the option: Use newlib-nano (--specs=nan.specs)      Add the following parameter to the Other linker flags:  -specs=nosys.specs 18. Click on the Apply button. 19. Set the Build Artifact (see below) and click on the OK button. 20. Remove all CW MCU 10.6 startup code (delete all files in the Project_Settings/Startup_Code project folder) and add a new Startup file by using Build options of CPU component: 21. Generate code (a new startup source code file is added into Project Settings/Startup_Code folder in the project). 22. Build the application. 23. If you see the following error: Error: Cannot run program "gcc": Launching failed Modify the PATH variable in the Properties of the Project. Select C/C++ Build/Environment page, double-click on the PATH variable and add the absolute path to the folder KDS_3.0.0\toolchain\arm-none-eabi\bin\ (e.g. add c:\Freescale\KDS_3.0.0\toolchain\arm-none-eabi\bin\; at the beginning of the PATH values). Click on the OK button. Build the application again. The project should be compiled without any error. If you still see any toolchain settings error and you are not able to fix these issue use instructions described in the document Processor Expert project (CW MCU 10.6) migration into new project in KDS 3.0.0​. 24. Open the context menu of the project in the Project window and select Debug As > Debug Configurations. Add a new debug configuration, e.g. GDB SEGGEER J-Link Debugging. 25. Verify the settings of the debugger (for example select the Device Name). 26. Click on the Apply button and then on the Debug button. The application is migrated and debugging should work properly.

This document describes the manual conversion of a (CodeWarrior MCU 10.6) Processor Expert project by creating of a new project in KDS 3.0.0 for the same target MCU and copying of Processor Expert project and user source code. This options of the CodeWarrior (or Driver Suite) project conversion provide an easy way how to convert the project but all customized settings of compiler, linker and libraries must be set manually in the new KDS 3.0.0 project again (this configuration will not be migrated). The migration of the whole CodeWarrior project is described in the document CW MCU 10.6 Processor Expert projects migration into KDS 3.0.0 Steps: 1. Create a new Kinetis project for the same target MCU (navigate to menu File > New > Kinetis Project). Write a new project name (you can write the same name of the original project). Select the same target MCU (or a target board that use the same target MCU). Kinetis SDK – select None Check Processor Expert Select the compiler that is available (installed) in your KDS 3.0.0 installation (GNU C Compiler is available by default). 2. Remove all Processor Expert components from the project (delete all CPUs and components if included). All components will be imported from the original project. 3. In the Components windows, navigate to the View Menu > Import > Import Processor Expert Component Settings 4. In the Import Processor Expert Component Settings windows, click on Browse button 5. In the dialog, select *.pe file extension and select the ProcessorExpert.pe from the original CodeWarrior Processor Expert project. Click on the Open button. 6. In the Import Processor Expert Component Settings windows select the target project (the new project). 7. The window contain list of all components that can be imported (added). You can select components that can be omitted (all will be imported by default). 8. Click on the Finish button. All selected components are imported and no warnings and errors should be reported. 9. Open the folder with the original CodeWarrior project and drag-and-drop source code files (copy files) from the  CodeWarrior project into the new project created in KDS (select Copy files).   Please note, that CodeWarrior projects have the main() function in the ProcessorExpert.c file but the Kinetis Project uses the main.c (copy the content or you can rename the copied ProcessorExpert.c file) . 10. If necessary you can customize the project settings of the project by using Properties (in the Project Explorer window open the context menu of the project and select Properties). You can select the settings that are required by your application (optimization level, adding path to external libraries and so on). 11. Generate the Processor Expert code and Build the application. When all source code is copied (and customized settings and paths are properly set) the application is compiled without any errors and warnings. Debugger connection are pre-configured in the new Kinetis Project in KDS 3.0.0 by default.

This article describe procedure how to properly install KSDK 1.1.0 support in KDS 2.0.0 (Kinetis Design Studio) and also additional steps to update GCC compiler and debug firmware on the FRDM-KL03Z board. KDS 2.0.0 installation If you don’t have KDS 2.0.0, please get the installation package (for Windows and Linux) on Freescale website. Go to the page Kinetis Design Studio Integrated Development Environment (IDE), select the build and install it. Kinetis SDK installation The KL03Z derivative support is distributed as a part of KSDK 1.1.0 release.  Download the Freescale Kinetis SDK 1.1.0 Windows or Linux installer and install it. After the KSDK 1.1.0 is installed you need also install the KSDK_1.1.0_Eclipse_Update. In the KDS main menu select Help > Install new software… , click on Add.. button, click on Archive and select KSDK_1.1.0_Eclipse_Update.zip in the KSDK subfolder (e.g. c:\Freescale\KSDK_1.1.0\tools\eclipse_update\KSDK_1.1.0_Eclipse_Update.zip): Additional Steps for Kinetis L family Next step is to install the updated GCC compiler. This is due to C standard library footprint issue in the GCC version that is distributed in KDS 2.0.0. For example, the KL03Z derivatives contain small amount of RAM memory and therefore this step is also strongly recommended. Download the latest GNU GCC ARM as a zip file from https://launchpad.net/gcc-arm-embedded, and install the file. Navigate to the KDS 2.0.0  install directory, locate the <install_dir>/ KDS_2.0.0/toolchain folder, and copy all files from the folder “<install dir>/GNU Tools ARM Embedded/4.8 2014q3” (e.g. c:\Program Files\GNU Tools ARM Embedded\4.8 2014q3) to this folder of KDS 2.0.0. Please note that when you update the GCC you must change the linker flags for every new project with GCC to “-specs=nano.specs -specs=nosys.specs” as described in the document. (otherwise the default setting of linker flags will cause an error of GCC linker). If you haven’t done that yet, update firmware of the FRDM-KL03Z board to allow application flashing and debugging (see https://segger.com/opensda.html).  For detailed instructions see OpenSDA User's guide and FRDM-KL03Z User’s Guide.   For example, you can start creating a new application for the KL03 according to instructions in document  Low power demo application on FRDM-KL03Z board with KSDK 1.1.0

This document describes the creation of the Low power demo application (Low power demo application on FRDM-KL03Z board ) in KDS 2.0.0  with latest version of KSDK 1.1.0. It is an update of the previous document because the KSDK 1.1.0 implementation brings new features that makes design of a low power demo application more complicated. This document describes the creation of the following low power demo application: When the application starts the green LED blink one time, The RTC device  alarm is set to 15 second  (external oscillator 32768Hz is used) to wakeup CPU and the CPU enters the VLLS1 mode (VLLS0 mode cannot be used with external oscillator).  The CPU wake up is possible by the following ways: - When you push the SW2 button the processor is woken and the green LED start blinking (5 times). - When you short the pin PTB6 to ground 5 times (the pin is available on the 8 pin header connector – pin number 4; you can for example connect a button to the pin number 4 and ground) the processor is woken and the green LED start blinking (5 times). - When selected RTC timeout expired (15 seconds) the processor is woken by the alarm interrupt and the green LED start blinking (5 times). The application is initialized again and recovery from the VLLS1 mode is executed. The alarm is set again to 15 second and the CPU enters the VLLS1 mode again. Preparation First of all the KDS 2.0.0 and KSDK 1.1.0 must be installed. You can find instructions in the document  How to install Kinetis SDK 1.1.0 support in KDS 2.0.0. New project When you properly install and update all the software you are prepared to create the Low power demo application. Create a new Kinetis design Studio project: Select the FRDM-KL03Z board Select the Kinetis SDK path to the KSDK 1.1.0 and select Processor Expert The application is created and there are not any warnings reported in the Problems window. But there is another issue. The fsl_os_abstraction component in the OSs group is added into application (it was not in the KSDK 1.0.0) and it allocated LPTMR device in the inherited fsl_lptmr_hal  component: The only solution of this conflict is removal of this component (the low power demo needn’t any OS; it is a simple application only). But this component is used by fsl_clock_manager and the fsl_clock_manager is used by PinSettings componnet. So you must remove all these component ( fsl_os_abstraction, fsl_clock_manager, PinSettings). When the PinSettings is removed from the project all signal names are also removed and you must select pins in the Cpu component again: The PinSettings component must be replaced by Init_GPIO component that allows settings of GPIO pins including routing and electrical properties. Add the Init_GPIO component into the project and set following properties (switch to Advance view): Select Device - GPIOB Set Settings/Clock Gate to Enabled. Set Settings/Pin 0 group to Initialize and select following properties of this pin (LLWU_P4): Pin Direction – Input Pull resistor – Enabled Pull selection  - Pull Up Set Settings/Pin 6 group to Initialize and select following properties of this pin (LPTMR_ALT3): Pin Direction – Input Pull resistor – Enabled Pull selection  - Pull Up Set Settings/Pin 11 group to Initialize and select following properties of this pin (PTB11 – GREEN LED): Pin Direction – Output Output value  – 1 Set Pin selection/routing/Pin 11 to Enabled. The Pin 11 group is open and the PTB11 is selected as the Pin (GPIO functionality). These settings provide initialization code for routing of selected pins and also GPIO functionality for PTB11 that used for driving of the green LED of the RGB LED on the freedom board. There is also necessary to change the linker settings when you have installed the new version of GCC tools (according to the document How to install Kinetis SDK 1.1.0 support in KDS 2.0.0 - Additional Steps for Kinetis L family chapter) Open the context menu of the project, select Properties item and change the Other linker flags settings to “-specs=nano.specs -specs=nosys.specs”, in C/C++ Build / Settings,  Tools Settigns tab, Cross ARM C++ Linker/Miscellaneous: Tip: If you want to know details of compiled code and the code size, you can use the following options to create extended list file and print code size info on the following Toolchains tab: You can generate Processor Expert code and process Build of the application without any error and warning. When the Build is finished the following information is provided in the Console window: 'Invoking: Cross ARM GNU Create Listing' arm-none-eabi-objdump --source --all-headers --demangle --line-numbers --wide "Low power demo KL03.elf" > "Low power demo KL03.lst" 'Finished building: Low power demo KL03.lst' ' ' 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf" text         data          bss          dec          hex      filename 1480          108          876         2464          9a0      Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' ' ' Note: You can see that the memory footprint is quite small because all SDK component are removed. Routing of pins Routing of pins is provided by Init_GPIO and other components in the project. There will be used following pins: SW2 - ADC0_SE9/PTB0/IRQ_5/LLWU_P4/EXTRG_IN/SPI0_SCK/I2C0_SCL – input pin for the SW2 button on the board as LLWU wakeup pin GPIO pin – PTB6/IRQ_2/LPTMR0_ALT3/TPM1_CH1/TPM1_CLKIN1 – input pin of LPTMR device LED_GREEN - PTB11/TPM0_CH0/SPI0_MISO - output pin that driver the green LED of the RGB LED on the board Adding Processor Expert components Now you can add all components for the low power demo application. fsl_gpio_hal to control GPIO pins Init_LLWU and fsl_llwu_hal components to control LLWU device Init_SRTC and fsl_rtc_hal to control RTC device Init_LPTMR and fsl_lptmr_hal to control LPTMR device fsl_smc_hal to control SMC (System Mode Controller) device CPU device We are going to use external oscillator 32768Hz and we need to configure device to allow Very Low Leakage Stop modes. There we set following properties in the Component Inspector of the CPU (switch to Advance view): Check that the Clock settings/Clock Sources/System oscillator 0 is Enabled and set Enable in stop to Enabled. The Clock source, clock pins and clock frequency are preset for the FRDM-KL03Z board Go to the Clock configuration/Clock Configuration 0 and set: Internal reference clock/Slow IRC frequency to 2MHz (it is enough for our demo application and it also decrease power consumption). MCG lite settings/MCG mode set to LIRC_2M Very low power mode to Enabled (leave setting of VLP mode entry to User because the VLLS1 mode is entered after blinking; we will write the code to enter VLLS1 mode) System clocks/Core clock set to 0.5Mhz System clocks/Bus clock set to 0.5Mhz (it allow us to enter very low leakage stop modes) Set Low Power mode setings/Acknowledge isolation to Not allowed value (we will do it in the user code) GPIO pins Open the Component Inspector of fsl_gpio_hal componet, switch to Advance view and set following properties: Select Device - GPIOB LLWU (Low-Leakage Wakeup unit) device Open the Component Inspector of Init_LLWU, switch to Advance view and set following properties: Set Settings/External Source/Pin 4 to Any edge value (we will use this pin that is connected to SW2 button) Set Pins/Pin 4 to Enabled and select  the Pin ADC0_SE9/PTB0/IRQ_5/LLWU_P4/EXTRG_IN/SPI0_SCK/I2C0_SCL in the item below Set Initialization/Utilize after reset values to no We will use the LLWU to wake-up the CPU and we need not any interrupt. RTC (Real Time Clock) device Open the Component Inspector of Init_SRTC, switch to Advance view and set following properties: Set Settings/Clock gate to Enabled Set Settings/Oscillator settings/Oscillator state to Enabled (it enable external oscillator also in stop modes) Set Settings/Time settings/Alarm time [s] to 15 (15 seconds timeout to wake-up from VLLS1 mode) Set Interrupts/ RTC interrupt/Interrupt request to Enabled Set Interrupts/ RTC interrupt/Time overflow interrupt to Disabled Set Interrupts/ RTC interrupt/Time invalid interrupt to Disabled Set Initialization/Time counter to Enabled Set Initialization/Utilize after reset values to no LPTMR (Low-Power Timer) device Open the Component Inspector of Init_LPTMR, switch to Advance view and set following properties: Set  Settings/Clock gate to Enabled Set Settings/Clock settings/Clock select to Internal 1kHz LPO (this clock source is enabled in the VLLS1 mode) Set Settings/Clock settings/Prescale value/Glitch filter to Prescaler/64; Glitch Filter 32 (it will eliminates glitches on connected button that will be used for generating pulses) Set Settings/Compare value to 4 (the LPTMR interrupt is invoked when the compare value is equal to counter and the counter value is increased, i.e. 5 pulses on the input pins invoke the LPTMR interrupt) Set Settings/Timer mode to Pulse Counter (we will use the timer to count external pulses on the input pin 3) Set Settings/Pin select to Input 3 Set Settings/Pin polarity to Active Low Set Pins/Input pin 3 to Enabled and select PTB6/IRQ_2/LPTMR0_ALT3/TPM1_CH1, TPM_CLKIN1 in Pin 3 item. Set Interrupts/Interrupt request to Enabled Set Interrupts/Timer interrupt to Enabled (we will use the timer interrupt to wakeup CPU from VLLS1 mode after 5 pulses on the input 3 pin) Set Initialization/Timer enable to yes Set Initialization/Utilize after reset values to no We have finished design time settings of Processor Expert components and we are ready to write the application code. When you generate code and Build the application there will not be any error or warning. The Processor Expert project looks as follow: Application code During the component settings we have enabled two interrupt – RTC interrupt and LPTMR interrupt. Therefore we need to write theses interrupt service routines. If you look for example into RTC.h file, you can find the declaration of the RTC_IRQHandler interrupt routine. So we can use the declaration to write the definition of the routine in the main.c program module: #define RTC_ALARM_TIMEOUT_SEC 15 /* RTC interrupt service routine */ PE_ISR(RTC_IRQHandler) { if (RTC_HAL_HasAlarmOccured(RTC_BASE)) {   // set the next alarm in RTC_ALARM_TIMEOUT_SEC seconds (clear also the TAF flag)   RTC_HAL_SetAlarmReg(RTC_BASE,RTC_HAL_GetAlarmReg(RTC_BASE) + RTC_ALARM_TIMEOUT_SEC); } if (RTC_HAL_IsTimeInvalid(RTC_BASE)) {        /* clear TIF (Time Invalid Flag) by stop of the counter and setting TSR reg */        RTC_HAL_EnableCounter(RTC_BASE, false);        RTC_HAL_SetSecsReg(RTC_BASE, 0);        /* enable counter */        RTC_HAL_EnableCounter(RTC_BASE, true); } } This interrupt routine services the Alarm interrupt in case that it is invoked during blinking of the green LED in the run mode (clear the flag and set the new Alarm time) and also it services the Invalid Time interrupt that can occur during recovering from the VLLS1 mode. Please note, that RTC module is little bit special , it runs in all  run, wait and stop modes and the reset enables the Time Invalid interrupt bit (TIIE bit in RTC_IER) and invoke the Time Invalid interrupt on reset (POR or software reset). Therefore we need to clear the Invalid Time flag otherwise the application remain invoking RTC interrupt in an infinite cycle and the application does not work at all (it is also one of the issue that has not a straight forward solution). The RTC interrupt routine (defined above) shall properly serve all case we need in our application. Please note, that RTC interrupt always cause the wake-up from low-leakage stops modes (it is not configurable by LLWU on KL03 derivatives – see the chip-specific LLWU information). In addition, the after reset value of RTC_SR register is 0x01 (TIF flag is set). Therefore when the RTC is not initialized and a low-leakage stop mode is entered the CPU is immediately woken-up due to the RTC module interrupt flag (TIF flag is set). I.e. you must always properly initialize RTC module and clear all flags before you enter a low-leakage stop mode. We need also a service routine for the LPTMR device that is used for waking up from VLSS1 mode. This is a simple interrupt service routine that just clear the LPTMR interrupt flag: /* LPTMR interrupt service routine */ PE_ISR(LPTMR0_IRQHandler) {   /* clear LPTMR interrupt flag */   LPTMR_HAL_ClearIntFlag(LPTMR0_BASE); } Now we can write the main function. We will need a temporary count variables for blinking: /* Write your local variable definition here */ volatile uint32_t i; // for waiting uint8_t blink_count; We need also a definition of the pin PTB11 that drivers the GREEN LED /* PTB11 - LED GREEN pin */ #define LED_GREEN_PIN 11 And the number of LED blinking: #define LED_BLINK 5 After devices initialization in PE_low_level_init() we need to check the reason of reset (POR reset or VLLS1 recovery). Thus we can write following code: /* Write your code here */   if (RCM_SRS0 == 0x01) { /* test the reason of reset - wakeup on VLLS */     if(PMC->REGSC &  PMC_REGSC_ACKISO_MASK) {       PMC->REGSC |= PMC_REGSC_ACKISO_MASK; /* VLLSx recovery */     }     for (blink_count = 0; blink_count < LED_BLINK; blink_count++) {        // green LED blinking     GPIO_HAL_ClearPinOutput(GPIOB_BASE,LED_GREEN_PIN);        for (i = 0; i<40000; i++);     GPIO_HAL_SetPinOutput(GPIOB_BASE,LED_GREEN_PIN);         for (i = 0; i<40000; i++);   }     // set the next alarm in "RTC_ALARM_TIMEOUT_SEC" seconds (clear also the TAF flag)     RTC_HAL_SetAlarmReg(RTC_BASE,RTC_HAL_GetAlarmReg(RTC_BASE)+RTC_ALARM_TIMEOUT_SEC);   } else {       /* power-on reset */       /* switch the green LED on */     GPIO_HAL_ClearPinOutput(GPIOB_BASE,LED_GREEN_PIN);        /* wait a while */        for (i = 0; i<40000; i++);        /* switch the green LED off */     GPIO_HAL_SetPinOutput(GPIOB_BASE,LED_GREEN_PIN);   } In case of VLLS1 recovery we acknowledge the pin isolation ACKISO bit in the PMC_REGSC register. This bit must be cleared to allow normal run mode of all pins. Then five blinking of the green LED follows (it is just a simple code for demo purposes only; you can write your own more sophisticated code for blinking by TPMx device with Init_TPM component if you want). In case of POR reset one blink of the green LED is processed. When the reset/wakup state is served by the our application code the VLLS1 mode can be entered. As the first step, we need to be sure that there are not any interrupt flags set to wake-up the CPU from VLLS1 mode so we clear LLWU and SW2 pin (PTB0) interrupt flags and then we enter VLLS1 mode by using enter_vllsx function: /* clear LLWU flag for the selected pin 4 - PTB0 */ LLWU_F1 |= LLWU_F1_WUF4_MASK; /* clear interrupt flag of the SW2 pin - PTB0 */ PORTB_PCR0 |= PORT_PCR_ISF_MASK; // enter the VLLS3 //enter_vllsx((smc_por_option_t)NULL,kSmcStopSub3); // enter the VLLS0 - RTC and LPTMR do not work becuase of external crystal clock source does not work in the VLLS0 mode //enter_vllsx(kSmcPorEnabled, kSmcStopSub0); // enter the VLLS1 enter_vllsx((smc_por_option_t)NULL,kSmcStopSub1); // switch the green LED on - error state when the VLLSx mode is not entered GPIO_HAL_ClearPinOutput(GPIOB_BASE,LED_GREEN_PIN);  There is also code for switching on the green LED in case the VLLS1 mode is not entered (indication of the error state). The enter_vllsx function is defined by the following way (it is used existing function from a demo KSDK demo example): /* * VLLSx mode entry routinue */ static void enter_vllsx(smc_por_option_t PORPOValue, smc_stop_submode_t VLLSValue) {        smc_power_mode_config_t smcConfig;        /* set power mode to specific VLLSx mode */        smcConfig.porOption = true;        smcConfig.porOptionValue = (smc_por_option_t) PORPOValue;        smcConfig.powerModeName = kPowerModeVlls;        smcConfig.stopSubMode = (smc_stop_submode_t) VLLSValue;        SMC_HAL_SetMode(SMC_BASE, &smcConfig); } It is all code we need for our low power demo application. The application can be built and run now. 'Invoking: Cross ARM GNU Create Listing' arm-none-eabi-objdump --source --all-headers --demangle --line-numbers --wide "Low power demo KL03.elf" > "Low power demo KL03.lst" 'Finished building: Low power demo KL03.lst' ' ' 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf" text         data          bss          dec          hex      filename 7828          112          896         8836         2284      Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' ' ' Note: You can see that the code size has increased because SDK functions have been used in the application. This is partly due to usage assert function that allows reporting of error by using standard libraries. If you needn’t this functionality and you need just a compact code (to decrease the power consumption) you can do it by the following way: Open Properties of the Low power demo KL03 application, select C/C++Build/Settings, on the Tool Settings tab, select Cross ARM C Compiler/Preprocessor and add NDEBUG symbol in the Defined symbols list: When you Clean and Build the application again the code size is reduced: 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf" text         data          bss          dec          hex      filename 3192          108          876         4176         1050      Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' ' ' 08:20:28 Build Finished (took 15s.886ms) There is also additional step that allows you to reduce the code size of the application. You can set Optimization Level of GNU C tools. Open Properties of the Low power demo KL03 application, select C/C++Build/Settings, on the Tool Settings tab, select Optimization and set the Optimization Level to requested value (please note that some of the level are not suitable for debugging): Debugging The application contain predefined  debug connect by default. . When you open the context menu of the project in the Project Explorer window and select Debug As/Debug Configurations.... The Debug Configurations window is opened and you can select and configure all predefined debug configurations (OpenOCD, PE Micro, Segger J-link). The default configuration can be easily used with the Freedom board (OpenSDA interface – j-link or PE Micro). You can just select the right debug connection and click on the Debug for debugging of your application. In the Debug Configuration window open the GDB SEGGER J-Link Debugger  group and select the Low power demo KL03 Debug configuration. See the Debugger tab, there is already filled MKL03Z32xxx4 Device name. Uncheck Allocate console for semihosting and SWO (SWO is not support by OpenSDA SEGGER J-link). Go to on Startup tab and uncheck the Enable SWO option (SWO is not supported by OpenSDA SEGGER J-link). Click on the Apply and Debug button and the debugger starts (you must have the FRDM-KL03Z board connect to the workstation). You can now start the application (click on the Resume button) and check the functionality. The debugger is disconnected due to VLLS1 mode entry. But the application run and can be used. If you want to connect a button for the LPTMR pulses generating you can connect one pin of the button to the PTB6 on pin #4 of 8-pins connector J1 and the second pin of the button to the GND to the pin #7 of the 10-pins connector J2, see below: You can use this demo application as a start point of your real low power application. I hope it will help you and save your time of your first low power application implementation in the Processor Expert. There is also possible to measure power consumption of the CPU in VLLS1 mode. It is described in the FRDM-KL03 User Guide. Just unsolder R27 and R28 and solder a header pins to J10 position of the board. You must use jumper for J10 now to connect power supply for the CPU and when the jumper is removed you can use these two pins to measure the energy consumption of the CPU (e.g. by a multimeter)

This file can be used on the MC56F8322 device to output clock signals to pins for checking the ROSC frequency as trimed by the factory trim values. The code was generated by processor expert with GUI selections made in Code Warrior IDE.

This document describes the creation of the following low power demo application: When the application starts the green LED blink one time, The RTC device  alarm is set to 15 second  (external oscillator 32768Hz is used) to wakeup CPU and the CPU enters the VLLS1 mode (VLLS0 mode cannot be used with external oscillator).  The CPU wake up is possible by the following ways: - When you push the SW2 button the processor is woken up and the green LED start blinking (5 times). - When you short the pin PTB6 to ground 5 times (the pin is available on the 8 pin header connector – pin number 4; you can for example connect a button to the pin number 4 and ground) the processor is woken and the green LED start blinking (5 times). - When selected RTC timeout expired (15 seconds) the processor is woken by the alarm interrupt and the green LED start blinking (5 times). The application is initialized again and recovery from the VLLS1 mode is executed. The alarm is set to 15 second and the CPU enters the VLLS1 mode again. Preparation First of all the KDS 1.1.1 (KDS 2.0.0) and KSDK 1.0.0 for KL03Z must be installed. You can find instructions in the document How to install KL03 SDK support in KDS 1.1.1 and KDS 2.0.0. New project When you properly install and update all the software you are prepared to create the Low power demo application. Create a new Kinetis design Studio project: Select the FRDM-KL03Z board Select the Kinetis SDK path to the KSDK 1.0.0 for KL03Z and select Processor Expert The application is created but there are many warnings reported in the Problems window saying that there is a conflict: Ignored error: Selected value is in conflict with other configuration(s) property 'Pin 13', property 'CH1 - Channel 1', property 'Pin' from component gpio_pins, property 'ERCLK32K clock output' Exclusive connection required by property 'CH1 - Channel 1'; Selected value is in conflict with other configuration property 'CH1 - Channel 1', conflict in configuration of MUX bit-field of PORTB_PCR13 register. ; Selected value is in conflict with other configuration property 'Pin 13', property 'Pin' from component gpio_pins, conflict in configuration of MUX bit-field of PORTB_PCR13 register. (CLKOUT - Oscillator output), Low power demo KL03, .... To resolve all these warnings you need to select the required functionality of reported pins in the PinSettings component: Open the Component Inspector of the PinSettings component, select the Routing tab and select the Pins View mode. All pins are available on one tab and you see small exclamation icons in rows where are reported conflicts: Click on each item with warning icon (the Selected Function row) and uncheck unused function of the pin to select one function only, i.e. you need to specify which functionality of the pin is initialized by code generated by Processor Expert. You can select GPIO functionality in all case except the last pin number 24 that is used by debugger as swd_dio pin: You can see that there is not any warning now and all pins are routed according to the selection you have done. There is also necessary to change the linker settings when you have installed the new version of GCC tools (according to the document that is available in the KSDK 1.0.0 for KL03Z installation folder in KSDK_1.0.0-KL03Z\doc\Kinetis SDK Freescale Freedom FRDM-KL03Z Platform User’s Guide.pdf – chapter Appendix B: Kinetis Design Studio environment variable fix and swap tool chain) Open the context menu of the project, select Properties item and change the Other linker flags settings to “-specs=nano.specs -specs=nosys.specs”, in C/C++ Build / Settings,  Tools Settigns tab, Cross ARM C++ Linker/Miscellaneous: Tip If you want to know details of compiled code and the code size, you can use the following options to create extended list file and print code size info on the following Toolchains tab: You can generate Processor Expert code and process Build of the application without any error and warning. When the Build is finished the following information is provided in the Console window: 'Invoking: Cross ARM GNU Create Listing' arm-none-eabi-objdump --source --all-headers --demangle --line-numbers --wide "Low power demo KL03.elf" > "Low power demo KL03.lst" 'Finished building: Low power demo KL03.lst' ' ' 'Invoking: Cross ARM GNU Print Size' arm-none-eabi-size --format=berkeley "Low power demo KL03.elf"    text          data           bss           dec           hex       filename    8860           112           640          9612          258c       Low power demo KL03.elf 'Finished building: Low power demo KL03.siz' Routing of pins When you open the gpio_pins component (in Component Inspector window) you can see that there are configured pins that are already used on target board: SW2 - ADC0_SE9/PTB0/IRQ_5/LLWU_P4/EXTRG_IN/SPI0_SCK/I2C0_SCL – input pin for the SW2 button on the board SW3 - ADC0_SE1/CMP0_IN1/PTB5/IRQ_12/TPM1_CH1/NMI_b - input pin for the SW3 button on the board ACCEL_INT - ADC0_SE0/CMP0_IN0/PTA12/IRQ_13/LPTMR0_ALT2/TPM1_CH0/TPM_CLKIN0/CLKOUT – input pin of inertial sensor interrupt LED_RED - PTB10/TPM0_CH1/SPI0_SS_b – output pin that driver the red LED of the RGB LED on the board LED_GREEN - PTB11/TPM0_CH0/SPI0_MISO - output pin that driver the green LED of the RGB LED on the board LED_BLUE - PTB13/CLKOUT32K/TPM1_CH1/RTC_CLKOUT - output pin that driver the blue LED of the RGB LED on the board Note: You can see routing of all pins when you generate report of PinSettings component. Open the Component Inspector of PinSettins, Routing tab and click on the HTML Report button. We will use the SW2 button to wakeup the CPU and the green LED for indication of the CPU state. Adding Processor Expert components Now you can add all components for the low power demo application. Init_LLWU and fsl_llwu_hal components to control LLWU device Init_SRTC and fsl_rtc_hal to control RTC device Init_LPTMR and fsl_lptmr_hal to control LPTMR device fsl_smc_hal to control SMC (System Mode Controller) device CPU device We are going to use external oscillator 32768Hz and we need to configure device to allow Very Low Leakage Stop modes. There are set following properties in the Component Inspector of the CPU (switch to Advance view): Check that the Clock settings/Clock Sources/System oscillator 0 property is Enabled and set Enable in stop property to Enabled. The Clock source, clock pins and clock frequency are preset for the FRDM-KL03Z board. Go to the Clock configuration/Clock Configuration 0 and set: Internal reference clock/Slow IRC frequency to 2MHz (it is enough for our demo application and it also decreases power consumption). MCG lite settings/MCG mode set to LIRC_2M Very low power mode to Enabled (leave setting of VLP mode entry to User because the VLLS1 mode is entered after blinking; we will write the code to enter VLLS1 mode) System clocks/Core clock set to 0.5Mhz System clocks/Bus clock set to 0.5Mhz (it allow us to enter very low leakage stop modes) Set Low Power mode settings/Acknowledge isolation to Not allowed value (we will do it in the user code) LLWU (Low-Leakage Wakeup unit) device Open the Component Inspector of Init_LLWU, switch to Advance view and set following properties: Set Settings/External Source/Pin 4 to Any edge value (we will use this pin that is connected to SW2 button) Set Pins/Pin 4 to Enabled and select SW2 in the item below Set Initialization/Utilize after reset values to no We will use the LLWU to wake-up the CPU and we need not any interrupt. RTC (Real Time Clock) device Open the Component Inspector of Init_SRTC, switch to Advance view and set following properties: Set Settings/Clock gate to Enabled Set Settings/Oscillator settings/Oscillator state to Enabled (it enables external oscillator also in stop modes) Set Settings/Time settins/Alarm time [s] to 15 (15 seconds timeout to wake-up from VLLS1 mode) Set Interrupts/ RTC interrupt/Interrupt request to Enabled Set Interrupts/ RTC interrupt/Time overflow interrupt to Disabled Set Interrupts/ RTC interrupt/Time invalid interrupt to Disabled Set Initialization/Time counter to Enabled Set Initialization/Utilize after reset values to no LPTMR (Low-Power Timer) device Open the Component Inspector of Init_LPTMR, switch to Advance view and set following properties: Set  Settings/Clock gate to Enabled Set Settings/Clock settings/Clock select to Internal 1kHz LPO (this clock source is enabled in the VLLS1 mode) Set Settings/Clock settings/Prescale value/Glitch filter to Prescaler/64; Glitch Filter 32 (it will eliminates glitches on connected button that will be used for generating pulses) Set Settings/Compare value to 4 (the LPTMR interrupt is invoked when the compare value is equal to counter and the counter value is increased, i.e. 5 pulses on the input pins invoke the LPTMR interrupt) Set Settings/Timer mode to Pulse Counter (we will use the timer to count external pulses on the input pin 3) Set Settings/Pin select to Input 3 Set Settings/Pin polarity to Active Low Set Pins/Input pin 3 to Enabled and select PTB6/IRQ_2/LPTMR0_ALT3/TPM1_CH1, TPM_CLKIN1 in Pin 3 item. Set Interrupts/Interrupt request to Enabled Set Interrupts/Timer interrupt to Enabled (we will use the timer interrupt to wake-up CPU from VLLS1 mode after 5 pulses on the input 3 pin) Set Initialization/Timer enable to yes Set Initialization/Utilize after reset values to no To avoid glitches on the PTB6 pin, that is used as input pin of the LPTMR, we will also enable pull-up in the PinSettins. Open Component Inspector of the PinSettings, select Functional Properties tab and set the pin number 1 (PTB6) as follows: We have finished design time settings of Processor Expert components and we are ready to write the application code. When you generate code and Build the application there will not be any error or warning. The Processor Expert project looks as follow: Application  code During the component settings we have enabled two interrupts – RTC interrupt and LPTMR interrupt. Therefore we need to write theses interrupt service routines. If you look for example into RTC.h file, you can find the declaration of the RTC_IRQHandler interrupt routine. So we can use the declaration to write the definition of the routine in the main.c program module: #define RTC_ALARM_TIMEOUT_SEC 15 #define LED_BLINK 5 /* RTC interrupt service routine */ PE_ISR(RTC_IRQHandler) { if (RTC_HAL_HasAlarmOccured(RTC_BASE)) { // set the next alarm in RTC_ALARM_TIMEOUT_SEC seconds (clear also the TAF flag) RTC_HAL_SetAlarmReg(RTC_BASE,RTC_HAL_GetAlarmReg(RTC_BASE) + RTC_ALARM_TIMEOUT_SEC); } if (RTC_HAL_IsTimeInvalid(RTC_BASE)) {        /* clear TIF (Time Invalid Flag) by stop of the counter and setting TSR reg */        RTC_HAL_EnableCounter(RTC_BASE, false);        RTC_HAL_SetSecsReg(RTC_BASE, 0);        /* enable counter */        RTC_HAL_EnableCounter(RTC_BASE, true); } } This interrupt routine services the Alarm interrupt in case that it is invoked during blinking of the green LED in the run mode (clear the flag and set the new Alarm time) and also it services the Invalid Time interrupt that can occur during recovering from the VLLS1 mode. Please note, that RTC module is little bit special, it runs in all run, wait and stop modes and the reset enables the Time Invalid interrupt bit (TIIE bit in RTC_IER) and invoke the Time Invalid interrupt on reset (POR or software reset). Therefore we need to clear the Invalid Time flag otherwise the application remain invoking RTC interrupt in an infinite cycle and the application does not work at all (it is also one of the issue that has not a straight forward solution). The RTC interrupt routine (defined above) shall properly serve all case we need in our application. Please note, that RTC interrupt always cause the wake-up from low-leakage stops modes (it is not configurable by LLWU on KL03 derivatives – see the chip-specific LLWU information). In addition, the after reset value of RTC_SR register is 0x01 (TIF flag is set). Therefore when the RTC is not initialized and a low-leakage stop mode is entered the CPU is immediately woken-up due to the RTC module interrupt flag (TIF flag is set). I.e. you must always properly initialize RTC module and clear all flags before you enter a low-leakage stop mode. We need also a service routine for the LPTMR device that is used for waking up from VLSS1 mode. This is a simple interrupt service routine that just clear the LPTMR interrupt flag: /* LPTMR interrupt service routine */ PE_ISR(LPTMR0_IRQHandler) { /* clear LPTMR interrupt flag */ LPTMR_HAL_ClearIntFlag(LPTMR0_BASE); } Now we can write the main() function. We will need a temporary count variables for blinking: /* Write your local variable definition here */ volatile uint32_t i; // for waiting uint8_t blink_count; After devices initialization in PE_low_level_init() we need to check the reason of reset (POR reset or VLLS1 recovery). Thus we can write following code: /* Write your code here */   if (RCM_SRS0 == 0x01) { /* test the reason of reset - wakeup on VLLS */     if(PMC->REGSC &  PMC_REGSC_ACKISO_MASK) {       PMC->REGSC |= PMC_REGSC_ACKISO_MASK; /* VLLSx recovery */     }     for (blink_count = 0; blink_count < LED_BLINK; blink_count++) {         // green LED blinking         GPIO_DRV_ClearPinOutput(kGpioLED2);         //GPIOB_PCOR = (GPIOB_PCOR & (~GPIOB_PSOR_MASK)) | GPIOB_PSOR_VALUE;         for (i = 0; i<40000; i++);         GPIO_DRV_SetPinOutput(kGpioLED2);         //GPIOB_PSOR = (GPIOB_PSOR & (~GPIOB_PSOR_MASK)) | GPIOB_PSOR_VALUE;         for (i = 0; i<40000; i++);     }     // set the next alarm in "RTC_ALARM_TIMEOUT_SEC" seconds (clear also the TAF flag)    RTC_HAL_SetAlarmReg(RTC_BASE,RTC_HAL_GetAlarmReg(RTC_BASE)+RTC_ALARM_TIMEOUT_SEC);   } else {     /* power-on reset */     /* switch the green LED on */     GPIO_DRV_ClearPinOutput(kGpioLED2);     /* wait a while */     for (i = 0; i<40000; i++);     /* switch the green LED off */     GPIO_DRV_SetPinOutput(kGpioLED2);   } In case of VLLS1 recovery we acknowledge the pin isolation ACKISO bit in the PMC_REGSC register. This bit must be cleared to allow normal run mode of all pins. Then five blinking of the green LED follows (it is just a simple code for demo purposes only; you can write your own more sophisticated code for blinking by TPMx device with Init_TPM component if you want). In case of POR reset one blink of the green LED is processed. When the reset/wake-up state is served by our application code the VLLS1 mode can be entered. As the first step, we need to be sure that there are not any interrupt flags set to wake-up the CPU from VLLS1 mode so we clear LLWU and SW2 pin (PTB0) interrupt flags and then we enter VLLS1 mode by using enter_vllsx function: /* clear LLWU flag for the selected pin 4 - PTB0 */ LLWU_F1 |= LLWU_F1_WUF4_MASK;   /* clear interrupt flag of the SW2 pin - PTB0 */ PORTB_PCR0 |= PORT_PCR_ISF_MASK; // enter the VLLS3 //enter_vllsx((smc_por_option_t)NULL,kSmcStopSub3); // enter the VLLS0 - RTC and LPTMR do not work becuase of external crystal clock source does not work in the VLLS0 mode //enter_vllsx(kSmcPorEnabled, kSmcStopSub0); // enter the VLLS1 enter_vllsx((smc_por_option_t)NULL,kSmcStopSub1); // switch the green LED on - error state when the VLLSx mode is not entered GPIO_DRV_ClearPinOutput(kGpioLED2); There is also code for switching on the green LED in case the VLLS1 mode is not entered (indication of the error state). The enter_vllsx function is defined by the following way (it is used existing function from a demo KSDK demo example): /* * VLLSx mode entry routinue */ static void enter_vllsx(smc_por_option_t PORPOValue, smc_stop_submode_t VLLSValue) {        smc_power_mode_config_t smcConfig;        /* set power mode to specific VLLSx mode */        smcConfig.porOption = true;        smcConfig.porOptionValue = (smc_por_option_t) PORPOValue;        smcConfig.powerModeName = kPowerModeVlls;        smcConfig.stopSubMode = (smc_stop_submode_t) VLLSValue;        SMC_HAL_SetMode(SMC_BASE, &smcConfig); } It is all code we need for our low power demo application. The application can be built and run now. Debugging The application does not contain any debug connection by default in KDS 1.1.1. The KDS 2.0.0 contains debug configurations but the settings must be updated according to following description. We just need to add (modify) a debug configuration for our FRDM-KL03Z board and Open SDA Segger j-link debugger. Open the context menu of the Low power demo KL03 project in the Project Explorer window and select Debug As > Debug Configurations .... In the Debug Configuration window double click on the GDB SEGGER J-Link Debugger item and a new Low power demo KL03 Debug configuration is created. Select the Debugger tab and enter the Device name: MKL03Z32xxx4 (you can find the correct CPU name in list when you open Support device names link that is located to right of this item). Uncheck Allocate console for semihosting and SWO (SWO is not support by OpenSDA SEGGER J-link). Go to on Startup tab and uncheck the Enable SWO option (SWO is not supported by OpenSDA SEGGER J-link). Click on the Apply and Debug button and the debugger starts (you must have the FRDM-KL03Z board connected to the workstation). You can now start the application (click on the Resume button) and check the functionality. The debugger is disconnected due to VLLS1 mode entry. But the application run and can be used. If you want to connect a button for the LPTMR pulses generating you can connect one pin of the button to the PTB6 on pin #4 of 8-pins connector J1 and the second pin of the button to the GND to the pin #7 of the 10-pins connector J2, see below: You can use this demo application as a start point of your real low power application. I hope it will help you and save your time of your first low power application implementation in the Processor Expert. There is also possible to measure power consumption of the CPU in VLLS1 mode. It is described in the FRDM-KL03 User Guide. Just unsolder R27 and R28 and solder a header pins to J10 position of the board. You must use jumper for J10 now to connect power supply for the CPU and when the jumper is removed you can use these two pins to measure the energy consumption of the CPU (e.g. by a multimeter).

This article describe procedure how to properly install support for KL03 derivative in KDS (Kinetis Design Studio) 1.1.1  (KDS 2.0.0) and also additional steps to update GCC compiler and debug firmware on the FRDM-KL03Z board. KDS 1.1.1 (KDS 2.0.0) installation If you don’t have KDS 1.1.1 (KDS 2.0.0), please get the installation package (for Windows and Linux) on Freescale website. Go to the page Kinetis Design Studio Integrated Development Environment (IDE), select the build and install it. Kinetis SDK installation The KL03Z derivative support is distributed as a service pack KSDK 1.0.0 for KL03Z. Download the Freescale Kinetis SDK_1.0.0 for the FRDM-KL03Z Windows or Linux installer and install it. After the KSDK 1.0.0 for KL03Z is installed you need also install the PEx service pack for KL03. In the KDS main menu select Help > Install new software… , click on Add.. button , click on Archive and select KL03Z-1.0.0-GA-SA-RC2-for-Eclipse.zip in the SDK subfolder (e.g. c:\Freescale\KSDK_1.0.0-KL03Z\tools\eclipse_update\KL03Z-1.0.0-GA-SA-RC2-for-Eclipse.zip): Additional Steps Next step is to install the updated GCC compiler. This is due to C standard library footprint issue in the GCC version that is distributed in KDS 1.1.1 (KDS 2.0.0). The KL03Z derivatives contain small amount of RAM memory and therefore this step is also strongly recommended. Detailed instructions, how to update the GCC, are provided in the KSDK user guide located in the KSDK 1.0.0 for KL03Z installation folder in KSDK_1.0.0-KL03Z\doc\Kinetis SDK Freescale Freedom FRDM-KL03Z Platform User’s Guide.pdf – chapter Appendix B: Kinetis Design Studio environment variable fix and swap tool chain. Please note that when you update the GCC you must change the linker flags for every new project with GCC to “-specs=nano.specs -specs=nosys.specs” as described in the document. (otherwise the default setting of linker flags will cause an error of GCC linker). If you haven’t done that yet,  update firmware of the FRDM-KL03Z board to allow application flashing and debugging. It is described in the same document in the chapter Appendix C: OpenSDA J-Link firmware updated. You can start creating a new application for the KL03 now. For example see Low power demo application on FRDM-KL03Z board.

The Processor Expert Driver Suite 10.4 Update 2 is available on the Freescale web and as Eclipse update. This update applies to the Driver Suite 10.4, or 3rd party IDE's with Processor Expert as Atollic TrueSTUDIO or Emprog Thunderbench. It is NOT applicable to CodeWarrior or Kinetis Design Studio: the upcoming KDS V2.0.0 release will include that update. This update features an improved new project wizard with device filtering support, alignment with the Kinetis SDK v1.0.0 and the upcoming SDK v1.1, and includes bug fixes (see release notes for details). The update is cummulative, so you can apply it to Driver Suite 10.4 with or without the Update 10.4.1. Release Notes: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=PE_DRIVER_SUITE&fpsp=1&tab=Documentation_Tab Download from the web: http://www.freescale.com/webapp/sps/site/overview.jsp?code=PEXDRV_UPDATES_10_4 Then update Eclipse with Window > Install new softeare and use the downloaded archive. Eclipse Updater: Use the following update URL to download the update 10.4.2 (menu Help > Install New Software): http://freescale.com/lgfiles/updates/Eclipse/PExDrv10_4/com.freescale.pexdrv.updatesite Best regards, Erich

The C project that doesn't use Processor Expert can be converted to Processor Expert. This is useful when the user finds out that he/she would like to use additional features of Processor Expert. WARNING! Note that in most cases this conversion involves necessary manual changes in the application code, because for example the register interrupt vectors table definitions created by the user often conflicts with Processor Expert definitions. Don't forget to backup the whole project before the conversion. Some files will have to be removed from the project. The conversion to Processor Expert is recommended to experienced users only. Steps: Select the command in the main menu File > New > Other and in the New Project Wizard select Processor Expert / Enable Processor Expert for Existing C Project Select the project you want to update. Select the derivative that will be included in PEx project (you should use the same derivative with the _4SDK suffix that has been selected when the project was created without PEx). Select the target compiler (select for example the IAR ARM C Compiler if the C project has been created as IAR ARM C project) Confirm changes (renaming of main.c module and any other changes you want to apply) and click on the Finish button. The project with PEx is created but there need to be done following changes: Go to project Properties to the Procesor Expert > Kinetis SDK Specific and fill the SDK path. Use browse button and select a path to the Kinetis SDK folder or fill the ${KSDK_PATH} which is default system variable. This variable points to the default Kinetis SDK folder. After this project still shows some errors. Remove the PinSettings component from project and add new PinSettings component from Components Library. This process adds missing fsl_clock_manager component to the project too. Press the button Generate Processor Expert Code and project should be generated without errors. Remove the duplicate main.c module – the main_backup.c file (copy content of the old main.c module into the new one created by PEx) and delete the old version of the file (main_backup.c) Processor Expert includes all IO maps and startup files. Therefore all IO maps and startup files from the original C project must be removed (e.g. content of the Static_Code folder). Processor Expert generate linker file ProcessorExpert.xxx (e.g. file ProcessorExpert.icf for IAR ARM C Compiler). Therefore all linker command files from the original C project must be removed.

The C project that doesn't use Processor Expert can be converted to Processor Expert. This is useful when the user finds out that he/she would like to use additional features of Processor Expert. WARNING! Note that in most cases this conversion involves necessary manual changes in the application code, because for example the register interrupt vectors table definitions created by the user often conflicts with Processor Expert definitions. Don't forget to backup the whole project before the conversion. Some files will have to be removed from the project. The conversion to Processor Expert is recommended to experienced users only. Steps: Select the command in the main menu File > New > Other and in the New Project Wizard select Processor Expert / Enable Processor Expert for Existing C Project Select the project you want to update. Select the derivative that will be included in PEx project (you should use the same derivative, but without the _4SDK suffix, that has been selected when the project was created without PEx). Select the target compiler (select for example the IAR ARM C Compiler if the C project has been created as IAR ARM C project) Confirm changes (renaming of main.c module and any other changes you want to apply) and click on the Finish button. Remove the duplicate main.c module – main_backup.c (copy content of the old main.c module into the new one created by PEx) and delete the file The project with PEx is created but there need to be done following changes: Remove the PinSettings component from project and add new PinSettings component from Components Library. This process adds missing fsl_clock_manager component to the project too. Press the button Generate Processor Expert Code and project should be generated without errors. Remove the duplicate main.c module – the main_backup.c file (copy content of the old main.c module into the new one created by PEx) and delete the old version of the file (main_backup.c) Processor Expert includes all IO maps and startup files. Therefore all IO maps and startup files from the original C project must be removed. Processor Expert generate linker file ProcessorExpert.xxx (e.g. file ProcessorExpert.icf for IAR ARM C Compiler). Therefore all linker command files from the original C project must be removed.

The C project that doesn't use Processor Expert can be converted to Processor Expert. This is useful when the user finds out that he/she would like to use additional features of Processor Expert. WARNING! Note that in most cases this conversion involves necessary manual changes in the application code, because for example the register interrupt vectors table definitions created by the user often conflicts with Processor Expert definitions. Don't forget to backup the whole project before the conversion. Some files will have to be removed from the project. The conversion to Processor Expert is recommended to experienced users only. Steps: Select the command in the main menu File > New > Other and in the New Project Wizard select Processor Expert / Enable Processor Expert for Existing C Project Select the project you want to update. Select the derivative that will be included in PEx project (you should use the same derivative with the _4SDK suffix that has been selected when the project was created without PEx). Select the target compiler (select the GNU C Compiler by default but if you have not installed any other compiler in the Kinetis Design Studio) Confirm changes (renaming of main.c module and any other changes you want to apply) and click on the Finish button. The project with PEx is created but there need to be done following changes: Go to project Properties to the Procesor Expert > Kinetis SDK Specific and fill the SDK path. Use browse button and select a path to the Kinetis SDK folder or fill the ${KSDK_PATH} which is default system variable. This variable points to the default Kinetis SDK folder. After this project still shows some errors. Remove the PinSettings component from project and add new PinSettings component from Components Library. This process adds missing fsl_clock_manager component to the project too. Press the button Generate Processor Expert Code and project should be generated without errors. Remove the duplicate main.c module – the main_backup.c file (copy content of the old main.c module into the new one created by PEx) and delete the old version of the file (main_backup.c) Remove all IO maps files from the original project. The KDS bareboard project have all these files included in the Includes folder by default (core_......h files and IO map files). Remove all startup files from the original project. The KDS bareboard project have all these files (startup_xxxxxx.S and system_xxxxxx.c files) included in the Project_Settings/Startup_Code  folder. Remove linker file xxxxxxxxxxxx_flash.ld from the original project. Use the Processor Expert.ld linker file that is generated by Processor Expert. In the context menu of the project select Properties and in the Properties window go the C/C++ Build > Settings > Tool Settings, select the Cross ARM C++ Linker / General and select the ProcessorExpert.ld file instead of MK......_flash.ld (see the following screenshot).

The C project that doesn't use Processor Expert can be converted to Processor Expert. This is useful when the user finds out that he/she would like to use additional features of Processor Expert. WARNING! Note that in most cases this conversion involves necessary manual changes in the application code, because for example the register interrupt vectors table definitions created by the user often conflicts with Processor Expert definitions. Don't forget to backup the whole project before the conversion. Some files will have to be removed from the project. The conversion to Processor Expert is recommended to experienced users only. Steps: Select the command in the main menu File > New > Other and in the New Project Wizard select Processor Expert / Enable Processor Expert for Existing C Project Select the project you want to update. Select the derivative that will be included in PEx project (you should use the same derivative that has been selected when the project was created without PEx). Select the target compiler (select the GNU C Compiler by default if you have not installed any other compiler in the Kinetis Design Studio) Confirm changes (renaming of main.c module and any other changes you want to apply) and click on the Finish button. The project with PEx is created but there need to be done following changes: Remove the duplicate main.c module – the main_backup.c file (copy content of the old main.c module into the new one created by PEx) and delete the old version of the file (main_backup.c) Remove all IO maps files from the original project. The KDS bareboard project have all these files included in the Includes folder by default (core_......h files and IO map files). Remove all startup files from the original project. The KDS bareboard project have all these files (startup_xxxxxx.S and system_xxxxxx.c files) included in the Project_Settings/Startup_Code folder. Remove linker file xxxxxxxxxxxx_flash.ld from the original project. Use the Processor Expert.ld linker file that is generated by Processor Expert. In the context menu of the project select Properties and in the Properties window go the C/C++ Build > Settings > Tool Settings, select the Cross ARM C++ Linker / General and select the ProcessorExpert.ld file instead of MK......_flash.ld (see the following screenshot).

Processor Expert provides possibility to switch between processor modes by providing concept of “operation modes”. The CPU component provides a function SetOperationMode that can be called to select one the following general modes: RUN – normal mode, running at full speed. WAIT – core sleeps, but the peripherals are running SLEEP – both core and peripherals sleep and can wake up to continue execution STOP – both core and peripherals sleep and usually can wake up only via reset These modes are mapped to the platform specific modes of the chip. By switching to WAIT/SLEEP/STOP modes when possible (for example no computation is done for a while),  it's possible to achieve a lower consumption of the whole chip. The following table shows an example of the operation modes mapping for Kinetis L that shows the state of the core, bus and recovery method for each mode:   The Very low power mode option is available in Clock configurations of CPU properties (see below), i.e. the selection of the power mode is done by combination of the SetOperationMode and SetClockConfiguration methods. The exact mapping of the DOM_xxx options can be configured in the CPU component inspector (the Advenced view has be enabled). For example the DOM_SLEEP can be mapped to normal stop mode, very low power stop, partial stop 1 or partial stop 2 of Kinetis L.

The attached document shows how tou use Processor Expert Driver Suit to generate code for CW. You can see details in the notes at the botton of the slides.  Best regards, Carlos

The attached document shows how tou use Processor Expert Driver Suit to generate code for IAR. You can see details in the notes at the botton of the slides. Best regards, Carlos