Tutorial: DIY Kinetis SDK Project with Eclipse – Startup

This is the start of a multi-post tutorial about the Freescale Kinetis SDK, released back in April as beta version. The SDK a set of peripheral drivers, and will become the standard software foundation and drivers provided by Freescale for their ARM Cortex based devices. Similar what other vendors already do. While this is a good step, it is the same time very disruptive for my university projects with new Freescale Cortex-M devices. And with everything new (and beta), it needs time to learn. So this post is about creating a Do-It-Yourself Kinetis SDK project from scratch for Eclipse. This part is about the startup code: about everything to get the application started.

FRDM-K64F with SD, nRF24L01+ and HC-06 Bluetooth

FRDM-K64F with SD, nRF24L01+ and HC-06 Bluetooth

Learning new stuff?

Typically I have two kind of students:

  • Type 1 is looking for something already set-up and working. Does not want to know about all the details. All what he cares about is reaching the goals, e.g. passing the exam or have his lab assignment working.
  • Type 2: As type 1 does want to reach the goal too. But wants to understand and know the details behind it, down to the bits and bytes.

Type 1 is what is more ‘extrinsic’ (externally) motivated, while Type 2 is more ‘intrinsic’ (internally) motivated. Type 1 typically has more problems later to apply the knowledge to similar situations, while Type 2 needs to be careful to balance between how much to go into the details without loosing the final goal out of sight.

It is the same way with developing software or using tools: many prefer to just have an example and then go with it. Others want to build up something from scratch (DIY: Do-It-Yourself) and know every detail. To some extend it is a typical ‘make or buy’ decision: each approach has its justification.

Creating (instead of buying) needs time, but has the opportunity to gain knowledge. But creating can be painful if it does not work the right way, or if at the end the result is not achieved. This tutorial is for the DIY readers, as it goes through the steps to build an initial project for the Freescale Kinetis SDK with Eclipse IDE, GNU ARM Embedded and the GNU ARM Eclipse plugins.

If you are a Type 1 person (and still reading this): scroll to the end of this article, and you find the link to download the project from GitHub ;-).

Eclipse Kepler and Kinetis Design Studio (KDS)

By default, this tutorial is using my classroom IDE with Eclipse Kepler and GNU ARM Embedded toolchain (see “Constructing a Classroom IDE with Eclipse for ARM“). Many of the steps outlined in this tutorial are performed by the ‘new project wizard’ inside the Kinetis Design Studio (KDS). I have outlined the differences in my text below. So if you are using KDS, then many settings will ‘magically’ in place which makes things easy. However, this does not give you the knowledge about *what* is configured, and *why* things are the way configured as they are. So I believe even if you are KDS, this tutorial is of value for you because it makes a deep dive into the mechanics and settings for a KDS project. I hope that makes sense? And as a side effect it allows you to work around some of the KDS beta version issues.

Freescale Kinetis SDK

Kinetis SDK Block Diagram (Source: Freescale web site)

Kinetis SDK Block Diagram (Source: Freescale web site)

The Freescale Kinetis SDK is available as beta download from http://www.freescale.com/ksdk. It is basically a set of drivers (UART, SPI, I2C, …) with API for the Freescale Kinetis (ARM) microcontroller. It comes with a very permissible open source license attached which makes it attractive. It has a hardware abstraction layer and the ability to plug-in operating systems with an Operating System Abstraction (OSA) like MQX, uCOS and FreeRTOS, but is bare-metal (no RTOS) by default. It is the first time Freescale really adopts CMSIS (the standard for ARM cores). Unfortunately, the Freescale Kinetis SDK is quite complex and not easy to setup (at least with the current beta). And this is the reason for this tutorial: showing how to set up a ‘bare’ project in Eclipse which then can be extended more functionality later on.

The Kinetis SDK comes with make files to build it. You need to be a make file expert to understand all the distributed make files which is beyond the scope of this tutorial. Because of the complex and many directory structure, it is not easy to use the SDK with an IDE like Eclipse neither. So let’s have a look at the directories:

Kinetis SDK Directory Structure

