The importance of brown-out detection

The batteries expired in one of the AuroraWatchNet test magnetometers this week. I was expecting that to happen since the magnetometer wasn't operating in its low-power mode and the battery voltage from the two 1.5V alkaline cells had been hovering around 2V for some time. The Atmel ATmega1284P microcontroller is actually powered at 3.3V using a boost power supply. What I didn't expect was for the system to not start after replacing the battery. I could tell xboot was working since the LED flashed 3 times as usual after the reset button was pressed. After that the LED stayed on but nothing else happened, not even the start-up debug messages from the serial port. I guessed the flash program memory had somehow got corrupted.

I used the AVR Dragon to extract the contents of the flash memory (avrdude -P usb -c dragon_jtag -p atmega1284p -U flash:r:flash.img:r) and compared it against the saved raw image file using the linux split and cmp commands. Sure enough, three pages of flash memory were set to 0xFF, probably from some erroneous page clear operation. Brown-out detection was disabled by the fuse settings to save power. Big mistake! What I think happened was as the voltage dipped below its valid range the microcontroller started executing random commands, including 3 SPM page clears, one of which was the first page of flash which holds the interrupt vector table. Valid execution was doomed.

What I should have done was to enable brown-out detection in the fuses, 2.7V seems the most appropriate setting for an 8MHz clock and 3.3V operation. To save power during sleeping the brown-out detection can be disabled with a call to sleep_bod_disable(). Lesson learned!

Calunium: version 2.1

Calunium v2.1.
Click on the image for an annotated version.

This upgrade to Calunium v2 provides several minor improvements. There is the option to fit a Microchip MCP220 UART-USB converter instead of the FTDI connector. For development purposes the MCP2200 is much more convenient than an external FTDI cable or adaptor; operation at both 3.3V and 5V is supported. For low-power battery operation the MCP2200 uses too much power so the FTDI connector option has been retained.

I find I operate Calunium almost exclusively at 3.3V. I've not been able to find any real-time clocks in a dual-in-line package that operate at 3.3V and feature battery-backup. Suitable clocks are supplied in a SOIC or smaller package. I have therefore removed the DIP footprint option for the real-time clock. The space saved has allowed me to add optional load capacitors for the crystal so that a MicroChip MCP7941x real-time clock can be used. This clock has several benefits over the popular DS1307 (or its 3.3V equivalent, the DS1338). It is cheaper, it can compensate for crystal frequency errors, it has EEPROM storage, two alarms and it also has a unique identifier. This change goes against one of the original aims of Calunium, to use through-hole components to keep it accessible to the widest possible audience. However, considering the other interesting on-board peripherals (micro-SD socket, RFM12B and MCP2200) require surface-mount soldering skills I thought this a reasonable compromise to make. The original through-hole only designs are still available for those who really do not want to use any surface-mount components.

The final improvement is that the SPI clock signal is now routed with a ground plane between it and the real-time clock crystal.

For the full list of features please see the original Calunium v2 blog post.

Calunium v2 (top) and v2.1 (bottom) PCBs.
Click on the image for an annotated version.

RFM12B shield for Raspberry Pi

RFM12B shield for Raspberry Pi, with integrated in-circuit serial programmer.
Click on the image for an annotated version. 

I recently described the preliminary design of a RFM12B shield for the Raspberry Pi, which used an Atmel ATmega328 to interface between the Raspberry Pi's UART and the RFM12B's SPI interface. The design also included a buffered two-channel in-circuit serial programmer (ISP) using the Raspberry Pi's general purpose I/O. The first channel is for programming the on-board ATmega328 whilst the second channel can program external microcontrollers.

The boards have now been manufactured and the first one assembled and tested. The interface to the RFM12B and the built-in AVR ISP programmer both work as designed. I have been using the Arduino environment to compile and upload the firmware to the ATmega328. The microcontroller pin mapping is identical to the Arduino Uno although the activity LED is wired to D9 since D13 is normally in use by the SPI interface. The ATmega328 operates at 3.3V and is clocked by the internal 8MHz RC oscillator. No bootloader is needed. The Github repository contains boards.txt and programmers.txt files for use with the Arduino IDE, the standard Arduino core is used.

I have been using the first board to replace a Ciseco URF radio module. The firmware for the ATmega328 incorporates my transparent serial emulation layer. This provides a Stream object to which data can be read, and written (or printed), in just the same way as HardwareSerial and SoftwareSerial objects. The same emulation layer can then be used on remote Calunium, Arduino or JeeNode boards to provide a bi-directional data stream, allowing the user to interface to the RFM12B as easily as an XRF or XBee radio module. The emulation layer transparently uses acknowledgements and retries to provide a robust channel, which is an improvement over the Ciseco XRF and URF radio modules. Alternative firmware for the RFM12B shield is easily uploaded to provide different functionality.

ISP programmer

The avrdude configuration file contains details for two GPIO programmers; gpio0 is connected to the on-board ATmega328 and gpio1 is for programming external microcontrollers. By fitting a jumper to the JP1 header the external microcontroller can be powered from the Raspberry Pi's 3.3V supply. Be sure to observe the maximum current rating for the 3.3V supply and never fit the jumper if the remote microcontroller is self-powered. The 74LVC244 buffer ensures that MCUs operating at 5V can be safely connected. Typically the high output level from the 74LVC244 buffer will be recognised as a high but it doesn't meet the worst-case specifications when the external MCU is powered from 5V.

Open source

The Eagle PCB design files for the RFM12B/ISP shield for Raspberry Pi are available on Github and are licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. The RF12 transparent serial emulation layer is also available on Github and is released under the MIT license.

Errata

There is a connection missing on the schematic from the drain of FET Q2 to pin 5 (/RESET) on the external ISP header (X3). This connection is also missing from the PCB but can be easily fixed with a direct wire connection on the underside of the board.

Update

I've added a description of how to install and use the patched version of avrdude, http://blog.stevemarple.co.uk/2013/03/how-to-use-gpio-version-of-avrdude-on.html.