From BTnodes - A Distributed Environment for Prototyping Ad Hoc Networks

Documentation: TipsAndTricks

This page is editable for everyone, just click 'Edit' on top of this page and use the password spamprotection

BTnode Community Tips and Tricks

Here we want to establish a forum for the BTnode community to share information about support, projects and "nifty" things that everyone encounters on a daily basis or more serious hacks and bugfixes to keep the community happy. Enjoy.

If you want to add your own data, you can press the edit button on the top.

BTnode Rev3 Bluetooth Remote Programming

As the BTnut Rev3 contains enough SRAM to store a new firmware image, it can be reprogram itself. For this, the bootloader needs to be installed on the BTnode and the new firmware image need to be stored in the hidden SRAM pages. The BTnut system already provides this as an optional service to any BTnut app which makes use of Bluetooth. See the app/bt-reprog example in the BTnut distribution.

So far, we only provide a Java implementation to upload a new firmware image for the host pc.

Small tutorial:

After that you can upload a new firmware to the BTnode via Bluetooth. The tools help page is available: remoteprogrammer.RemoteProgrammer --help

Note: The size of the data packet used by the Java tool need to fit into the max L2CAP packets defined on L2CAP initialzation. If in doubt start with small packets (e.g. 40 bytes :)

Bluetooth and Java

We mostly use Java to communicate with the BTnodes. For this, you need a JSR-82 implementation for you OS.

We can recommend avetanaBT for Mac OS X, Windows and Linux. Note: The linux version is free, were as the Mac and the Windows versions are sold for a moderate fee (about 25 Euro) by avetana-GmbH at but a 14-days evaluation.

On Windows, you could also try out the bluecove implementation at, but it does only support RFCOMM. From an engineering point of the view, the lower layer L2CAP is better suited to communicate with the BTnodes as you probably are interested in sending data in packets to the PC.

Large Code will not run on small, harmless Source Code Changes

On larger code (>120 KB, without bootloader) it happens sometimes (small unrelated changes in sources) that the code will not start/run anymore. This is because of the Reset Vector, which is set to the bootloader section (0x1fe00) and will jump under certain circumstances (which ones??) to this address. Set the high fuse from 0x00 to 0x01 (BOOTRST=1), and magically your application will run again...

AVR Factory Settings

Fresh Atmel AVR processors come with an internal clock source configured. This requires a somewhat reduced ISP clock frequency. On fresh ATmega128 230 kHz seeems to work ok although it is probably safer to use 57 kHz (the next lower frequency).

AVRISP MK2 6-pin Adapter Cables

The new AVRISP mkII programmers need an adapter cable to fit into the usbprog rev 2 boards:

ISP 10-pin HeaderISP 6-pin Socket

Note: New AVRISP mkII are configure with a very high SCK paramter which results in very slow programming. To change the SCK, enter terminal: avrdude -p m128 -c avrispmkII -P usb -t, and change it with sck 3 (SCK of 4 us instead of preconfigure 953 us).

Serial Consoles at D-ITET/ETHZ

The lab for embedded systems running on the tardis-b* machines uses minicom as serial terminal program. To operate correctly the correct port needs to be specified as an argument:

minicom usb0 selects the config file for USB port 0 57600 8N1 found in /usr/pack/minicom-2.1-rs/etc-linux.

The minicom configuration can be reached by CTRL-A O.

BTnodes Breaking

Although generally a robust platform, BTnodes can break. Apart from mechanical destruction (most likely your own fault), electrostatic discharge (ESD) and wrongful operation can harm your BTnodes. Here are my favorite tips to keep you happy:

To verify the ISP programming frequency without AVR Studio, you can start avrdude in the terminal mode (e.g. avrdude -p m128 -c stk500v2 -P /dev/tty.usbserial -t) and there issued the parms command to get the current oscillator setting. To set it to a about 1.23 MHz you have to enter: fosc 1000000. Verify again using parms.

BURN = avrdude

BURNPORT = /dev/ttyS0

BURNFLAGS = -pm128 -cavrispv2 -P$(BURNPORT) -s

Alternatively you can use uisp with the settings:

BURNFLAGS = -dprog=stk500 -dpart=atmega128 -dserial=$(BURNPORT) \\ --wr_fuse_e=0xFF --wr_fuse_h=0x00 --wr_fuse_l=0xBF

If you are still unsure about certain things, read up in the extensively available documentation before harming your precious hardware.

BTnode rev3.20 and rev3.22 ISP Programming Failures

The BTnode rev3.20 and rev3.22 suffer from a hardware bug that can impact the ISP programming. This bug shows in cases when the CC1000 power is off during ISP programming. In the worst case, your Atmega128 will not enter programming mode any more (due to wrong CKOPT and CKSEL* fuse bit setttings). In order to avoid this from happening we suggest to use avrdude (instead of uisp) for ISP programming that checks the correct fuse bit settings before exiting programming mode and resetting with wrongful fuse bit settings. Furthermore a series resistor in the SCK line between the CC1000 and the ATmega128 helps to prevent wrongful programming from happening. This series resistor can be manually patched unter the SCK pin (5th from the left).

