Using Kinetis Design Studio V3.0.0 with the Launchpad 4.9-2015-q2 Release

The Kinetis Design Studio v3.0.0 comes with the GNU/GCC ARM Embedded (launchpad) version 4.8-2014-q3. End of June 2015, ARM released a new version, the 4.9-2015-q1.So why not using that newer release?

Release GCC ARM Embedded 4.9 update 2

Release GCC ARM Embedded 4.9 update 2

  1. It comes with GDB version 7.8 and has the ‘return of function display’ feature.
  2. GDB has Phyton scripting support.
  3. It fixes that nasty GDB bug ‘breakpoint on removed code’ issue.

Is that already enough to make that switch?


  1. Go to and download the release. I prefer the zip file, direct link: and download it.
  2. Make sure that Kinetis Design Studio (KDS) is not running. Rename the existing toolchain folder (C:\Freescale\KDS_3.0.0\toolchain) so you have a backup
  3. Create a new folder C:\Freescale\KDS_3.0.0\toolchain and put the files of the archive there.

That’s it! KDS will use the new toolchain from c:\Freescale\KDS_3.0.0\toolchain.

💡 If using KDS on Mac OS or Linux, the installation and setup is very similar.

Project Conversion: not needed 🙂

Well, the cool thing is: there is no need for project conversions: KDS v3.0.0 projects for the 2014-q3 work as-is for the new 2015-q2  toolchain, the compiler/linker options are the same :-).

There is one thing: as this changes the build tools/compilers, you should make a ‘clean’: remove all object files and do a clean build. Mixing object files/libraries from different compiler versions can cause strange things, so better to have a clean state from the beginning.

Debugger: Show Return Value

If I use the ‘step to return’ function:



It now shows in the Variable view the return value:

display of returned value

display of returned value

Code/Data Size Comparison

ARM claims that there are “Additional code size optimizations”. I used the Sumo Freescale Kinetis K22 Robot application to benchmark the code/data size:

4.8 Q3 2014 4.9 Q2 2015
text data bss text data bss
-O0 121796 20400 10240 122196 20396 10240
-O3 96436 20352 10240 96760 20348 10240
-Os 75364 20336 10240 75580 20336 10240
-Os -flto 65952 20332 10212 66180 20328 10144

I noticed a small code size increase with moving to the 4.9 Q2 2015 tools. Quickly looking at the map file indicates that this is coming from the newlib-nano used in the application.

GDB with Python Support

The 4.8 Q3 2014 release does not have GDB Python support. In GDB v7, support for extending the debugger with Python has been added. To use Python with GDB, use arm-none-eabi-gdb-py instead of the normal arm-none-eabi-gdb in the debug launch configuration.

Instead of


I can use


and it will use the version with Python enabled.

Using Python GDB in Eclipse Launch Configuration

Using Python GDB in Eclipse Launch Configuration

I have not played with the Python extension, but the ability to extend the debugger with Python scripting support sounds like a cool feature to be used to me.

Newlib-Nano, printf() and Semihosting

I faced a problem with using semihosting and printf(): the application crashed inside malloc(). Yes, printf() uses malloc() in newlib-nano, yet again a reason why I do not like printf(). Stepping through the code I saw that a NULL pointer was de-referenced.

Stack pointer comparison in _sbrk

Stack pointer comparison in _sbrk

This reminded me about a similar problem a while back ( And indeed, with providing my version of _sbrk() function, the problem did not occur any more:

void *_sbrk ( uint32_t delta )
extern char _end; /* Defined by the linker */
static char *heap_end;
char *prev_heap_end;

  if (heap_end == 0) {
    heap_end = &_end;

  prev_heap_end = heap_end;
  heap_end += delta;
  return (void *) prev_heap_end;


The new 4.9 Q2 2015 ARM launchpad release adds important bug fixes and includes Python support. I noticed a small code size increase especially in my larger applications, mainly because of changes in the libraries. As printf() in newlib-nano is using malloc(), and this checks the stack pointer against the heap memory area, either change the linker file or use my version of _sbrk() implementation. Other than that, all my applications using the new 4.9 release run without any issues. So are there enough reasons to switch the toolchain? I wish there would be better code size, but alone that nasty gdb bug fixed (you cannot have a breakpoint on removed code) makes me switch :-).



5 thoughts on “Using Kinetis Design Studio V3.0.0 with the Launchpad 4.9-2015-q2 Release

  1. Hi Erich !
    As it turned out is incompatible with the current version KSDK_1.2.0.
    Unable to make a project KSDK_1.2.0\middleware\tcpip\rtcs\

    ‘Building file: C:/Freescale/KSDK_1.2.0/middleware/tcpip/rtcs/source/if/getaddrinfo.c’
    ‘Invoking: ………………………………………..
    C:/Freescale/KSDK_1.2.0/middleware/tcpip/rtcs/source/if/getaddrinfo.c:75:15: error: static declaration of ‘strdup’ follows non-static declaration
    static char * strdup( const char *s);
    In file included from c:\freescale\kds_3.0.0\toolchain\arm-none-eabi\include\string.h:10:0,
    from C:/Freescale/KSDK_1.2.0/middleware/tcpip/rtcs/source/if/getaddrinfo.c:48:
    c:\freescale\kds_3.0.0\toolchain\arm-none-eabi\include\string.h:80:8: note: previous declaration of ‘strdup’ was here
    char *_EXFUN(strdup,(const char *));



What do you think?

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

You are commenting using your 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 )

Google+ photo

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

Connecting to %s