From the Trenches: Embedded Platform Work

I’m tinkering with a new platform for my embedded projects, based on the NXP LPC1768, which is an ARM Cortex-M3 chip.

I picked up an eval board (the Blueboard LPC1768-H) back in late 2010.  The board is nothing to write home about, and has some design choices that I seriously question (like non-0.100″ aligned headers… Really guys?  I thought it was just the Arduino that made this foolish error).  However, it was cheap, and it has the basics for getting something up and running easily with fewer unknowns that diving right into a custom design.

When I first got the board, I got a basic build environment running on Windows using the CodeSourcery Lite GNU compiler port, with Eclipse as an IDE.  At the time, I had no debugging capabilities, but the LPC17xx series has a built in serial bootloader, which allows one to program the flash memory (but not debug) over a plain old serial port.  You use a tool like FlashMagic to speak the bootloader protocol, which is fine, but you’re basically stuck in burn-and-learn mode with this kind of setup unless you integrate a debugger/monitor into your code.  If you have some working examples to start with, a lot of patience, and don’t venture too far off the beaten path, you can make this work.  However, ARMs are complicated processors, at least when compared to good old 8-bit microcontrollers.  Just to give you some idea, the LPC17xx user manual is over 800 pages long.  Good bedtime reading.

So, the project got thrown onto the back burner shortly after I got code compiling and running, but hit a wall with an interrupt vector issue, and I had no way to debug it easily.  I ran out of patience and moved on.  Flash forward to now, when I have a rekindled interest in spinning PC boards and tinkering with electronics stuff in my spare time.  A bit of luck turned up a JTAGkey in-circuit debugger from Amontec sitting unused in a box at work.  A quick check confirmed it should work with the LPC17xx.

The last time I did anything serious on a smaller-scale ARM (i.e., not the big-boy ARM micros like the Sitara Cortex A8, on which running Linux is possible), I was using the commercial Keil MDK.  This includes everything in one package: compiler, IDE, debugger hardware, RTOS, etc. This is fine for a commercial project, but it’s cost-prohibitive for hobbyists.  As mentioned before, I had found some good free alternatives for the compiler and an IDE (though a text editor and Makefiles work just fine too).  The final piece of the puzzle came not only with finding the JTAGkey hardware, but also running across OpenOCD, which is an open source package that actually drives various JTAG interfaces and lets you do gdb style debugging either via command line or through Eclipse.

So I’ve been working on putting all of the bits and pieces of software together to make a working build and debug environment.  It’s not easy – it’s definitely not plug and play by any means.  After a bunch of pretty intense hours, I have partially working environments on both Linux and Windows, but I’m still sorting out details.  As of this evening I’m finally able to see the first signs of life working through the debugger, and have stepped through a handful of lines of code through the Eclipse debug interface, before it explodes and faults in a libc setup routine.  I *can* program the flash chip on the part and run the code just fine without a debugger.  Baby steps, I guess.

In working on this stuff so far, I’ve tried out a couple of different pre-built toolchains for ARM.  One was Yagarto, which did seem to build code, but is not available for Linux.  I find this a bit weird, since the GNU toolchain originated in a Unix environment, and to have something that is repackaged GNU code be Windows-only is just strange.  In my quest to find something more Linux-friendly, I found out that newer versions of Ubuntu have access to gcc-arm-linux-gnueabi packages. Unfortunately, I also discovered that these packages were not available directly in Ubuntu 10.04 LTS (long-term-support), but there were backports available from Linaro.   Unfortunately, gdb seemed to be missing in action, so that pushed me back to CodeSourcery, which is probably where I should have started to begin with.  I briefly tried Ubuntu 11 to see if the newer packages were any better, Unity made my skin crawl. I deleted that virtual machine with extreme prejudice.

Another headache was dealing with the FTDI USB driver situation to get OpenOCD running on Linux.  Many of the available JTAG debuggers are based around this chip, but the drivers from FTDI are only free-as-in-beer, but not free-as-in-speech.  This of course irks the open source people to no end, so there’s an open source alternative that’s perhaps not fully baked that is available.  I tried running with the open-source drivers, the closed-source drivers, and probably accidentally, combinations in between.  Currently, my best working setup is running OpenOCD on my Windows host, with the open source libusb layer drivers replacing the FTDI drivers.  Because OpenOCD works over a TCP/IP socket (more or less just like regular old remote gdb debugging if you’ve ever done that), I can connect the tools running in my virtual machine back up to the host over the network with no problems.  However, I have at least had some success with various combinations, and it all deserves more attention as the project progresses.

