Wireless Module Prototype


This is a random idea I had a few months ago. I wanted a small cheap wireless module that could be setup as a mesh network of sensors. This of course could be describing XBees, but I wanted something of my own. My implementation uses the RFM12B wireless module which costs around 6$ in single quantities. An ATtiny84 microcontroller on back will do all of the processing over SPI.


Prototype partially assembled.

My prototype board is partially assembled. I am missing some 0603 resistors needed to connect the SPI lines on the wireless module to the MCU. I also reminded myself how painful it is to try and solder SMT parts without the proper equipment. I am a fan of solder paste and a cheap reflow oven. If those aren’t available a regular soldering iron works as long as there is plenty of flux. With plenty of flux soldering 0402 isn’t even a problem! Unfortunately my flux was nowhere to be found. I’m saving my second prototype board for when I have some solder paste and can compare the two boards.

In terms of the idea behind the board, I plan on writing my own software to communicate between nodes on a wireless mesh network. There are two outputs/inputs on each node. This means I could easily attach 1-wire or analog sensors to the board, toggle a switch, send IR commands, etc.

The next revision of the board will be smaller, hopefully matching the dimensions of the wireless module. It will also include a coin cell battery holder.

More to come when I get the parts I need and I start on the software.


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!