Accelerometer in KDS   Description:   A project made in KDS using the FRDM-MKL46Z256VLL4 board's LCD screen to display accelerometer data. The LCD will initially display the accelerometer data for the X axis. Pressing SW3 will toggle between displaying other axis. A timer has also been included from my previous project. Pressing the SW1 at any time will reset the timer back to 0.   Sections of code taken from an example project found at: https://github.com/ErichStyger/mcuoneclipse/tree/master/Examples/FRDM-KL46Z/FRDM-KL46Z_Demo

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 !

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/

Writing to Acceleometer data to SD Card in KDS   Description:   A project made in KDS using the FRDM-MK64FN1MOVLL12 board to write the Accelerometer data to an SD Card. Every second, the time and the value of the variables x, y and z taken from the Accelerometer will be written to an SD Card. They will be written in a log.txt file, which will be created if it does not exist. The LED will flash green every second when writing. In case of an error, the LCD will flash red every second.   Sections of code taken from http://mcuoneclipse.com/2014/05/26/tutorial-data-logger-with-the-frdm-k64f-board/   Issues:   Time will always begin at 17:51:31 after being flashed. This is due to it being set as such at TmDt1_Init.

Since last year, I have received several same cases from customers when using KSDK1.2/KSDK1.3 and KDS3.0 with MK02FN128. When create a new MK02FN128 KSDK project with  SDK Project Generator (http://www.nxp.com/products/software-and-tools/run-time-software/kinetis-software-and-tools/development-platforms-with-mbed/software-development-kit-for-kinetis-mcus:KINETIS-SDK?fpsp=1&tab=Design_Tools_Tab ) or KDS3.0 project wizard, even the new created project has build errors:   When we use KSDK,  ksdk_platform_lib_xxxx must be built for the specific SoC being used in the new created KSDK platform. For K02F12810, this library project file is under: C:\Freescale\KSDK_1.3.0\lib\ksdk_platform_lib\kds\K02F12810   Open ksdk_platform_lib_K02F122810 with KDS3.0, there is wrong setup in ksdk_platform_lib_K02F12810 properties setting: the default target processor is cortex-m0plus!   Because K02 is cortex m4 core, obviously we need modify ksdk_platform_lib_K02F12810 target setting to cortex-m4 instead:   After above revise, rebuild the library project.  Then rebuild user project. The errors are gone.   If user needs to use K02F12810 ksdk_hal_lib_K02F12810 or ksdk_startup_lib_K02F122810 library, they need revise ARM family core to cortex-m4 accordingly. These two libraries project files are under: C:\Freescale\KSDK_1.3.0\lib\ksdk_hal_lib\kds\K02F12810 C:\Freescale\KSDK_1.3.0\lib\ksdk_startup_lib\kds\K02F12810   I have tested all the KSDS1.3 library projects. This defect is only in K02F12810 . NXP doesn’t have K02F FRDM board so far, User can download K02F128 project to FRDM-K22F board without problem. I suggest user use K02F128 project+FRDM-K22F board to start a project. For more information on this related, see application note: http://cache.nxp.com/files/microcontrollers/doc/app_note/AN5040.pdf “Using the FRDM-K22F to Evaluate K02 and K22FN Devices Hardware and Software Considerations”

Some customers have special requirements for the output data.  They need them to be aligned, especially when they are using the customized bootloader or Flash Programmer.     However, the hex file generated in KDS3.2 is not aligned as the customer expected. Below is extracted from the hex file generated in a KE06 project.  In this file, the data is not aligned at 16 bytes, and the size of each line is different.   The attached document shows generate aligned Hex and S-record file step by step.

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

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.

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

Recently I received two cases from Kinetis users. They both meet problem when porting Kinetis Interrupt project from CodeWarrior 10.x to KDS. There is a document KDS_Porting_Guide.pdf under KDS install folder which covers this topic. However I know many customers still have difficulty even they follow the document steps. This scenario is normal; because users’ projects are various, we can’t expect one porting document solve all kinds of problem of individuals. For me, honestly, I seldom use this porting guide to port my project. I prefer porting my project all by hand. Thus I can know my project changes from up to bottom. Thus even if I meet problem later, I can still position it easily and quickly. For the reason of time, in this article, I will focus on how to port Kinetis Interrupt from CodeWarrior to KDS by hand. Some NVIC register definition name and file structure are different in CodeWarrior and KDS. One big difference is that KDS uses core file from ARM limited directly. I summarized the difference as below table. It’s good to know the basic difference before we start the porting.       CodeWarrior KDS NVIC Register Definition :   Where MCU header file. Eg: MK60N512VMD100.h ARM Core file. Eg: core_cm4, core_cm0plus.h Written by NXP(former Freescale) ARM Limited Sample of usage NVICISERx = 0x01 NVIC->ISER[x] = 0x01 Packaged in NVIC_EnableIRQ(n) Vector Table Definition: Where Kinetis_sysinit.c Startup_MK60D10.S Language Using C Assembly Interrupt handler name Defined by user Defined by KDS. Eg, PORTA_IRQHandler Allow user modify. For more, see attached document.

FRDM-K64F is an ultra-low-cost development platform for Kinetis K64, K63, and K24 MCUs. this board is already widely used among Freescale customers. http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K64F   The FRDM-K64F platform features OpenSDAv2, the Freescale 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 J-Link interface, 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 are enclosed in this article as attachment.

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

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

Greetings, the new Kinetis Design Studio V3.0.0 is available in the download section of the Freescale web: http://www.freescale.com/kds Kinetis Design Studio is free of charge and unlimited.   What's New New Eclipse Luna 4.4 IDE Added Mac OS X (10.10, "Yosemite") host operating system support with Segger J-Link. Added CMSIS-SVD Peripheral Register viewer. New 'Welcome' view New GNU ARM Embedded (launchpad) toolchain, reducing memory footprint especially for small devices. New upgrade/migration assistant to migrate projects to V3.0.0. Updated and extended Segger and P&E debugging support: attach to running target, semihosting and advanced flash programming features. New Processor Expert V3.0 with multiple repository support and simplified Kinetis SDK usage and ability to generate projects for IAR and Keil. Updated New Project Wizard (NPW) for simpler project creation. Updated GNU ARM Eclipse plugins, multiple tool chain configurations. Aligned and optimized for Kinetis SDK v1.2 New Device Support: see attached release notes (Rev 1).   Additional Kinetis SDK Device Support For full/additional device support: Download the Kinetis SDK v1.2 from Software Development Kit for Kinetis MCUs|Freescale Install the Kinetis SDK Add Kinetis SDK v1.2 to KDS: Use the menu Help > Install New Software and use C:\Freescale\KSDK_1.2.0\tools\eclipse_update\KSDK_1.2.0_Eclipse_Update (KSDK path on windows)   See https://community.freescale.com/docs/DOC-103698 for additional details, especially about porting KDS v2.0.0 projects to the GNU ARM Embedded (launchpad) tools.   Screenshots of new features   Mac OS X support:   New Workspace Welcome view:   Kinetis SDK selection in New Project Wizard:   Ability to generate Processor Expert (Microcontroller Driver Suite) external projects for IAR and Keil:     Eclipse Luna 4.4, e.g. Split Editor Views:   Processor Expert V3.0 and multiple component repositories:   Upgrade assistant to migrate projects from KDS V1.x/V2.0.0 to V3.0.0:   Multiple tool chain configurations:   Peripheral Register Viewer:   JTAG Daisy Chaining:   Advanced Flash Programming Options: Attach to running target:   And finally, for the 'lovers of the dark side' :-): Eclipse Luna 'Dark' style:   Enjoy 🙂

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

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 🙂

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.

More and more customers now use the ARM MBED develop Internet of Things(IoT) and embedded devices, also includes the kinetis chips. While this development tool only supports writing and compile code , not supports debug project. The good news is now we can export the project to KDS, we can debug it on KDS IDE. Below is the steps how to do it .

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 🙂

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