Based upon the TinyOS-Bootloader for the Imote2, a new, completely rewritten Bootloader was developed.


  1. Motivation
  2. Comparison old vs. new version
  3. Documentation
  4. Installation
  5. Download
  6. References
  7. Authors


The TinyOS Bootloader did not meet our requirements in several ways:
  1. We do not develop TinyOS Programs, but own C++ Application. The Linkerscript and Loader which are provided with tinyos were insufficient for these needs
  2. The programs we wanted to deploy where therefore somewhat larger. The TinyOS Bootloader is rather slow and inflexible, larger programs can even corrupt the bootloader itself, transforming your Imote2 into an expensive brick (unless you are comfortable with JTAG).
  3. We wanted to use Linux for the Upload process, but there was no such possibility with the TinyOS Codeloader
Because of this all, we did not fix the TinyOS Bootloader (which has some rather overcomplicated design by the way) but we wrote our own Bootloader, Codeloader, Linkerscript and startup code. In further developments we extended the functionality between these components and therefore our work provides some very useful features.

Comparison old vs. new version

Disadvantages of the standard-bootloader
Advantages of the new bootloader
  • platform specific implementation of codeloader (MS Windows + cygwin)
  • support only for C-executables (gcc)
  • support for images up to 1-2MB, depending on location (primary/secondary)
  • unreliable communication, sometimes failes
  • low data-programming speed <20kb/s on USB
  • possible corruption of the bootloader itself
  • bad and incorrect documentation
  • platform independent codeloader (java) based on libusb
  • support for C/C++-executeables (gcc / g++)
  • capable of replacing the TinyOS bootloader
  • support for images up to 28MB
  • support for independent configuration/data storage
  • communication model is technologie independent (programming via wireless may be possible with same communication protocol)
  • programming only at boottime - more reliable
  • avoids accidental programming of false node due to node specific configuration
  • fast development using in-RAM-execution feature
  • Optional Abort Handler in additionally given new startup code
  • higher data-programming speed due to better USB utilization, DMA transfer and compression
    • ~350kb/s permanent flash programming
    • ~950kb/s in-RAM-execution
  • documentation via technical report and detailed using doxygen


Codeloader, Bootloader, Linkerscript, Startup Code

This small image should illustrate the difference between the two names "bootloader" and "codeloader". The bootloader resides on the Imote2 and is static, except for our new releases. The codeloader is a small Java program and is located on the pc-side. The new image is sent by the codeloader via USB cable to the bootloader on the Imote2.
Besides the bootloader and codeloader, there is additional work related to these concepts: The "Linkerscript" is provided to the linker and controls therefore the linkprocess. The bootloader and startup code need the image to be at specific addresses in the memory and the linkerscript assures that the image fulfils these requirements.
The "Loader" is included in every image. It does some initialization of the hardware and finaly starts the application. In case of a runtime error (such as a faulty memory access) the startup code also takes control and tries to output fault information and a backtrace of the current call stack.

Installation instructions
First of all you should know that the bootloader is not yet capable of updating itself. This means that you need JTAG access to the device.

Thus it is highly recommended that you have the interface board and a JTAG dongle or some equivalent JTAG access and you should be familar with using these things. If you still consider using our bootloader, here are your instructions for installing it:

Building an image for the Imote2 platform

Note: we do not use the Wasabi xscale-elf toolchain anymore and we stopped supporting this toolchain. It is outdated and the binutils of that toolchain lack some features which were quite useful and there is no point in using such an old toolchain. Instead, we use a newer toolchain based on gcc-4.4.2 which we built from source.

If you want to build your own application (without TinyOS), you can start like this:

Building an image for the Imote2 platform with tinyOS

NOTE: Your "old" TinyOS applications won't run directly by using the new code-/bootloader. We have changed the image location, which makes it neccessary to relink (recompile) your source code with a patched linkerscript and startup code.
We provide a patch for tinyos-2.x CVS, which applies the necessary changes to tos.x and toscrt0.s in your tinyos-2.x source folder. Just apply the patch using

cd path/to/tinyos-2.x; patch -p1 < /path/to/tinyos.patch
After that, the newly created images (main.bin.out) follow our "old image format", which can be used by our bootloader.
As you might guess, there is also a "new image format" but for the moment, we did not attempt to get it work with TinyOS. That means, that there are some features missing, such as executing the image from RAM, having detailed fault information in case of an errornous memory access and so on. If you want to get that work, you have to look above and try to merge these to methods of creating images.

Using Codeloader to flash Imote2

Consider you want to flash image.out:

java -jar codeloader.jar -file image.out
After starting the Imote, the image will be transferred. Note that the must be in your JREs default library path, or you have to provide it using the -Djava.library.path=... switch.
Details on using the codeloader (i.e. configuration files)

NOTE: The new bootloader will only accept new images at boottime. This is wanted and expected behaviour and not considered as a fault.




Concepts and realization by

Forschungsaktivitäten, Projekte und Organisationen

Zu den Kontaktdetails des Verantwortlichen dieser Seite

This page in english. Diese Seite auf englisch.