• Join
  • Sign In with my.TI Login
Texas Instruments
  • Products
  • Applications
  • Tools & Software
  • Support & Community
  • Sample & Buy
  • About TI
Sample & Purchase Cart Sample & Purchase Cart
  • Search
  • Advanced
TI E2E™ Community
  • Support Forums
  • Blogs
  • Groups
  • Videos
  • 简体中文
  • More ...
TI Home » TI E2E Community » Support Forums » Low Power RF & Wireless Connectivity » Low Power RF Hardware & Tools Forum » cc1101 transmit problem
Share
Low Power RF & Wireless Connectivity
  • Forums
  • Announcements
  • Files
  • E2E Wiki
Options
  • Subscribe via RSS

Forums

cc1101 transmit problem

This question is not answered
Fatima M.s
Posted by Fatima M.s
on Jul 17 2012 03:21 AM
Prodigy10 points

hi

I can read and write cc1101 registers, but when I issue command strobes it seems that it doesn't work.

I read MARCSTATE after these command strobes:

CC_Idle(), MARCSTATE: 5f (CC_Cmd(CCxxx0_SIDLE))
CC_Cmd(CCxxx0_STX): 2f

this is my code for command strobes:

#define RF433_CS_UP    PORTB.4=1;
#define RF433_CS_DN    PORTB.4=0;
                            //PORTB.4 is connected to CSn

 unsigned char CC_Cmd(unsigned char Cmd)
{
    unsigned char Status;

    RF433_CS_DN;
    CC_Rdy();
    Status=CC_SpiWr(Cmd);
    RF433_CS_UP;
    delay_us(10);
    return Status;
}


void CC_Rdy()
{
 while(PINB.6);    //PINB.6 is connected to SO(GDO1)
   return;
}

after issuing SIDLE strobe, MARCSTATE must be 0x01 and after STX strobe, it must be 0x13.
I couldn't find where the problem is. can anybody help,please?

this is my Tx code:

While(1)
   {
                  CC_Idle();

                                    read[1]= CC_RdReg(CCxxx0_MARCSTATE);
                                   sprintf(buffer_lcd,"%x ",read[1]);
                                   lcd_puts(buffer_lcd);
                  delay_ms(20);
                  CC_WrReg(CCxxx0_TXFIFO,0X40); //packet length
                  CC_WrReg(CCxxx0_TXFIFO,5);  //set  address
                  CC_WrReg(CCxxx0_TXFIFO,1); 
                  CC_WrReg(CCxxx0_TXFIFO,2);
                  CC_WrReg(CCxxx0_TXFIFO,3);
                  CC_WrReg(CCxxx0_TXFIFO,4);
                  CC_WrReg(CCxxx0_TXFIFO,5);
                  CC_WrReg(CCxxx0_TXFIFO,6);
                  CC_WrReg(CCxxx0_TXFIFO,7);
                 
                  CC_Cmd(CCxxx0_STX);

                  delay_ms(50);
                                        read[1]= CC_RdReg(CCxxx0_MARCSTATE);
                                       sprintf(buffer_lcd,"%x ",read[1]);
                                       lcd_puts(buffer_lcd);
               
                  CC_ClrTx();
                  delay_ms(50);
                  CC_Idle();
                  lcd_clear();
                 
                  delay_ms(800);
            }

RF_settings:

