Progress

MSP430 & Contiki

Our initial aim was to put the Contiki OS onto the MSP430 (6 series) powered board, as we had the chips and programmers to do this. The board is ideal due to its built-in radio and suitable Flash & RAM size. However, we came across numerous problems in using Contiki, and in incompatibilities with our board.

Contiki

The initial problem we had was in getting anything within Contiki to work. Contiki is available as source code or already set up in an Ubuntu virtual machine with all the relevant examples and compilers installed. From here, we managed to use the COOJA simulator to compile a basic example for Skymotes (which wasn't our hardware, but the only device that the simulator would handle, but the device which most of the examples were written for). This showed a number of identical nodes talking to each other and sending a "Hello World" message back and forth. Some of the other examples allowed us to set a "sink" for data to be sent to, or other basic functionality.

ContikiRPL

One of the IPv6 examples supplied with Contiki was ideal for our uses, as it showed a number of nodes and one "sink" forming a tree structure of the best route for data to take to reach the sink using the IETF standard for RPL (Routing Protocol for Low Power and Lossy Networks). In the simulator, we could see this taking place, and see what data was being passed along. We decided that this would be ideal, as it would save us writing an efficient tree discovery routine for the nodes ourselves.

However, one thing we noticed was that the nodes would constantly refresh the tree, regardless of whether any data was being sent. We thought that this wouldn't be optimal for our purposes, as using the radio uses up battery life, which we couldn't afford to spare. Therefore, we set out to modify how often the tree was updated, so we could specify it to happen (eg) once a day. Pretty soon it became obvious that the routine for tree formation was hard coded into RIME (Contiki's network stack). We eventually managed to find what looked like a relevant variable, though changing it made no difference to the simulation. At this point, we decided to leave that problem and examine it later, as there were other more pressing issues.

MSP430

The simplest way of writing for the MSP430 was to use Code Composer, as this had all the correct headers in place, and was simple to use. We easily managed to get a simple program running which flashed LEDs. However, the version of Code Composer we had was limited, hence we decided to use a slightly more powerful tool which would allow us full access to the device. Once we had compiled the compiler we needed to compile for the MSP430 (msp430-gcc, our board required version 4), we soon managed to get a simple hello-world application running. This was uploaded to the device using mspdebug.

We then decided to compile Contiki for the MSP430, which proved most difficult of all. We initially struggled to get anything running due to a host of compiler errors. This was solved by performing a cvs update to get the most recent version of Contiki, as it appeared that the version we had initially downloaded had been released with a small number of bugs.

With the most recent, we tried compiling the hello-world example we had used in the simulator, though this wouldn't compile for the MSP430. Eventually, we found a number of headers that weren't being included properly, and altered some of the source code for Contiki to fix this. We also had to make a few predicted changes to the code to tell it which version of the chip we were on. When we finally managed to compile a hello world example for the MSP430, we easily loaded it onto the device and set it running. Here, again, we had the problem of not being able to tell if the program was running. We therefore added a few lines of code to alternate the LEDs. However, running this didn't do anything, our assumption being that it hadn't got the memory locations for the LEDs. We found a file containing the addresses, though couldn't find any way to force the compiler to include this file and use these values.

At this point, we did some more reading investigating to discover what the cause of the problem may be, and discovered that our Series 6 MSP430 chip required a later version of the compiler (4.4.4), while Contiki required an earlier version (3.2.3). Unfortunately, these were incompatible, and we decided that waiting for an update to Contiki that accepted the most recent compiler would not be viable.

At this point, unfortunately, we decided to abandon Contiki altogether, and write code natively for the MSP430, which, while more detailed work, would take out a lot of the intermediate troubleshooting

Network

Luckily, someone else in ECS had recently written a network stack for the MSP430, which we were able to use parts of.