Kinetis SDK Directory Structure

  • apps: has demo applications.
  • boards: has board configuration which have the peripherals of a particular board (e.g. LED, accelerometer, etc) configured.
  • doc: has API reference manuals and getting started guides.
  • lib: the purpose of this folder is to contain pre-build libraries of SDK configurations.
  • mk: has common make files
  • platform: this has the core of the SDK with many sub folders, including the CMSIS.
  • CMSIS: has the CMSIS-CORE and CMSIS-DSP files.
  • drivers: has device drivers like UART, SPI, I2C, …
  • hal: hardware abstraction layer for the device drivers.
  • linker: has linker files
  • startup: has C/C++ startup files
  • utilities: common utility functions. Weired part is that it contains the SDK OS (Operating System) abstraction too?
  • rtos: The SDK itself does not come with any RTOS (it comes as ‘bare metal’), but is prepared that an RTOS (FreeRTOS, MQX, uCOS, …) can be plugged in here.
  • usb: USB stack sources are here.

With this high level overview knowing what is in the SDK, we can start to create a project with it.

Preconditions

For this tutorial you need:

  1. Eclipse Kepler IDE with GNU ARM Embedded toolchain and GNU ARM Eclipse plugins. See “Constructing a Classroom IDE with Eclipse for ARM” how to build such a toolchain.
  2. Kinetis SDK downloaded and installed. You can download it from http://www.freescale.com/ksdk. I have Eclipse variable ${KSDK_PATH} pointing to the installation location.
  3. Because the SDK only supports a few devices as of today, I’m using the FRDM-K64F board. If you have a different board, then you can use the steps below, just use a different board name.

To have things independent where the SDK is installed, I have two variables defined in my workspace: ${KSDK_PATH} and KSDK_LOC:

${KSDK_PATH} is used for the GNU build tools to find the header files/etc:

KSDK_PATH build variable

KSDK_PATH build variable

KSDK_LOC is used for linking files in the project:

KSDK_LOC Linked Resource Variable

KSDK_LOC Linked Resource Variable

Using that KSDK_LOC variable, I can make my linked files using it:

Link to KSDK_LOC

Link to KSDK_LOC

Outline

I’m going through the baby steps to create a project, add the needed files to have at the end a project running with the Kinetis SDK. So with this you learn which files you need and how to configure a project from scratch. The project does not do anything at the end, so this will be subject of a next tutorial (to be written).

So let’s start…

Creating Empty Project

First, I need to create a new project:

💡 For KDS, use the menu File > New > Kinetis Design Studio Project, and then only select the SDK option (Processor Expert option not enabled).

  1. Menu File > New > C Project:

    New Kinetis SDK Project

    New Kinetis SDK Project

  2. Provide a project name and select ‘Empty project’ for ‘Cross ARM GCC’:

    Empty Cross ARM Project

    Empty Cross ARM Project

  3. Use the defaults in the other wizard dialogs, and have the project created.

And I have what I asked for: an empty project 🙂 :

Empty Project

Empty Project

Compiler Settings

The project is a default one, so the first thing to do is to verify that it is generating the code needed for my CPU. I’m using here the FRDM-K64F board which has an ARM Cortex-M4F. The ‘F’ suffix means it has a hardware floating point. So I go to the project settings (select the project, menu Project > Properties > C/C++ Build > Settings) and configure it for

  1. Cortex-M4
  2. FP instructions (hard)
  3. fpv4-sp-d16
Cortex-M4F with hardware floating point

Cortex-M4F with hardware floating point

💡 The KDS project wizard already should have set the correct settings as shown in the screenshot.

Startup code

The first thing I need for my project is the startup code. The startup code sets program counter and stack pointer, configures my hardware (clock speed, clock gates, …), initialize my global variables and then jumps to main(). The Kinetis SDK comes with a startup code which I’m going to add.

💡 I’m creating here folders (context menu on project,  New > Folder) to ‘mimic’ the Kinetis SDK folder structure, and have then ‘link to files’ to the files in the Kinetis SDK structure. The Kinetis SDK has many, many sub folders, and this makes it really hard to find files, and requires to setup many compiler include paths. So creating the folder structure in my project helps me to visualize from where I’m taking the files. Of course you can use another way (e.g. copy all the needed files into a folder inside your project). Actually that copy method is not a bad idea, but not used here. Just experiment and use the way which fits you best.

The startup for my board needs three files:

❗ I’m using ‘link to files’ here for the startup code, as I’m not going to change the startup files. However, some times it is necessary to change the startup files for the application needs. In this case, make sure you *copy* the files to your project, otherwise you are changing the content of the SDK!

