• 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 Proprietary Software & SimpliciTI Forum » RFRXTXIF only asserted once
Share
Low Power RF & Wireless Connectivity
  • Forums
  • Announcements
  • Files
  • E2E Wiki
Options
  • Subscribe via RSS

Forums

RFRXTXIF only asserted once

This question is answered
quilkin
Posted by quilkin
on Apr 03 2012 11:29 AM
Intellectual410 points

Hi

I have been using packet mode RX and TX (using DMA) successfully using a CC1110 but need to change to receiving & checking individual bytes because I need to receive data from a different protocol where the packet length doesn't fit the DMA method.

So now I have a interrupt as follows....

#pragma vector=RFTXRX_VECTOR
__interrupt void rfbyte_IRQ(void) {

    if (sppIntData.mode == SPP_RX_MODE) {
       byteRcvdFlag = TRUE;

      recdByte=RFD;
    }
    RFTXRXIF=0;
}

.....but this only ever fires once. The correct byte is received (first after the SYNC byte) but no others.

I have tried testing for RX_OVERFLOW etc but no difference. Clearly I am missing something fundamental.

Thanks in advance.

Report Abuse
  • Reply
You have posted to a forum that requires a moderator to approve posts before they are publicly available.
All Replies
  • Siri
    Posted by Siri
    on Apr 10 2012 02:49 AM
    Expert4650 points

    Hi

    Here is some code you can use to test the  RFTXRXIF flag. This code can be tested together with SmartRF Studio as the transmitter (use the recommended 1.2 kBaud setting).

    void main(void) {
      // Choose the crystal oscillator as the system clock and set system clock
      // speed = fRef (fxosc)
      CLKCON = CLKCON_26_MHZ_XOSC; // Request switch to crystal oscillator
      while (CLKCON & OSC_BIT); // Wait until the clock switch has occurred
      SLEEP |= OSC_PD_BIT; // Power down unused oscillator

      PKTCTRL0  = 0x05; // packet automation control
      FSCTRL1   = 0x06; // frequency synthesizer control
      FREQ2     = 0x21; // frequency control word, high byte
      FREQ1     = 0x65; // frequency control word, middle byte
      FREQ0     = 0x6A; // frequency control word, low byte
      MDMCFG4   = 0xF5; // modem configuration
      MDMCFG3   = 0x83; // modem configuration
      MDMCFG2   = 0x13; // modem configuration
      DEVIATN   = 0x15; // modem deviation setting
      MCSM0     = 0x18; // main radio control state machine configuration
      FOCCFG    = 0x17; // frequency offset compensation configuration
      FSCAL3    = 0xE9; // frequency synthesizer calibration
      FSCAL2    = 0x2A; // frequency synthesizer calibration
      FSCAL1    = 0x00; // frequency synthesizer calibration
      FSCAL0    = 0x1F; // frequency synthesizer calibration
      TEST1     = 0x31; // various test settings
      TEST0     = 0x09; // various test settings
      PA_TABLE0 = 0x50; // pa power setting 0
      IOCFG0    = 0x06; // radio test signal configuration (p1_5)

      // Infinite loop
      while (TRUE) {
        UINT8 i = 0;
        RFST = STROBE_RX;
        
        while (!RFTXRXIF);
        RFTXRXIF = 0;
        rxBuffer[i++] = RFD;
        
        while (i < rxBuffer[0] + 3 ) {
          while (!RFTXRXIF);
          RFTXRXIF = 0;
          rxBuffer[i++] = RFD;
        }
        if (rxBuffer[rxBuffer[0] + 2] & 0x80)
          packetReceived++;
      }
    }

    I have tested this and it works. If you get this to work your problem is probably related to the way you set up your interrupts.

    BR

    Siri

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • quilkin
    Posted by quilkin
    on Apr 10 2012 11:24 AM
    Intellectual410 points

    Hi Siri

     

    Many thanks for your reply.

    After checking all the regsiters in your sample against my code I find the only differences that have an effect are to do with the packet size. I have PKTCTRL0 as 0x04, i.e. fixed packet size.

    I have now tried a variable size and find that all data is received as expected, as long as PKTLEN is defined as longer than the actual packet size transmitted. That's fine and as expected.

    If I try a fixed packet size on the transmitter, I seem to get one good packet received but no more; subsequently I just get  one byte and no further RFTXRXIF assertions (whatever the packet size is defined as).

    I am trying to receive packets from an older CC1010 system and I don't know what the packet size is going to be before I receive part of it. The size is not defined in the first byte after SYNC, as it would be for a CC1110 packet (the size is actually in the 3rd byte, the first byte is the destination address of the packet).

    Is it the case that, even when receiving data in a 'byte-by-byte' mode (i.e. not using DMA for packets) , that the receiver will still attempt to collect 'x' bytes before  RFTXRXIF is asserted, where x is either the first byte of the packet (variable length mode) or the number of bytes defined by PKTLEN (fixed length mode)?  In other words, is there any way I can set this up to receive (and interrogate) just three bytes of a packet, without knowing the packet size or waiting for an arbitrarily long packet to arrive?

    If not, this gives me a problem because I need to send an acknowledgement within a short time of receiving the packet. If the packet is small then the originator of the packet will time out waiting for this acknowledgement. (The orginator of the packet is using the 'SImple Packet Protocol' which was example code for the CC1010.)

    Best regards

    Chris

    cc1110 packet length CC1010
    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • Siri
    Posted by Siri
    on Apr 11 2012 03:09 AM
    Expert4650 points

    Hi

    Assume you want to receive the following packet:

    Preamble - sync - x - x - Length n - data_1 - data_2 - ... - data_n-1 - data_n - CRC - CRC

    On the receiver you should use fixed packet length and set packet length to a high number. Then you can run the following code:

     

    while (TRUE) {

        UINT8 i = 0;
        RFST = STROBE_RX;
        while (i < 3 ) {
          while (!RFTXRXIF);
          RFTXRXIF = 0;
          rxBuffer[i++] = RFD;
        }
        PKTLEN = rxBuffer[2] + 3;
        while (i < rxBuffer[2] + 5 ) {
          while (!RFTXRXIF);
          RFTXRXIF = 0;
          rxBuffer[i++] = RFD;
        }
        if (rxBuffer[rxBuffer[2] + 4] & 0x80)
          packetReceived++;

    }

    It is here assumed that CRC calculation is enabled together with append status.

    BR

    Siri

    Report Abuse
    • Reply
    You have posted to a forum that requires a moderator to approve posts before they are publicly available.
  • quilkin
    Posted by quilkin
    on Apr 16 2012 07:04 AM
    Verified Answer
    Verified by Siri
    Intellectual410 points

    Siri

    Brilliant, this has solved it. I never thought to change PKTLEN on the fly like this.

    I now have CC1010 talking to CC1110 with the orginal 'SPP' protocol.

    Many thanks

    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