Code Coverage with gcov, launchpad tools and Eclipse Kinetis Design Studio V3.0.0

What makes Eclipse great: using open source tools there are a lot of tools and techniques available which usually are only provided for desktop development.

A while back I described how to do code coverage with Eclipse Kepler and the GNU ARM Embedded (launchpad) tools (see “Code Coverage for Embedded Target with Eclipse, gcc and gcov“). With Kinetis Design Studio out, time to do the same with that Eclipse distribution, especially as Freescale is now using the stock GNU ARM Embedded tools too.

Coverage with multiple Files

Coverage with multiple Files

Continue reading

tinyK20 USB Thumb Drive Enclosure

In “tinyK20 Open Source ARM Debug/Universal Board – First Prototypes” I talked about using a USB thumb drive enclosure for the board, so here is the idea:

Thumb Case for tinyK20

Thumb Case for tinyK20

Continue reading

Debugging the FRDM-K64F with P&E Multilink

The FRDM-K64F board as other Freescale Freedom board have an onboard debugging device. For everyone who wants to debug the FRDM-K64F board with say a P&E Universal Multilink, here is my setup in case you do not get it working out of the box:

FRDM-K64F with P&E Multilink

FRDM-K64F with P&E Multilink (click to enlarge)

Continue reading

Proof of Concept: Open Source ARM SWD Debug and General Purpose Board

The Teensy is a great and tiny board (see “USB CDC with the Teensy 3.1 Board“), but it lacks real SWD/JTAG debugging capabilities (see “Hacking the Teensy V3.1 for SWD Debugging“). The Freescale Freedom boards are great, but for many applications too big, and have potentially too many components on it. So what about building a breadboard friendly tiny board which *has* SWD debugging ability *and* can be used to debug another boards?

So here is a working prototype based on the FRDM-K20D50M:

FRDM-K20D50M used as debug probe

FRDM-K20D50M used as debug probe

Continue reading

UART with the FRDM-KL02Z Board

In my classes I’m mainly using the Freescale FRDM-KL25Z board, as it provides the best value for the money, and 128 kByte FLASH with 16 kByte of RAM is enough for many smaller projects. I do have as well the FRDM-KL02Z Board (32 KByte FLASH, 4 KByte of RAM) which is an inexpensive board to evaluate the smaller KL02Z microcontroller. Because someone reported a problem not being able to use the UART over OpenSDA/USB-to-CDC bridge, I have created a demo project which communicates with a console on the host.

FRDM-KL02Z Board

FRDM-KL02Z Board

Continue reading

USB CDC with the Teensy 3.1 Board

For a project I want to use the Teensy 3.1 board (see “Hacking the Teensy V3.1 for SWD Debugging“) in USB CDC mode: that way the Teensy board can connect to the host and exchange data or attach a console to the Teensy board: that way I can connect the Teensy over USB to the host use the USB as communication interface:

Teensy with Octo Board

Teensy with Octo WS2811 Board

Continue reading

Sensirion SHT11 Temperature and Humidity Sensor on a MikroElektronika Click Board

In one of my earlier posts (“Using the DHT11/DHT22 Temperature/Humidity Sensor with a FRDM Board“) I’m using the DHT11/DHT22 temperature/humidity sensors with the FRDM-KL25Z board. These sensors are very inexpensive, but have limited measurement range and accuracy. As pointed out by a reader of that article, Sensirion (a Swiss company :-)) has good sensors too, and I decided I would like to try the SHT11 sensor:

  • 0-100% Relative Humidity
  • +/- 3% Relative Humidity accuracy
  • -40 – +125Β°C
  • 2.4 – 5.5V supply voltage
SHT11 Sensor

SHT11 Sensor

Continue reading

Poor Man’s Trace: Free-of-Charge Function Entry/Exit Trace with GNU Tools

There are cases where my application runs find for days, weeks or even months, but then from time to time there is an application crash. Yes, the watchdog will recover it, but still it would be good to know what happened? One solution would be to hook up a trace probe (like the one I have described in this post: “First Steps with the P&E Tracelink“). But having such a trace probe attached all the time is first not cheap and second not always possible. So what if the application would leave ‘breadcrumbs’ behind which would tell me the flow of the program leading to the problem? I have found a functionality in the GNU tools which seems not be widely known or use, but is incredibly helpful in such cases.

So what if I could get a log like this telling me which functions get called by whom?

{ 00000E88->00000DA0 ???->DEMO_Init
} 00000E88<-00000DA0 ???<-DEMO_Init
{ 00000E8C->00000D40 ???->DEMO_Run
Β { 00000D62->00000CE8Β  DEMO_Run:0x0022->decide
Β  { 00000D0E->00000C60Β  decide:0x0026->calcValue
Β  } 00000D0E<-00000C60Β  decide:0x0026<-calcValue
Β  { 00000D16->00000CA0Β  decide:0x002E->getValue
Β Β  { 00000CC6->00000C60Β  getValue:0x0026->calcValue
Β Β  } 00000CC6<-00000C60Β  getValue:0x0026<-calcValue
Β  } 00000D16<-00000CA0Β  decide:0x002E<-getValue
Β } 00000D62<-00000CE8Β  DEMO_Run:0x0022<-decide
Β { 00000D62->00000CE8Β  DEMO_Run:0x0022->decide

Continue reading