Startup Code

Startup Code

  1. ${KSDK_SDK}\platform\startup\startup.c: initialization of global memory and variables.
  2. ${KSDK_SDK}\platform\MK64F12\system_MK64F12.c: this configures the ‘system’ with clock configuration.
  3. ${KSDK_SDK}\platform\MK64F12\gcc\startup_MK64F12.S: the application entry point from the reset vector, written in assembly.

💡 The KDS project wizard has copied the system and startup files to the project at project creation time.

It is important to understand the sequence of the startup:

Standard Startup Sequenc

Standard Startup Sequenc

  1. At hardware reset, the processor fetches the initial stack pointer and initial program counter from the reset vector. Typically the PC then points to the Reset_Handler.
  2. The reset handler performs system initialization, initialize the memory and library. Each step can be configured with assembler macros (see below).
  3. System initialization is peformed to configure watchdog, initial clock settings or things like enabling the Floating Point Unit (FPU) if present.
  4. The bss data (global memory) gets initialized.
  5. As last step it calls the library (C Runtime, crt) _start routine. This initializes the runtime/ANSI library. This part then calls the application main() routine.

Each of the steps can be configured with assembler preprocessor macros, more about this later.

CMSIS Include Headers

If I would now try to compile it, it will result in errors because header files are not found:

${KSDK_PATH}/platform/startup/startup.c:31:41: fatal error: device/fsl_device_registers.h: No such file or directory
 #include "device/fsl_device_registers.h"

So I need to add the following CMSIS paths to my compiler include paths (-I option):

💡 The KDS new project wizard already has these paths configured.

"${KSDK_PATH}/platform/CMSIS"
"${KSDK_PATH}/platform/CMSIS/Include"
"${KSDK_PATH}/platform/CMSIS/Include/device"

💡 I’m using an Eclipse variable KDSK_PATH to point to the SDK location, so if I move my project or the SDK, I only need to update one variable.
💡 As a tip, you can copy/paste the paths into the settings panel.

CMSIS Header Include Path

CMSIS Header Include Path

💡 Question: How to know where the folder is? Answer: I use the Windows Explorer and search inside the SDK folder for the files.

CPU Compiler Preprocessor Macro/Define

Now if I build, it will find the header files, but will stop with another error:

💡 The KDS project created by the wizard already has the CPU preprocessor macro configured.

${KSDK_PATH}/platform/CMSIS/Include/device/fsl_device_registers.h:569:6: error: #error "No valid CPU defined!"
 #error "No valid CPU defined!"

The thing is that the SDK needs to know the CPU I’m compiling for as a compiler preprocessor macro/define. To know which define it is expecting, I open the file fsl_device_registers.h and search/look for my CPU (MK64F in my case). This gets me to this section (around line 235):

#elif (defined(CPU_MK64FX512VDC12) || defined(CPU_MK64FN1M0VDC12) || defined(CPU_MK64FX512VLL12) || \
    defined(CPU_MK64FN1M0VLL12) || defined(CPU_MK64FX512VLQ12) || defined(CPU_MK64FN1M0VLQ12) || \
    defined(CPU_MK64FX512VMD12) || defined(CPU_MK64FN1M0VMD12))
    #define K64F12_SERIES

    /* Extension register headers. (These will eventually be merged into the CMSIS-style header.)*/
    #include "device/MK64F12/MK64F12_adc.h"

I have the MK64FN1M0VLL12 on my board, so I specify this in the compiler preprocessor settings:

💡 I use a magnifying glass to read the tiny writing of the device on the board.

Preprocessor Setting to Specify the SDK Derivative

Preprocessor Setting to Specify the SDK Derivative

main()

Now it compiles my startup code, and the linker kicks in. But it will report that it cannot find main():

'Invoking: Cross ARM C Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections  -g3 -Xlinker --gc-sections -Wl,-Map,"FRDM-K64F_Bare_SDK.map" -o "FRDM-K64F_Bare_SDK.elf"  ./Sources/main.o  ./SDK/platform/startup/MK64F12/gcc/startup_MK64F12.o  ./SDK/platform/startup/MK64F12/system_MK64F12.o  ./SDK/platform/startup/startup.o   
c:/tools/ide/gcc/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
c:/tools/ide/gcc/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/fpu/crt0.o: In function `_start':
(.text+0x4a): undefined reference to `main'
collect2.exe: error: ld returned 1 exit status
make: *** [FRDM-K64F_Bare_SDK.elf] Error 1

