CC1100/CC2500 Known Issues

From TinyOS Wiki
Revision as of 10:54, 15 February 2008 by Dmoss (talk | contribs)
Jump to: navigation, search

Compile Order

You need to reference the CC1100.h / CC2500.h / CC1100ControlC / CC2500ControlC files before adding BlazeC to the compile mix. The CC*00.h files define the size of arrays within the Blaze radio stack. Not having those definitions setup before compiling in BlazeC causes lots of problems, and you won't be able to turn on your radio.

Typically, ActiveMessageC should be responsible for pulling in files in the correct order.

Note that compiling in the CC1100ControlC or CC1100.h file is enough to give your platform CC1100 capabilities. Similarly, compiling in the CC2500ControlC or CC2500.h file will give your platform CC2500 capabilities. Your ActiveMessageC file just needs to reference one or both of those CC*00ControlC files to tell the radio stack which radio types it has attached.

Bad Crc?

Problem: I have a sender node running the RadioCountsToLEDs app and a receiver node running the BaseStation App. I also have it setup to toggle LED2 if a bad CRC is detected as I did yesterday. It flashes receive LED1 for sometime but after awhile the receiver node starts flashing the LED2 instead of the receive LED1. I can fix the problem by pressing the reset button on the sender node and it will go back into normal routine but start over from count 0 obviously.

Solution: For MSP430 platforms, enable DMA on the SPI bus talking to the radio. This is done by adding a command to your Makefile:

 CFLAGS+=-DENABLE_SPI0_DMA

If your SPI bus isn't fast enough, you'll be transmitting corrupted packets.


Dual-Radio Platforms

We haven't had any success getting a dual-radio platform to operate when both radios are turned on. It may be necessary to control the power to each radio on your platform with a FET switch. FET switches worked for our dual-radio platform.