To remedy the situation you can apply an external clock to the 7.3728 MHz cyrstal and then reset the fuse bits manually using an ISP programmer or JTAG pod.

AVR-ISP Firmware 1.x <-> 2.x

Starting from AVR-STUDIO 4.11, a newer firmware version is installed by Avr-Studio which is not well supported in avrdude/uisp (at least it's damn slow for me (MR)). AVR-STDIO 4.10 can downgrade the AVR-ISP BOX to firmware 1.15 which works well. To perform a firmware downgrade using Windows, a USB Prog Board and a BTnode, either install the AVR-STUDIO 4.10 or just use the relevant STK500 firmware 1.18 installer. Then, power off the ISP (disconnect the BTnode), connect the two holes close to the left edge opposite to the RS232 connector. Power on the ISP (plug the USB Prog Board into the BTnode). Then start the upgrade tool: "STK500/upgrade.exe". DONE

Windows COM ports

If you want to use COM ports higher than COM9 then you have to prefix the port with //./ (e.g. //./COM10). This format is actually the correct one and also works for COM1-COM9. However, if you don't like the high port numbers you can also change (with admin rights) the assigned port number in: Device Manager->Ports->COMx->Properties->Port Settings->Advanced.

USB programming board on Windows

If you want to attach more than one USB programming board to your machine, they need to use the same USB port. This means you need to have a USB hub. This is a problem with the driver, if you check the Device Manager, you will get an error message like the following:

Windows cannot load the device driver for this hardware because there is a
duplicate device already running in the system. (Code 42)

USB programming board on Linux

Silabs does not provide drivers on their website for their USB-Serial Bridge CP2101 that we used for the USB Programming board. Together with your USB Programming Board you should also get working Mac OS X and Windows XP drivers. The provided linux binary drivers do work on some Linux systems but certainly not on all. Luckily, some brave people went out and took the trouble of reverse-engineering the used protocol.

Linux Kernels 2.6.12 and higher contain a working CP2101 module. Read more on the availability for 2.4 Kernels. The serial port will be available as /dev/ttyUSB0 and so forth.

Linux Kernels of the 2.6.x series older than 2.6.12 don't contain the module, but it's possible to add it without recompiling the whole kernel. You need the source code of the currently running kernel and also the source code of a newer kernel that contains the CP2101 module. Copy the file drivers/usb/serial/cp2101.c into the currently running kernel's source tree. Modify the Makefile in the drivers/usb/serial directory by adding the line obj-m += cp2101.o. Switch to the root directory of the kernel sources, and verify that a .config file is there. If not, you may find it at /boot. Build the module with make drivers/usb/serial/cp2101.ko, copy it to /lib/modules/`uname -r`/kernel/drivers/usb/serial and run depmod.

CVS Checkout of the BTnut System Software

cvs login
cvs -z3 co -P btnut

Checkout the Nut/OS (aka Ethernut) project:

cvs login
cvs -z3 co -P nut

Both project ('nut' and 'btnut') has to be on the same directory level! For developer CVS access have a look at

Go into 'btnut' directory:

cd btnut

edit file 'Makedefs' and adapt 'BURNPORT' (e.g. 'BURNPORT = /dev/ttyUSB0')

Make libraries of BTnut (Makedefs assumes Nut/OS with 'NUTDIR' in '../nut'):


If there are no errors, where are now ready to compile and flash BTnode-applications...

Detailed AVR Toolchain Installation Instructions

This this webpage explains how to install the GNU AVR toolchain and is a modified version of

The default behaviour for most of these tools is to install everything under the /usr/local directory. In order to keep the AVR tools separate from the rest of your system, we recommend you install everything into /usr/local/avr. If the /usr/local/avr directory does not exist, you should create it before trying to install anything. You will need root access to install there. If you don't have root access to the system, you can alternatively install in your home directory, for example, in $HOME/local/avr. Where you install is a completely arbitrary decision, but should be consistent for all the tools.

You specify the installation directory by using the --prefix=dir option with the configure script. It is important to install all the AVR tools in the same directory or some of the tools will not work correctly. To ensure consistency and simplify the discussion, we will use $PREFIX to refer to whatever directory you wish to install in. You can set this as an environment variable if you wish:

export PREFIX

For csh-type shells, use

setenv PREFIX $HOME/local/avr

Be sure that you have your PATH environment variable set to search the directory you install everything in before you start installing anything. For example, if you use --prefix=$PREFIX, you must have $PREFIX/bin in your exported PATH:

export PATH

Warning: Make sure that either the environment variable CC is set to gcc, or that running cc results in an execution of the newly compiled gcc.

Note: The versions for the packages listed below are known to work together. If you mix and match different versions, you may have problems. You can download the recommended version by clicking on the package name, or search for alternative versions following the link under the package name.

GNU Binutils for the AVR target

The binutils package provides all the low-level utilities needed in building and manipulating object files. Once installed, your environment will have an AVR assembler (avr-as), linker (avr-ld), and librarian (avr-ar and avr-ranlib). In addition, you get tools which extract data from object files (avr-objcopy), dissassemble object file information (avr-objdump), and strip information from object files (avr-strip). Before we can build the C compiler, these tools need to be in place.

Download and unpack the source files:

gunzip -c binutils-.tar.gz | tar xf -
cd binutils-

It is usually a good idea to configure and build binutils in a subdirectory so as not to pollute the source with the compiled files. This is recommended by the binutils developers.

mkdir obj-avr
cd obj-avr

The next step is to configure and build the tools. This is done by supplying arguments to the configure script that enable the AVR-specific options.

../configure --prefix=$PREFIX --target=avr --disable-nls

If you don't specify the --prefix option, the tools will get installed in the /usr/local hierarchy (i.e. the binaries will get installed in /usr/local/bin, the info pages get installed in /usr/local/info, etc.) Since these tools are changing frequently, It is preferrable to put them in a location that is easily removed.

When configure is run, it generates a lot of messages while it determines what is available on your operating system. When it finishes, it will have created several Makefiles that are custom tailored to your platform. At this point, you can build the project.

make install

You should now have the programs from binutils installed into $PREFIX/bin. Don't forget to set your PATH environment variable before going to build avr-gcc.

GCC for the AVR target

Warning: You must install avr-binutils and make sure your path is set properly before installing avr-gcc.

The steps to build gcc and avr-gcc are essentially the same as for binutils:

gunzip -c gcc-.tar.gz | tar xf -
cd gcc-
mkdir obj
cd obj
../configure --prefix=$PREFIX --enable-languages=c,c++ --disable-nls
make install
cd ..
mkdir obj-avr
cd obj-avr
../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++ --disable-nls
make install
To save yourself some download time, you can alternatively download only the gcc-core-.tar.bz2 and gcc-c++-.tar.bz2 parts of the gcc. Also, if you don't need C++ support, you only need the core part and should only enable the C language support.

Note: The stdc++ libs are not included with C++ for AVR due to the size limitations of the devices.

AVR Libc

Warning: You must install avr-binutils, avr-gcc and make sure your path is set properly before installing avr-libc.

Note: If you have obtained the latest avr-libc from cvs, you will have to run the reconf script before using either of the build methods described below.

To build and install avr-libc:

gunzip -c avr-libc-.tar.gz
cd avr-libc-
cd build
make install
Note: The doconf script will automatically use the $PREFIX environment variable if you have set and exported it.


Uisp also uses the configure system, so to build and install:

gunzip -c uisp-.tar.gz | tar xf -
cd uisp
./configure --prefix=$PREFIX
make install


Note: It has been ported to windows (via cygwin) and linux. Other unix systems should be trivial to port to. Avrdude is part of the FreeBSD ports system. Building and installing on other systems should use the configure system, as such:

gunzip -c avrdude-.tar.gz | tar xf -
cd avrdude
mkdir obj-avr
./configure --prefix=$PREFIX
make install

GDB for the AVR target

Gdb also uses the configure system, so to build and install:

gunzip2 -c gdb-.tar.gz | tar xf -
cd gdb-
mkdir obj-avr
cd obj-avr
../configure --prefix=$PREFIX --target=avr
make install
Note: If you are planning on using avr-gdb, you will probably want to install either simulavr or avarice since avr-gdb needs one of these to run as a a remote target backend.


Simulavr also uses the configure system, so to build and install:

gunzip -c simulavr-.tar.gz | tar xf -
cd simulavr-
mkdir obj-avr
cd obj-avr
../configure --prefix=$PREFIX
make install


AVaRice also uses the configure system, so to build and install:

gunzip -c avarice-.tar.gz | tar xf -
cd avarice-
mkdir obj-avr
cd obj-avr
../configure --prefix=$PREFIX
make install
Note: AVaRice uses the bfd library for accessing various binary file formats. You may need to tell the configure script where to find the lib and headers for the link to work. This is usually done by invoking the configure script like this (Replace with the path to the bfd.h file on your system. Replace with the path to libbfd.a on your system.):

CPPFLAGS=-I LDFLAGS=-L ../configure --prefix=$PREFIX

Note: As of 2003-08-15, no offical AVaRice release works like this. Use a 2.0 snapshot until the 2.1 release is made, or use obtain the source from cvs.

Retrieved from
Page last modified on March 06, 2008, at 04:04 PM