My bad! So I add a main.c source file to my project:

Main.c added

Main.c added

Embedded programs never leave main(), so I add an endless loop to the end:

💡 The KDS wizard has already added main().

sss (copy in Text tab!)int main(void) {
  for(;;) {
    /* never leave main */
  }
}

Linker File

That linker error reminds me about an important thing missing so far: the linker file!

💡 Projects created with the KDS new project wizard have the linker file added.

The Kinetis SDK comes with a linker files for my microcontroller in

${KSDK_PATH}\platform\linker\gcc\K64F12

I tell the linker to use the FLASH file (K64FN1Mxxx12_flash.ld):

SDK Linker File

SDK Linker File

And I specify the path to the linker file(s) as “${KSDK_PATH}\platform\linker\gcc\K64F12”:

Linker Library Search Path

Linker Library Search Path

 Linker and Libraries

Building the project still reports a linker error:

❗ KDS is *not* using the standard GNU ARM Embedded (launchpad) toolchain. It is having some differences how the linker handles things, and that linker seems to automatically link things differently.

'Invoking: Cross ARM C Linker'
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections  -g3 -T K64FN1Mxxx12_flash.ld -Xlinker --gc-sections -L"C:\Freescale\KSDK_1.0.0-Beta\platform\linker\gcc\K64F12" -Wl,-Map,"FRDM-K64F_Bare_SDK.map" -o "FRDM-K64F_Bare_SDK.elf"  ./Sources/main.o  ./SDK/platform/startup/MK64F12/gcc/startup_MK64F12.o  ./SDK/platform/startup/MK64F12/system_MK64F12.o  ./SDK/platform/startup/startup.o   
c:/tools/ide/gcc/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/fpu\libg.a(lib_a-exit.o): In function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
collect2.exe: error: ld returned 1 exit status
make: *** [FRDM-K64F_Bare_SDK.elf] Error 1

So it means that my linker (or library) settings are not correct yet. _exit() is called at the end of main(), but as for an embedded program, I do not want (and need) to leave main.

Therefore I can add

-specs=nosys.specs

to the linker options which tells the linker not to include any special system library functionality.

Other Linker Flags

Other Linker Flags

With this, I’m able to link:

'Invoking: Cross ARM GNU Print Size'
arm-none-eabi-size --format=berkeley "FRDM-K64F_Bare_SDK.elf"
   text       data        bss        dec        hex    filename
   2692       1088         28       3800        ed8    FRDM-K64F_Bare_SDK.elf
'Finished building: FRDM-K64F_Bare_SDK.siz'

Stack and Heap

There are a few things in the assembly startup file I can configure through assembler macros, as mentioned earlier. The first thing is the stack size. By default, it uses 4 KByte (0x1000):

#ifdef __STACK_SIZE
    .equ    Stack_Size, __STACK_SIZE
#else
    .equ    Stack_Size, 0x00001000
#endif

The other thing is the heap size which is 4 KByte (0x1000) by default:

#ifdef __HEAP_SIZE
    .equ    Heap_Size, __HEAP_SIZE
#else
    .equ    Heap_Size, 0x00001000
#endif

If I don’t want to go with the defaults, I can tune this in the project settings as assembler preprocessor defines, e.g.

"__STACK_SIZE=0x0400"
"__HEAP_SIZE=0x00"
GNU Assembler Preprocessor Settings

GNU Assembler Preprocessor Settings