I’ve currently got it working the furthest on a Windows 7 host with a Windows XP virtual machine guest. My ultimate hope is to be able to get it all running under Linux, so I can make a virtual machine image with everything needed on it and hand it out to some of my closer programmer friends who might want to give embedded development a try on something a little more “real” than an Arduino.  And you can bet that I have some plans brewing for some new PC board designs centered around this (or similar) ARM processors.

More as it happens!

Related Posts

Embedded Hacking Weekend

I’ve gotten back into the ARM Cortex M3 embedded stuff (yes, again), specifically with the NXP LPC1768 chip.   I’ve had this Blue Board development board hanging around…

Cortex M3 Articles

Happened across a pair of articles giving a good overview of embedded development with the Cortex-M3. Part 1 covers the processor architecture while Part 2 gets more…

Epic Hardware Hacking Weekend

It turned out to be quite an epic weekend of building boards and getting things up and running.  It’s good to be back in the groove with…

Custom PCI Express Riser

One of the other boards I had in the latest order is an oddball PCI Express 1X riser card, which I could not find commercially.  In trying…

The Hammer

I thought I’d try to get one more design into the January 23 Laen PCB order.  For the new CNC electronics setup, I’m going to be using…

USB Pendant Hacking

I’ve been knee-deep in USB and LCD hacking, playing around some concepts for a control pendant for my CNC mill.  It was a good excuse to exercise…

This Post Has 5 Comments

  1. I’m pretty sure the Arduino does the weirdly-spaced header thing in order to make sure you can’t plug boards into them rotated 180 degrees, which you’d be able to otherwise. It kind of goes along with the whole for-beginners thing, but I also ran into that same problem back when I was messing with it regularly. That’s part of why I started mostly using a variant board with one row of headers, correctly spaced.

    That’s probably what they were doing with the board you’re using too, but it makes less sense for this one since it’s not designed explicitly for noobs…

  2. Aha – I didn’t consider that it would help prevent mis-plugging. I guess it solves one problem and creates another. As you noted, at least some people have wised up to that and have offered breadboard-friendly versions of things. There’s the Mbed LPC1768 board, for example: http://mbed.org/nxp/lpc1768/

    I’m not sure that protection from misplugging is a valid excuse for the Blueboard. Even headers that are on the same side of the board are mis-aligned from one another. Also, I don’t know that there are any commercial daughtercards (ugh… “shields”) available, which is kind of the whole point with the Arduino. I think someone simply didn’t have a snap grid turned on in their layout package.

  3. The other issue with the Keil toolchain is that it sucks. I thought I was going to get to redo all that stuff on a new toolchain, but the customer dropped the embedded webserver funtionality so it’s falling back to usb integrated with the micro that runs the radio.

    The problem with doing this stuff professionally is that I don’t have the patience for hobbyist bullshit anymore. Your batch pcb posts gave me hope, but it sounds like software is still a problem.

  4. There’s definitely a bit of a learning curve with this stuff, but so far the tools are considerably better than hobbyist-grade. It is, however, free – and you get what you pay for in terms of having to figure a lot of crap out for yourself. There are commercial variants of most of the various components, which gets you support at least.

    I’ll echo your sentiments about the Keil toolchain. This stuff feels less brittle in some ways (and you have all the source and can figure it out if you have to), but it’s also not toolchain+RTOS+TCP/IP stack all ready to run out of the box like the Keil MDK was for the larger LPC2xxx parts. Stuff is out there, but you have to do some legwork.

    I’ve got code building and I’m now properly debugging and have real stuff running on my part. There are still plenty of things I’m trying to figure out, but reliably loading and debugging code with a visual debugger tool, all on free software, is pretty cool.

  5. Yeah, it definitely sounds better than when I tried to get msp430-gcc working for my MQP.

    The one embedded-ish platform that the open source stuff was actually quite good for was the old 68k era PalmOS stuff.

Leave a Reply to Jeff Cancel reply

Your email address will not be published. Required fields are marked *