Sunday, February 21, 2010

XML of SmartRF Studio 7

by Travis Goodspeed <travis at radiantmachines.com>
concerning TI SmartRF Studio 7.

For those who have not personally suffered the experience, choosing radio register values is an absolute pain. In this brief article, I will demonstrate a method for extracting settings in bulk from SmartRF 7 Studio for use in other projects.

Suppose that a program should configure a CC1110 to operate on a particular frequency, in a particular encoding, etc. The code will like the following, which is from the CC1110 examples. This will generate a carrier wave near 823 MHz, as the 2.433GHz FREQ[] value is outside of the allowed range.

Chipcon Settings

To choose a different center frequency, the engineer is expected to either find the register's definition within the datasheet or use SmartRF Studio, a screenshot of which is below. The software is a Windows application for communicating with a radio through a serial port. It also allows an engineer to load preconfigured profiles for certain types of modulation, such as IEEE 802.15.4 or SimpliciTI. Once loaded, the settings may be tweaked and loaded into a packet-sniffer firmware for debugging projects.

Chipcon Range Limits

The screenshot above, from SmartRF 6, can provide a decent idea of how infuriating the software might become. For product development, the register settings are to be copied and pasted into opaque source files. It can instill the same sort of anger as an uncooperative web form, even after the old Visual Studio 6 libraries have been located to make it work under Wine.

SmartRF 7--at Beta 0.9.1 as of this writing--is a new client under active development, one which seems to have been rewritten from scratch or at least significantly refactored. The old Win32 GUI has been replaced with QT4, making a future Linux or Mac port possible. Most importantly of all, however, is that the default configurations, as well as register explanations, are stored as XML.

SmartRF 7

The screenshot above shows how default configurations are chosen for the target radio. Users can select an example, then change any of the settings they like. These configurations are further abstracted into an "Easy Mode" which hides all the messy minutia of radio, abstracting use to standards and channel numbers.

These configuration settings are to be found as XML in the config/xml/ directory, organized by chip and presentation. The following is an example of one such configuration file for the CC1110.
SmartRF 7 XML

Patching these configurations allows for the easy addition of new standards. For example, I added support for my Tennessee Belt Buckle radio by adding a new stanza to easymode_settings.xml.
SmartRF Belt Buckle

The register definitions and their bitfields are also defined in XML. The following from register_definition.xml for the CC1110 described the FREQ2 register's meaning.
SmartRF 7 XML Register Def

Printing SDCC special-function register definitions, such as those found in cc1110.h, is as easy as a bit of Python magic,

#!/usr/bin/python

# Simple script for dumping Chipcon register definitions to SDCC header.
# Only intended as a rough example.
# by Travis Goodspeed, Engineer of Superior Belt Buckles

import xml.dom.minidom
def get_dom(chip="cc1110",doc="register_definition.xml"):
fn="/opt/smartrf7/config/xml/%s/%s" % (chip,doc);
return xml.dom.minidom.parse(fn)

dom=get_dom();

for e in dom.getElementsByTagName("registerdefinition"):
for f in e.childNodes:
if f.localName=="DeviceName":
print "// %s=%s" % (f.localName,f.childNodes[0].nodeValue);
elif f.localName=="Register":
name="unknownreg";
address="0xdead";
description="";
for g in f.childNodes:
if g.localName=="Name":
name=g.childNodes[0].nodeValue;
elif g.localName=="Address":
address=g.childNodes[0].nodeValue;
elif g.localName=="Description":
if g.childNodes:
description=g.childNodes[0].nodeValue;
print "SFRX(%10s, %s); /* %50s */" % (name,address, description);


These configuration files should allow for new Chipcon radio applications and development tools to be written in short order. Please contact me if you would be so kind as to write a complete Python class for querying this data.

Friday, February 5, 2010

Call for Info Flash

by Travis Goodspeed <travis at radiantmachines.com>
continuing a discussion of MSP430 Info Flash

Neighborly MSP430 developers, please do me a favor and email me the contents of memory from 0x1000 to 0x1100 of every MSP430F2xx device that you can. I'm trying to reverse engineer the exact distributions of the CALBC1_16MHZ and CALDCO_16MHZ values in order to build a UART library that operates without Info Flash. The GoodFET does this well enough, but I still get the occasional bug report when a device is slightly out of range. I can reduce the default to baud rate or try similar tricks to get around this, but I want to know exactly which values are safe.

If your GoodFET can be programmed by goodfet.bsl but does not respond after programming, try the info flash images available in /contrib/infos/ to see if any of them work.
air% goodfet.bsl -e -p 2618-002.txt;\
goodfet.bsl -p ../../trunk/firmware/goodfet.hex
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Mass Erase...
Transmit default password ...
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Program ...
256 bytes programmed.
MSP430 Bootstrap Loader Version: 1.39-goodfet-8
Invoking BSL...
Transmit default password ...
Current bootstrap loader version: 2.13 (Device ID: f26f)
Program ...
10596 bytes programmed.
air% goodfet.monitor peek 1000 100A
1000 55aa
1002 3fff
1004 abcd
1006 55aa
1008 1234
air%


Previously programmed GoodFETs have info flash wiped during programming, but if yours has never been programmed, you can dump the info with
goodfet.bsl --dumpinfo >info.txt