This is an ISF2.1 Project that goes with the blog post titled "Creating a Data Logger embedded application using ISF 2.1".

This document provides guidance for relocating Code and Data within the MCU memory map. As part of this process it explains how create new memory segments and sections by editing the GCC Linker File (.ld) for Kinetis Architectures.   Contents:   1.- Introduction 2.- Preliminary Backgrounds 3.- Linker File (.ld) Overview 4.- Relocating Code 4.1.- Prerequisites 4.2.- Relocating Code in ROM 4.3.- Relocating Code in RAM 4.4.- Relocating Code in a Specific RAM address 4.5.- Relocating Code in External RAM 5.- Relocating Data 6.- Linker File for RAM Project   Best Regards, Carlos Mendoza Technical Support Engineer

This document summarizes how to use printf() to print string to Console and UART in KDS2.0 .   Printing string to Console and UART both includes three conditions: Processor Expert project, KSDK project and bareboard project.   Refer to this document, we can use the printf() in KDS with any project conveniently.

In most of Freescale MCUs, there is only one Flash on chip.  When executes Flash programming we need copy Flash programming routine from Flash to RAM then execute it from RAM.  The reason is that when writing MCU Flash, program is also reading instruction from same Flash, but Flash can’t perform reading and writing parallel. So executing the flash programming routine from RAM can avoid Flash read/write conflict.   In Cotex M0+ core kinetis, Platform Control Register (MCM_PLACR) is added. The MCM_PLACR register selects the arbitration policy for the crossbar masters and configures the flash memory controller. A useful bit I am going to talk about is bit 16 ESFC: Enable Stalling Flash Controller. When this bit enabled, it can stall flash controller when flash is busy.  Setting ESFC bit can well-balance time sequence of Flash reading and writing – when writing Flash, reading Flash instruction can wait, and vice versa. Using ESFC bit can make our flash programming easier. Thus one Flash can write itself, which is not possible for other one Flash MCU without ESFC bit control.   Currently MCM_PLACR is supported in below chips with Cotex M0+ core embedded: MKE02/04/06 SKEA MKL02/04/05/14/15/16/17/24/25/26/27/33/34/36/43/46 MKM13/14/32/33/34/38 MKV10 MKW01     I didn’t find any official Flash Programming demo code on ESFC bit usage so far. So I made sample code under Codewarrior10.6 and KDS2.0 respectively. The demo codes are for MKL25, but the method is available for all Cotex M0+ MCU I listed above. It’s easy to port the flash programming code to other Cotex M0+ chip. Here are porting steps for both KDS and CW environment: - Create new project with project wizard with default setting to create a new project - Copy flash_kinetis_m0.c and flash_kinetis_m0.h to project Source code folder - Include the specific MCU header file in  "flash_kinetis_m0.h", for example  #include "MKL25Z4.h" - Include "flash_kinetis_m0.h" to the related source file:  #include "flash_kinetis_m0.h”   Enjoy Flash Programming!