❗ KDS beta V1.0.1 has here another another macro (“__START=main”) defined. Actually this is a bug, and that macro should be removed (it is documented in the KDS release notes at https://community.freescale.com/docs/DOC-100441).

Startup Configuration Macros

In a similar way, there are other configuration of the startup code with the __NO_SYSTEM_INIT and __NO_INIT_DATA_BSS macros, right at the start of the reset vector, and there is __START afterwards.

❗ Because KDS v1.0.1 beta does *not* add startup.c, you need to have the __NO_INIT_DATA_BSS macro defined!

__NO_SYSTEM_INIT and __NO_INIT_DATA_BSS

__NO_SYSTEM_INIT and __NO_INIT_DATA_BSS

  • If __NO_SYSTEM_INIT is defined as assembler preprocessor macro, then no system initialization is performed. SystemInit() is defined in system_MK64F12.c and configures the watchdog and initial system clock. I recommend that you perform that SystemInit() unless have very specific needs and know what you are doing!
  • If __NO_INIT_DATA_BSS is defined as assembler preprocessor macro, then no bss (global variable initialization and vector table copy to RAM) is performed. The function init_data_bss() is located in startup.c. Disabling bss initialization can be useful if you take care about initialization of variales (and libraries!) inside the application itself. That way code size of the application can be reduced. Typically it is *not* recommended to disable bss initialization.
  • __START is defined by default to call _start() in the GNU library. If you are not going to use the library and no runtime, you can define your own symbol.

 Debugging

The last step is to download and debug the application on the board. We have not added any functionality yet. All what we have is the startup code. Create a debug configuration and download it to the board. If everything goes fine, you should end up at main():

Reached Main

Reached Main

Congratulations 🙂

Summary

The Kinetis SDK comes with startup code and device drivers. The current SDK structure makes it not easy to be used with an IDE. To build my application with the SDK, it is important to know how the startup code works, and how I can add and configure it to my ’empty’ project. This is painful at the beginning, but going through all the steps ensures that things are understood, and can be tweaked later as necessary. And as a benefit: you should now understand how and why KDS is doing things :-). And as an additional benefit: the project built with GNU ARM Embedded (launchpad) toolchain is a few bytes smaller then the one with the Kinetis GNU toolchain ;-).

If you are only interested in the finished project, then it is available on GitHub (for Eclipse Kepler).

Topics for a continuation of this tutorial, if there is enough interest: adding board support, adding a blinking LED, adding FreeRTOS, …

Happy Startuping 🙂

 

 

Advertisements

