Around the beginning of the year I posted this article about my idea for a breakout board for NXP’s LPC1114 ARM Cortex-M0 microcontrollers after being inspired their announcement for a DIP packaged Cortex-M0 micro. Earlier this month I received the PCBs for my design and built two of the boards using my reflow oven.
In the above pictures I didn’t populate the power LED, but everything else is in place and tested. The LPC1114 QFN package was actually a pleasure to work with using solder paste and a reflow oven. I didn’t have a small enough tip for my solder paste which meant I had a little too much solder in places but that was easily cleaned up with a fine tipped iron. The most obvious place where there is too much solder is around the crystal oscillator on the right, and the 0805 capacitors on the left of the board.
After building two of the boards there were a few things I was happy with, and a few more disappointments. Firstly due to the pin layout of the LPC1114 chip in the QFN package I could make this breakout board quite small and still keep a fairly large ground plane. The small size was a goal of mine especially considering I wanted to be able to plug this board into a standard breadboard. It was almost something I would use!
Now on to the disappointments: My idea presented in my other post about reset and boot-loader buttons was a failure. I had an idea of using small edge mounted buttons to reset and enter the boot-loader mode on the LPC1114. While the idea worked in terms of functionality the implementation failed in terms of ergonomics. Pressing the buttons to load code onto the chip was an unpleasant experience which I think cost too much in usability. My next gripe which I thought might be a problem is that I still need to hook up an external device (In this case a FTDI USB to UART chip) to reprogram the LPC1114. Lastly the silkscreen on the board was blurry! Although this was my fault for making the size too small. It was legible, but it is nice to be able to read which pins you are connecting without squinting.
I am quite happy with building these breakout boards as a learning experience. I do plan on making a second revision which incorporates what I have learned. I plan on doing away with the buttons and instead adding a small FTDI USB to UART chip in a QFN package. This can also be used along with lpc21isp software to automatically reset and enter the ISP boot-loader. As an added bonus this would add USB serial functionality to the board without adding anything extra for easy debugging and prototyping. The external crystal could also be eliminated with the pins being broken out so that any crystal could be used. This would offset some of the cost added with the FTDI chip and USB connector, especially considering the LPC1114 has a 12MHz internal oscillator.
I will post schematics and layouts for the updated version 2 of my breadboard-able ARM microcontrollers once I have them ready to send off.
Before I found the updated version of lpc21isp I thought I was stuck using flashmagic, or writing my own tool to program the chip over serial. When I first looked through the user manual I unfortunately missed the syntonization protocol the bootloader follows. I was about to try looking at the data being transmitted on an oscilloscope when I found the correct way to finish the auto-baud routine. Section 21.3.3 of the lpc111x user manual (UM10398) fits it all into one paragraph.
The confusing aspect of this protocol is that earlier in the user manual section 10.5.14 specifies doing auto-baud using an ‘A’ or ‘a’ character and gives reasoning as to why those characters are used. The ISP auto-baud protocol requires the ‘?’ character.
If one character was all that was needed to enter the bootloader I would try and think of a couple reasons for the use of the ‘?’ character. However, after sending the initial ‘?’ there are another couple of steps required.
The protocol to access the bootloader is as follows:
Reset with the ISP pin held low
Connect to RX/TX and open a terminal with your favorite program
‘?” and hit return
LPC111x will return ‘Synchronized’
Reply with ‘Synchronized’
LPC will return ‘OK’
Reply with the crystal frequency in kHz (12000 in my case)
LPC will return ‘OK’
Auto-baud is now finished and ISP commands can be executed.
In my case the formatting covered up some of what I had typed, but everything worked perfectly even at 115200 baud.
I might still write something in python to flash new code onto my board, but the new version of lpc21isp looks promising and covers OSX and Linux.
I figured this would be a good first post for a blog. The other day I discovered NXP’s press release about TSSOP/DIP packaged ARM Cortex-M0 microcontrollers. When these chips are eventually released it will make prototyping much easier and cheaper. Of course it would be nice to have something I can play with right now, and I got to thinking about making a tiny breakout board / development kit.
The easiest way to start these kind of projects is to just drop down a chip and fan out all of the pins. The positives of this method are that it is easy to lay out and cheap to make. However when I started to think about how I would be using this board it made sense to add the essentials on the board.
The internal 12MHz oscillator in the LPC111X series is only accurate to 1%, so it makes sense to include an external crystal. I chose 10MHz for a few reasons. It is the minimum frequency crystal that the PLL accepts, it is easily multiplied to 50MHz which is the maximum frequency supported, and finally it gives me a different base frequency from 12MHz (and thus more options).
The next big thing is a voltage regulator. It would be nice to be able to stick a cheap LiPo into designs without having to worry about regulator. The LPC111x series is also fairly low power, drawing around 8mA at 3.3V/50MHz in active mode, so a LDO can be used with a dropout voltage of around 100mV (or less depending on the current consumption). Of course the 3.3V power rail is broken out to a header to power other peripherals, or 3.3V can be fed directly in as long as the regulator input isn’t connected.
I also included an LED to indicate power to the board. For development purposes power consumption isn’t really an issue and the extra 1-2mA the LED draws is negligible. For lower power applications where the MCU will be shut down the led can easily be removed.
The final important features of this board are buttons. There are two surface mount right angle momentary switches mounted on the bottom of the board. One is connected to the reset line and the other is connected to the P0.1 which is when pulled low on reset will enter the built in ISP boot-loader. This is also the feature that lead me to choose the LPC111X series. The first chip I looked at was the LPC1102 which has an incredibly small 2mmx2mm WLCSP (Wafer Level Chip Scale Package) package ( Redundant ). Other than the limited number of pins, the LPC1102 has a decent number of features. The BIG problem with this chip is that there is no ISP entry pin. Unless the user specifies a point in their code to jump back to the boot-loader programming is a one time deal. For a development tool that won’t work, hence the next smallest/cheapest chip series was chosen. To get back on topic, having the two buttons means that with one finger it is possibly to roll over the two switches pressing reset, then reset and ISP, releasing reset, and finally releasing the ISP pin. This will prepare the chip’s ISP and reprogramming can be done over the serial port. These pins are also broken out and the process can be done automatically with certain software, however having the physical buttons has always been helpful to me.
Finally after a couple of days worth of work my board is about 99% complete. Right now the one important error with the board is the LPC111X footprint. The vias should line the perimeter of the inner pad (which is the only ground pin on this package). This leaves room for solder paste in the middle which will not get sucked through and possibly hurt the physical connection of the chip to the PCB.
Both the top and bottom layers are extensively labeled. The silkscreen will of course be tiny but should be readable. Having the reference on the chip means less time reading through datasheets and more time writing code.
The image I have as the heading to this post is testing out ISP programming with the LPCXpresso. This board has the LPC1114 which has 32kB of flash and 8kB of SRAM, and will probably be the same chip I include on my board except in a different package. A chip with less memory can be used to reduce the cost, a LPC1111 with 8kB of flash and 2kB of SRAM cuts the cost in half.
I pieced together a working set of header files and linker scripts for the LPC111X MCUs and verified I could actually program the chip using the ISP bootloader. I first succeeded in getting the MCU to acknowledge FlashMagic on windows, and then moved on to being able to program using only OSX. When I went to download FlashMagic I was pleasantly surprised that there was an OSX version available! However whenever I tried to communicate with anything the program promptly crashed. This happened on both 10.6 and 10.7 and I couldn’t find an easy fix. Instead I turned to lpc21isp, and open source tool for programming different ARM micros. At first I didn’t have any luck, it could communicate with the chip but didn’t recognize it. A short update later things were running perfectly! One oddity I found with this program is that uploading a .hex file it will not automatically start the program, however if I use a .bin file it works perfectly.
The final consideration for this board is cost. The LPCXpresso is actually a fairly cheap ARM Cortex-M0 development board at around $30. I wanted to get something that could retail for half that. The total BOM for the board I’m working on comes to around $8 in single quantity without the PCB. Buying in quantities of 100 reduces this to around $5 with the LPC1114. Using an LPC1111 would cut another 1$ off this price. This makes a price point of 15$ very much within reach (after accounting for shipping, manufacturing, etc).
I will probably fix the via issue with the board tomorrow and send it out to get some PCB prototypes made, meaning I should be able to continue this post in a couple of weeks. I will also set up a git repository when I get a chance to hold my code for this project. That’s all for now!