This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GDO0 On CC1100E Not Rising

Other Parts Discussed in Thread: MSP430F1611, CC1100E, CC1100

Hi all,

I am attempting to interface an MSP430F1611 to a 950/960 MHz CC1100E, but I cannot get the pair to transmit properly.

On the transmitting side, I have a CC1100E evaluation module plugged into a SmartRF04 evaluation board, which is then connected to an MSP430F1611 breakout board. The relevant resistors on the evaluation board have been removed, and the connections I've made are as follows (evaluation board -> MSP430):
G0 -> P2.4
G2 -> P5.6 (connected but not used)
CSn -> P5.4
SCLK -> P3.3
SI -> P3.1
SO -> P3.2
GND -> GND
I've double checked these connections but I put them here in case there's something obvious I've missed. On the receiving side, I have an unmodified SmartRF04 evaluation board plugged into a PC and connected to SmartRF Studio 7.

To set the CC1100 registers on the transmitting board, I went to the SmartRF Studio Easy Mode, selected the 955 MHz low data rate packet tx configuration, and exported the register settings to my code. The receiving registers are the defaults set by SmartRF Studio. My process is to start packet RX on the receiving module, and then run the tx code on the microcontroller. However, the receiving module never receives any packets.

Debugging further, I found that the microcontroller hangs on this line in the code from the library: 

while (!(TI_CC_GDO0_PxIN&TI_CC_GDO0_PIN));

... showing that GDO0 doesn't go high when transmitting. I am somewhat of a beginner at this I have no idea what the problem could be, can someone please point me in the right direction? Unfortunately, I do not have a logic analyzer available to double check the SPI communication, but I do have an oscilloscope. I have included my main.c code below, but I can post other files or register settings if requested.

Thanks in advance for any help!

 

// CC1100 Test

#include "include.h"

extern char paTable[];				// Defined in CC1100-CC2500.c
extern char paTableLen;

char txBuffer[4];					// Send buffer
char rxBuffer[4];					// Receive buffer

void main(void){
	WDTCTL = WDTPW + WDTHOLD;		// Stop watchdog

	// Initialize LED
	P6DIR |= BIT0;
	P6OUT |= BIT0;

	__delay_cycles(5000);			// 5ms delay to compensate for different startup times

	// Setup SPI & CC1100
	TI_CC_SPISetup();				// Initialize SPI port
	TI_CC_PowerupResetCCxxxx();		// Reset CC1100
	writeRFSettings();				// Write RF settings to CC1100. RF settings can be gathered from SmartRF Studio 7 & entered into CC1100-CC2500.c

	// Write power amplifier table. Value taken from SmartRF Studio
	TI_CC_SPIWriteBurstReg(TI_CCxxx0_PATABLE, paTable, paTableLen);



	// Build packet
	txBuffer[0] = 2;				// Packet length
	txBuffer[1] = 0x01;				// Packet address
	txBuffer[2] = 0x2A;				// Packet content

	unsigned int i;
	for(i=0;i<10;i++){
		RFSendPacket(txBuffer, 3);	// Repeatedly send packet
		P6OUT ^= BIT0;					// Turn on LED
	}

	// Wait
	P6OUT ^= BIT0;					// Turn on LED
	while(1){}
}

 

  • Hi all,

    I have not figured out the problem yet but I found this thread and tried some of the suggestions. Here are my results:

    1. User "M" stated that this problem may be a deadlock. I'm doubtful that this is the problem since I don't have any interrupts that can cause the microcontroller to run code other than the while loop that it's getting stuck on.
    2. "M" also stated that the radio might be in a TX underflow state. I thought this was the problem but I found out the radio was set to variable packet length mode, and I have set my packet length to two (one address byte and one data byte). Maybe the RFSendPacket() function doesn't support variable length packets?
    3. Finally, I tried reading from the MARCSTATE register by using the command 

    char regStat = TI_CC_SPIReadReg(TI_CCxxx0_MARCSTATE);

    According to CCS, the value of the MARCSTATE register is 47 (decimal), which doesn't even appear to be present in the radio control state diagram. This leads me to believe that my problem lies in my SPI communication. Has anyone else run into similar problems?

    Anyways, hope this might help someone in the future, I'm going to keep looking.

    Thanks,
    Nipun