unsigned char RF_setting[48]=
{0x29,       // CCxxx0_IOCFG2       
0x2e,       //CCxxx0_IOCFG1
0x06,       //CCxxx0_IOCFG0
0x07,       //CCxxx0_FIFOTHR
0xd3,       //CCxxx0_SYNC1
0x91,       //CCxxx0_SYNC0
0xff,       //CCxxx0_PKTLEN
0x04,       //CCxxx0_PKTCTRL1
0x05,       //CCxxx0_PKTCTRL0
0x05,       //CCxxx0_ADDR
0x00,       //CCxxx0_CHANNR
0x0c,       //CCxxx0_FSCTRL1
0x00,       //CCxxx0_FSCTRL0
0x10,       //CCxxx0_FREQ2
0xb1,       //CCxxx0_FREQ1
0x3b,       //CCxxx0_FREQ0
0x2d,       //CCxxx0_MDMCFG4
0x3b,       //CCxxx0_MDMCFG3
0x13,       //CCxxx0_MDMCFG2
0x22,       //CCxxx0_MDMCFG1
0xf8,       //CCxxx0_MDMCFG0
0x62,       //CCxxx0_DEVIATN
0x07,       //CCxxx0_MCSM2
0x3f,       //CCxxx0_MCSM1
0x18,       // CCxxx0_MCSM0
0x1d,       // CCxxx0_FOCCFG
0x1c,       // CCxxx0_BSCFG
0xc7,       // CCxxx0_AGCCTRL2
0x00,       // CCxxx0_AGCCTRL1
0xb0,       // CCxxx0_AGCCTRL0
0x87,       // CCxxx0_WOREVT1
0x6b,       // CCxxx0_WOREVT0
0xfb,       // CCxxx0_WORCTRL
0xb6,       // CCxxx0_FREND1
0x10,       // CCxxx0_FREND0
0xea,       // CCxxx0_FSCAL3
0x2a,       // CCxxx0_FSCAL2
0x00,       // CCxxx0_FSCAL1
0x1f,       // CCxxx0_FSCAL0
0x41,       // CCxxx0_RCCTRL1
0x00,       // CCxxx0_RCCTRL0
0x59,       // CCxxx0_FSTEST
0x7f,       // CCxxx0_PTEST
0x3f,       // CCxxx0_AGCTEST
0x88,       // CCxxx0_TEST2
0x31,       // CCxxx0_TEST1
0x09,       // CCxxx0_TEST0
0xC0};       // CCxxx0_PATABLE

Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Fatima M.s
    Posted by Fatima M.s
    on Jul 17 2012 05:03 AM
    Prodigy10 points

    I found the problem regarding reading MARCSTATE, I hadn't set the burst bit to 1. so it was actually issuing command strobe!!

    now that I have made it right . I'm getting 0D after issuing STX  !  I'm looking for the problem.

    in the Tx code after CC_Idle() the MARCSTATE is correct (0x01), but after STX MARCSTATE is 0x0D, I read the chip status byte too, it was 0x0f after Idle and 0x1f after STX, it goes to receive mode! I checked everything I could think of, STX address is 0x35 and the codes are in the first post, I left this:

    unsigned char CC_SpiWr(unsigned char data)

    { unsigned char received=0;

    SPDR = data;

    while(!(SPSR & (1<<7)));

    received=SPDR;

    return(received);

    }

    I don't know why it keeps going to receive mode. what did I miss?

    thanks in advance

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Fatima M.s
    Posted by Fatima M.s
    on Jul 18 2012 06:18 AM
    Prodigy10 points

    I solve the problem I don't know exactly how, but I manged to read MARCSTATE and chip status byte correctly. now there is another problem.

    MARCSTATE in TX in 0x13 and chip status byte is 0x20. TX code  is placed above, in receiver GDO0 pin stays low, it seems that it doesn't receive any sync word, registers all exactly the same in transmitter and receiver, this RX code:

    CC_Idle();
    for(j=0;j<47;j++)
                     {    
                       CC_WrReg(j,RF_setting[j]);
                     };
                     CC_WrReg(CCxxx0_PATABLE,RF_setting[47]);
             delay_ms(20);
    CC_RxOn();
       
                            
             for(i=0;i<62;i++)
                 {
                 RFData[i]=0;
                 };        
                  lcd_gotoxy(0,0);
                  read[2]= CC_RdStatus(CCxxx0_MARCSTATE);
                  sprintf(buffer_lcd,"MS2=%x",read[2]);
                   lcd_puts(buffer_lcd);

             while (1)
             {    

                  if(PIND.3)  //PIND.3 is connected to GDO0
                  {
                    while (PIND.3);  
                        
                   
                    iLen= CC_RdReg(CCxxx0_RXFIFO); //variable packet length
                    Addr=CC_RdReg(CCxxx0_RXFIFO);  // address check enabled
                            lcd_gotoxy(0,1);
                            sprintf(buffer_lcd,"iLen=%x ",iLen);
                            lcd_puts(buffer_lcd);
                            
                            sprintf(buffer_lcd,"Addr=%x",Addr);
                            lcd_puts(buffer_lcd);

                    if (iLen!=0&&iLen<64&&Addr==5)
                    {   
                       CC_RdRegs(CCxxx0_RXFIFO,RFData,iLen-1);
                       CC_ClrRx();
                       delay_ms(1);
                       CC_RxOn();
                       delay_ms(5);
                       conter1=0;
                       PORTC.3=1;
                       
                       lcd_clear();
                       lcd_gotoxy(0,0);
                       for(i=0;i<iLen-1;i++)
                            {
                            sprintf(buffer_lcd,"%d",RFData[i]);
                            lcd_puts(buffer_lcd);
                            }
                    }
                   

                else
                    {
                       CC_ClrRx();
                       delay_ms(1);
                       CC_RxOn();   
                       delay_ms(5);
                    };     
                  }  
             };
         

    MARCSTATE  in receiver is 0X0D and chip status byte is 0x10, but it receives nothing

    does anybody know where the problem is?

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Fatima M.s
    Posted by Fatima M.s
    on Aug 01 2012 05:07 AM
    Prodigy10 points

    hi again

    I managed to solve the problem , I can send and receive data.
    i faced another problem:
    I want to sent 30 byte of data, address check and variable data length are enable:

    transmitter:

    CC_WrReg(CCxxx0_TXFIFO,0X1F);
    CC_WrReg(CCxxx0_TXFIFO,5);
    CC_WrRegs(CCxxx0_TXFIFO,DataAES,30);
    receiver:

    iLen= CC_RdReg(CCxxx0_RXFIFO);
    Addr=CC_RdReg(CCxxx0_RXFIFO);

    if (iLen!=0&&iLen<64&&Addr==5)
    {
    CC_RdRegs(CCxxx0_RXFIFO,DataAES,iLen-1);
    ...
    }

    I receive first to sixteenth bytes correctly then 3 bytes wrong values then the other 11 bytes correct again.
    first I thought it's noise but this 3 bytes wrong values are always the same for a specific data. and it's always bytes number 17-19.
    does anybody knows why this is happening?

    unsigned char RF_setting[48]=
    {0x29,       // CCxxx0_IOCFG2       
    0x2e,       //CCxxx0_IOCFG1
    0x06,       //CCxxx0_IOCFG0
    0x47,       //CCxxx0_FIFOTHR
    0xd3,       //CCxxx0_SYNC1
    0x91,       //CCxxx0_SYNC0
    0x3d,       //CCxxx0_PKTLEN
    0x05,       //CCxxx0_PKTCTRL1
    0x05,       //CCxxx0_PKTCTRL0
    0x05,       //CCxxx0_ADDR
    0x00,       //CCxxx0_CHANNR
    0x06,       //CCxxx0_FSCTRL1
    0x00,       //CCxxx0_FSCTRL0
    0x21,       //CCxxx0_FREQ2
    0x62,       //CCxxx0_FREQ1
    0x76,       //CCxxx0_FREQ0
    0xf5,       //CCxxx0_MDMCFG4
    0x83,       //CCxxx0_MDMCFG3
    0x13,       //CCxxx0_MDMCFG2
    0x22,       //CCxxx0_MDMCFG1
    0xf8,       //CCxxx0_MDMCFG0
    0x15,       //CCxxx0_DEVIATN
    0x07,       //CCxxx0_MCSM2
    0x3f,       //CCxxx0_MCSM1
    0x18,       // CCxxx0_MCSM0
    0x16,       // CCxxx0_FOCCFG
    0x1c,       // CCxxx0_BSCFG
    0xc7,       // CCxxx0_AGCCTRL2
    0x00,       // CCxxx0_AGCCTRL1
    0xb0,       // CCxxx0_AGCCTRL0
    0x87,       // CCxxx0_WOREVT1
    0x6b,       // CCxxx0_WOREVT0
    0xfb,       // CCxxx0_WORCTRL
    0xb6,       // CCxxx0_FREND1
    0x10,       // CCxxx0_FREND0
    0xe9,       // CCxxx0_FSCAL3
    0x2a,       // CCxxx0_FSCAL2
    0x00,       // CCxxx0_FSCAL1
    0x1f,       // CCxxx0_FSCAL0
    0x41,       // CCxxx0_RCCTRL1
    0x00,       // CCxxx0_RCCTRL0
    0x59,       // CCxxx0_FSTEST
    0x7f,       // CCxxx0_PTEST
    0x3f,       // CCxxx0_AGCTEST
    0x81,       // CCxxx0_TEST2
    0x35,       // CCxxx0_TEST1
    0x09,       // CCxxx0_TEST0
    0xC8};       // CCxxx0_PATABLE

    thanks in advance for your help

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Fatima M.s
    Posted by Fatima M.s
    on Aug 02 2012 00:19 AM
    Prodigy10 points

    isn't there anybody to answer?

    I'm reading PARTNUM value ff and VERSION f. does this mean that the chip  is partially dead?

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Fatima M.s
    Posted by Fatima M.s
    on Aug 06 2012 05:32 AM
    Prodigy10 points

    I used the wrong function to read status registers, i'm reading PARTNUM and VERSION correct.

    other register values for :   30 bytes data, variable length and address check enable


    chip status byte: 0x10(RX)    0x20(TX)
    TXBYTES(0x3A): 33
    RXBYTES(0x3B): 32
    MARCSTATE:  0x0d(RX)    0x13(TX)

    I tried sending 60 bytes, all correct except bytes number 17-19

    first I thought it has something to do with register setting but then I doubted that it might be hardware problem.

    can anyone help please?
    thanks a lot

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • TIABO
    Posted by TIABO
    on Aug 07 2012 02:56 AM
    Expert6785 points

    Hi,

    Good to hear that you were able to read the registers correctly. Is the problem _always_ located in bytes 17-19? Do you receive packets where the CRC checks out?

    Br,
    ABO 

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
TI E2E™ Community
  • Support Forums
  • Blogs
  • Videos
  • Groups
  • Site Support & Feedback
  • Settings
TI E2E™ Community Groups
  • TI University Program
  • Make the Switch
  • Microcontroller Projects
  • Motor Drive & Control
Other Communities
  • Deyisupport
  • Designsomething.org
  • beagleboard.org
  • TI on Element 14
  • TI on TechXchangeSM
Other Technical & Support Resources
  • WEBENCH® Design Center
  • Product Information Centers
  • Technical Documents
  • TI Design Network
  • TI Technical Articles
  • TI Training

All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Terms of Use of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Terms of Use of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.

Follow Us Texas Instruments on Facebook Texas Instruments on Twitter Texas Instruments on LinkedIn Texas Instruments on Google+
TI Worldwide | Contact Us | my.TI Login | Site Map | Corporate Citizenship | mobile m.ti.com (Mobile Version)

TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs and
embedded processors, along with software, tools and the industry’s largest sales/support staff.

© Copyright 1995-2013 Texas Instruments Incorporated. All rights reserved.
Trademarks | Privacy Policy | Terms of Use