Archive for August, 2009

My quickie guide for setting up mspgcc for ez430-cc2500

Mostly for my own reference for the next time I have to set it up on a new machine, but may help others on their first time install. Valid as of Feb. or so this year.

Software ‘shopping’ list (all free/OSS tools)
Set up the toolchain (mspgcc). There seem to be several important tools
missing from the mspgcc distro as of this writing, including ‘make’ and
msp430-insight (graphical debugger) that the docs claim are included
with the package. So the complete shopping list is:

NOTE: This binary IIRC was not linked on Sourceforge’s downloads page at the time; there was only an older build and this link had to be fished from semi-private newsgroup postings. If there is a newer binary available, download that one.

MinGW/msys (provides ‘make’ and some utilities) :
If it gives you the options of installing minGW and msys, say YES to both.

CoreUtils (provides unix-like ‘rm’ tool required by make) :

Skipping the debugger for now until I figure out how to use it myself ;-) Seems to work occasionally under win32, but it’s flaky.

Required Knowledge Assuming you already know C and have the appropriate chip documentation/datasheets.
Have a quick read-through of the mspgcc FAQ and manual. Both are
reasonably short for what they are.

The manual contains a lot of advanced stuff you can skip at first, or
skip entirely. This includes (at minimum) the stuff about customizing
the startup/end procedures, stack, the entire ABI section, inline
assembly, and stuff about building mspgcc (the package you get is
already built).

Get familiar with ‘make’. Outside of kinky application-specific tools
like the Microchip assembler/compiler and ‘IAR Kickstart’, the rest of
the free world uses make to automate compiling, linking,
installing/running and packaging their code. Go into the mspgcc
‘examples’ folder and find the blinking LEDs example (e.g.
E:\mspgcc\examples\leds). Open up the file called Makefile in Wordpad
and have a look inside. This is the master script that will smartly
handle all your compiling, programming the chip, and avoid you rewriting
lots of code whenever you change chips. The contents will probably look
like gibberish, there are only a few parts that are important for our
purposes. The make tool installed by mingw32 is named ‘mingw32-make’.

How make works is you specify one or more ‘targets’, i.e. things make
can do. Running make with no target specified compiles your program.
Some other targets are ‘mingw32-make clean’ (delete your old build and
any scratch files), or ‘mingw32-make download’ (compiles your program,
downloads it to the chip and runs it). All the necessary commands to
handle each target are in the Makefile.

Since the top half of the ez430 kit is essentially the USB Sy-Bi-Wire programmer, you have to change the download command to:

msp430-jtag –spy-bi-wire -lpt=USBFET -e leds.elf

I.e. in the Makefile you’d find and change the download section to:

download-jtag: all
msp430-jtag –spy-bi-wire -lpt=USBFET -e ${NAME}.elf

As long as you have the Makefile open, now is a good time to find the
CPU= line and change it to match the msp430 variant you are actually
using. In the case of the eZ430 board:
CPU = msp430x2274

Now when you #include the base generic as you will for most any
mspgcc project, it will automatically switch in the correct headers and
peripheral support for that specific CPU.

DIY-Spy: a homebrew 2.4GHz wi-fi spectrum analyzer

I was reading the Thinkgeek catalog a while back and an interesting gadget caught my eye: “Wi-Spy”, a 2.4GHz spectrum analyzer on a USB stick. Coming from the world where “spectrum analyzer” refers to a big benchtop box with a name like Le Croyright, we can’t afford those Agilent on it, my first thought was, “A good spectrum analyzer in the GHz range is like a gazillion bucks; what’s really inside this thing?”

Not much, it turns out. After seeing the guts I would not use this device for anything remotely demanding accuracy, but on the bright side, it would be pretty straightforward to make your own that works just as well! Possibly with parts that are already on your board (*cough*XBee).

According to this review and a couple other tech sites, the innards of the original are nothing more than a Cypress WirelessUSB SoC (CYWUSB6934) and USB interface. According to this updated review, the latest version switches to TI/Chipcon’s CC2500 radio ($2.15 USD in quantity) and retails for $399.

The “WirelessUSB” and CC2500 radios are inexpensive 2.4GHz radio chips used in devices such as cordless mice, game controllers and remote controls. What it has in common with many other digital radios is an RSSI (Received Signal Strength Indication) register, which can be read out to provide a measure of how much signal (i.e. interference) is present on any given channel. Wireless gadgets normally use such a mechanism to find the cleanest channel to broadcast on. Most any radio chip with an RSSI readout should work here: XBee, TI/Chipcon’s CC25xx parts, Nordic, etc. I have a big nut going right now for Nordic’s nRF24L01, but unfortunately this does not have an RSSI measurement to speak of (there is a 1-bit “collision detect” flag that warns if the RF energy on the current channel is above a set threshold).

