MSP 430 – FreeRTOS porting & implementation of the CC2420 drivers
We’ve decided to take a popular OS for embedded (FreeRTOS) in its free version and port it to the MSP 430 on the sky board.
This operating system supports threads and it was a main advantage while coming to implement a CC2420 application.
We can implement one thread for console (user operations) and one thread for accessing the queue for incoming messages.
Of course our main objectives required smaller milestones such as developing SPI and UART drivers, and also for our own benefit a debug system using the board LEDS.
We’ve used 2 sky boards and PC’s to develop the system.
No other hardware was required.
Tools of development
We’ve used Eclipse platform for software developing because it enabled us to use SVN project over google code, and our project is hosted on http://msp430xf1611.googlecode.com
We’ve used Putty to capture UART debug outputs.
Porting the FreeRTOS
First we ported the FreeRTOS OS to the sky board with the MSP 430 processor.
We’ve used web sites describing what are the necessary adjustments for such action.
We’ve used the MSP 430 CPU guide to fetch relevant information for the porting such as clock rates, PIN arrangements, memory management, stack and etc.
Developing the UART drivers
For creating a feedback from the PC we needed the UART drivers. The CC2420 required the SPI drivers so this milestone was for developing assistance only.
We’ve used the MSP 430 guide to learn the basic of UART initialization and usage.
Also we used the Open Source Contiki OS to learn more about this driver.
Developing the Debug Library
For our benefit we’ve created a debug library using the LED’s on the Sky board.
Also, we’ve implemented the printf function from scratch.
The reason for that is that the stdlib is not thread safe and we wanted to use prints from different threads.
The FreeRTOS provided locks so we built the printf function to use locks and be thread safe.
Developing the SPI drivers
For this issue we’ve found a Texas Instruments implementation and used this module
Overall this milestone was pretty straight forward.
Developing the CC2420 drivers
This was the heart of our project and as so it took the most of the time.
We’ve read all the documentation about the CC2420 (Capicorn pdf) and also the MSP 430 diagram of connection in the sky board.
Also, again, we used the Contiki OS as a good reference although it was very hard to read code.
We’ve ran into a lot of problems as it is hard to find information about this module. Also errors are not printed on screen but instead can hung up the application.
We will describe one bug and how it was discovered:
We’ve noticed that our CC2420 state machine is working ok but the machine is somehow stuck on the receive state and no data is shown although the other sky board is sending data.
After week of debug, we’ve noticed that if we create a thread that flashes the LED’s and try to send data the CPU itself is stuck and not just the CC2420.
After another week of investigating we’ve discovered that the CPU was configured to handle the CC2420 incoming data by an interrupt handler, which was pointed to void and the CPU just jumped to some default address and stayed there.
We’ve canceled the interrupt handler registration command and instead asked to handle such data by polling the correct CC2420 FIFO flag.
This of course solved the problem.
Writing simple connection protocol
For connecting our MSP’s we’ve developed a simple protocol which consists two parts:
Because of that other CC2420 devices can locate this device and send messages to it by using its device ID.
Our messages are limited to 128 bytes, as from 128 and on it is saved for the discovery protocol.
Implementing a Console
This was important for demonstrating the project so we’ve created a simple console application that runs on a different thread and can accept commands from the user keyboard.
The options are help, map of the network, status of your own CC2420 device, send messages to other known CC2420 on the network.
What was difficult
We can say for sure that the main problem was lack of examples.
When you work on a specific hardware module you must understand the details very good and it requires great understanding of the hardware.
Also good understanding of memory layouts and flow of runtime were required.
We’ve spent hours reading documents and developing code that was eventually pretty short ( < 1500 lines)
We both think that in the end developing an embedded project is nothing like developing an application.
The difficulties are different. A lot of research is needed and in constrast to the application world examples are almost no where to be found.
However, this experience can greatly improve skills that are generally not needed writing Java/C# code.