Getting Started - TinyOS-2.0.2 (T2)

An Account on Omega.CS.Berkeley.EDU

To use the Motescope or Omega Testbed, you will need to have an EECS named account. If you do not have an EECS named account, you can request an account here. (UCB affiliates only.)

Testbed Directories

We have provided a very basic set of files, scripts, and binaries to help you use the Motescope Testbed.
/export/smote/testbed/  -  The root directory.
/export/smote/testbed/config/  -  Examples of testbed config files can be found here.
/export/smote/testbed/senvironment/  -  Files to help assign environment variables.
/export/smote/testbed/tools/  -  Scripts (wrappers) and binaries.

Environment Variables

Prior to using any version of TinyOS, you should make sure that all the appropriate environment variables are set. You can login to Omega.CS.Berkeley.EDU, and find the senvironment file that matches the version you are using.

% source /export/smote/testbed/senvironment/senvironment-2.0.2

This will set the most basic variables for TinyOS-2.0.2:

# TinyOS' Main Directory (primarily used when TinyOS is installed at an alternate location)

# Source Tree (includes docs, source, tools)
export TOSROOT=${TOS_INSTALL_PREFIX}/opt/tinyos-2.x

# Source Code
export TOSDIR=${TOSROOT}/tos

export CLASSPATH=${TOSROOT}/support/sdk/java:${CLASSPATH}
export MAKERULES=${TOSROOT}/support/make/Makerules

# If you are using msp, add the paths to the msp430 directory
export PATH=/export/smote/software/msp430-telosb/bin:${PATH} export PATH=$PATH:{TOS_INSTALL_PREFIX}/opt/msp430/bin

# Add paths to the avr bin directory
export PATH=$PATH:${TOS_INSTALL_PREFIX}/usr/bin:${TOS_INSTALL_PREFIX}/usr/avr/bin

# Extend the path for java
type java >/dev/null 2>/dev/null || PATH=`/usr/local/bin/locate-jre --java`:$PATH
type javac >/dev/null 2>/dev/null || PATH=`/usr/local/bin/locate-jre --javac`:$PATH
echo $PATH | grep -q /usr/local/bin || PATH=/usr/local/bin:$PATH

# Environment variables needed by the wrappers for the testbeds
export TESTBED=/export/smote/testbed/
export TBHOME=$TESTBED/tools/
export PATH=$TBHOME/bin:$PATH
export RSCPATH=$TBHOME/rsc-t2

Next, check to see if the TinyOS build system is enabled:

% printenv MAKERULES

It should have returned a path to a file called Makerules. If not, you will need to make sure that the MAKERULES variable is set properly.

Generally, you would have to specify each mote you use on a separate command line. However, if you use the wrappers available to you to run your program, you can point the environment variable $TOS_TESTBED_CONFIG to the file that specifies the motes you wish to use. In the directory /export/smote/testbed/config/omega/, we have a few preconfigured sets of motes based on geographic location from within the building.

The format is mote <moteid> <mote name>

% export TOS_TESTBED_CONFIG=/export/smote/testbed/config/omega/420.cfg
mote 0 UCC7YDD8
mote 1 UCC7Y9HG
mote 2 UCC7Y9EY
mote 3 UCC7Y9F2
mote 4 UCC7Y9FL
mote 5 UCC7Y9FD
mote 6 UCC7Y9HK
mote 7 UCC7Y9N4
mote 8 UCC7YDDC
mote 9 UCC7Y9HD
A complete list of motes and maps can be found here.


You should now be able to compile a program.

% cd MyApplicationDirectory  -  cd into your application's directory
% make telosb  -  Issue a 'make' followed by the type of hardware you have (micaz, mica2, telosb, etc.)
% make telosb sim  -  Add the sim option for a simulation

You should see a similar output from your compile.

% cd Bling
% make telosb
mkdir -p build/telosb
        compiling BlinkAppC to a telosb binary
ncc -o build/telosb/main.exe -Os -O -mdisable-hwmul -Wall -Wshadow -DDEF_TOS_AM_GROUP=0x7d -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -DIDENT_PROGRAM_NAME=\"BlinkAppC\" -DIDENT_USER_ID=\"goto\" -DIDENT_HOSTNAME=\"smote\" -DIDENT_USER_HASH=0xb9611962L -DIDENT_UNIX_TIME=0x477b5ec8L -DIDENT_UID_HASH=0x9c402039L -lm
        compiled BlinkAppC to build/telosb/main.exe
                2654 bytes in ROM
                    55 bytes in RAM
msp430-objcopy --output-target=ihex build/telosb/main.exe build/telosb/main.ihex
        writing TOS image


NOTE: Currently, there is no formal system or mechanism to create a reservation. To ensure your experiment is not interrupted, it is advised that you email the mailing-list to informally reserve motes.

cd into the directory called "build." It should have been created when you compiled your program. If you compiled your code on a different computer, simply make a tarball of the "build" directory and transfer it to Omega.CS.Berkeley.EDU.

There are wrappers available to help get your compiled program onto the mote and the data off of the mote. Below is a simple example of how to get a program onto a mote and retreiving the data from it.

Make sure you are your testbed config file has been defined.

Verify that the correct set of motes are being specified.
% cat my_tos_testbed_config_file.cfg
mote 1 UCC7Y9HQ
mote 1 UCC7Y9OO

cd into the application's directory and compile the program.
% cd Bling
% make telosb
Erase any program that may already reside on the motes using the wrapper
%  --motes=$TOS_TESTBED_CONFIG  --erase
2 UCC7Y900
Programming 2 motes.

Download your compiled program (from the build directory) onto the mote using the same wrapper.

You may see the following error messages during erasing or downloading ...

Uploading TinyOS app Could not find symbol TOS_LOCAL_ADDRESS in build/telosb/main.exe, ignoring symbol.
Could not find symbol TOS_LOCAL_ADDRESS in build/telosb/main.exe, ignoring symbol.
Could not find symbol TOS_LOCAL_ADDRESS in build/telosb/main.exe, ignoring symbol.
This is an acceptable error. It simply means that a particular variable is not used
in the application. When the installer tries to resolve the symbol, it can't find it
and ends up spitting out that error (so nothing to worry about).
Thanks Arsalan for this explanation

ERROR: exited with code 256
       msp430-bsl -c --telosb -r -e -I -p build/telosb/main.ihex.22
.ERROR: exited with code 256
       msp430-bsl -c /dev/ttyUSB17 --telosb -r -e -I -p build/telosb/main.ihex.12
If you get this error, it means those nodes are not working currently, and you cannot download your
program onto them. This is a problem with the USB driver. Generally, when I get this problem, I have to
either restart omega or pull out the usb cable and plug it back in, or do both if the problem still exists.
Thanks Arsalan for this explanation

Conducting some tests, another reason for this particular message may be connected to a timing
issue with the wrapper. Re-issuing the command over and over again will return
different results each time. It is true that some of the motes are disabled and need to be re-seated,
but others will respond on subsequent attempts. Many motes that replied with an ERROR message
will respond if the msp430-bsl command is issued on the command line.

Another error message besides ERROR is FAILED. Based on observation, the motes that returned a
FAILED message took two to three times longer to respond (with a success) than other motes.
Increasing the timeout time in the wrapper may remedy the problem.

Another thing I noticed during my tests was how the motes would load in groups. I'm pretty sure
the distribution/groupings were closly related to the topology of the hubs in the ceiling.

  This material is based upon work supported by the National Science Foundation under grants #0435454 and #0454432, and the NSF Graduate Research Fellowship Program. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.