|This page is editable for everyone, just click 'Edit' on top of this page and use the password |
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.
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.
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 :)
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 http://www.avetana-gmbh.de/avetana-gmbh/produkte/jsr82.eng.xml but a 14-days evaluation.
On Windows, you could also try out the bluecove implementation at http://bluecove.sourceforge.net, 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.
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...
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).
The new AVRISP mkII programmers need an adapter cable to fit into the usbprog rev 2 boards:
|ISP 10-pin Header||ISP 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).
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
The minicom configuration can be reached by
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:
0x01) and 230.4 kHz (AVRISP versions
0x02) works well.
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
Makedefsfile. These can be easily overridden by specifying the correct settings as environment variables.
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.
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.
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
If you want to use COM ports higher than COM9 then you have to prefix the port with
//./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.
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)
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
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/btnode login
cvs -z3 -d:pserver:email@example.com:/cvsroot/btnode co -P btnut
Checkout the Nut/OS (aka Ethernut) project:
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/ethernut login
cvs -z3 -d:pserver:email@example.com:/cvsroot/ethernut co -P nut
Both project (
'btnut') has to be on the same directory level! For developer CVS access have a look at http://sourceforge.net/cvs/?group_id=81773.
'Makedefs' and adapt
'BURNPORT = /dev/ttyUSB0')
Make libraries of BTnut (Makedefs assumes Nut/OS with
If there are no errors, where are now ready to compile and flash BTnode-applications...
This this webpage explains how to install the GNU AVR toolchain and is a modified version of http://www.nongnu.org/avr-libc/user-manual/install_tools.html.
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:
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
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.
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 -
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.
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.
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.
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 -
../configure --prefix=$PREFIX --enable-languages=c,c++ --disable-nls
../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++ --disable-nls
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.
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
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 -
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 -
Gdb also uses the configure system, so to build and install:
gunzip2 -c gdb-.tar.gz | tar xf -
../configure --prefix=$PREFIX --target=avr
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 -
AVaRice also uses the configure system, so to build and install:
gunzip -c avarice-.tar.gz | tar xf -
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.