LPC1114FN28 with Open Source Tools


I’ve been excited about the LPC1114FN28 for a while now (at least, as excited as one could be about a microcontroller).  The LPC1114FN28 is a microcontroller from NXP with an ARM Cortex-M0 core in a 28 pin DIP package. With 32k of flash and 4k of RAM, this chip isn’t the biggest or baddest on the block, but at $1.50 in small quantities, it has just about every other uC beat in the performance-per-dollar arena.  It’s got the basic peripherals, SPI, Serial, ADC, and I2C.  It’s programmable via SWD or serial bootloader. Though I don’t use a breadboard too often any more, it’s great to have an easy-to-prototype ARM chip in my box.  Unfortunately, these chips are notoriously difficult to work with, especially with open source tools.

A few posts ago, I talked about getting an open-source ARM toolchain up and running.  With the correct linker scripts, this toolchain will work very well for this chip.  NXP has also seen fit to include an internal RC oscillator on-board, so the breadboard setup for this chip is surprisingly simple.  Here’s what I used:

I’ve got an LED for power, an LED hooked up to PIO1_8 (pin 17), a reset switch, and a pin header configured to work with an FTDI cable or an FTDI friend hooked up to the serial lines.  Most important is the resistor between ground and PIO0_1 (pin 24).  The value of this pin is sampled at reset, and if it is tied to ground, the chip enters the serial bootloader. Otherwise, it executes the loaded program.  This process can’t be done in software, so you have to connect this resistor when you want to load code, and disconnect the resistor when you want to run your program.  You could also use a pin on the FTDI friend for this, but you’d have to modify the ISP software.

As I said, I’m using the toolchain I configured earlier.  I found some blinky test code for another chip in the LPC1114 family, and modified it to work with the LPC1114FN28.  The modified code can be found here: https://github.com/Zuph/lpc1114-blink

In order to get the code to work, I altered the linker script to reflect the amount of RAM on this particular chip, and changed the pin configuration for the LED pin.  I also had to change the clock source: this was the most difficult piece to chase down.  Unlike AVR chips, where the clock configuration is set by fuses, this ARM chip (and many others) force the user to configure clock sources manually. Originally, line 154 of main.c read:


This configured the chip to use an external oscillator.  Changing this to:


resolved the problems.  Output code is now being generated properly, but getting it on the chip is a different problem entirely!  Reading the manual for the series makes the bootloader look like a fairly simple piece of work!  Auto-baud synchronization makes interfacing simple, and the commands are reasonably easy to understand.  There are a few programs which purport compatibility with the the LPC111x family, including VSProg (from the Versaloon folks), and a likely-abandoned projected called lpc21isp.  Neither of these programs, however, support the LPC1114FN28/102 variant.  VSProg looked to be the most promising (given its general purpose nature), but modifying the config files proved fruitless in adding support for the FN28 (if you can get it working, please let me know!).  lps21isp, however, worked well once the parameters for the chip were programmed in.  I’ve uploaded the code for my variant here: https://github.com/Zuph/lpc21isp

I had to change lpcprog.c, adding the following on line 116:

{ 0x1A40902B, "1114FN.../102", 32, 4, 8, 1024, SectorTable_17xx, CHIP_VARIANT_LPC11XX },

This adds the FN28 chip-id, along with the amount of RAM, flash, number of flash pages, and the maximum amount of data to transfer at once (the bootloader uses a two step process, writing code to RAM, then moving it to flash in order to reprogram the ship).  Once this is added, I was able to easily flash code to the chip, although I wasn’t able to do so at 9600 baud.  115200 baud works well.

In summary, wire up a breadboard as seen in the picture above, compile the blink code, flash it on to the chip using the lpc21isp program, remove the resistor on pin 24, reset the chip, and watch it blink!

Here are the exact commands I used:

Possible caveats: The chip will only attempt to enter the bootloader once.  If autobaud has been attempted and failed, you’ll need to reset your chip to attempt it again.  Also, in the programming command, we give it the speed (in kHz) of the RC oscillator, since that’s the oscillator that the bootloader will be using.

