SimpliciTI Adventures

February 1, 2009

Last week I received a batch of CC2500 radio modules.


Good news, they work great. I don't have to deal with laying out the RF or buying an expensive demo board. They were cheap enough I could buy a handful and build my own network. The bad news was in the ez430-RF2500 package. It was shipped without the source files for SimpliciTI and much of the headers were stripped. Apparently the ez is built with an earlier version of SimpliciTI and the frames are not the same as in the latest slac139. So, after beating myself up trying to work with the existing code on the EZ boards, I'm moving on. It did lead me to really dig around in the SimpliciTI code and understand it pretty well. I've got it working with an MSP430F149 and got to the point of sniffing packets from the ez boards. I have rutted around in TI's packet sniffer and it seems that it will only work with proprietary connections, USB specific boards. I'm going to post on TI and ask if they could offer protocol and a COM port connection. (And maybe it is really there but I don't know where it is.)

But for now, I have written a rudimentary sniffer for my board. Here is the output on a hyper-terminal link:

size:17  DEST:03 8E 75 84  SRC:FA A9 27 AC  PORT:0x03
DE 00 d:21 D7 85 EF BE AD

size:14  DEST:03 8E 75 84  SRC:FA A9 27 AC  PORT:0x02
Payload:20 D8 82 20 00

size:19  DEST:00 00 00 00  SRC:03 8E 75 84  PORT:0x02
00 3D 0122 D8 07 EF BE AD

size:14  DEST:FA A9 27 AC  SRC:03 8E 75 84  PORT:0x20
Payload:03 D9 D2 00 1B

size:14  DEST:FA A9 27 AC  SRC:03 8E 75 84  PORT:0x20
Payload:03 DA D2 00 1B

This is the EZ boards doing a join and a couple of temperature and battery voltage packets at the end. The packets move so fast I got an overrun in the third one, more sophisticate software would buffer packets, but this is good enough for me right now, I can see it working. It may be that the TI Sniffer uses raw binary data and would make a sniffer hack pretty simple. But for this, I assemble the ASCII string on the MSP430 so I can just send it to a dumb terminal app. Here is the code, a quick and dirty hack.

Packet Sniffer Hack

You would do what ever you have to to ship it off to your UART. Just past the test for an echo in dispachFrame(...), mwk_frame.c, put in:

    PostSnifferPacket( fiPtr );

And away you go, a poor man's packet sniffer. As I actually build my own network I'll add to this page. For now, I'm pleased with SimpliciTI, it is easy to use. I'd say forget the LEDs and Buttons stuff. The only question I have standing is just how compact the code really is. With asserts on and no optimization, I'm producing > 20k of code. It is hard to believe this will really trim down to the advertised 8K.

My hardware for this project:


February 3, 2009

Yesterday I got a network together. That was a great moment for me. It took longer than it should have because I assumed I could start with the disk sent with the EZ430-RF2500. If you just want to play with the App layer and leave the radio as it is, use the project on the disk. If you plan on writing your own network and need to build SimpliciTI, put that disk on the shelf and leave it there. Go to the TI site and download the latest slac139 package. That telephone box has an FT232RL in it for the RS232 part of projects. The TI Demo monitor works from a COM port, so:

TI Demo Monitor

The MSP430F149 board above is the 'Access Point' (AP) and I've put my own 'End Device'(ED) code on the two EZ boards. There is no AP temperature as I didn't bother, this was about the radio project.

SimpliciTI with MSPGCC

SimpliciTI will work just about out of the box with MSPGCC. From the slac139, take the folders from:

eZ430-RF2500 Wireless Sensor Monitor\CCS_Source\Components

And put them in your favorite source folder. I put them in a sub folder called simti_source. Don't try to reorganize it, don't change anything in these folders but for one special header. In the following link you will find the code to add to bsp_msp430_defs.h that supports MSPGCC. It is ready to use from there. If you have the urge to 'fix' something in these files, don't, it is not worth it, the code works.

SimpliciTI Brief Tutorial (PDF)

(I'll keep a copy in case this link ever expires)

I use bat files to make. I'm use to it, but the same rules apply if you make from Eclipse. Each radio project will have a unique object so you can't make a SimpliciTI lib for general use. I have two bat makes for a project, one for the radio and one for the app. This way I don't have to make the radio object over and over while working on the application. Here is my radio bat.


The order of the include paths is important in that you want to start with your workspace folder first.

This is because you will copy project specific headers and source from the SimpliciTI folder into your workspace folder and modify them there. You do not have to edit anything in the SimpliciTI source.

The following is what I did for the MSP430F149.These files are copied into the workspace folder.


#define BSP_NO_LEDS

That's it, you don't need the rest of that stuff. I don't know what LEDs and buttons are doing here, this is a radio library, shut them off.


BSP_EarlyInit(...) is not used, you can delete it. Otherwise, I used the software timer (SW_TIMER defined) to get going so all the code needed here is:

#include "bsp.h"
#include "bsp_config.h"
#include <HEUtils.h>

void BSP_Delay( uint16_t usec )
    usec/= ( 20 / BSP_CONFIG_CLOCK_MHZ );
    brief_pause( usec );


I just kept the whole thing and changed this:

#define BSP_BOARD_C               "bsp_board.c"
#define BSP_INIT_BOARD()          nop( )


By using bsp_config.h for the driver include, you don't need the bsp_drivers.c

#define BSP_DRIVERS_C                "bsp_config.h"
#define BSP_INIT_DRIVERS()          nop( )


In a folder called bsp_external in your workspace, two more files These configure the SPI interface for the flavor of MSP430 you are using. Also, if you are handling interrupts for other pins on the port you put the GDO0 and GDO2 on, the handler is in mrfi_board.c I had to change quite a bit in mrfi_board_defs.h, I won't post that here. But if you are going to use a 1xxx device, this include may be a better staring point than the one TI ships.


But this should do it for you. From there look at the AP and ED examples for talking on the radio network and go through some SimpliciTI docs.

One other thing, the global defines. I would put those in a header but I started the why they did it. Look over them carefully! Like, the obvious can be so hard to see. At one point I had END_DEVICE defined while building an AP. I was looking for a subtle problem and just didn't see it for a while. That was an 'I feel dumb' moment.

There is one file in the SimpliciTI files that you may want to modify, it is mrfi\radios\family1\mrfi_spi.h. Here you can change the likes of frequency, bandwidth, etc., for the radio. TI has a parameter tool called SmartRF Studio that will generate the defines.

Thanks, Dan.
pubdan3 (at) lakeweb (.) net

Copyright © 1996 - 2010, Highlands Electronics All Rights Reserved.
Page created: 1 feb 10   rev: 3 feb 10