• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 18 subscribers
  • Views 1423 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC430 / RFIFG10 Problem

Chris_CBC
Intellectual 470 points
Other Parts Discussed in Thread: CC1101, CC1100

Hi All,

I am using a CC430 in a project where I need the RF1A module to do a "windowed" receive. To initialize the sequence a syncronizing beacon is transmitted and then the CC1101 receiver is turned on for about 4 mS (or shorter is a message is received before the timeout). To detect a reception I am using the RFIFG10 Radio Core Interrupt. Its functionality is listed in table 22-5 of the User Guide as follows:

RFIFG10
Positive edge: Packet received with CRC OK.
Negative edge: First byte read from RX FIFO. (Equal to GDOx_CFG=7)

I have used this interrupt sucessfully on stand alone CC1100 parts in the past so I am familiar with the functionality, but the CC430 RF1A doesn't seem to be functioning as I expect. The interrupt seems to work properly once, and then never occurs again. But when I look in the Rx FIFO after the timeout occurs I can see the expected message sitting in the buffer. So the message is being received, but the interrupt is not occuring.

Further investigation led to inspection of the "Radio core signal input register" (RF1AIN Register). This register is the source of the RFIFG10 flag. I think the way it works is the RF1AIN bit 10 signal should go low to high when the CRC is verified and should go high to low when the first byte is read from the FIFO. The problem I am having is that I cannot get the RF1AIN bit 10 to clear without reseting the RF1A module. If I reset then the above cycle starts over again, but leaves me in the same spot with only the first messsage triggering the "Packet received with CRC OK" interrupt.I have tried several things to clear the bit, but can't find a confiiguration that or work around that works.

I have also looked thru the Errata and can't find a bug that matches my experience. Although RF1A5 is close as it deals with these interrupts as well.

Has anyone else found this problem? Is it something I don't have configured properly?

  • 0
    TI__Genius 14940 points

    You must read the RF1AIV register to reset the interrupt flip flop.  Simply clearing the flag in the IFG register does not reset the ISR state flag.

    Jim Noxon

  • 0 in reply to Jim Noxon
    Intellectual 470 points

    Hi Jim,

    Thanks for your reply, but I am not sure I understand your answer WRT to my description of the problem.

    The first reception causes a RFIFG10 positive edge interrupt and I service the interrupt using the RF1AIV vector. The RF1AIFG and RF1AIE registers are performing as I would expect them too. The problem occurs after the first reception / interrupt occurs.

    I am unable to get a second RFIFG10 positive edge interrupt because the signal that it is derived from (bit ten of the RF1AIN register) never clears. My understaning of the data sheet is as follows:

    Bit 10 of the RF1AIN should go from low to high when a "Packet received with CRC OK.", and

    Bit 10 of the RF1AIN should go from high to low when First byte is read from RX FIFO.

    On the first interrupt the RF1AIN bit 10 does go from low to high which causes the RFIFG10 interrupt. The ISR reads the data from the FIFO which should have cleared RF1AIN bit 10. But the RF1AIN bit 10 never goes low. This sets up the situation where the positive edge interrupt (Packet received with CRC OK) cannot occur because the positive edge never occurs.

    What I don't understand is why the RF1AIN bit 10 never goes low. I think I am doing what the datasheet says will clear the bit, but it doesn't happen. Bit 10 is stuck high and thus the interrupt can't trip a second or subsequent time.

    The problem seems to be occuring beneath the layer of interrupts and interrupt processing. It looks like the problem it is at the underlying hardware layer of the CC1101. But that is just my humble opinion and I hoping I am wrong. 

    What do you think?

    Chris

  • 0 in reply to Chris_CBC
    TI__Mastermind 36395 points

    Chris,

    Did you select which edge you wanted to be interupted on? Here is an example from the demo code for the CC430. 

      // BIT9 is the Sync recieved/sent and end-of-packet.
      RF1AIES |=  BIT9;        // edge select, high to low (end-of-packet)
      RF1AIFG &= ~BIT9;        // Clear pending interrupts
      RF1AIE  |=  BIT9;        // Enable RX end-of-packet interrupt

    You have to select which edge you want the interupt to happen on using RF1AIES.
    Regards
    /TA 

  • 0 in reply to TA12012
    Intellectual 470 points

    Hi TA,

    Thanks for your input. I have confirmed the edges are correct, but I am using two different interrupts rather than two sides of the same interrupt. Using RFIFG10 on the receive side offers the benefit of doing the CRC check in the CC1101, and thus I don't need to check once I draw the message into the uC.

    I use the following interrupts from the C1101 RF1a module:

    1. I use RFIFG9 (falling edge) for Tx complete --> The datasheet / user guide says this is " end of packet".

    2. And use RFIFG10 (rising edge) for Rx complete with CRC check  --> The datasheet / user guide says this is "Packet received with CRC OK".

    I pulled these details from page 538 of the user guide.

    The problem is that the RFIFG10 interrupt only works once after the RF1A module is reset. After that it is stuck (read never trips again). The stuck condition, as far as I can tell, is because the RF1AIN register (RFIFG10 is linked to the RF1AIN10 bit) is not behaving as I expect. Or what I understand to be the exepcted behaviour as per my understaning of the datasheet.

    To my understanding bit 10 of RF1AIN should set when the message CRC is confirmed, and should clear when I read the message data from the Rx FIFO. It is setting on the CRC, but I can't get it to clear when I read the Rx FIFO.

    What do you think about the RF1AIN register's behaviour. Is my interpretation correct? Or am I out to lunch?

    This is a challenging problem...perhaps i am going to have to offer up a reward? How does a case of beer sound!!!

    Chris

     

     

  • 0 in reply to Chris_CBC
    TI__Genius 14940 points

    After conferring with the MSP430 group, this is a known issue.  I wasn't given all the details but there will be some errata coming out (somewhere in the future).  All I can tell you is to find another interrupt signal to use as there is also no work around they could provide me at this time.

    I'm sure you've been pulling your hair out over this for a while now.  I doubt TI will compensate you for your newly required Rogain prescription but I do empathize with you if that helps.

    Regards,

    Jim Noxon

  • 0 in reply to Jim Noxon
    Intellectual 470 points

    Hi Jim,

    Thanks for your follow up. In parallel with your response I got a response back from another TI contact that I queried about this issue.

    The  response confirms your description.

    In their response they said the Errata would be published shortly. The summary of what I was told is as follows:

    The intended behavior of RF1AIN10 is that it is set after the last byte is received [into RX FIFO] and reset after the first byte is read from the RX FIFO.
    However, the actual behavior is that the RF1AIN10 does not reset after the first byte of the RX FIFO is read.

    This is what causes the RFIFG10 interrupt to occur once and then never again. So to work around the problem they suggested...

    Use RF1AIN9 for RX handling instead. To verify the RX packet CRC, enable the RF1A option to append the CRC_OK bit to the end of the RX packet. The CRC_OK bit can be checked after reading out the RX FIFO buffer.

    Well, that seems like a wrap on that issue...Thanks to all who participated.


    Chris


     

  • 0 in reply to Chris_CBC
    TI__Genius 17802 points

    Everyone,

    As Chis mentioned, this behavior has been documented and will appear on the next update of the erratasheet. The erratum will go under the name of RF1A8 in the sheet.

    Regards,

    Dung