Let me know if you have any questions.


  • […] [Brad] has been very excited about an ARM Cortex-M0 chip released by NXP; it’s a fully featured ARM microcontroller, and is, quite amazingly, stuffed into a hobbiest and breadboard-friendly DIP-28 package. After finding a supplier for this chip, [Brad] dove in and put together a great tutorial for programming an ARM on the breadboard using open source tools. […]

  • Thanks! I’ve got my own chips now and am looking forward to some breadboard ARM tinkering.

    Is your FTDI friend reconfigured for 3.3v VCC output? From what I see here you might be feeding it 5V, which is supposedly bad.

  • The resistors have color bands marked in the drawing. The values don’t matter too much. Use resistors appropriate for the LEDs for the ones which are attached to the LEDs, and use whatever you’ve got laying around to pull up the switch and pull down the boot pin (1k, 4.7k, doesn’t really matter).

  • Thanks for the article Brad,

    My toolchain seems to work and I can build your sample, but all I seem to be able to get out of lpcprog is “no answer on ‘?'”. This is the code built from your repository (on windows).

    Could you give some more details on your FTDI Friend connections? From the schematic, it looks like you’ve got pin 16/TXD to RTS on the FTDI_F, and pin 15/RXD to RX on the FTDI_R, then power to TX and ground to CTS.

    At least that’s according to the board shown at http://www.adafruit.com/products/284 which matches the FTDI Friend board pinout on the brand new board I’ve got.

  • Replying to myself:

    pin 15 to Tx on the FTDI Friend
    pin 16 to Rx ”

    But what was blocking is that 12000 wasn’t working as a param to lpcprog. I had to run lpcprog with:

    lpcprog lpc1114_blink_led.hex com3 115200 120000

    …and I got gnu make for Windows from the min-gw package: http://mingw.org/wiki/Getting_Started

    Merrily blinking away now.

  • I got this to work back in September (though I had to shift the FTDI header one pin over). I just tried again, though, and had a few rough spots:

    – On OSX, remove the -static option from CFLAGS in lpc21isp, or else it won’t link (“ld: library not found for -lcrt0.o”).

    – Commit 2371112 (“Fixed bug with incomplete arguments”) broke lpc21isp. It printed the tool title, then exited from LoadFiles1(). Reverting that change made the tool work again.

    – Thanks to Steve on the 12000 -> 120000 change — that worked for me.

  • lpc21isp was not working for me. It would only print info to the terminal up to the line about its version.. 1.83 or something. Even with debug level 5 it would only show the version before dropping to command prompt. (This is on a lubuntu linux system).

    After adding a bunch of debug printf’s to figure out the code, I was able to get it working.

    The solution for me was to comment out the following lines in lpc21isp.c :
    lines 1965 though 1976

    By removing the checks for the prev member of the file struct, The code stopped giving a ret_val of -1 which kept calling exit().

  • The toolchain setup linked from this page talks about the bare-metal toolchain, and OpenOCD.
    I wonder if there is information anywhere showing if/how a gdb+OpenOCD+FTDI-friend+LPC1114 combo might work.

    On Fedora 14 I also need to remove -static from the lpc21isp Makefile.
    Also, the Makefile seems to have .out suffixes to the binary name in some, but not all places.

    {{{ Andy

  • It seemed to work for me using 12000.
    I also needed to revert that last commit relating to LoadFiles1.

    I now have a little flashing LED. Yay!

    ( I used a FTDI friend (5V) and put the 5V through a little 0.33uF L78L33 0.1uF regulator setup to make the 3.3V needed for the main circuit, because I didn’t want to alter the FTDI friend to its 3.3V setting and ultimately my design will have a 5V rail and I’ll have to make the 3.3V needed ).

    Thanks for an excellent write up.

    {{{ Andy

  • LPCXpresso may not be open source, but it’ll let you work as soon as posible. I tried a really open source solution for STM32L100 (ST) and it worked great (eclipse + gcc tool chain + gdb). However, I’m a really big fan of NXP, so hope some day I can do their controllers.