35 thoughts on “Tutorial: DIY Kinetis SDK Project with Eclipse – Startup

  1. Greetings Erich

    It seems all silicon vendors expect all of their users to be the type 2 person you mentioned above. (Including Freescale, because they don’t pay you to create this blog.) They leave it up to the “student” to figure out how to use their silicon.

    It seems the attitude of all MCU user forums with which I have had experience (ATMEL, STM, NXP, and to some extent, Freescale) have the unspoken attitude that one should already be an engineer experienced in their silicon and software in order to ask a question. But there is no place to gain that experience. There are no basic comprehensive tutorials for MCU beginners that I have found.

    The only place I have found in the last 3-4 years of searching the online “MCU ecosphere” (many hundred, if not several thousand, hours – mostly on my own time) that has basic step by step tutorials for beginners through advanced users is MCUONECLIPSE.com.

    Why the silicon vendors don’t understand the importance of formally teaching their prospective buyers how to use their silicon is beyond me. For the most part, they leave it up to unpaid volunteers on their forums to guess at what might solve the forum user’s questions.

    (The exception might be NXP who has a forum member named lpcxpresso-support, but they too exemplify the above attitude – in my opinion.)

    There are millions of people who are justified being the type 1 person. In the marketplace, for instance, there are countless engineers, engineering technicians and the like, who have no interest in, or perhaps no time for learning the details of something they just want to use as a tool to do their job. (Maybe they would prefer to spend two weeks on vacation with their family rather than spending two weeks learning the details, limitations, and idiosyncrasies of a new MCU and its propitiatory software.)

    Their priority is to build a new device to make their company money as soon as possible. In this world economy, their company may be borderline solvent, and if their product is delayed six months, it may be too late for the company and all the employees and families that rely on the company to provide income for them. They need an MCU to control a simple device. They can write a C program in a few days to do what they want.

    They don’t want to spend months – as I have unwillingly had to do several different times – learning all the minute details of a new MCU or software package to simply read some inputs, toggle some outputs, and make some basic decisions in the process.

    If other silicon vendors had someone like you to explain how to set up their software and use their devices, they would sell millions of more devices, there would be a whole lot more MCU based inventions from non-engineers, and many thousands of people would not cumulatively waste countless work-years trying to bring new products to market only to fail and give up because no one can be bothered with actually explaining how to start from the beginning and put it all together.

    Thank you for “bothering” to start from the beginning and provide a clear explanation of how to use Freescale silicon to do what we want, whether we are a “type 1” or a “type 2” student.

    😉

    Like

  2. Finally…, but I agree, it’s a bit confusing. They were promoting Processor Expert, they had bunch of bare-metal examples, they used MQX-driver based approach… I hope this will be the final change and they will stick to some consistent, standard way of working with peripherals.

    Like

  3. Pingback: Tutorial: DIY Kinetis SDK Project with Eclipse – Board Configuration | MCU on Eclipse

  4. Pingback: Switching ARM GNU Tool Chain and Libraries in Kinetis Design Studio | MCU on Eclipse

  5. Hi Erich,

    Thank you for your wonderful work.

    I have used two of your links:
    Constructing a Classroom IDE with Eclipse for ARM
    Tutorial: DIY Kinetis SDK Project with Eclipse – Startup

    I notes a minor issue on the first page. Should J-Link software should be installed into C:\Tools\segger or C:\Tools\IDE\segger? Looking at the images, I chose the second folder.

    After I finished the second tutorial, I have run into an issue. I went through the tutorials twice on two computers. While I get the following:

    15:24:32 **** Incremental Build of configuration Debug for project FRDM-K64F_Bare_SDK ****
    make all
    ‘Invoking: Cross ARM GNU Print Size’
    arm-none-eabi-size –format=berkeley “FRDM-K64F_Bare_SDK.elf”
    text data bss dec hex filename
    2824 1080 28 3932 f5c FRDM-K64F_Bare_SDK.elf
    ‘Finished building: FRDM-K64F_Bare_SDK.siz’
    ‘ ‘
    15:24:32 Build Finished (took 421ms)

    I also get two errors:

    Description Resource Path Location Type
    Field ‘VTOR’ could not be resolved startup.c /FRDM-K64F_Bare_SDK/SDK/platform/startup line 104 Semantic ErrorDescription Resource Path Location Type
    Symbol ‘SCB’ could not be resolved startup.c /FRDM-K64F_Bare_SDK/SDK/platform/startup line 104 Semantic Error

    Here is the line that shows the error. I was wondering if you can shed any light on it. Thanks.

    Like

  6. Hello Erich,

    Thanks for creating this wonderful resource. I am having some difficulty with this tutorial. I built the classroom IDE using your other tutorial.

    Now am getting these error.

    Description Resource Path Location Type
    Field ‘VTOR’ could not be resolved startup.c /FRDM-K64F_Bare_SDK/SDK/platform/startup line 104 Semantic Error
    Symbol ‘SCB’ could not be resolved startup.c /FRDM-K64F_Bare_SDK/SDK/platform/startup line 104 Semantic Error

    Of course when you try to debug it, it gives you another error:

    Error with command: gdb –version
    Cannot run program “gdb”: Launching failed

    I would appreciate any help. Thank you.

    Like

    • Hi Abdul,
      what version of the SDK are you using? I wrote that tuturial with the beta version of the SDK.
      And the debugger error is no surprise: if you cannot build, you will fail with debugging.
      So first you need to be able to compile that. Have you searched your sources where VTOR and SCB are defined and used?

      Like

      • Dear Erich,

        I was able to catch a few mistakes I made. First, I was not using Kepler, that was a source of some of my headaches. Now I am using Version: Kepler Service Release 2, Build id: 20140224-0627 with KSDK_1.0.0-Beta. I have matched every software items you have mentioned in the “classroom IDE tutorial”. While I have the latest (non-beta versions) of KDS (KDS_1.1.0) and KSDK (KSDK_1.0.0) and it works without any problem, I am still interested in your DIY Kinetis Eclipse version.

        There was one conflict that related with the Windows 7 environmental variable defined in Freescale’s “Kinetic SDK K64 User’s Guide.pdf” (Appendix B). In this document KSDK_PATH points to the KDS, not KSDK. In your tutorial is KSDK_PATH points to the KSDK not KDS. I changed the windows 7 environment variable to KDS_PATH so it will not conflict with your DIY tutorial. After having done all things I am now stuck with one last error (I hope). I have not been able to find any reference to this on the web.

        make: *** [Sources/main.o] Error -1073741515

        I am not sure if you have seen this this before. I am hoping you or one of your readers may have some idea what it refers to. While I can use the latest KDS, I agree with you that creating your own IDE is very instructive.

        Thanks once again.

        Abul

        Like

        • Could it be that you shared the workspace with other Eclipse versions? Make sure you use a new workspace for every different IDE (KDS, CodeWarrior, Atollic, DIY Kepler, …).
          I think your build tool configuration for that project is probably using the wrong tool chain. If you go into the project properties, C/C++ settings, are all the panels there?
          I hope this helps.

          Like

  7. Thank you for taking the time to put this up. I have been through the example in KDS, and everything seems to work fine in terms of linking – my syntax highlighting shows that it recognizes the data structures, and things like “fsl_…” in my includes are successful during compiling. When I got to add any functions from SDK I get undefined references? Any thoughts?

    Like

    • Yes, the SDK is definitely pretty hard to use, because there are endless files and folders. I have ‘solved’ that with constantly grepping and searching the sources to know where functions are defined, so I know which files to add to the project. Adding a driver like I2C means to add multiple things (the driver, plus the Hardware Abstraction Layer (HAL) ones, potentially more, plus adding that to the compiler include paths. I recommend that you grep/search the SDK source tree and find out, where the undefined referenced symbols are defined. And then add these files to your project too.

      Like

  8. Is there any way to get smaller elf/flash files in kds?
    the linker seems to add a bunch to all the C application code
    I have to make the total elf test size. about 10k larger..

    I assume those are extra libraries I need, but I am not sure..

    SteveH

    Like

  9. Hi Erich,

    Thanks for your time doing this tutorial.
    I am using Kinetis IDE and I could follow the steps up to the linker. When I compile, everything seems fine until it gets to the linking stage. I get the following error:
    “… ‘Building target: BareSDK_FRDMk64.elf’
    ‘Invoking: Cross ARM C Linker’
    arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -T MK64FN1M0xxx12_flash.ld -Xlinker –gc-sections -L“C:\Freescale\KSDK_1.1.0\platform\linker\MK64F12\gcc” -Wl,-Map,”BareSDK_FRDMk64.map” –specs=nosys.specs -o “BareSDK_FRDMk64.elf” ./Sources/main.o ./SDK/platform/startup/MK64F12/gcc/startup_MK64F12.o ./SDK/platform/startup/MK64F12/system_MK64F12.o ./SDK/platform/startup.o
    c:/freescale/kds_2.0.0/toolchain/bin/../lib/gcc/arm-none-eabi/4.8.0/../../../../arm-none-eabi/bin/ld.exe: cannot open linker script file MK64FN1M0xxx12_flash.ld: No such file or directory
    collect2.exe: error: ld returned 1 exit status
    make: *** [BareSDK_FRDMk64.elf] Error 1 … ”

    It cannot open that “MK64FN1M0xxx12_flash.ld” file because this is on the SDK folder, and it seems it is looking for it in the IDE folder. Could you give me any suggestion for this error? I do not know how to modify the toolchain parameters and all of that very well.

    Thanks in advance

    Like

    • Hi Nestor,
      in your project, it searches the linker file in the path specified with the linker option -L:
      -L“C:\Freescale\KSDK_1.1.0\platform\linker\MK64F12\gcc”
      So this is not the IDE, but an SDK location. Can you check if that linker file MK64FN1M0xxx12_flash.ld exists there?
      The -L option is specified in the linker settings, same for the linker file name.
      I hope this helps,
      Erich

      Like

      • Hi Erich, thanks for the quick response 🙂

        The mentioned file exists in that folder, actually there are 4 files in the folder :
        -MK64FN1M0xxx12_flash.ld
        -MK64FN1M0xxx12_ram.ld
        -MK64FX512xxx12_flash.ld
        -MK64FX512xxx12_ram.ld

        I specified in the “library search path” section, on Kinetis, the following path:
        “${KSDK_PATH}\platform\linker\MK64F12\gcc”, where KSDK_PTAH is “C:\Freescale\KSDK_1.1.0” string type.

        It is a bit strange, do you think there would be any other thing wrong?

        Like

        • Hi Nestor,
          hmm, no, I don’t see the problem. Can you try to specify the full file path (without macro, etc) for the -T option?
          It happened to me that I had some non-printable characters/tabs in it. Or that I did not use straight double quotes (“)?

          Like

        • Hi Erich,

          I tried to do that. I wrote the straight double quotes, but it gave the same error. Then I changed the name of the sdk folder, instead of “SDK_1.1.0” I used “SDK110”, but it remains the same.

          Then what I tried was to include that linker file into my workspace under the folder “platform.” When I compile the program it gives the following output:
          ************************************************************************************************************
          16:05:15 **** Incremental Build of configuration Debug for project BareSDK_FRDMk64 ****
          make all
          ‘Building target: BareSDK_FRDMk64.elf’
          ‘Invoking: Cross ARM C Linker’
          arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -T “D:\userdata\negarcia\Freescale\BareSDK_FRDMk64\SDK\platform\MK64FN1M0xxx12_flash.ld” -Xlinker –gc-sections -L”D:\userdata\negarcia\Freescale\BareSDK_FRDMk64\SDK\platform” -Wl,-Map,”BareSDK_FRDMk64.map” -o “BareSDK_FRDMk64.elf” ./Sources/main.o ./SDK/platform/startup/MK64F12/gcc/startup_MK64F12.o ./SDK/platform/startup/MK64F12/system_MK64F12.o ./SDK/platform/startup.o
          ‘Finished building target: BareSDK_FRDMk64.elf’
          ‘ ‘
          ‘Invoking: Cross ARM GNU Create Flash Image’
          arm-none-eabi-objcopy -O ihex “BareSDK_FRDMk64.elf” “BareSDK_FRDMk64.hex”
          ‘Finished building: BareSDK_FRDMk64.hex’
          ‘ ‘
          ‘Invoking: Cross ARM GNU Print Size’
          arm-none-eabi-size –format=berkeley “BareSDK_FRDMk64.elf”
          text data bss dec hex filename
          3060 1076 2076 6212 1844 BareSDK_FRDMk64.elf
          ‘Finished building: BareSDK_FRDMk64.siz’
          ‘ ‘

          16:05:17 Build Finished (took 1s.946ms)
          ************************************************************************************************************

          My concern is that, this output does not mention anything about the Compiler or the assembler as it did before. Do you think this is correct? Is my IDE environment already ready?

          Also, to get this output I didn’t use the “–specs=nosys.specs” command, otherwise I got this error:

          **************************************************
          16:15:30 **** Incremental Build of configuration Debug for project BareSDK_FRDMk64 ****
          make all
          ‘Building target: BareSDK_FRDMk64.elf’
          ‘Invoking: Cross ARM C Linker’
          arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 -O0 -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -g3 -T “D:\userdata\negarcia\Freescale\BareSDK_FRDMk64\SDK\platform\MK64FN1M0xxx12_flash.ld” -Xlinker –gc-sections -L”D:\userdata\negarcia\Freescale\BareSDK_FRDMk64\SDK\platform” -Wl,-Map,”BareSDK_FRDMk64.map” –specs=nosys.specs -o “BareSDK_FRDMk64.elf” ./Sources/main.o ./SDK/platform/startup/MK64F12/gcc/startup_MK64F12.o ./SDK/platform/startup/MK64F12/system_MK64F12.o ./SDK/platform/startup.o
          arm-none-eabi-gcc: error: nosys.specs: No such file or directory
          make: *** [BareSDK_FRDMk64.elf] Error 1
          **************************************************

          I did not really understand why we need that command. Would you be so kind to guide me a little bit more on this? maybe just referring to a document and I will read it. I’d appreciate your help.

          Like

  10. Sorry….
    Just an addition, I cleaned the project then I built all, and I got the outputs for the arm c compiler, the gnu assembler, and the linker. It seems that there are no errors. But I am not sure.
    Once I get home I’ll plug the board to see if I can debug.

    Like

    • Hi Nestor,
      no problem. Probably your make files were out of sync somehow. Clean (or even better: delete the output folder with the make files) usually solves the problem.

      Like

  11. Hi Erich, I keep getting this error.. any ideas?

    ..\build\test.axf: Error: L6218E: Undefined symbol Image$$VECTOR_RAM$$Base (referred from fsl_interrupt_manager.o).

    Like

      • Hi Erik,
        I am trying to find out the memory map in .map file but it is so much confusing. Could you give me some clues to find it. The way it is shown in CW is much more easy.
        I am working with KDS.

        Thanks and best regards

        Like

        • Yes, agreed. The GNU linker memory map is really not easy to read. Unfortunately there is no way around it: you need to get familiar with it. What works best for me is to search the items I’m looking for (CTRL-F for find).

          Like

  12. Eric I am a begginner with one of these boards and i would like to know how you would extract the existing configuration off it?
    Thanks

    Like

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.