ARM Cortex-M board from scratch part 3: Kinetis KE04

If you have read my previous post in this series, you'll know that I had mixed feelings about the LPC810 and LPC812 chips from NXP. They are certainly simple and flexible in use, but without a stable and predictable technique to program them I just ended up more frustrated. However, I impressed myself by successfully soldering the surface-mount TSSOP package of the LPC812.

So this time I am attempting to scratch-build a circuit based on a Cortex-M0+ from completely different manufacturer, the Freescale Kinetis KE04. Unlike the NXP parts, this chip has no built-in bootloader, but relies on the "industry-standard" SWD protocol for programming and debugging. Freescale have a huge range of Cortex-M microcontrollers, but the reason I chose this particular one is that it comes in a similar package to the LPC812. I know I can solder this, and I already have a breadboard adapter to fit it.

I am quite familiar with the Kinetis range, having written software to run on their FRDM development boards, but have, so far, never worked with the bare chips. I already have the Freescale FRDM board for this chip, so I reckoned that I might be able to try out some software and the programming connections and protocols on a definitely working board, then try the same approach on my home-built one.

FRDM boards come with a separate MCU on the board just for debugging over USB. As delivered, this emulates a mass storage device. Programming is done by building a binary file, then dragging it onto the device using the host PC's file management tools. I can see why they do this, as it is pretty much independent of particular development tools. However, I want to build my software in Freescale KDE or Keil uVision and deploy it to the hardware using a generic debug probe.

Testing Kinetis KE04

I started by trying to connect my ULink2 debug probe to the FRDM board, but found a few problems. The first problem was that this device is only really supported by Keil uVision, so I could not easily use any of the software developed using KDE or Freescale CodeWarrior. The second, and more serious problem is that when I opened up my ULink2 to attach the Cortex-M SWD cable, the circuit board did not look much like the pictures on the Keil web site, and there was not even a header to fit the cable. Even though this device has worked well with several STM32 development boards using the 20-pin JTAG connector, I have now come to the tentative conclusion that the one I have my be either a "clone", or a reduced model which does not support SWD.


It took me a while to decide that the debug probe might be part of the problem. At the same time I was also poring over datasheets and reference manuals for the KEO4 chip. This was useful, as it suggested that programming would be both easier and more reliable with a 10KOhm pull-up on the RESET and NMI pins and a decoupling capacitor across the power pins. While experimenting, I used an oscilloscope to look at the signals on the pins and saw a strange repeating pattern on the RESET pin, even when pulled up. This puzzled me until I found a page on the Freescale web site and a stack exchange thread which explained that this is very common on new chips, and that any good debug probe should be able to halt the chip and clear the flash memory to stop this behaviour.

Without a working ULink2, one fallback position was to buy a real debug probe. However, a potentially simpler (and cheaper!) alternative would be to update the firmware on the FRDM board to act like the de-facto standard Segger debug probe. Erich Styger at MCU on Eclipse wrote a useful post on how to do this. It seems Segger provides official "OpenSDA" software for this task, and installing it was pretty straightforward. I was soon able to download, run and debug software using both KDE and Keil uVision on the FRDM board. The next step was to connect the re-flashed debug probe to my scratch-built board. To my amazement, it worked, and I was soon running a 'blink' program.



I was so delighted, that I danced around my workbench a little, then tried again a few times just to make sure things were really working.

There is one fly in the ointment, though, the issue of licence terms and conditions. The licence for the Segger formware for the FRDM boards makes it very clear that it is not to be used with external or custom boards, but only with the chips in situ on the FRDM development boards. So, strictly, by even trying this I was breaking the terms, and this is not an ethical or sustainable way to continue.

Next time I shall look at some other, more legal, ways of using Segger firmware.

ARM Cortex-M board from scratch part 2: LPC810

As I mentioned in my previous post in this series, I have been planning for a long time to make my own ARM Cortex development board from scratch. After a lot of mulling around, and a bit of a false start with the LPC1114 chip, I discovered JeeLabs, a comprehensive web site, blog and upcoming book all about this sort of stuff run by Jean-Claude Wippler. A lot of the older material is based around Atmel AVR chips. Starting in November last year, however, Jean-Claude has been exploring the world of 32-bit ARM, beginning with the cute little LPC810, in a breadboard-friendly eight-pin Dual-in-Line package.


This chip is small in both size and features compared to most ARMs, but still packs a surprising amount of punch. It has a Cortex M0+ core running at 25MHz, 4K of flash, 1K of RAM, six GPIO pins, two UARTs, SPI, I2C, several timers and an analogue comparator. All of this is a bit much to squeeze into only eight pins, especially when you consider that two of them are earmarked for power and ground! The way NXP get around this is by providing a built-in switch matrix which can route (almost) any chip feature to any pin. This gives a surprising amount of flexibility for simple applications.

