MSP 430 – FreeRTOS porting &
implementation of the CC2420 drivers
Description
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.
Hardware
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.
Project
Milestones
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)
Conclusions
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.