(:note 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.
(:toc:)
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:
- Get and Install Required software a JSR-82 implemenation for your OS. See #Bluetooth and Java
- Get the the Remote Programming implementation by Mustafa Yuecel. Get it via cvs from: http://btnode.cvs.sourceforge.net/btnode/proj/yuecelm/ You need the L2CAPCommunication and RemoteProgrammer modules.
- Compile both modules. L2CAPCommunication references the JSR-82 implemenation, and RemoteProgrammer references L2CAPCommunication and the JSR-82 implemenation.
- Install the app/bt-reprog example via the USB ProgBoard.
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 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.
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 Header | ISP 6-pin Socket |
| 1 | 4 |
| 2 | 2 |
| 3 | |
| 4 | |
| 5 | 5 |
| 6 | 6 |
| 7 | 3 |
| 8 | |
| 9 | 1 |
| 10 |
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:
- Do not change the fuse bit settings in the Atmel AVR unless you know what you are doing.
- Be gentle with the connectors. Turn off or disconnect power before de/attaching anything.
- Be sure to use the right programming frequency on your ISP programmer. It should be less than 1/4th of the system frequency. Generally the Atmel default setting of 1.23 MHz (AVRISP versions
0x01) and 230.4 kHz (AVRISP versions0x02) 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 parms.
- We suggest programming with avrdude and a programming device like the AVRISP. The defaults settings are found in the
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.
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 -d:pserver:anonymous@btnode.cvs.sourceforge.net:/cvsroot/btnode logincvs -z3 -d:pserver:anonymous@btnode.cvs.sourceforge.net:/cvsroot/btnode co -P btnut
Checkout the Nut/OS (aka Ethernut) project:
cvs -d:pserver:anonymous@ethernut.cvs.sourceforge.net:/cvsroot/ethernut logincvs -z3 -d:pserver:anonymous@ethernut.cvs.sourceforge.net:/cvsroot/ethernut co -P nut
Both project ('nut' and 'btnut') has to be on the same directory level! For developer CVS access have a look at http://sourceforge.net/cvs/?group_id=81773.
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'):
make
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 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:
PREFIX=$HOME/local/avrexport 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:
PATH=$PATH:$PREFIX/binexport 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-avrcd 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.
makemake 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 objcd obj../configure --prefix=$PREFIX --enable-languages=c,c++ --disable-nlsmakemake installcd ..mkdir obj-avrcd obj-avr../configure --prefix=$PREFIX --target=avr --enable-languages=c,c++ --disable-nlsmakemake 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.gzcd avr-libc-./doconf./domakecd buildmake install
Note: The doconf script will automatically use the $PREFIX environment variable if you have set and exported it.
UISP
Uisp also uses the configure system, so to build and install:
gunzip -c uisp-.tar.gz | tar xf -cd uisp./configure --prefix=$PREFIXmakemake install
Avrdude
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 avrdudemkdir obj-avr./configure --prefix=$PREFIXmakemake 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-avrcd obj-avr../configure --prefix=$PREFIX --target=avrmakemake 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
Simulavr also uses the configure system, so to build and install:
gunzip -c simulavr-.tar.gz | tar xf -cd simulavr-mkdir obj-avrcd obj-avr../configure --prefix=$PREFIXmakemake install
AVaRice
AVaRice also uses the configure system, so to build and install:
gunzip -c avarice-.tar.gz | tar xf -cd avarice-mkdir obj-avrcd obj-avr../configure --prefix=$PREFIXmakemake 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.