Micromouse 5/2012

I recently added my documentation for my Micromouse project to my Projects page. Check it out:

Micromouse 2012

More of my projects will be added to my Projects page soon, stick around!


LPC1769 Fast Fourier Transform

I recently discovered that NXP has published a DSP library for their ARM Cortex-M3 microcontrollers and I thought it would be fun to write an FFT example using my OpenLPC dev board. It works wonderfully!

I apologize for the video of a computer monitor, the screen capture software didn’t run well when trying to refresh the terminal that quickly.

The example code is actually fairly simple seeing as the heavy lifting is done by the pre-complied library. I turn on and set up the on-chip analog to digital converter and then take 1024 samples storing them in SRAM. There are no imaginary samples so I just store 0 every other sample. The array is then sent as an argument to the Fast Fourier Transform function along with a separate pointer to another location in SRAM on the LPC1769 where the results are stored. The magnitude is then calculated and scaled for printing to the terminal. Because I am using a higher resolution FFT I just print a few of the frequency bins (in the video I print 74) so that it will fit on my screen. My current code doesn’t use interrupts and so the sampling frequency depends on the execution time to store the ADC results in  SRAM along with some logic operations and the 65 clock cycles for the actual conversion. When it is all set and done I repeat the process at 20Hz.

The hardware setup was very simple. An arbitrary signal comes from my function generator centered at 1.5V and fed through an RC low pass filter with a cutoff frequency at ~70KHz for anti-aliasing. This is roughly around the Nyquist frequency of the ADC as I am sampling at around 160KSPS. For practical applications this wouldn’t work well and would allow a lot of signals to alias into the sampled signal, however it takes the edge off of what I was working with.

In all it took a couple hours to get everything set up and running correctly. I will clean up my code and use interrupts in the future to get a more predictable sampling frequency. For now my code is available on my GitHub repository.


LPC Bootloader Auto-Baud

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.

Connected to the bootloader.

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.

A Cheap Breadboard-able ARM Chip

LPC1114 Breakout
LPCXpresso Development Kit

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.

Top Layer
Top Layer

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.

Bottom Layer
Bottom Layer

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!