Although the point of this exercise is to build my own development boards, sometimes its comforting to have something to fall back on to test things out. NXP originally produced a nice simple development board for this chip, but sadly it seems that this board is no longer available, so if I am to do anything with this device I will have to make my own.

The first step is to find out a minimum circuit. Luckily, JeeLabs has this covered

NXP LPC810 minimal circuit
Image thanks to

There are some interesting things about this circuit. The first is the very small number of components There's the microcontroller itself, a smoothing capacitor for the power pins and an LED. The second interesting thing is the LED. It is mainly used as a rough and ready regulator to drop 5V, provided by a serial adapter board, to 3.3V for the device. For a purely 3.3V circuit, even that would not be necessary! The simplicity of this circuit made me very happy. Surely even I can't get this wrong! I still have niggling worries about the lack of any pull-up or pull-down resistors on any of the communication pins, but Jean-Claude has obviously made it work. I quickly assembled the specified circuit on a small breadboard, following the JeeLabs instructions.

LPC810 on breadboard

Next came the challenge of programming the LP810. There are so few pins that it does not make sense to permanently dedicate several of them to functions such as RESET and the SWD programming protocol, and not everyone has a SWD debug probe. To help get round this, the LPC810 comes with a built-in bootloader which looks for a particular pattern of highs and lows on some of the pins and switches into a serial programming mode.