Introduction Up and including to version 2.0.0, the Kinetis Design Studio (KDS) is using a custom GNU toolchain built by SOMNIUM Technologies, referred here as 'legacy'. That toolchain is built from the Free Software Foundation (FSF) source base, with a few minor modifications. Starting with v3.0.0, KDS will use the unmodified GNU Tools for ARM Embedded (launchpad, GCC ARM Embedded in Launchpad) toolchain (4.8-2014-q3-update : Series 4.8 : GCC ARM Embedded release), referred here as 'launchpad'. Projects created with KDS v3.0.0 will use the 'launchpad' tools by default. The reasons for 4.8-2014-q3 instead of using the later 4.9 release is because of stability and smaller footprint of 4.8 applications.   Outline This document outlines what are the differences between the 'legacy' and 'launchpad' toolchain, and what is needed to port existing 'legacy' projects to the 'launchpad' ones. It is already possible to use the 'launchpad' tools with KDS v2.0.0 today (see Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse), therefore the information in this document can be applied to KDS v2.0.0 to with using the 'launchpad' toolchain.   KDS Upgrade Assistant Kinetis Design Studio V3.0.0 comes with a migration assistant to migrate projects to the GCC ARM Embedded (launchpad) tools. The migration assistant is accessible from the menu Project > KDS Upgrade Assistant: This opens a dialog with the currently open projects in the workspace:   NOTE: if the Upgrade Assistant does not list your project, then you still can do the manual steps as listed below (changing the linker flags).   Select the project(s) you want to migrate and press Next. In the next dialog you can configure the details of the conversion, then press Finish: A report will be generated in each project directory:   Migration of KDS Projects To migrate an existing 'legacy' project to a 'launchpad' project, usually only the linker settings need to be changed. For this go into the project properties, and check the 'Other linker flags' settings of the Linker. The table below shows the difference between the two: Legacy 'Other linker flags' Launchpad 'Other linker flags' <none> -specs=nosys.specs -nanolibc -specs=nano.specs -specs=nosys.specs   For example this project is a legacy project using the newlib-nano library: To use it with the 'launchpad' toolchain, use -specs=nano.specs -specs=nosys.specs as shown below: With this, normally projects are converted from the 'legacy' to the 'launchpad' toolchain.   NOTE: after switching toolchains, delete all intermediate or object files (e.g. delete the Debug/Output folder inside the project. Mixing object files or libraries from different toolchains and compilers will likely cause problems.   Now your project should compile fine. However, if you face a problem about wrong Thumb mode, see the following subsection.   Wrong or missing Thumb mode If getting errors like      Error: selected processor does not support Thumb mode      error: interrupt Service Routines cannot be coded in Thumb mode This means that the project settings do not properly pass the processor to the compiler. That problem mainly occurs with Kinetis SDK projects, and with Cortex-M0+ (Kinetis-L) projects. As explained in the next section, the launchpad tools by default use the ARM, not the thumb mode. The solution is to add      -mcpu=cortex-m0plus for these Kinetis-L projects to the compiler 'Other target flags'.   The following sections provide more detailed information about the differences.     Differences Both the 'launchpad' and the 'legacy' toolchains are GNU toolchains, and largely compatible. However there are notable differences between the two toolchains:   legacy launchpad GNU Binaries Microsoft 32bit binaries, Linux 64bit binaries Microsoft 32bit binaries, Linux 32bit binaries(1) GNU binutils 2.32.2 2.23.2.20140731(*) GCC 4.8.0(*) 4.8.4 (ARM/embedded-4_8-branch) NewLib 1.19.0(*) 2.1.0(*) Newlib-nano 1.0(*) 2.1 GDB 7.6(2) 7.6.0.20140731-cvs(2) ARM Mode Thumb ARM (non-Thumb) (*) Modified. (1) See next section about running 32bit GNU tools on 64bit Linux. (2) The legacy GDB has Python support, while this is not present in the launchpad 4.8-2014-q3 build. Python support has been added by ARM in 4.9-Q4-2014 release.   Launchpad 32bit Binaries to run on 64bit Linux Because the 'launchpad' tools are 32bit binaries on Linux only, this can cause issues on 64bit Linux systems (e.g. Ubuntu 14.04 64bit) if the needed 32bit support libraries are not installed. A usual error message is that arm-none-eabi-gcc could not be found, even if that file is present, because the system does not know how to run it. This is because the 'launchpad' tools are built as 32bit binaries, an the compatibility package needs to be installed. See http://gnuarmeclipse.livius.net/blog/toolchain-install/ how to install the necessary compatibility libraries for Linux.   ARM Default Mode The default options for the 'legacy' toolchain produce code for the ARM Cortex-M0+ (Thumb mode), while the 'launchpad' tools default to the 'ARM' mode (non-Thumb). Therefore it is important that the command line options -mthumb with the appropriate -mcpu= or -march= options are used if using the tools in command line only mode. If using the GNU ARM Eclipse plugins, then no changes are needed as these options are set in the project already:     Default Libraries and Options The GNU compiler driver and linker is using default pre-built libraries in certain sub directories. These directories contain a default set of libraries, based on the compiler and architecture options specified during the build and link phase. Using linker options like -L to include a specific library or using options like -nostdlib or similar have an effect which libraries in which subdirectory are used. The library folder location is in <KDS_Installation_PATH>\toolchain\arm-none-eabi\lib   The following table lists the specific options used for both the legacy tools and launchpad tools to link for a specific architecture and floating point ABI used: Target Legacy Options Legacy Subdir Launchpad Options Launchpad Subdir ARM Cortex-M0+ <default> <default> -mthumb -march=armv6s-m armv6-m ARM Cortex-M4 -mcpu=cortex-m4 m4 -mthumb -march=armv7e-m armv7e-m ARM Cortex-M4F -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 m4/fp/v4-sp-d16 -mthumb -march=armv7e-m -mfloat-abi=hard -mfpu=fpv4-sp-d16 armv7e-m/fpu ARM Cortex-M4F with softfp ABI -mcpu=cortex-m4 m4 -mthumb -march=armv7e-m -mfloat-abi=softfp -mfpu=fpv4-sp-d16 arm7e-m/softfp   Newlib-nano Both the legacy and the launchpad toolchain include the newlib-nano library, a standard library more optimized for embedded devices than the normal newlib one. The option to select the newlib-nano library is different: Newlib-nano for Legacy Newlib-nano for Launchpad -nanolibc --specs=nano.specs   Application _start() The startup code needs to call the _start() function of the library which then calls the main() function. The _start() function in the library is responsible to initialize the library and prepare it to be used by the application. In order to do this, the library needs to have the __stack symbol defined in the linker file which points to the top of stack. For this, the __stack symbol needs to be defined in the linker file as in the example below: /* Highest address of the user mode stack */ _estack = 0x20000000;    /* end of m_data */ __SP_INIT = _estack; __stack = _estack;   Semihosting The legacy library has semihosting included in the libraries, and users can use _isatty() and _write() to overwrite the existing semihosting hooks. With the launchpad tools semihosting is enabled with the -specs=rdimon.specs linker option, and users can implement their own hooks with _sbrk(), _write(), _close(), _fstat(), _isatty(), _lseek() and _read(). To completely disable semihosting, the options -specs=nosys.specs can be passed to the linker.   Application Exit Function The legacy library includes a default implementation of _exit(), while the launchpad tools do not include this. Using the -specs=nosys.specs linker option will ensure that the linker does not complain about the missing _exit() function.   Summary A typical legacy Kinetis Design Studio (KDS) V2.0.0 project can be easily migrated to the launchpad toolchain with adding -specs=nosys.specs linker option and replacing the -nanolibc legacy option with -specs=nano.specs linker option.   Links Kinetis Design Studio: Kinetis Design Studio Integrated Development |Freescale GNU Tools for ARM Embedded: GCC ARM Embedded in Launchpad Q3 2014 GNU Tools for ARM Embedded Release: 4.8-2014-q3-update : Series 4.8 : GCC ARM Embedded Blog article about how to switch KDS toolchain: Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse GNU ARM Eclipse plugin website and blog by Liviu: Welcome to the GNU ARM Eclipse plug-ins! | GNU ARM Eclipse Article by Liviu how to install toolchain: http://gnuarmeclipse.livius.net/blog/toolchain-install/

Greetings, the new release of Kinetis Design Studio V2.0.0 has been released and is available on the web (http://www.freescale.com/kds).   V2.0.0 is a new full release, supporting Windows (7/8 (both 32 and 64bit) and Linux (64bit binaries for Ubuntu, RHE and CentOS) from the download tab: Kinetis Design Studio Integrated Development |Freescale (current description says 32bit for Linux, but it is really 64bit, this should be fixed soon).   What's new: Support for 64bit Linux with 64bit binaries. Improved NPW (New Project Wizard) which automatically creates debugger launch configurations for OpenOCD, P&E and Segger. Automatic device filtering in the NPW. Greatly improved Kinetis SDK support with automatically adding compiler include paths for new Kinetis SDK component and files. Updated P&E and Segger debug connections Built-in support for the upcoming Kinetis SDK v1.1 release Updated Processor Expert (V10.4.2) Many bug fixes and other improvements Details in the Kinetis Design Studio V2.0.0 release notes (Documentation Tab). As with the previous V1.1.0 release, new device support and Kinetis SDK support is added through the SDK Eclipse update, present in the Kinetis SDK. See the release notes for details.   There is no need to uninstall V1.1.1, as V2.0.0 can be installed in parallel, and projects are compatible. Moving to V2.0.0 is highly recommended for Linux users and anyone using the Kinetis SDK.   Best regards, Erich Styger

hi, Thank you for your response. Now am sending the file in  .doc format please check it once and let me know where are the mistakes in porting. Thanks and Regards, Padmaja

Configuration used:                 Hardware :              TWR-K60D100M                                                 P&E Multilink Universal rev B                 Software:                CW for MCU V10.6                                                 KDS V1.1.1   Attached you will find 3 docs explaining step by step how to import a MCU V10.6 projects under KDS1.1.1   1- Porting sample MCU V10.6 project to KDS V1.1.1 2- Porting sample Processor Expert MCU V10.6 project to KDS V1.1.1 3- Porting sample MQX MCU V10.6 project to KDS V1.1.1   If you see problem or mistake, don't hesitate to contact me.     Another project: 4- Porting Example delivered on MCU V10.6 to KDS V1.1.1 (example_mcu_KDS.zip)         + How to solve the "Program "gcc" not found in PATH" message       Other problems linked to the vector table moving MCU to KDS 3.0.0:  I am attempting to port a project from CodeWarrior 10 to KDS 3.0.   I was porting from CodeWarrior 10 to KDS 3.0. After fixing all the coding differences I ran into a runtime problem. The code kept restarting. In comparing the C startup file provided by KDS and CodeWarrior I found that CodeWarrior was turning off the WatchDog and setting the Interrupt Vector Table address, KDS was not doing this. I copied the relevant CodeWarrior code to the SystemInit() function in the system_MK20D7.c file. This disabled the WatchDog, but left me with the problem of the code restarting whenever the an interrupt was generated. I finally figured out that the problem was with the line of code that was attempting to re-locate the Vector table address. Although the code appears to work for CodeWarrior it is totally bogus fro KDS. Removing the line solved the problem. After renaming all my interrupt handlers to the KDS naming convention everything now works as it should.

When you want to start debugging with SEGGER J-Link lite debugger in Kinetis Design Studio 1.1.1 you must set properly several options otherwise the debugger behave incorrectly (it seems that debugger works but the application execution does not work - e.g. functions are not called).   When you create a new Kinetis Design Studio project (with Processor Expert), write you code and build the application you must also create a debug configuration (open the context menu of the project in the Project Exporer and select Debug As / Debug Configurations...). In the Debug Configuration window create a new debugger connection for GDB SEGGER J-Link Debugging and set the correct values for the derivative of your project (e.g. MKL25Z128 derivative on FRDM-KL25Z target board): On the Debugger tab set the device name (see the list of Supported device names)  (e.g.set value MKL25Z128xxx4 for the MKL25Z128) and uncheck the Allocate console for semihosting and SWO (it is not supported).     On the Startup tab uncheck Enable semihosting and Enable SWO.   Click on Apply to save the settings. the debugger is connection is set properly now and you should be able to debug your application (click on the Debug button). Note: You can use this option for the OpenSDA connection when the SEGGER firmware is flashed. SEGGER offers a firmware running on the Freescale OpenSDA platform which makes OpenSDA compatible to J-Link Lite (see pages https://www.segger.com/opensda.html). You can find more details about OpenSDA MSD Bootloader in the OpenSDA User’s Guide document, see http://www.freescale.com/files/32bit/doc/user_guide/OPENSDAUG.pdf

For those of you interested in starting up designs with K64 and KDS here you will find basic baremetal examples with detailed step by step guides explaining which registers to configure, they also include Reference Manual extracts to make it easier to understand and learn how to do so for those unfamiliar with Kinetis devices.   The rar files include document and code example. I hope all  you find them useful.     K64F-GPIO K64F-Interurpt K64F-UART K64F-ADC K64F-PWM

Hello KDS users!   Nowadays assembly language is being eradicated for embedded systems, and other alternatives such as C/C++ are widely used.   However we know sometimes it becomes necessary to get to "the bones" of our MCU, even from a C project, and play directly with its registers and status flags. Some use cases are:   - Startup code - Bootloaders - Time critical routines - Benchmarking   It is common to include assembly code using the "__asm()" style. But what if I want to use my C variables in the assembly code? or if I want to call an assembly subroutine from a C project? We can do this in Kinetis Design Studio, which comes with GCC tools preinstalled.   The attached document is an overview and explanation of this extended assembly feature. Also I am including a pair of example projects developed in KDS v1.1.1, for the KL25Z128 and K60DN512 devices.   Thanks to Abigail Inzunza Lopez, who helped with this.   I hope you find this useful !

KDS does not come with a register level detail view included, only the ARM core non-memory mapped registers are displayed in the Registers view. There is an open source Eclipse plugin which can be added to KDS which brings register level details: For this view, install the EmbSys Eclipse plugin, and apply a patch (zip file) to get all the Freescale register detail information in SVD (XML) files. The installation and usage of the plugin is described in: http://mcuoneclipse.com/2014/05/29/how-to-add-register-details-view-in-eclipse/   The patch files which fix an issue in the existing plugin (see EmbSys Registers View with CMSIS-SVD dimElementGroup | MCU on Eclipse) and adds extra Freescale SVD files to the installation (see Updated Eclipse EmbSysReg Viewer with extra Freescale SVD Files | MCU on Eclipse).   The patch files are hosted on SourceForge: McuOnEclipse - Browse /Eclipse Plugins/EmbSysReg at SourceForge.net   Happy Registering 🙂

In case you have created a project without Processor Expert option enabled at project creation time, it might be the easiest way just to create a new project with Processor Expert enabled, and then move things over. In case this approach is not feasible, then the following document outlines the steps to concert such a project into a Processor Expert project: Adding PEx to KDS bareboard project (with SDK) | Freescale Community   Happy Converting 🙂

This document is a step by step to install KDS.

If you are migrating from CodeWarrior to KDS, then you might notice that CodeWarrior had a 'Add Files...' menu: KDS is using an unmodified Eclipse version, and because the above menu was a CodeWarrior specific extension, this menu is not present in Eclipse. But there are many different other ways in Eclipse how to add existing files to a project in KDS: File Import Menu Drag and Drop Copy and Paste See How to Add Existing Files to Eclipse Projects | MCU on Eclipse   Happy Adding 🙂

Introduction   OpenOCD is the PC host application that is used by OpenSDAv2 (CMSIS-DAP application) for debugging. The standard installation of KDS does not include support for debugging the K22FN512 & K24FN256 device families via OpenOCD. This document will guide a KDS user through updating OpenOCD, bundled in KDS, to provide support for the K22FN512 & K24FN256 device families. In addition, we will show the user how to re-configure a KDS project to use OpenOCD to debug with CMSIS-DAP on a FRDM-K22F development board.   Requirements   The following CMSIS-DAP versions are required for this version of OpenOCD:   Development Board CMSIS-DAP Version FRDM-K22F 0203 TWR-K22F120M 0203 TWR-K24F120M ff03   Updating OpenOCD   First the user must locate their installation of KDS. On Windows machines, the default installation directory is “C:\Freescale\KDS_1.1.1”. For Linux users, the default installation folder is “opt/Freescale/KDS_1.1.1”. Inside this installation, you should see the same directories and files as seen in the figure below. Note: before continuing you must stop any debugging sessions and shutdown KDS.   Figure 1: Default KDS_1.1.1 installation directory.   In Figure 1, you can see the folder named “openocd”. This contains all the files necessary for OpenOCD to run in KDS. Before we install the updated version of OpenOCD we must rename the “openocd” folder. This way we have the old version of OpenOCD, should you feel the need to return.   Figure 2: Renamed "openocd" folder.   Once the “openocd” folder is renamed, as in Figure 2, we then need to download the “kds-openocd-update-09-04-14.zip” file attached to this document. Save this file into the KDS installation directory, as in Figure 3.   Figure 3: KDS OpenOCD update in KDS installation.   Once downloaded, extract the “openocd” folder for your operating system into the KDS installation directory. Figure 4 shows where the updated “openocd” folder is located for Windows users.   Figure 4: Location of updated OpenOCD folder for Windows.   Once the new “openocd” folder is copied to your KDS installation the update process is complete. OpenOCD in KDS now supports the K22F family of devices. It is now possible for FRDM-K22F users to debug their KDS projects with CMSIS-DAP via OpenOCD. Figure 5 shows the KDS installation folder after successfully updating OpenOCD.   Figure 5: Updated KDS installation.   Preparing projects for debugging with OpenOCD   Now a quick walkthrough on how to configure KDS projects to debug using OpenOCD. We will assume that the user already has a project in their workspace.[1] The first step is to highlight the desired project, and then select “Debug Configurations…” from the Debug drop down.   Figure 6: Open "Debug Configurations..."   Once the “Debug Configurations” menu pops up on your screen, select “GDB OpenOCD Debugging”, then click on the “New Launch configuration” button in the upper left of the window. Figure 7 shows where these items are located.   Figure 7: Create a new GDB OpenOCD Debugging configuration.   The new debug configuration should automatically pull in information from the selected project. If an .elf file exists for the project, then the “C/C++ Application” and “Project” fields will be populated as in Figure 8.   Figure 8: These fields should be generated automatically if the project has already been built.   If the “C/C++ Application” field is not populated, you can search your project for an .elf file using the “Search Project…” button below the “C/C++ Application” field. If no .elf exists, then it is necessary for the user to build the project to generate the .elf file.   Once the “Main” tab has been completed, it is time to move onto the “Debugger” tab. In the “Debugger” tab, it is necessary for the user to define the configuration file in the “Config options” field. For debugging in KDS, OpenOCD will need a configuration file, and the default configuration file is “kinetis.cfg”. Enter “-f kinetis.cfg” into the “Config options” field. Figure 9 shows the correct input for the “Config options” field. After populating the field, the user can now press the “Debug” button to begin debugging.   Figure 9: User must enter “Config options”.   If this is the first time debugging in the current workspace, a dialog box will appear prompting you to open the “Debug” perspective. You should check the “Remember my decision” box, and press the “Yes” button. This will allow KDS to switch to the “Debug” perspective, for you whenever you begin to debug an application. See Figure 10 for more detail.   Figure 10: Select to automatically change perspective when debugging.   Figure 11, below, shows a successful debug connection to the target device using OpenOCD. The application has run to “main” and is waiting for the user to interact with the debug session.   Figure 11: Once debugger has connected and run to main.   Summary   After completing the steps in the sections above, a KDS user should be able to debug applications using OpenOCD and CMSIS-DAP with K22FN512 & K24FN256 device families. For more information on KSDK and KDS please consult the documentation located in C:\Freescale\KSDK_1.0.0\doc and C:\Freescale\KDS_1.1.1\doc\pdf, respectively.   [1] For directions on importing an existing KSDK demo to KDS please consult the device family specific user’s guides in “C:\Freescale\KSDK_1.0.0\doc”, and on creating new KDS projects consult the “kds_user_guide” in “C:\Freescale\KDS_1.1.1\doc\pdf”. Original Attachment has been moved to: kds-openocd-update-09-04-14.zip

A new updated plugins is available from P&E with extended device support (see list at the end) for KDS V1.1.1:   NOTE: You need V1.1.1 for this update, as V1.1.0 has an issue with updating the P&E plugins, unless you apply a manual workaround. See the V1.1.0 release notes.   Use the menu Help > Install New software and use the PEmicro update site from the list: Select the updated plugin, and press 'Next' to go through the installation. At the end, you are asked to re-start KDS.     Release Note information: KDS_513_b140905 includes the following features and bug fixes:   (*) Adds device support for the following devices: (*) Add MBED/PEMICRO OpenSDA support for FRDM-K22F and FRDM-K64F boards   Kinetis - K24 Series k24fn256m12   Kinetis - KL17/KL27/KL33/43 Series kl17z32m4 kl17z64m4 kl17z128m4 kl17z256m4 kl27z32m4 kl27z64m4 kl27z128m4 kl27z256m4 kl33z128m4 kl33z256m4 kl43z128m4 kl43z256m4   Kinetis - KMx - Photon3 km14z64am5 km14z128am5 km33z64am5 km33z128am5 km34z128am5   Kinetis - KV4x kv40f64m15 kv40f128m15 kv40f256m15 kv43f64m15 kv43f128m15 kv44f64m15 kv44f128m15 kv45f128m15 kv45f256m15 kv46f128m15 kv46f256m15   Kinetis - K11/K21 - K20 512k/1Mb k11dn512am5 k11dx128am5 k11dx256am5 k21dn512am5 k21dx128am5 k21dx256am5 k21fn1m0am12 k21fx512am12   Kinetis- K02F Series: K02F128M10 K02F64M10   Kinetis- KW Series:   KW01Z128 KW21D256M5 KW21D512M5 KW22D512M5 KW24D512M5   Kinetis- K66/65 Series: K66FX1M0M18 K65FX1M0M18 K66FN2M0M18 K65FN2M0M18   Kinetis - WPR Series alpha WPR1516M2   KDS_506c_b140807 includes the following features and bug fixes:   Plugin Version 1.12.   ENGR00325552 - Includes changes to p2.inf to include both metadata and artifact repositories on the same line. ENGR00325553 - Specify IP issue for Ethernet P&E interfaces (Cyclone MAX, Tracelink) is addressed. Adds support for MBED Bootloader 2.1 on FRDM-K22F and FRDM-K64F boards.       Happy Updating 🙂

In case you are running into this error while trying to uninstall KDS on Windows (I had it with KDS V1.1.0, but it might apply to other versions too):   "Error opening installation log file. Verify that the specified log file location exists and is writeable."   After some googling, some installers (or uninstallers) can cause that error message. It seems that some files/folders are not accessible. In my case I had it with installing KDS, and then wanted to uninstall it as I installed (in error) V1.1.0 (and not the latest V1.1.1). I had not rebooted afterwards. But when I rebooted, the problem does go away.   So if you run into that problem: reboot your machine and try again. It worked for me.   Happy Uninstalling 🙂

Greetings, A new release V1.1.1 of KDS is available from the Download tab on http://www.freescale.com/kds V1.1.1 is a full release, and it is recommended to use this new release going forward. V1.1.1 supports Windows (7/8), Linux (32bit binaries for Ubuntu, RHE and CentOS): What's new: Linux RHE and CentOS installation (RPM) Updated KDS User Guide Updated P&E updated site handling to allow support for incremental device support Fixed IP Adddress Setup for P&E Ethernet connection devices (Cyclone MAX, TraceLink) For details, see the V1.1.1 Release Notes.   In addition to the KDS V1.1.1 release, there is an Eclipse update for Processor Expert and Kinetis SDK support. Implemented workaround for HEAP size needs of Newlib-nano GNU library Fixed include path delimiter for Linux hosts Fixed flash configuration field values for several bare project derivatives Updated board configuration templates. Details in the Update1 Release Notes.   Download this .zip file, then install it in Eclipse/KDS using the menu Help > Install New Software (the update will be available on the KDS Eclipse online update site too)   :   Please use KDS V1.1.1 with Eclipse/Processor Expert/SDK Update1 going forward. KDS V1.1.0 projects and settings can be used with V1.1.1.   Best regards, Erich

Outline How to start debugging with the GDB debugging in KDS. If you are coming from CodeWarrior, then debugging with KDS is somewhat different because of the nature of GDB, and because the debug configuration panels look different.   This document uses FRDM-K64F board (Freescale Freedom Development Platform) Kinetis Design Studio V1.1.0.(Kinetis Design Studio Integrated Development) Screenshots from Windows 7 host (but things are very similar to any other host supported)   Creating Debug Configuration In order to debug, a debug configuration needs to be created. It is assumed that you already have compiled/linked your project at this time.   In order to have most fields of the debug configuration pre-populated, select the project in the Project Explorer view:   Select the menu Run > Debug Configuration: Alternatively, the debug icon drop down list can be used: Kinetis Design Studio supports three different debugging connections: GDB OpenOCD Debugging: this uses the OpenOCD to CMSIS-DAP debug protocol, available with OpenSDAv2.0 (FRDM-K64F) or OpenSDAv2.1 (FRDM-K22F) GDB PEMicro Interface Debugging: this can be used for any P&E device (Multilink, or OSJAT/OpenSDA P&E firmware on a Freescale board) GDB SEGGER J-Link Debugging: this can be used with any Segger device (J-Link, or OpenSDA J-Link firmware on a Freescale board) Once the configuration is created, I recommend to name it according t Double click on one of the entries to create a new configuration for it. Instead double clicking you can use the 'New' icon as well: What I recommend is to name the debug configuration. So I know later which configuration is for what. What I'm using is <project name><connection> like below: Another thing I highly recommend is to save the debug configuration as file in the project (.launch). This allows sharing or passing the debug configuration with the project files. To do this, I have 'Shared file' enabled: That way the launch configuration files are stored in the project:   Then I need to fill out the fields for the debug configuration. The details are listed in DS Debug Configurations (OpenOCD, P&E, Segger), and listed here again:   For OpenOCD, use "-f kinetis.cfg" which is the same for all Kinetis devices:   For P&E: select the interface, port and device:   For Segger, specify device name, interface (use JTAG only if you know the debug header supports JTAG. If in doubt, choose SWD): SWO (Single Wire Output) is an extra pin to SWD/JTAG, and currently not supported on FRDM boards. So I disable that option for my FRDM boards, as otherwise the debugger will complain later about it:   Debugging and Debug Icon To Debug, one way is to use the 'Debug' button from the Debug Configuration dialog: You have to do this at least once. Once you have done that, then you can use the drop down of the Debug icon: Just pressing the 'Debug' Icon is in general NOT recommended if it does not show in the tooltip a launch configuration: And if you get the dialog below: DO NOT select either gdbserver or remote gdb/mi: it does not work that way 😞 Press Cancel, and select it from the list, or select it from the 'Debug Configurations...' dialog:   Although KDS V1.1.0 has improved in this area, it is possible that it will show you a selection of launch/debug configurations (then you are ok to choose one): The recommended way is to use the drop down list and to select the desired debug/launch configuration:     Trouble Shooting If debugging does not work, here are a few trouble shooting tips:   Settings: verify that your launch configuration settiings are ok. That you are debugging the correct board with the correct connection (P&E, OpenOCD, Segger).   Power: Verify that your board has power and connected with the correct USB port on the board.   Not Debugging Twice: Make sure that you are *not* debugging the same application board twice, or you will get this: Because the board is already running a debug session: Always terminate an existing debug session before starting a new one: Kill any Zombies: the gdb client and server are usually terminated after a debug session. After terminating a debug session, verify that these services are *not* present any more in your task manager (Windows): arm-none-eabi-gdb.exe: this is the ARM GDB client, needed for the OpenOCD, Segger and P&E servers listed below openocd.exe: this is the OpenOCD GDB server pegdbserver_console.exe: this is the P&E GDB Server JLinkGDBServerCL.exe: this is the Segger GDB Server If you see multiple zombies/instances like this: kill them:   Links KDS Debug Configurations (OpenOCD, P&E, Segger) FRDM-K22F: Debugging with P&E OpenSDAv2.1 Firmware FRDM-K22F: Debugging with Segger J-Link OpenSDAv2.1 Firmware OpenSDAv2 FRDM-K64F | MCU on Eclipse Creating New Eclipse Debug Configuration | MCU on Eclipse