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?

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?

Installation

1. Go to https://launchpad.net/gcc-arm-embedded and download the release. I prefer the zip file, direct link: https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q2-update/+download/gcc-arm-none-eabi-4_9-2015q2-20150609-win32.zip) 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:

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

${cross_prefix}gdb${cross_suffix}

I can use

${cross_prefix}gdb-py${cross_suffix}

and it will use the version with Python enabled.

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.

This reminded me about a similar problem a while back (https://mcuoneclipse.com/2014/03/16/freertos-malloc-and-sp-check-with-gnu-tools/). 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;
}

Summary

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 :-).

Links

• GCC ARM Embedded (launchpad): https://launchpad.net/gcc-arm-embedded
• Freescale Kinetis Design Studion: http://www.freescale.com/kds
• Switching toolchains in KDS: https://mcuoneclipse.com/2014/07/11/switching-arm-gnu-tool-chain-and-libraries-in-kinetis-design-studio/
• Bug in previous GDB (at least up to 4.8-2014-Q3: https://mcuoneclipse.com/2014/10/11/failed-to-debug-with-gdb-breakpoints-or-expressions-on-non-existing-locations/
• Extending GDB with Phyton: http://sourceware.org/gdb/current/onlinedocs/gdb/Python.html#Python
• Issue with malloc() checking stack pointer: FreeRTOS, malloc() and SP check with GNU Tools
• Reasons why not to use printf(): Why I don’t like printf()