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.

Problem with paket sending (MSP430 & CC2500)

Other Parts Discussed in Thread: CC2500

Hi,

I created a board after the schematics and similar to the layout of the wireless sending board of the ez430 RF2500 and programmed it with a code. The problem is, that it sends one paket (that can be received from the ez430 RF2500), but when it goes the second time through the while(1), then it doesn't send the paket. The LED is on for the time until the TimerA sends an interrupt. Could it be that I have to initiate the CC2500 with SmartRF Studio or could it be a hardware issue? Because when I test the code with the ez430 RF2500 sending module it works fine! I really would appreciate it if you culd give me some help. Thank you.

Best regards

DP

Here's the code:

(The functions are from the MSP430/CC1100-2500 Interface Code Library v1.0)


#include "include.h"

#define TX_LENGTH 16       // CC2500 TX buffer length
#define PRESCALE 20       // I2C prescale

extern char paTable[];       // CC2500 pa table
extern char paTableLen;       // CC2500 pa table length
char txBuffer[TX_LENGTH];      // CC2500 TX Buffer

void main (void)

{

  WDTCTL = WDTPW + WDTHOLD;      // Stop WDT
  BCSCTL1 = CALBC1_8MHZ;      // Set DCO
  DCOCTL = CALDCO_8MHZ;
 
  FCTL2 = FWKEY + FSSEL1 + FN4 + FN2;     // MCLK/20 = 8MHZ/20 = 400kHz for Flash Timing Generator
   
  P1DIR = 0xFF;        // switch all ports off
  P1OUT = 0x00;
   
  P2SEL &= ~(0x40);       // P2.6 as IO
  TI_CC_SPISetup();       // initialize SPI port
 
  TI_CC_PowerupResetCCxxxx();      // reset CCxxxx
  writeRFSettings();       // write RF settings to CCxxxx config register
  TI_CC_SPIWriteBurstReg(TI_CCxxx0_PATABLE, paTable, paTableLen); // Write CCxxxx PATABLE
  TI_CC_SPIStrobe(TI_CCxxx0_SPWD);     // sleep CCxxxx
 
  // Configure ports -- LEDs, GDO0 to RX packet info from CCxxxx
  TI_CC_LED_PxDIR = TI_CC_LED1+TI_CC_LED2;    // LED ports
  TI_CC_GDO0_PxIES |= TI_CC_GDO0_PIN;     // interrupt on GDO0 falling edge (end of pkt)
  TI_CC_GDO0_PxIFG &= ~TI_CC_GDO0_PIN;     // clear GDO0 flag
  TI_CC_GDO0_PxIE |= TI_CC_GDO0_PIN;     // enable interrupt on end of packet
  TI_CC_LED_PxOUT =0;       // LEDs off
  BCSCTL3 |= LFXT1S_2;       // LFXT1 = VLO 
 
  TACCTL0 = CCIE;       // TimerA interrupt enabled
  TACCR0 = 1500;       // TimerA (12kHz) timeout: 1500 ~ 1 sec
  TACTL = TASSEL_1 + MC_1 + ID_3;     // ACLK, upmode (ID_3 => 1.5kHz = 12kHz / 8)
 
  _EINT();
 
  while(1)
  {

    txBuffer[0] = TX_LENGTH - 1;     // packet length
    txBuffer[1] = 1;       // receiver address
    txBuffer[2] = 1;
 
    TI_CC_LED_PxOUT = 2;      // switch green LED on
    RFSendPacket(txBuffer, TX_LENGTH);     // send CCxxx TX buffer over RF
    TI_CC_LED_PxOUT = 0;      // switch green LED off
 

   
    TI_CC_SPIStrobe(TI_CCxxx0_SPWD);     // CCxxxx sleep
    __bis_SR_register(LPM3_bits+GIE);     // MSP430 sleep
  }
}   


#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
  __bic_SR_register_on_exit(LPM3_bits);
}


#pragma vector=PORT2_VECTOR
__interrupt void port2_ISR (void)
{
  __bic_SR_register_on_exit(LPM3_bits);
  P2IFG &= ~TI_CC_GDO0_PIN;       // Clear flag
 
}

  • The CC2500 is configured by the MSP-430

    DPflaum said:
    writeRFSettings();       // write RF settings to CCxxxx config register
    each time the software starts. While the RF settings can be generated by RF Studio to be used in the code, you do not use RF Studio to pre-initialize the CC2500 prior to using it with the MSP-430.

    You write the hardware design was taken from the Ti ez430 RF2500 and the software you are using on your board works on the Ti ez430 RF2500. If the software is the same file loaded into both units then there is a hardware design difference.

    I suggest you try the experiment again where you try your board and then  the Ti board with the same software build file without any changes to the software. 

     

  • Hi,

     

    I noticed that the 26 MHz crystal is not being turned of and that the other signals between the MSP and the CC2500 aren't the same as on the working board. I also noticed that there is a problem with the following lines of the RFSendPacket function:

     

    TI_CC_GDO0_PxIES &= ~TI_CC_GDO0_PIN;       // Int on rising edge (end of pkt)
        _BIS_SR(LPM3_bits + GIE);

     TI_CC_GDO0_PxIES |= TI_CC_GDO0_PIN;       // Int on falling edge (end of pkt)
        _BIS_SR(LPM3_bits + GIE);

     

    Because if I let them out, the function RFSendPacket is executed fast (LED blinks fast) and if I let them in, then the LED is on for a too long time. I measured the GDO0 signal and it's not the same as on the working board!

    What could be the reason for it? Thank you!

     

    TI_CC_LED_PxOUT = 2;
    RFSendPacket(txBuffer, TX_LENGTH);
    TI_CC_LED_PxOUT = 0;

    void RFSendPacket(char *txBuffer, char size)
    {
        TI_CC_SPIWriteBurstReg(TI_CCxxx0_TXFIFO, txBuffer, size); // Write TX data
        TI_CC_SPIStrobe(TI_CCxxx0_STX);         // Change state to TX, initiating data transfer
        TI_CC_GDO0_PxIES &= ~TI_CC_GDO0_PIN;       // Int on rising edge (end of pkt)
        _BIS_SR(LPM3_bits + GIE);
        TI_CC_GDO0_PxIES |= TI_CC_GDO0_PIN;       // Int on falling edge (end of pkt)
        _BIS_SR(LPM3_bits + GIE);
    }

  • Hi,

     

    is it important to use a specific type of CC2500? There are this one: RTR1, RTY1, RTK, RTKG3, RTKR, RTKRG3

    I use the RTKR, should it work with this one too?

  • There is only one type. All of the CC2500 are the same.  The letters RTR1, RTY1, RTK, RTKG3, RTKR, RTKRG3 etc are how they are packaged for shipment and automated assembly loading such as 'tape and reel', tubes, boxes, etc.

  • Ok, thank you. That's what I also thought. Is the length of the traces on the ez430 RF2500 board in some way important? Especially the communication traces between the MSP and the CC2500. Or the traces to the 26 MHz crystal. How can I get informations about the material of the traces and the ground plane? Maybe this could be a reason for my problem.