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.

CC430F5135 - RECEPTION FAILURE IN LONG TIME OPERATION

Other Parts Discussed in Thread: CC430F5135, TEST2

I have an application with CC430F5135, and occurs an abnormal event when the receiver remains in activity effect for a long time. The system consists of one receptor and many emitters. The emitters work in LPM and work OK. However the receiver fails to receive the signals when it remains for a long period of time without activity. This period can vary of hours to days, according to the test.
In debug with CCS it was found that the firmware is running on the main loop of the program, but the interruption of receiving data via RF does not occur.

Items already checked:
- The interrupt flags are reset;
- The oscillator os 26Mhz it is running (Verified with oscilloscope).
- One reset in Radio core in periodic time can prevent this fault;

I need of help to understand and prevent this failure.

I believe in supporting of the community.

Thanks

  • Hi, 

    One way to get this trouble is Errata RXFIFO_OVERFLOW Issue (see page 8 at http://www.ti.com/lit/er/swrz020d/swrz020d.pdf)

    I had a similar problem when used variable packet length mode and there was a strong interference source for my receiver.

    http://e2e.ti.com/support/wireless_connectivity/f/156/p/338256/1183853.aspx#1183853

     BR

  • Its suggestions are relevance, in my simulations occurs exactly o descrito em "" however i not can determine if is caused by a strong interference.

    A palliative is periodically make a cleaning in RX FIFO. Isn't a elegant solution.


    In my company not have a strong interference source "I believe".

    I read in your post that you have a big dataflux. Small packages in small time periods. In my application have one small package "21 bytes" and a long time inter packages (Hours in most cases).
    And in all failures cases occurs in one big time period of inactivity.
    Ex: Put the receiver in test and simply leave it turned on.


    After a time not receive packages. And a cleaning in RX FIFO solve the problem until the next failure.

    You have one suggestion?

  • Hi,

    What is your RX settings? I think it is the significant info to  analize.

    BR

  • Hi,

    This is my RF settings.

    All another registers is default.

    I be waiting one commentary of this configuration.
    Disregarding the problem cited above, the system working satisfactorily with good distance.

    Thanks!!!

    RF_SETTINGS rfSettings = { //CRISTAL HOSONIC

    0x08, // FSCTRL1 Frequency synthesizer control.
    0x00, // FSCTRL0 Frequency synthesizer control.
    0x22, // FREQ2 Frequency control word, high byte.
    0xB7, // FREQ1 Frequency control word, middle byte.
    0x23, // FREQ0 Frequency control word, low byte.
    0xC9, // MDMCFG4 Modem configuration.
    0x83, // MDMCFG3 Modem configuration.
    0x1B, // MDMCFG2 Modem configuration.
    0x22, // MDMCFG1 Modem configuration.
    0xF8, // MDMCFG0 Modem configuration.
    0x00, // CHANNR Channel number.
    0x34, // DEVIATN Modem deviation setting (when FSK modulation is enabled).
    0x56, // FREND1 Front end RX configuration.
    0x10, // FREND0 Front end TX configuration.
    0x18, // MCSM0 Main Radio Control State Machine configuration.
    0x16, // FOCCFG Frequency Offset Compensation Configuration.
    0x6C, // BSCFG Bit synchronization Configuration.
    0x03, // AGCCTRL2 AGC control.
    0x40, // AGCCTRL1 AGC control.
    0x91, // AGCCTRL0 AGC control.
    0xE9, // FSCAL3 Frequency synthesizer calibration.
    0x2A, // FSCAL2 Frequency synthesizer calibration.
    0x00, // FSCAL1 Frequency synthesizer calibration.
    0x1F, // FSCAL0 Frequency synthesizer calibration.
    0x59, // FSTEST Frequency synthesizer calibration.
    0x81, // TEST2 Various test settings.
    0x35, // TEST1 Various test settings.
    0x09, // TEST0 Various test settings.
    0x4F, // FIFOTHR RXFIFO and TXFIFO thresholds.
    0x29, // IOCFG2 GDO2 output pin configuration.
    0x06, // IOCFG0 GDO0 output pin configuration. Refer to SmartRF® Studio User Manual for detailed pseudo register explanation.
    0x04, // PKTCTRL1 Packet automation control.
    0x05, // PKTCTRL0 Packet automation control.
    0x00, // ADDR Device address.
    0x78 // PKTLEN Packet length.
    };

  • Hi,

    It seems that  [ 0x78 // PKTLEN Packet length. ] is not a good setting if you use just 21 bytes packet.

    I would rather set  PKTLEN = 0x18. Any way it should be less than RX FIFO (64 bytes) for your case.

     

    BR

  • Hi.

    I solve my problem with this app note information: "Posted by Oleg Pushkarev": Errata RXFIFO_OVERFLOW Issue (see page 8 at http://www.ti.com/lit/er/swrz020d/swrz020d.pdf)

     My receive buffer was work in limit, and case of some extra byte "Noise for example." will be   Put the RF receiver in buffer overflow.

    The problem was solved with limiting the receiving buffer length in 60bytes.

    Thanks!