The world is changing, and the say is “change is good” :-). In the software and API world, change very often means that a change results into something broken. So I had battled with semihosting working on the NXP Kinetis parts, only to find out that it does not work any more with using the latest version 2.0. The semihosting output e.g. with P&E debug connection remains empty:
I’m using the FRDM-KL25Z in my classes, and that board is very popular: low price (<$15), reasonable features (48 MHz ARM Cortex M0+, 128 KByte of FLASH, 16 KByte of RAM), and many tutorials elsewhere and on McuOnEclipse :-).
For the next (Fall) semester I’m looking for alternative boards, and one is the Freescale (now NXP) FRDM-KL27Z:
I’m using Processor Expert components for nearly every Freescale (now NXP) projects: for S08, S12, ColdFire, DSC and especially all the different NXP Kinetis devices. Not only because it makes software development fast and easy and allows re-use of software, but as well because Processor Expert has a good way to pack and distribute software components. Unfortunately Processor Expert is not any more included for the new Kinetis devices (see “First NXP Kinetis SDK Release: SDK V2.0 with Online On-Demand Package Builder“). So I have looked into an alternative and hopefully vendor neutral way to build and distribute software packages using CMSIS-Pack.
In case there are problems with the C/C++ preprocessor, it is useful to generate the compiler preprocessor listing. Here is how to create a preprocessor listing with GNU gcc compiler and the GNU ARM Eclipse plugins in Eclipse:
Readers of my blog know: I’m not a fan of printf(), and I think for many good reasons. Still printf() is widely used, and the GNU gcc tries to optimize things. This is observed with a simple example: If I’m writing
One of the most important aspects for developing complex realtime applications is get insights into what is going on the target. Segger just has released a free tool which gives an incredible useful insight view and visualization:
I don’t own a Mac computer, and I try to keep my tutorials as multi-host-platform as possible. So it is always cool to see if someone else posts a nice tutorial on a different host machine: For all Mac (and as well non Mac) users, have a look at this tutorial Nash Reilly has posted: “An Introduction to Freescale’s Kinetis Design Studio.”
It nicely explains downloading and installing KDS with the Kinetis SDK and then run a ‘hello world’ program on the hardware.
Sometimes I need to link an object file (e.g. bootloader.o) to my application, and I do not want to build it, or I do not have the sources to build it. There is a simple way with the GNU ARM Eclipse plugins to link extra object files:
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.
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).
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.
The 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?
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: