top of page
  • Writer's pictureCigdem Sengul

Making MicaZ motes work with Contiki – an open source operating system for Internet of Things

This blog post describes how to program MicaZ motes under the Contiki Open Source Operating System for the Internet of Things (IoT) (

I recently started putting together devices for an Internet of Robotic Things Lab. The main idea is to use different sensor, communications and robotics platforms to create a flexible testing environment for various IoT style applications.

I do have Raspberry Pi and Arduino based devices, but I also own the older TelosB and MicaZ motes.  And, I am looking into buying other newer platforms.

The TelosB motes support Contiki well and I have tested them in a bunch of different scenarios (Contiki recognizes them as the sky platform).

However, with the MicaZ motes (, I did not have immediate success. They are programmed the old fashioned way (through a programming board and through a USB interface).

Below  I list a number of issues I have run into and the solutions I put together based on various answers I found scattered over the Internet.   In the rest, I assume that you are familiar with Contiki make and upload commands  (otherwise see here: and also here:

(1) I noticed this first when I was trying to run the hello-world application.  Compilation  (i.e., make TARGET=micaz hello-world) failed with:  In file included from ../../cpu/avr/dev/flash.c:4:0: /usr/lib/avr/include/avr/boot.h:112:16: error: attempt to use poisoned “SPMCR” #elif defined (SPMCR)

Solution: This is a bug of avr-gcc, and is well reported. So it was easy to fix. You need to patch /usr/lib/avr/include/avr/boot.h as follows:

#if defined (SPMCSR) #  define __SPM_REG SPMCSR #else #if defined (SPMCR) #  define __SPM_REG SPMCR #else #  error AVR processor does not provide bootloader support! #endif #endif

(2) Then when compiling blink, another make error: sudo make TARGET=micaz blink CC     ../../platform/micaz/./init­net.c ../../platform/micaz/./init­net.c:64:28: fatal error: net/uip­fw­drv.h: No such file or directory #include “net/uip­fw­drv.h”

Solution: This is again a simple bug to resolve. The path missed “ipv4” in the original file, and hence could not locate the file. Modify init­net.c so that the #include line points out to the right directory:

#include “net/ipv4/uip­fw­drv.h”

(3)  Then the upload fails (i.e., make TARGET=micaz blink.upload fails) with a uisp error uisp ­dprog=mib510 ­dserial=/dev/ttyS0 ­dpart=ATmega128 ­­wr_fuse_h=0xd1 ­­wr_fuse_e=ff ­ erase ­­upload if=blink.srec ­­verify Direct Parallel Access not defined.

Solution: After trying a few things, I thought the best way is to switch to avrdude instead. I chose to translate the original uisp command to a one that can be understood by avrdude.  In the end, I did the following after compilation to upload (replaces the make command with upload):

> avr­-objcopy -­O srec blink.micaz blink.srec > sudo avrdude ­-cmib510 -­P/dev/ttyUSB0 ­-pm128 ­-U hfuse:w:0xd1:m ­-U efuse:w:0xff:m ­-e ­-v ­-U flash:w:blink.srec:a

After running this,avrdude verifies and writes to the flash. When it is all done, you should see: avrdude done.  Thank you.

Then you should see your Micaz mote blinking.

Note 1: To run the command, you have to check first which USB port your programmer is connected first. Mine was with /dev/ttyUSB0.

Note2: If you see avrdude: Yikes!  Invalid device signature. This is just a poor programmer board and mote connection. Make sure the mote is firmly connected.

Finally, I also tried with the radio-test and two Micaz motes are able to send and hear from each other with this method. Below is a picture of these motes blinking their LEDs as they send, and receive from each other and confirm a bi-directional link.

Now, if you have a TelosB, you will notice that running radio-test, it won’t hear the MicaZ mote, and vice versa. Taking a quick look at the configuration files, there are differences but both types of devices use IEEE 802.15.4 and are configured with the same PAN id and channel. Hence, this cross-platform communication part requires more investigation. But, so far so good.

2 views0 comments

Recent Posts

See All


bottom of page