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!