Mark Butcher

First experence with KDS (Beta) with FRDM-K64F

Discussion created by Mark Butcher on May 3, 2014
Latest reply on Sep 27, 2014 by Vittorio Castellini

Hi All


Here are some notes made whilst working with the new KDS for the first time with a FRDM-K64F board.



Installing KDS under Windows


The installer is simple to use. Just execute the setup "KDS-v1.0.1.exe" and follow the instructions.

The setup program is around 500MBytes in size and the installation process takes about 20 minutes to complete on a medium powered laptop. The actual installation starts after clicking through only a few typical setup screens.


There are no parallel installations of drivers etc. (that are noticeable to the user) but the PC must be restarted after completion for the configuration changes to take effect.


The release notes discuss a couple of known issues with the Beta version and points to the KDS community forum:


There are two directories created:





Starting KDS


During the installation a program was added to the program start menu. Optionally there will be a desk top link to it as well (depending on whether this was checked during the install process). The program starts as Eclipse typically does and may take a few minutes to launch the first time, asking which workspace is to be used at some point along the way.




Importing CodeWarrior 10.x projects into KDS


It is likely that KDS users have CodeWarrior projects that they would like to be able to use with KDS instead, or even in parallel to CW.


An attempt to import an existing CW10.5 project was successful in as much as the import of the files structure and targets was correct but there were no tool settings available to use the project once in the workspace. Although there is a context sensitive menu item named "Convert from CodeWarrior File..." this didn't react to attempts to use it.

When trying to open the project later in CW10.5 it failed since some of the project setups had been modified by the attempt in KDS; this means that a backup of the original files .cproject and .project, etc. should first be made before experimenting.

It was therefore decided to configure a new project based on internal examples to verify that this would be efficient.




KDS uses GCC 4.8.0 (CW10.5 used GCC 4.7.3). The standard settings for this compiler don't support asm() [for writing assembly in c-code] but instead required __asm__(). Otherwise all code is compatible.


The settings are very similar to CW10.5 settings (not all at the exact same locations but easily found) and so setting up a project again is not a huge task.

There are however a few things that don't work correctly (in comparison to CW10.5) which required some experimentation to work out what was (not) happening correctly and essentially resulted in some slightly nasty path names having to be introduced as workarounds. It may be that these will be improved in later versiosn so that they can be cleaned up appropriately:



1. Builder Settings.


The build directory is set to ${workspace_loc:/project_name}/Project_Flash but this is fixed and can not be modified to a (possibly) more convenient locations.



2. Path variables can be set but they don't work when used for defining locations where tools should should find files etc. For example it is possible to use a linker script path such as "${ProjDirPath}/Project_Settings/script.ld" but if ProjDirPath is replaced by a valid path variable (eg. PROJECT_LOC, which is the same location) it results in the linker just receiving "-T /Project_Settings/script.ld" [the path variable has been completely lost].

However build variables can be added which can be used form the same function so this not serious.




Building projects with KDS


KDS is missing the blend-in target drop-down which can be used to select a build target from the project explorer field but generally when editing and building one doesn't really notice any difference between working with CW10.5 or KDS.






This board is delivered with mbed debug support but Windows users will need to install the mbed serial port driver from to be abel to wwork with it.


If bad code is loaded to the board it is possible that the debugger can no longer connect to the board. This is seen by the red LED near to the debug connector flashing quickly. In this case use the debugger's integrated USB-MSD loader to program a software that operates normally. Keep a known good binary file at hand for such a case. See also Eric Styger's blog entry for more details:


The debugger on the board is CMSIS-DAP which is selected as OpenOCD (SWD mode).

If the installed debugger gets lost, which can happen if overwritten by a different code using its bootloader capabilities, the latest version and a description of how to load it can be found at - the version at the time of writing is called "k20dx128_k64f_if_mbed.bin"


When configuring a debug connection there are choices for the GDB OpenOCD, PEMicro and Segger J-Link. The FRDM-K64F uses the OpenOCD connection. The first trick to using this is to add

-f  kinetis.cfg

to the Debugger's "Other options" configuration" otherwise the debug configuration won't work with the connection.



There is a P&E version of the debugger which can be found in "C:\Freescale\KDS_1.0.1\pemicro\opensda". See also

In the KDS_1.0.1 this is called "DEBUG-FRDM-K64F_Pemicro_v108.S19" which is in SREC format and not suitable for loading to the board using the MBED loader. After conversion to binary it is possible to load it, however the debugger no longer started and so the original "k20dx128_k64f_if_mbed.bin" was reinstalled.



Unfortunately attempts to load code to the board or debug were unsuccessful although the debugger would connect and not give any error messages. It was seen that, although there was a lot of activity at the debug interface, the software that was already loaded continued to operate undesturbed. Any attempt to do anything with the debugger when connected resulted in it saying that there was no connection.


In comparison, the MBED debugger worked well with IAR, after adding the patch [This is detailed in the Freescale document:]



Working without debugger


Thanks to the MBED loader on the FRDM-K64F board it is still possible to load binary files to the board so that they can run.

It was however found that if Flash configuration settings in the binary image to be loaded are not all 0xff (apart from the non secured but that can be '0') the MBED loader would crash and so leave an invalid code programmed that would not operate. As long as the flash configuration values are left at 0xff it is reliable.





- KDS uses a different GCC compiler build which supports more core types (for K and KL Cortex-4 and Cortex-m0plus are used)

- the environment differs only slightly from CW10.x and runs fairly smoothly (faster than expected)

- there are a few workarounds needed to get an existing project configured in a comparable manner but nothing serious - annoying is mainly the fact that the location of the output directory can not be defined and so each target clutters up the embedded code directory a bit

- First attempts with flash loading and debugging failed but the code could still be loaded and verified using the built in MBED loader - the reason for this was not yet identified since there were no error messages when connecting or loading

- Due to the nature of Eclipse it is not possible to open a project in both KDS and CW10.x at the same time since they both want to have their (different) project files at the project root. The method used to move between CW10.5 and KDS (and also Atollic) is to keep a backup of the project files for each IDE and copy the project file set to the project root before opening the IDE to be used for a particular session


Essentially, once the debugger issue(s) can be solved and assuming that it then allows flash loading and basic debugging KDS should be able to replace CW10.x for all "basic use" since it doesn't look to have any major disadvantages for pure project building tasks.