If The ISP pin (pin 5) is low when the chip powers up or comes out of reset, it will enter programming mode and expect commands and data over a serial port on pins 2 and 8. While serial port adapters are cheap and plentiful (even though they don't often have an output which does exactly the right thing for the ISP pin) this approach does mean that some special software is needed which speaks the correct protocol over the serial port. JeeLabs recommends some software called lpc21isp which it recommends installing in a Linux virtual machine. I tried this approach and spent several days messing with software and modified serial adapter boards. All with no success.

In my case it seems that code in a Linux VM was either unable to write to the USB serial port, or suffered timing problems which prevented it form working. Whatever versions I could find for Windows were not quite the same and didn't work either. Eventually I gave up on the modified serial board approach, and fitted a manual ISP button (initially it was just a jumper cable). This allowed me to, eventually, get some JeeLabs example code onto the chip so I could see it blink an LED. The process still seemed pretty hit or miss, though. A large proportion of the time the software download would fail, with no obvious reason why, and messing with a manual ISP switch became very tedious. I also faced the problem that I was not set up to develop code in the same way as Jean-Claude at JeeLabs, so I was mostly limited to the supplied examples. I even tried connecting my Keil ULink 2 debug proble to the SWD pins, in an attempt to use Keil uVision to write code for this chip. Again without success. Adafruit recommends the LPCXpresso IDE, so I also installed that. Although I could use it to program other NXP chips on pre-made development boards, I still had no real success with programming the LPC810.


The LP810 is very sweet, but the small number of available pins does limit its usefulness. After some examples with this little chip, JeeLabs moved on to cover the very similar LPC812, which mainly differs in having a smaller (TSSOP) package with 20 pins. With a bit of care I was able to solder this chip onto a DIP adapter. The extra pins are nice, but I still faced the same issues with programming. I decided that however neat the idea of the ISP pin and serial bootloader seems on the surface, it is just too fiddly for sensible software development.

Next time I'll step into the confusing world of SWD, but this time I'll try with a microcontroller where I am already comfortable with the development software.

ARM Cortex-M board from scratch part 1: Too Many Options

As many of my readers will be aware, I have quite an extensive collection of microcontroller development boards with a wide range of controller chips from a variety of architectures and manufacturers. While it's fair to say that I enjoy programming and creating projects with these boards, there has always been a niggle in the back of my mind that too much of the work has been done for me. Often it's even worse than that: chip manufacturers delight in cramming boards full of peripherals and options which are great to play with but not much help in learning about the needs of the basic hardware.


I have come to the conclusion that to really understand things, I need to build my own development board(s) from scratch. A while ago I went down this route with an Atmel AVR microcontroller (as used in the popular Arduino boards) but that is no longer enough. The great majority of my development board collection is based on ARM Cortex-M micro-controllers, so I am determined to get to grips with building and programming my own ARM Cortex-M circuits. Along the way I expect to face the challenges of surface-mount soldering, complex programming protocols, massive documents and differing vendor implementations. If all this works out, I am even dreaming of learning how to design and produce my own printed-circuit boards for whatever I come up with.

Unlike the simpler world of Arduino, there are a multitude of choices when it comes to Cortex-M. ARM itself just sells core designs, it does not make chips - that is left to third parties: anyone who can pay the licence fees to ARM and has the resources to produce and market the silicon. Naturally these manufactures do not all make exactly the same devices. To start with, ARM provides a range of core designs in the Cortex-M series including M0, M0+, M3, M4, M4F and M7. Although broadly compatible, these chips offer different base capabilities. Each manufacturer chooses one or more of these cores and adds their own on-chip circuitry such as UART, SPI and I2C, analogue input and output, timers and so on. Some manufacturers (for example Cypress, in their PSoC range) add all sorts of programmable logic and analogue components, while others stick to simpler, cheaper designs. Each manufacturer also makes choices about power consumption and the ability to "switch off" parts of the chip to consume less.


After deciding what micro-controller core to use, choosing extra on-chip circuitry and power controls, there's still the matter of packaging. ARM Cortex devices are used in a very wide range of situations. Some need to be really tiny, others need lots of pins and power. Unlike more traditional AVR and PIC MCUs, there are hardly any ARMs in "breadboard-friendly" Dual-In-Line (DIP) packages. Luckily, there are a few.

For me, the biggest problem has been finding out what the minimum circuit for a given chip might be. I view this as the electronics equivalent of 'Hello World' or 'blink' in the software world. When starting out there are far too may choices to make. As well as which controller chip, there's how to wire it up to power and stuff, pull ups and pull-down resistors, capacitors and crystals, how to connect it to some sort of programmer, which programmer to use, which development software to use, and what to write to exercise the system. I always prefer to learn by starting with a bare minimum working design and making and testing small changes until I get to where I want. In the embedded design world this does not seem a very common approach. Instead, we are presented with huge technical references and datasheets, with no worked examples, which just reveal even more options to get wrong.

What I really want is a guaranteed minimal circuit to start with, so that if the device won't start or won't program, I know the problem is elsewhere. My naive assumption was that each manufacturer would obviously produce an 'application note' with such a minimal circuit, but no. I may be looking in the wrong place, but so far I have not found such a document from any manufacturer. I even bought some 'embedded system design' books in the hope that they might help, but they all start with software, and just assume that all the electronics is already in place.

With no apparent support from the manufacturers, I am left looking to the web for help. To try and eliminate PCB design from the problem, I plan to start with one of the few DIP ARM chips, and see how far that will get me.

NXP LPC1114 Dual in Line ARM chip

The first obvious choice is the NXP LPC1114. The micro-controller community got quite excited whe NXP released this part, and on the surface it looks like a good choice. Plenty of people have had a go at it and there seem to be quite a lot of web resources. There's one big problem, though. The chip itself is very hard to come by. None of the usual suppliers seem to stock it, leaving only a small collection of ebay vendors. I eventually managed to get hold of one for a mostly reasonable price, but so far I have not yet dared to try and program it in case I kill it!

It took me several months of indecision before I finally discovered some very helpful resources about another NXP chip, the LPC810. This is a much smaller DIP package with only 8 pins, not enough for even a basic JTAG connector, so it uses its own bootloader firmware. Next time, I'll cover my adventures with LPC810, and its close cousin LPC812.

A handy (and cheap) gadget for holding small PCBs

For the hundredth time I found myself trying to solder some small circuit board and annoyed by the way it skittered across my desk. I had tried 'helping hands' but these are fiddly and annoying to set up, the screws keep coming loose, and they hold the boards at wonky angles. I had just about given up, so I looked on the web for some sort of PCB clamp or vice.

Circuit Board Holder

Web sites typically seem to recommend 'panavise' brand but these seem pretty expensive and hard to get outside the USA. In a previous job we used a very clever system which clamped the PCB for component placement and also allowed it to be flipped over for through hole soldering, but this sort of thing is even more expensive. However, I looked a bit further and found an interesting little gadget for under £3 including delivery on ebay. I ordered one and it arrived the next day.

Circuit Board Holder with FRDM KE04Z board

The device is all metal, and reassuringly heavy with rubber feet and even screw holes to fix it. There's no way it will move, even under the most forceful electronics work. placing and removing boards for work is simple, just pull back the spring-loaded clip. It seems fairly adjustable for a variety of board shapes, but is obviously limited to boards small enough to fit. I have tried it with a selection of Freescale FRDM boards, Arduinos of various sizes as well as Raspberry Pi main boards, expansions and HATs and it comfortably held all of them. Something like a Gertboard would be too big, though. The device is designed for phone repair where everything is low-profile, so there's also a chance that some boards with lots of tall components might not fit properly because they bump into the central metal support bar.

I'm hoping that the metal bottom plate will also help spread waste heat from hot-air reflow soldering and unsoldering of surface-mount parts, but I haven't tried that yet.

Arduino development in a web browser

Over the last few years I have written and edited many Arduino sketches. Aside from a brief dalliance with Sublime Text I have exclusively used the dull but ubiquitous Arduino IDE.

At the time I started each project this seemed completely natural, but over time I seem to somehow lose track of where I put the code. I use a variety of different computers, including virtual ones, several file sharing and backup systems (Dropbox, Google Drive and Bittorrent Sync, for example) and a heap of removable media. Many of my 'important' sketches are version controlled and stored in GitHub or BitBucket. Somewhere in that lot is probably something useful for my next project, but it's getting tougher and tougher to find it.

With all this in mind I am excited to have found Codebender - a browser-based Arduino IDE which backs up all your sketches to 'the cloud' and is available from any computer with an internet connection. Strictly it also needs, for the moment at least, a Chrome browser if you want to run the plugin which recognizes, controls and communicates with your Arduino hardware. I use Chrome most of the time anyway, so that's not really a problem for me.


I have now uses Codebender heavily for a couple of projects, and found it smooth to use and somewhat easier to get to grips with than the original Arduino IDE. It recognizes and works with a large and growing collection of Arduino boards and compatibles, but it does not currently support non-AVR systems (Arduino Due and other ARM boards, Iteaduino Lite and boards with AVR-clone controllers, for example). It also has access to a large collection of libraries.

Interaction between the web interface and the Arduino is generally seamless, provided you have a reliable internet connection. I did find that I had sometimes to re-try programming the hardware when I was in an area with intermittent wi-fi, but none of my source code was lost and the second download attempt usually worked.

If you are like me, and hop from one machine to another, or even if you are just a bit tired of the quirks of the Arduino IDE, I recommend that you sign up for Codebender. It's free, and it might be useful.

For full disclosure, if you sign up using the links I give above, I get some points. If I get enough points, I might get a free T-shirt. Despite that, I still think this is a worthwhile service to try.

Raspberry Pi B+ and Altoids

Raspberry Pi B+ and Altoids tin

Just in case you have not noticed the hype that is all over our corner of the internet, there is a new version of the Raspberry Pi, called the "B+". I won't bother going into detail about its features, that's covered very well by many others including Adafruit, Gordon Henderson, Carrie-Ann Philbin and, of course, the Foundation.

I hope to do a bunch of stuff with this new board in the coming weeks, but for now I shall just answer one burning question:

No, despite its new rounded corners it still does not fit in an Altoids tin. Sigh.

A busy evening with the Ipswich Makerspace

On Thursday I popped along to the latest "Soldering irons and Software" evening with the Ipswich Makerspace group. This was easily the best attended so far with a wide range of projects in various stages of completion. The thing I found most intriguing about the number and variety of people was how quickly we have reached a sort of "critical mass". Despite little or no pre-planning several people quickly found someone else there who was in a great position to help with their projects.

Makerspace bat detectors

In my own case, I took along the ultrasonic distance sensor which have recently been playing with. Mainly I intended to fiddle with it and try to get a better, more linear and higher resolution, response for its use as a human input device. What actually happened was that someone sat down beside me with a big box of possibly-working bat detectors. If you have read many of the older posts here, you are probably aware that I'm very interested in bat detectors, so we had some fun discussions. Most interesting of all, though, was the way that I was able to set up my ultrasonic rangefinder to repeatedly "ping" so it could work as a passable "bat simulator". All that was needed was to point one of the detectors at the distance sensor to quickly find out if it was working. Operational detectors gave out a clear clicking in time with the transmission from the distance sensor.

Other people found themselves in similar situations, and the result was a great social atmosphere and some real progress made on several projects.

Now I'm looking forward to the next meeting even more.

Arduino Mini Pro and ultrasonic distance sensor

I've not blogged here for a few days. Unfortunately my "real job" got very busy. In the meanwhile I received another package of bits I had ordered from China weeks ago and mostly forgotten about ;)

Among other things in this package were some clone Arduino Mini Pro boards. These little boards have a SMD Atmega 328, crystal, LED, caps and a reset button, on a board which brings out all the inputs and outputs to 0.1" pitch. Designed for embedding in small projects, these do not have pins or sockets fitted, but the ones I ordered came with pin strips for both sides and an angled header for an end-mounted power and serial connector. I'm still astonished by the prices of these things. I got five of them for £7.77, with free postage. That's a bit over £1.50 each, no way I could even consider making one for that price.

Arduino Pro mini with ultrasonic ranger

Of course, these boards are not as friendly to use as a "full" Arduino, such as a Uno. They do not have USB, and do not come with a bootloader. Luckily this was not much of a problem. After all the effort I have spent on playing with bare ATmega chips recently, all it took was to connect up my "Xinda" USBTiny programmer to the correct pins (as described here) and I could program the board straight away. I tried out a few blinking LEDs and the like just to prove that it works.

Next, though, I wanted to try out the HC-SR04 Ultrasonic distance sensor boards I got in the same package. These have just four pins on them: the obvious power and ground, and two labelled "Trig" and "Echo". A bit of looking around found a web page with a wiring diagram and example program. I connected up the sensor, simplified the example program a little, and programmed it on to the Arduino pro micro board.

HC-SR04 Ping distance sensor]
VCC to arduino 5v; GND to arduino GND
Echo to Arduino pin 7; Trig to Arduino pin 8