So essentially, the firmware running on the dongle consists of:

for (channel=0; channel<255; channel++)
WriteReg(RF_CHANNEL, channel);

Hell, why didn’t I think of selling $2 of chip and 4 lines of code for $400? ;-) (I’ve even used those old Cypress radios before on a work project – Unigen’s ready-made JUNO module shown here is about 7 bucks.)

The DIY-Spy

As proof of concept (and a cool toy for anyone who has one of these lying around), I have implemented a working Wi-Fi spectrum analyzer on TI’s ez430-RF2500 development kit ($50), a 2-part USB dongle which consists essentially of a CC2500 radio strapped to an MSP430 low-power microcontroller (detachable bottom half) and a USB interface which enumerates as a virtual serial port (top half). The top half doubles as a standalone MSP430 programmer, so this kit is a great cheap way to get started playing with them.

Being the lazy efficient person that I am, I grabbed mspgcc and an existing ez430 RF demo program (JM Kikori’s RF2500 test application – raw transceiver) and just tossed the infinite RSSI loop into the middle of it.

Here is the main addition (simple & sweet). Forgive WordPress’ complete mangling of the formatting.

static void dump_rssi()
int i;
char rssi;
for(i=0; i<256; i++)
hal_spi_radio_writeReg( MRFI_CC2500_SPI_REG_CHANNR, i); // Channel number. Default spacing is ~200KHz/channel
hal_spi_radio_cmdStrobe( 0x34 ); // enter Rx mode (not needed except to start autocal)
rssi = (hal_spi_radio_readReg(MRFI_CC2500_SPI_REG_RSSI));
uart0_polled_putc((rssi&0xFE) | (i==0)); // Cheap speed hack: write upper 7 bits of RSSI value (throw away LSB). Use LSB to signal start of 256-channel RSSI byte list
hal_spi_radio_cmdStrobe( 0x36 ); // enter IDLE mode (not needed except for autocal)

The only real divergence of this from the pseudocode loop above is that the CC2500 requires periodic (or frequent, depending who you ask) recalibration, which can be set to be performed automatically on certain conditions (such as entering Rx mode). This setting is enabled, and the code above toggles between Rx and Idle modes between each channel change to trigger auto-calibration. To make things faster (for me as well as the gadget ;-), rather than perform any kind of real serial handshaking to keep the dongle and the graphing script in sync, I just truncate the least significant bit of the RSSI reading (1/2dBm) and use it to flag the start of the 256-channel sweep.

A more efficient approach would be to perform such calibration once per channel and cache the results (writing them back along with each channel change), which would in theory allow for much faster channel changes. But it’s really a moot point since here the 9600-baud connection to the virtual COM port (MSP430 <–> USB controller) is the limiter of maximum speed.

Most of the time in this project went into tweaking around with the CC2500’s fifty billion or so configuration register bits, not all of which are really documented. In the end I just installed their win32 configuration wizard for the undocumented voodoo (e.g. correct IF setting) and annoying math, and hand-tweaked the remaining settings. For this I set the base frequency to 2400MHz, and the channel spacing to ~ 405KHz, providing the frequency range 2400MHz to 2505MHz across the 256 channel settings. This corresponds to the 2.4GHz ISM band and a little extra. All automatic gain control features are disabled.

I’ve actually been sitting on this project now for a couple months, since I wasn’t getting the results I expected initially (sitting close to my WiFi access point) and had no good way to test it. Luckily, as it turns out I was tasked with developing some RF gadgets (nRF24L01-based) at work, which could easily be set up to output a raw carrier wave at a programmable frequency. Sure enough, testing revealed some bugs in my initial CC2500 register settings, now corrected.

The video above shows the resulting spectrum output as the nRF’s naked carrier is swept through a handful of frequencies. As it progresses, it should also become evident where my WiFi access point is broadcasting. The green lines show instantaneous signal, the red shows the peak value at each frequency, and the blue shows a running average. The display script is written in Processing.


Fairly undocumented; use at your own risk. – Source code and .elf binary for ez430 kit (use mspgcc to build from source), .inf file for virtual COM port (win32 only), and Processing script for display.