(NOTE: this document gets constantly updated with new information)   =========================================================================== Release Notes: Kinetis Design Studio (KDS) V1.0.1 Beta Date: 06-June-2014 ===========================================================================   Content: 1) What's New 2) Devices Supported 3) Known Issues and Workarounds   Freescale Community Forum: https://community.freescale.com/community/kinetis-design-studio   =========================================================================== 1) What's New =========================================================================== Kinetis Design Studio is a complimentary, free of charge and unlimited Eclipse based tool chain with GNU gcc and GNU gdb for the Freescale Kinetis devices. As debug connections, OpenOCD/CMSIS-DAP, P&E Multilink and Segger J-Link are supported.   A pre-release of the V1.0 beta has been used at the Freescale Technology Forum (FTF) 2014, and based on this feedback, several things have been improved: Installer: Backslash has been removed from KSDK_PATH variable. An additional variable is created (KSDK_PATH_1_0_0_BETA). Installer: Processor Expert CDE (Component Development Environment) is now installed too. Installer: fixed issue with intstallation into a path with spaces. Installer: The installation dialog dealing with removing old versions of KDS has been reworded to clarify that it offers users the opportunity to search for and remove old versions, not that it has already detected old versions on the system already. Installer: The working directory used by shortcuts created on Windows is now the KDS eclipse/ directory. This allows workspaces to be positioned relative to the installation. Processor Expert: an updated version of Processor Expert has been incorporated. Project Creation: Bare projects are now created with proper *.S assembly file extension. Project Creation: Kinetis SDK __START, __HEAP_SIZE and __STACK_SIZE preprocessor symbols are now generated, and include path settings have been extended. Project Creation: Projects for M4 cores with floating point unit have the hardware floating point options set in the compiler settings. Debugging: Updated (v4.84c) version of Segger debug tools which fixes a "Move to Line" GDB issue seen with previous versions. Eclipse: A new release of the GNU ARM Eclipse plugins (http://gnuarmeclipse.livius.net/blog) has been incorporated. This includes fixes for the following issues: On Windows the "Allocate console for OpenOCD" checkbox, that must always be checked, can no longer be modified. The GNU LD Error parser is now enabled by default. Previously errors and warnings from the linker didn't appear in the Problems view. Eclipse: The name of the default workspace has been changed to "workspace.kds". Eclipse: The list of available update sites now includes the P&E Micro update site. OpenOCD: In its default configuration OpenOCD will now always write a known-safe value to the Flash Configuration Field (FCF). This is designed to prevent users from inadvertently locking their devices by programming them with a broken executable. This safety feature can be disabled with the "fcf_write_enable" command, and re-enabled with "fcf_write_disable". These commands may only be used after the kinetis flash bank has been defined. OpenOCD: The part-specific OpenOCD configuration files included in previous releases have been deprecated. They have been replaced by a single configuration file for all kinetis parts: kinetis.cfg. This unified file also uses a faster adapter speed of 1000 Khz. Toolchain: Previous versions of the linker emitted a warning "cannot find entry symbol", when the specified entry point of the program could not be found. This warning has been promoted to an error by default. A pair of options, --warn-missing-entry --error-missing-entry, have been added to allow users to control this behaviour.   IMPORTANT: the KDS V1.0.1 beta installation comes with an installation of the beta Kinetis SDK. For KDS V1.0 GA (General Availability Release), the Kinetis SDK will be a separate installation/zip file, and therefore projects created with the KDS V1.0.1 beta will likely not work with that future Kinetis SDK version without modifictions (e.g. updating path settings).   =========================================================================== 2) Devices Supported =========================================================================== Processor Expert projects: - All Kinetis ARM Cortex-M0+ and Cortex-M4(F) devices supported by Processor Expert.   Kinetis SDK projects: - K64F (MK64FN1M0VMD12 only)   Bare Projects (no SDK and no Processor Expert projects) - K64F, KL25Z   =========================================================================== 3) Known Issues and Workarounds =========================================================================== Installation ISSUE: Users of the KDS v1.0 (FTF) may have an old KSDK_PATH "User" environment variable set. The updated installer only modifies system environment variables. WORKAROUND: Users should remove any stale "User" KSDK_PATH environment variables. ISSUE: When Kinetis Design Studio is installed in a read-only directory, for example Program Files, the Eclipse configuration is stored in a user-specific area. If the user has other versions of KDS, or other Eclipse-based products, using that same configuration area they may be prompted to perform an update when they launch Eclipse. For the components that don't provide a public update site this update will fail, however KDS should still be fully functional; the update can safely be skipped. WORKAROUND: Use the default installation path proposed by the installer. ISSUE: Installing on Linux, if you already have Segger drivers installed, you might receive an error like "dpkg: error processing kinetis-design-studio_1.0.1-1_i386.deb (--install): trying to overwrite '/etc/udev/rules.d/99-jlink.rules' which is alos in package jlink 4.78.7". WORKAROUND: make sure that you install as root. Uninstall the existing j-link drivers before running the KDS installer.   Project Creation ISSUE: For bare projects (no SDK, no Processor Expert), the project is with a linker file for the KL25Z. WORKAROUND: Change/replace the linker file with a linker file matching the device (e.g. copy from a Processor Expert project). ISSUE: Converting and Importing CodeWarrior for MCU projects to KDS as outlined in the QuickStart might result into projects which do not build. As the libraries for KDS are different (EWL), the cannot be automatically mapped to the GNU libraries. WORKAROUND: Update the projects settings manually after project import. ISSUE: Migrating existing CodeWarrior projects with multiple build targets can result in an error message Cannot run program "": Launching failed. The CodeWarrior Migration Assistant only converts the active build configuration. Other build configurations will be partially converted. WORKAROUND: This can be fixed by manually editing the Builder Settings tab in the C/C++ Build properties: Uncheck "use default build command" and replace ${cross_make} with make. ISSUE: After creating a project for MK64 devices that uses both Processor Expert and KSDK users may see build errors: "No valid CPU defined" fsl_sim_features.h. WORKAROUND: This can be worked around by adding a pre-processor definition supported by fsl_sim_features.h to the Projects C Compiler pre-processor settings. For FRDM-K64F make sure the following two symbols are defined in tehe Preprocessor settings of the compiler: "CPU_MK64FN1M0VLQ12" and "CPU_MK64FN1M0VMD12". ISSUE: For Kinetis SDK projects (both only SDK and SDK+PEx), global variables and library does not get properly initialized. A hard fault or undefined global variables are the possible result. This is caused by skipping some initialization code in the startup code. WORKAROUND: In the project settings, under Cross ARM GNU Assembler > Preprocessor, delete the "__START=main" and add __NO_INIT_DATA_BSS to the defines.   Processor Expert ISSUE: Using the AsynchroSerial component causes an error about missing SIM_PDD_SetClockSourceUART0(). (see Missing function SIM_PDD_SetClockSourceUART0 in KDS 1.0.1). WORKAROUND: See workaround in Re: Re: Missing function SIM_PDD_SetClockSourceUART0 in KDS 1.0.1 ISSUE: Processor Expert projects cause a rebuild of the project even if no changes are made. The issue is for example that after opening a project, the Processor Expert .pe (XML) file gets changed, causing a rebuild of the whole project. WORKAROUND: none.   Building ISSUE: ISSUE: In the problems view, after creating or opening a project, the messages "arm-none-eabi-gcc" not found in PATH appears. WORKAROUND: Ignore/delete these errors, as they come from the Eclipse indexer/parser, and they do not affect functionality. The messages will disappear as well if the project is built. Alternately the Problems view can be configured not to show errors from the Scanner: Select "Configure contents" from the Problems view menu, then uncheck the "Show all items" checkbox in the top left, and the "C/C++ Scanner Discovery Problem" checkbox in the types list. ISSUE: The Kinetis SDK comes with projects configured for the GNU ARM Embedded Toolchain which is different from the toolchain used in KDS. So the KDS make file projects cannot be used without modifications with KDS. WORKAROUND: Create a KDS project and add the SDK files to it. ISSUE: Building a Processor Expert project reports duing linking "arm-none-eabi/bin/ld.exe: cannot find entry symbol Reset_Handler". The likely reason is that the project sources for the CPU component including the vector table has not been generated properly. WORKAROUND: Enforce generation of the vector table and the linker file. Go the to 'Build' properties tab of the CPU component and e.g. change the stack size of heap size, then regenerate the code and build again.   Debugging ISSUE: Clicking on the 'bug' (or 'debug') toolbar icon shows a dialog named "Launch DEbug Configuration Selection", and debugging fails from there. WORKAROUND: select the debug configuration from the list behind the small triangle drop down in the 'debug' toolbar icon. ISSUE: When trying to start an OpenOCD debug session from within Eclipse, if the underlying OpenOCD tool fails to start, the Eclipse process manager may appear to hang or may fail with an uninformative error message. Possible causes of OpenOCD failing to start include a board not being connected, a board running the wrong OpenSDA application, or bad options being passed to OpenOCD. Running the command line tool: <KDS_INSTALL_DIR>/openocd/bin/openocd.exe may provide more informative output. WORKAROUND: Make sure the board is properly connected and powered. ISSUE: In some cases it is possible that with using OpenOCD and CMSIS-DAP it can lock the K64F chip on the board, so the CMSIS-DAP is not able to access it any more. You need a P&E Multilink or Segger cable to regain access to the chip. WORKAROUND: Make sure you use the lastest CMSIS-DAP release as it migh have fixed that issue. Use the P&E or Segger debug firmware to debug the board. Steps to load the new firmware: a) Power the FRDM-K64F board with the OpenSDA USB port and hold the reset button while powering the board b) Release the reset button, the board enumerates as BOOTLOADER device, the green LED is blinking. c) Copy the DEBUG_K64F_MBED_PEMICRO_V108.BIN file to the BOOTLOADER device. The green LED will blink fast. c) Repower the board normally: the green LED will be always on. ISSUE: If the PATH variable has double semicolons (;;) or a semicolon at the end, launching gdb debugger might fail. The it is possible that the gdb debugger specified with ${cross_prefix}gdb${cross_suffix} is not found. An error message with "Error while launching command: gdb --version" is shown. WORKAROUND: The likely reason for this issue is a double semicolon in the PATH environment variable, or a semicolon at the end of the variable, see  https://bugs.eclipse.org/bugs/show_bug.cgi?id=389823. If a double semicolon or one at the end is present in your PATH, remove it. If this does not help: In the launch configuration settings, instead using ${cross_prefix}gdb${cross_suffix}, point directly to the GDB executable, e.g. "C:\Freescale\KDS_1.0\toolchain\bin\arm-none-eabi-gdb.exe". ISSUE: The Quick Start Guide (installed in the layout, not the one in this community) states that no OpenOCD debug configuration is required, however "-f kinetis.cfg" must be specified in the other options box. WORKAROUND: specify "-f kinetis.cfg" in the other options box. ISSUE: The current versions of the mbed CMSIS-DAP image sometimes exhibit meta-stability. This manifests as "CMSIS-DAP Write Error (0x04)" and "Polling target kinetis.cpu failed" messages being emitted by OpenOCD. A possible cause is an invalid program being flashed to the device. WORKAROUND: Use another debug technology (P&E Multilink, Segger J-Link) to flash a valid program to the device. ISSUE: When creating a bare project (no KSDK and no Processor Expert) for MK64 devices, programs may not reach main when debugging. This is caused by the the COP watchdog triggering a reset. WORKAROUND: To work around this issue disable the watchdog in __init_hardware, as demonstrated by Processor Expert projects. See Disabling Watchdog for 'Bare' Projects ISSUE: 'Disconnect' from a running target debug session does not work as expected (e.g. halts the target). WORKAROUND: use this as 'Other options' in the debug configuration: -f kinetis.cfg -c "kinetis.cpu configure -event gdb-detach {   resume }"     =========================================================================== Freescale, the Freescale logo, Kinetis, Processor Expert are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. All other product or service names are the property of their respective owners. ARM is the registered trademark of ARM Limited. (c) 2014 Freescale Semiconductor, Inc. ===========================================================================

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 !

Hello community!   Attached is a document that explains how to use Kinetis Design Studio to debug both a bootloader and application at the same time, this will be done using GDB commands to specify an additional symbol file to be used in the debug session.   The bootloader used for this example is the project for the FRDM-K64F board provided in the KBOOT 1.2.0 named freedom_bootloader and the application is a bareboard led demo that was adapted to work with this bootloader by following the steps described in this document:   https://community.freescale.com/docs/DOC-256669   The document was created using the MK64FN1M0VLL12 MCU like the one in the FRDM-K64F board, but the same principles are applicable to any Kinetis MCU.   Software versions The steps described in this document are valid for the following versions of the software tools: KDS v3.2.0 KBOOT v1.2.0     Contents      1. Overview and concepts. 1.1 Kinetis Bootloader. 1.2 GDB Server.      2. Flashing Bootloader and Application. 2.1 Flashing freedom_bootloader project. 2.2 Loading demo application using the Kinetis Updater. 2.3 Flashing demo application and bootloader using the P&E advanced programming options.      3. Debugging Bootloader and Application. 3.1 Debugging bootloader and demo application projects using the P&E interface. 3.2 Debugging bootloader and demo application projects using the Segger interface.      4. Conclusion.      Appendix A - References.     I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza Original Attachment has been moved to: K64F12_Led_Demo.zip

  Hello Freedom community users Bheema has posted on the Element14 community a very clear tutorial (accessible following the link below) to create from scratch a basic project example for the FRDM-K64 with Kinetis Design Studio (KDS). Freescale Freedom development platform: [FRDM-K... | element14 I strongly recommend you to start following those steps to properly setup the tool and the OpenSDAv2 interface embedded in the new Freedom and TWR boards. Happy Programming Greg

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

In KDS and Codewarrior for MCU GCC build, linker will initialize RAM after reset, the enter main function. However in some application,  User doesn’t want linker initialize data section. A typical case is when in a bootloader+application combined project, the two program need share the same RAM memory - user application writes data to a shared RAM then invoke bootloader by software reset,  bootloader can read the exact data out. The data in shared RAM are not being overwritten by bootloader linker initialization.This article will introduce two methods about how to add uninitialized data section to GCC build.   Method 1. Use NOLOAD keyword in linker file: NOLOAD : The section should be marked as not loadable, so that it will not be loaded into memory when the program is run. For example in below section .buffram and .bss2 are addressed as “NOLOAD” and doesn’t need to be loaded when the program starts to run. For detail, see article on MCU on Eclipse: http://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/   Method 2. Use  pointer in C code for uninitialized RAM. This method doesn’t use NOLOAD. Here are the steps to utilize it: Step1: don’t define uninitialized RAM in linker file. Step2: in C file, use point to access the uninitialized address.   For detail, see attached document with demo listed.

Greetings, attached is the material of the Kinetis Design Studio (KDS) hands-on training held at FTF 2014 in Dallas. It was using the V1.0 pre-beta version of the tools. There will be some changes for the final V1.0 beta coming out early in May, but is very close to the upcoming beta.   Erich Original Attachment has been moved to: Lab_1.zip

Sometimes I only want to download a binary (.s19, .hex, .elf) without the need for the project and sources of it. With the command line version of GDB you can do this, but there is as well a way in KDS to do this more interactively: Flash to File...   From the Run menu, select 'Flash from file...':   Then configure your connection (see KDS Debug Configurations (OpenOCD, P&E, Segger)). Beside of the settings in the Debugger Tab (which depends on the used debug interface (P&E, Segger, OpenOCD, see note1 below), you need to specify in the 'Main' tab two things: The name of the binary (e.g. elf file) A project name (see note2 below)     Note1: there is a current issue in KDS v1.0.1beta that P&E is not listed as Debugging Connection. This is expected to be fixed in KDS V1.1 (GA).   Note2: While the project is not really necessary, there is the issue in KDS v1.0.1beta that without a project name, you will get an error. So if you start with a new/empty workspace, you need to create a 'dummy' project first and to provide this as a project name.   Happy Flashing 🙂

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

Hello community!   This document explains how to link the CMSIS-DSP library to a KSDK 2.x project in KDS.   The steps described in the document were done using the MK64FN1M0VLL12 MCU like the one in the FRDM-K64F board, but the same principles are applicable to any Kinetis MCU.     Software versions The steps described in this document are valid for the following versions of the software tools: KDS v3.2.0 KSDK v2.x     Contents   1. Glossary. 2. Overview and concepts.      2.1 CMSIS - Cortex Microcontroller Software Interface Standard.           2.1.1 CMSIS Components. 3. DSP example application.      3.1 Creating KSDK 2.x Project.      3.2 Linking CMSIS-DSP Library.      3.2 Importing DSP example source files. Appendix A - References.     I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza

When starting a new project, in many cases it is helpful to start from an existing project and copy it.  Here are some methods to do this when starting with the Kinetis Software Development Kit (KSDK).  This example is done with KSDK v1.3.0, and the toolchain Kinetis Design Studio (KDS) v3.2.0, using the KSDK hello_world demo for the FRDM-KL03Z board.   There is a handy tool called KSDK Project Generator, which is useful for starting a new KSDK project, or cloning some KSDK example projects.  But sometimes it is still preferred to copy an existing project.   KDS is built on the Eclipse IDE.  And Eclipse provides the ability to copy a project within the Project Explorer view.  To do this, right-click the project in the Projects View to copy, and select Copy.  And then the project can be pasted in the Project Explorer.   When pasting the project, Eclipse defaults to creating the copied project in your workspace directory.   Using the default location like this works for simpler projects, where the needed files are self-contained in the project directory.  But with a KSDK example project, this default location will typically lead to errors in the copied project, see screenshot below.  The reason is because the KSDK example projects use project-relative paths to find the source files and libraries used by the project.  These paths are relative from the original KDS project directory.  After copying to a new location like this, the needed files are no longer in the same relative location from the new KDS project directory.  In a new location like this, all the paths in the project settings will need to be updated from the new location to build.   So another option when copying the project is to place the new project under the same parent directory of the original project.  That way, all the project-relative paths are the same.  For example, the hello_world KDS project directory used here is located by default at C:\Freescale\KSDK_1.3.0\examples\frdmkl03z\demo_apps\hello_world\kds.  This time, the new project will be copied to the same parent directory, using C:\Freescale\KSDK_1.3.0\examples\frdmkl03z\demo_apps\hello_world\Copied_hello_world_frdmkl03z.  Using this location, the copied project builds without errors.   If it is preferred to move the new project somewhere other than the parent directory of the original project, then the paths in the new project settings need to be updated.  Here are the typical project settings within KDS that need to be changed based on the new project directory location:   C Compiler Includes settings for all the header files in KSDK:   Linker settings for the linker command file location:   Linker settings for KSDK library locations:

This is the first video of four KDS v3.0.0 videos. The videos shall guide you through installation and using the Kinetis SDK with a FRDM board.   Overview: Installation Kinetis Design Studio Kinetis SDK Kinetis SDK Eclipse Update Creation of SDK project for FRDM-K64F Compile/Build/Debug   List of all videos: Kinetis Design Studio Videos, Part 1: Installation of KDS and Kinetis SDK Kinetis Design Studio Videos, Part 2: Installation of OpenSDA Firmware on Freedom Board Kinetis Design Studio Videos, Part 3: Debugging with Kinetis Design Studio Kinetis Design Studio Videos, Part 4: Using Processor Expert in KDS

KDS V1.0.1 (beta) with FRDM-KL25Z board which has P&E OpenSDA as firmware loaded. Steps shown with creating the project, creating debug configuration for connection and device, then debugging it.

This SD card bootloader demo offers to user a way how to using SD card to update existing firmware. The two project of attachment are the demo code create by CodeWarrior 10.6 and KDS 3.0 . The document of attachment is the application note of the bootloader, you can find the detailed description about the bootloader.   It is easy to be used:      -Hardware: TWR-K60F120      -Software: CodeWarrior 10.6 or KDS 3.0        Getting started :      - Change the name of user application binary file to “app_0x10000_1.bin”, then copy and paste it on SD card;      - Insert the SD card into the TWR-K60F120 board;      - Build and flash “bootloader_sd_k60120m” to the board;      - Press the SW1 button, at the same time, press once the RESET button, thus it will update the user application to the flash.      - Again, only press the RESET button, it will directly run the user application.     Best Regards! Alice

NOTE: with the release of KDS V1.1.0 this quickstart is depreciated!   Note that this quickstart guide is an update/newer version than the one installed by the installer.

Hi everybody,   this time you will find in the attached document the required settings to build a C++ project using KDS3.0 and MQX for KSDK1.2.   For information about creating a simple C MQX RTOS for KSDK1.2 project please see the following document. How To: Create a New MQX RTOS for KSDK Project in KDS   For information about creating a simple C FreeRTOS for KSDK1.2 project please see the following document. How to: Create a New FreeRTOS for KSDK1.2 Project in KDS3.0   Best regards, Carlos

NXP Freedom K22F is an ultra-low-cost development platform for Kinetis K22 MCUs. This board is already widely used among NXP customers. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K22F   The FRDM-K22F platform features OpenSDAv2.1, which is a bit different as OpenSDAv2 on FRDM-K64F board.  The NXP open source hardware embedded serial and debug adapter running an open source bootloader. This circuit offers several options for serial communication, flash programming, and run-control debugging. User who works with KDS3.0 can choose Segger J-Link OpenSDA, P&E OpenSDA interface, or Mbed interface.  For each of the option, user need update debugger firmware first.  I will introduce each of them one by one.   All the related driver and firmware will be enclosed in this article as attachment.   Enjoy KDS + FRDM-K22F debugging. 🙂

(NOTE: this document gets constantly updated with new information) =============================================================================== Release Notes and News: Kinetis Design Studio V1.1.0 Version Date: 05-Aug-2014 ===============================================================================   Greetings, The Kinetis Design Studio is a complimentary (free of charge) IDE and tool chain to develop, build and debug embedded applications for Freescale Kinetis Devices. It is based on open source software including Eclipse, GNU compiler and GDB Debugger. The Kinetis Design Studio is offered for free, and support for it is provided through this Freescale Kinetis Design Studio Community Forum.   Setup Files and Installation The software can be downloaded from the download section here: Kinetis Design Studio Integrated Development |Freescale. Currently, installation files are provided for Windows 7/8 (.exe) and Ubuntu 32-bit (.deb). NOTE: Installation files for RedHat/Centos (.rpm) have not been released yet, but we expect either a workaround or a fix shortly. NOTE: To have the full device support (e.g. KV31 devices) and Kintetis SDK support, you have to install the Kinetis SDK and install the KDS Eclipse update in <sdk installation>\tools\eclipse_update.   Documentation and Release Notes The documentation page on http://www.freescale.com/kds hosts several documents: Fact Sheet: Information about Kinetis Design Studio User Guide: Installation and Setup, first steps with Kinetis Design Studio Porting Guide: How to port applications from CodeWarrior to Kinetis Design Studio. Release Notes: Information about device support, known issues and workarounds. As the information and release notes are constantly updated, an update of the infomation is provided in the "Release Note Update" section below. Migrating from KDS V1.0.1 (Beta) to KDS V1.1.0 If you have the beta version installed, there is no need to uninstall it. Uninstall it once you migrated everything from the beta to the V1.1.0. If you have a workspace or projects from the beta version, it is recommended that you start with a new workspace (do not share a workspace between different versions!). You should be able to migrate 'normal' projects easily. However, Kinetis SDK projects will not be able to be migrated easily, because there has been a lot of changes. If you are migrating a Kinetis SDK project, then the best advice is to create a new project with KDS V1.1.0 and then move your own files over.   Release Note Updates and News This section contains updates and news after publication of the release notes: 05-Aug-14: Installation for RedHat/Centos 32-bit: the installation files are on hold right now. Watch for an annoucement in this community forum. 05-Aug-14: OpenOCD for FRDM-K22F board: KDS does not support OpenOCD for the K22F on these boards yet. Instead, a Segger (see FRDM-K22F: Debugging with Segger J-Link OpenSDAv2.1 Firmwarehttp://www.segger.com/opensda.html) or P&E debug application can be used until there will be an OpenOCD update for KDS. Watch for an announcement in this community forum.   Thanks for using the Kinetis Design Studio!   =========================================================================== Freescale, the Freescale logo, Kinetis, Processor Expert are trademarks of Freescale Semiconductor, Inc., Reg. U.S. Pat. & Tm. Off. All other product or service names are the property of their respective owners. ARM is the registered trademark of ARM Limited. (c) 2014 Freescale Semiconductor, Inc. ===========================================================================   Freescale Community Forum: https://community.freescale.com/community/kinetis-design-studio

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!

Normally when debugging you need to know the status of your registers in the Embsys Registers section. Most of the time when a board or chip are just released you are not able to select them (because they're not available) and therefore it makes it more difficult for you to debug. In this document I will guide you through the process for adding any chip you are working with to EmbSys Registers section. 1. First of all it is needed to know where the Embsys Registers' Folder is located. Go to the folder where KDS is installed. 2. Go to eclipse folder. 3. \org.eclipse.cdt.embsysregview.data_0.2.4.freescale 4. \data 5. \SVD(CMSIS) 6. \Freescale 8. Finally this folder contains XML files, these files can be processed purely as data by the program. To add a new XML file which describes the new chip: 1. go to your chip's package (In my case \SDK_2.2_MKL28Z512xxx7.zip). Note: If you don't know where to build a package, please go to the following post: https://community.nxp.com/docs/DOC-333304  2. \SDK_2.2_MKL28Z512xxx7.zip\devices 3. \SDK_2.2_MKL28Z512xxx7.zip\devices\MKL28Z7 As you can see, the MKL28Z7 is not available in EmbsysRegView. Locate the XML and copy it to the route: C:\Freescale\KDS_v3\eclipse\plugins\org.eclipse.cdt.embsysregview.data_0.2.4.freescale\data\SVD(CMSIS)\Freescale Paste it in Freescale's folder: Go to EmbSysRegView again and now it will be available Restart Kinetis Design Studio and you'll be able to see your chip's registers: By Ivan Ruiz.