Many tool chains and linker are able to produce S19 files, such as with the GNU tools it is the ‘objcopy‘ which does this job (see “Binary (and S19) Files for the mbed Bootloader with Eclipse and GNU ARM Eclipse Plugins“). But these tools usually cannot handle the special cases. For example on the Freescale Kinetis K64F my serial bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“) had a problem with these lines in the S19 file:
Not aligned S19 file entries
Some of my robotics projects take a rather long time do a full build. When I developed applications with Visual C++ on the host, using precompiled headers gave me a big boost in compilation speed. I was looking for the same in similar with GNU and gcc, and as expected: gcc does support precompiled headers too. And indeed, I was able to cut down compilation time by 30% :-). So this post is about how to use gcc with precompiled headers in Eclipse/CDT to give my builds a boost.
using precompiled header
It has been a while since I published my ‘build my own DIY IDE’ (see “DIY Free Toolchain for Kinetis: Part 1 – GNU ARM Build Tools“). I have used that approaches in my classes successfully. Now a new semester is coming up, so time to update the instructions using the latest Eclipse IDE (Mars) and tools (GCC ARM Embedded (launchpad) with GNU ARM Eclipse).
Eclipse Mars Splash Screen
I have published a Sneak Preview how GNU gprof profiling looks for an embedded target ARM Cortex-M in an earlier post:
This tutorial explains how to profile an embedded application (no RTOS needed) on ARM Cortex-M devices with GNU gprof. Additionally I explain the inner workings to generate the data necessary for gprof.
Continue readingThe STMicroelectronics STM32F103 (ARM Cortex-M3) Nucleo boards include the on-board ST-Link v2 circuit which allows to debug the board. This circuit is similar to the OpenSDA circuit found on Freescale boards. Unlike the Freescale OpenSDA, the ST-Link is only the ST-Link: it is not possible to load a P&E Multilink or Segger J-Link or firmware on it. Luckily, the ST-Link has a SWD connector, but this connector is a non-standard one. So how can I debug that board with an Eclipse based environment with GNU ARM Eclipse plugins and a Segger J-Link?
Connected J-Link with Nucleo Board
Stack overflows are a big problem: If I see a system crash, the first thing usually is I try to increase the stack size to see if the problem goes away. The GNU linker can check if my global variables fit into RAM. But it cannot know how much stack I need. So how cool would it be to have a way to find out how much stack I need?
Static Stack Usage Analysis with GNU
And indeed, this is possible with the GNU tools (e.g. I’m using it with the GNU ARM Embedded (launchpad) 4.8 and 4.9 compilers :-). But it seems that this ability is not widely known?
I’m working on a conference paper and presentation, and tonight I had a break-through :-). So how cool is this: Profiling with GNU gprof a bare-metal embedded Cortex-M application (Freescale Kinetis K64F running the Freescale Kinetis SDK) in Eclipse:
Freescale Kinetis Microcontroller Application Profiling
This is Part 4 of a Mini Series. In Part 3, I described the software concepts (see “Tutorial: Adafruit WS2812B NeoPixels with the Freescale FRDM-K64F Board – Part 3: Concepts“). In this post I describe how to set-up the timer to trigger later DMA operations. The goal is to drive Adafruit’s NeoPixel (WS2812B) with the Freescale FRDM-K64F board:
NeoPixels with FRDM-K64F
This is Part 2 of a Mini Series. In Part 1, I described how to set up the hardware (see “Tutorial: Adafruit WS2812B NeoPixels with the Freescale FRDM-K64F Board – Part 1: Hardware“). Now it is time to have the software tools ready. In this post I describe to have the IDE (Freescale Kinetis Design Studio) with the Freescale SDK installed, along with the correct firmware on the FRDM-K64F Board. The goal is to drive Adafruit’s NeoPixel (WS2812B) with the Freescale FRDM-K64F board:
Freescale FRDM-K64F with NeoPixels
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
Is that already enough to make that switch?
MCU on Eclipse 