#define echoPin 7
#define trigPin 8

void setup() {
  Serial.begin (9600);
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);

void loop() {
  // send a pulse on the trigger pin to initiate measurement
  digitalWrite(trigPin, LOW);
  digitalWrite(trigPin, HIGH);
  digitalWrite(trigPin, LOW);

  // the length of the pulse on the echo pin is proportional to the distance
  long duration = pulseIn(echoPin, HIGH);
  long distance = (duration/2) / 29.1;

  if (distance >= 200 || distance <= 0){
    Serial.println("Out of range");
  else {
    Serial.println(" cm");

However, there's a gotcha. The code sends its output over the Arduino serial port, so the user can see the results on a terminal emulator. Unfortunately, because I was connected to the device using an ISP, there was no serial connection. So I could not see whether it was working or not.

The next step, then, was to connect the serial pins to a USB/serial adapter. I found one attached to a Raspberry Pi and connected it to the serial header conveniently placed at the end of the Arduino board. Once the PC had recognized the USB device, I could open up the serial monitor in the Arduino IDE and see the reported distance values. Looked roughly accurate too!

At this point there really seemed to be to many wires, so I took the opportunity to use the USBTiny to write a bootloader to the AVR chip, so next time I can just connect the four wires from the USB/serial connector and take care of all the programming and serial I/O.

So far I am pretty impressed with both these items. the Arduino Pro Mini is so small and (most importantly) so cheap that I can really see myself building it into all sorts of projects. It's especially nice that it does not come with the pins attached, so it can easily be wired direct

Building a “xino” Arduino clone kit

You'd think I would be fed up with Arduinos after all that messing about with one connected to a Raspberry Pi, but while playing with that it occurred to me that some months ago I had bought a nicely cheap Arduino board kit (Xino Basic for Atmel), assembled it, but not managed to program it, so I had tossed it back in the "later" box.

Xino components

Assembled Xino board

My initial attempts at programming used the five-pin power and serial programming connector mounted on the edge of the board. Despite trying several serial interface boards, and as many combinations of cable connections as I could think of, I could still not get it to respond to the Arduino IDE. Since then both my skills and my collection of equipment have improved, so I reckoned it was time to have another go.

Step one was to program a chip using my hand built "Arduino ISP" to check that the board assembly was correct. Blinking LEDs and my two way serial port test program showed that everything was OK in that department. Continually pulling the chip out of the socket was clumsy, though, and, despite my best efforts, was beginning to bend the legs a bit. So step two was to leave the chip in place and program it that way. The Xino board has solder pads for the 2x3 Atmel ICSP header, so it looked like I just needed to solder in some pins. Luckily I have one of the more recent versions of this board (it says (c) 2012 IoT Research), so I can connect both the ICSP and serial connectors at the same time. Apparently on the 2011 version of the board, the two connectors overlapped and could not be fitted at the same time. You can see a picture of one at the Ciseco page for this board.

Xino board being programmed using Xinda "USBTinyISP"

My first attempt at ICSP programming was a failure, but then I noticed the tiny pin numbers and realized that I had got the connector the wrong way round. After that I could program and re-program to my heart's content.

Now that I have this board working, the more I look at it, the more I like it. It's cheap and comes with everything you need apart from the MCU, crystal and capacitors, but I have plenty of those now, and I can always run the ATMega chip without a crystal if I want to. I can also leave off most of the other components and connectors if I don't want them. Even better, the board has a small but useful prototyping area and through-hole pads for all the Arduino pins so it would make a very easy and low cost way to embed an "Arduino" in a project.

I might just order a few more...