• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 1078 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.

CC1101 falsely indicating that sync word and packet received

Shreya V K
Prodigy 80 points
Other Parts Discussed in Thread: CC1101

Hi everybody!

I'm an undergrad student attempting to use cc1101 as a receiver using msp430. At present, GDO0 pin (connected to P1.7 of MSP in the experimenter's board) has been configured such that it gets asserted when SYNC word has been received and gets de-asserted once packet reception is complete and the program is written in such a way that assertion and de-assertion of the pin P1.7 generate interrupts where the interrupt service routine displays "Sync word received" and "Packet reception complete" on the terminal i/o.  The problem is that P1IFG7 flag gets set on it's own when SRES command is issued, leading to an interrupt being generated on P1.7 as soon as P1IE is set (Interrupts are enabled on port 1), thereby falsely displaying that sync word and packet have been received, when infact NOTHING HAS BEEN TRANSMITTED YET. Giving a software solution by clearing P1IFG flag before enabling interrupts doesn't seem to work as the flag doesn't get cleared. How do I fix this? What could be the problem?

My code follows the following sequence:

  1. Power on reset code +SRES
  2. Set CC1101 to idle mode.
  3. Flush TX and RX FIFOs
  4. Configure all registers
  5. P1IES&=0x7f (High to low transition generates interrupt on P1.7)
  6. Enable GIE
  7. SCAL command strobe
  8. P1IE|=0x80 (Enable P1.7 interrupts)// This is when the isr is falsely getting started right now
  9. Issue SRX command strobe.

Thanks in advance!

  • 0
    TI__Genius 12735 points

    Hi

    Most likely are the radio detecting sync word in the channel noise. This can happen if you use a sync word with poor auto correlation properties or you are not gating the sync word detection. It is recommended to  use the default sync word provided by SmartRF Studio.  Please see section 17.1 and 17.2 in the user guides for more information about sync word gating.

  • 0 in reply to Martin B
    Prodigy 80 points

    Martin, first of all, thanks for the quick reply! I tried using the default SmartRF Studio values for the sync word (SYNC1-0xD3, SYNC0-0x91), but to no avail! Even now, P1IFG7 is getting set (sometimes this sets even before the code is started) and falsely messages are being displayed

  • 0 in reply to Shreya V K
    TI__Genius 12735 points

    If you get interrupts before the radio has gone into RX, it sounds that you have some noise on the IO line that causes the interrupt. I would use a oscilloscope to debug the IO line to verify that the only signal pulling on the line comes from the radio and that the radio only asserts when it is in fact in RX. 

  • 0 in reply to Martin B
    Prodigy 80 points

    Thank you so much Martin! You were a big help!

    Turns out, the problem was that I had configured IOCFG0 as 0x06 after PIIE was set. While I thought this wouldn't affect the code, the oscillator showed me that as soon as SRES was issued, GDO0 pin started giving a periodic signal. Further perusal of the datasheet made me realise that since SRES sets all registers to the reset configuration, which for GDO0 is CLK_XOSC/192, the clock signal was probably the one generating interrupts on P1.7 leading to the erroneous display of messages.

  • 0 in reply to Shreya V K
    TI__Genius 12735 points

    Hi

    I'm glad you solved the issue. You are correct that when the radio is reset the default output on GPIO0 is 0x3F which will give you a 135 kHz clock (26MHz XOSC/192) output.

    Best of luck continuing forward!