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.

CC1200: CC1200

Part Number: CC1200

Dear Sirs:

     We are starting production of a transceiver using the cc1200.  Testing has revealed that receivers lock up at random intervals from 4hours to 2 days.  We have discovered that whenever lockup occurs, the carrier sense valid stops pulsing.  So we are using this signal to tell whether the 

receiver needs to be re-initialized.  We are using the receiver in sniff mode.

The question is whether this is a good way or if there is a better way.

Thanks

John Moore

  • If the carrier sense signal stops pulsing, I would assume that the radio has stopped entering RX mode (you are not getting any more WOR events (WOR_EVENT0/1/2 can be monitored on a GPIO).

    Hi John

    This is most likely because the SW is not doing error handling properly, and the radio ends up in IDLE state rather than going back to SLEEP, and the application is not strobing it back in WOR mode.

    I would strongly recommend that you find the root cause of why the radio “is stuck” and fix this, rather than implementing a work-around. When I do not know what is causing your failure, I will not recommend any fix either.

    Typical problems can be that you are not using packet length filtering and that your buffers are not large enough for the max length packet (length byte + 255 payload bytes + 2 status bytes) or that your RXFIFO overflows.

    If you are in RX FIFO ERROR state, the radio will not go back to WOR mode before you flush the RX FIFO (SFRX) and send another WOR Strobe (SWOR).

    If you are using packet length filtering, are you settings TERM_ON_BAD_PACKET_EN = 0?

    BR

    Siri

  • Thanks, Siri:

         I'll check out your suggestions.

    John

  • Hi, Siri:

          In the interrupt driven rx routine I do a read to determine the message type (how long it is), then read the rest of the message.

    Then I read one more byte and read no of bytes.  This could be wrong!!:

    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //test Read one more byte in Rx FIFO. subs.c
    cc120xSpiReadRxFifo(rxBuffer, (rxBytes)); // for test.  in subs.c

    Then Check for errors.  If any flush fifo and set to sniff mode.:


    //CheckForErrors: check for packet errors

    cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);    //check the state.

    if(marcState ==0x11)
    {
    WaitForIdleState(); //wait for idle state to be reached
    trxSpiCmdStrobe(CC120X_SFRX); //3A. command to flush rx fifo
    WaitForIdleState(); //wait for idle state to be reached
    trxSpiCmdStrobe(CC120X_SWOR); //set radio to rf sniff mode
    }

    Thanks,

    John

  • Hi John

    If you do any reading BEFORE the following lines;

    cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //test Read one more byte in Rx FIFO. subs.c
    cc120xSpiReadRxFifo(rxBuffer, (rxBytes)); // for test.  in subs.c

    this might be wrong. You should ALWAYS check that there are data in the FIFO before you read it.

    Also, I am wondering about your error checking.

    what do you do in the WaitForIdleState (except waiting for IDLE)? Are you strobing IDLE and then wait for IDLE to be entered?

    If, you do, this is not necessary, as you can strobe SFRX directly when in RX_FIFO_ERR state.

    If you are just polling MARCSTATE for IDLE, this is wrong, as the radio will not enter IDLE automatically from RX_FIFO_ERR state (MARCSTATE = 0x11)

    could it be that you are stuck in this state, waiting for IDLE?

    Siri

  • Thanks, Siri, you are a lifesaver:

         I corrected my code based on your remarks to the following near the end of the runrx function:

    //cc120xSpiReadRxFifo(rxBuffer, (rxBytes)); // in subs                                                          Removed these 3 lines
    //if(rxBytes>0)
    // cc120xSpiReadReg(CC120X_NUM_RXBYTES, &rxBytes, 1); //clean out the fifo subs.c

    //CheckForErrors: check for packet errors                     
    cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1); //check the state.                                    corrected this
    if((marcState & 0x1F) ==0x11) //rec fifo error
    {
    trxSpiCmdStrobe(CC120X_SFRX); //3A. command to flush rx fifo and go to idle state
    WaitForIdleState(); //wait for idle state to be reached
    trxSpiCmdStrobe(CC120X_SWOR); //set radio to rf sniff mode
    }
    else
    {
    if((marcState & 0x1F) ==0x1) //in idle?
    trxSpiCmdStrobe(CC120X_SWOR); //set radio to rf sniff mode                                                             this seems to be needed
    }

         Thanks,   John

  • Siri:

         The receiver runs in ewor mode.

         In the main loop outside interrupts, I am also checking marcstate to see if it is in idle mode.

    If it is in idle mode this routine then does: 

                   trxSpiCmdStrobe(CC120X_SWOR);   //set radio to rf sniff mode 

    But ewor timer causes the receiver to go in and out of idle/receive modes so will this sometimes 

    read idle mode or will it always read ewor mode?

    thanks, John

  • You will never be able to read that the chip is in ewor mode, since ewor is a mode and not a state.

    When using ewor, the radio is either in SLEEP, IDLE, SETTLING or RX. If it is in SLEEP when you start to read, pulling CSn low will wake up the device, so that MARCSTATE will report IDLE.

    BR

    Siri

  • Thanks, Siri:

        So it appears that using the CSValid pulse is as good as anything to tell if the radio is in sniff mode??

    John

  • I do not think CARRIER_SENSE_VALID can be used.

    According to the User's guide, the CS response time is the time it takes before CARRIER_SENSE_VALID is asserted. This is the
    maximum time the radio will be in RX state when RX termination based on CS is enabled, so I think that this signal will not be asserted before the radio actually exit RX. Another "problem" is that this signal will be hardwired to 0 or 1 in SLEEP state, depending on which GPIO you choose to output it to (In the below, WOR_EVENT0 is output to GPIO2 and CARRIER_SENSE_VALID to GPIO3 when running Sniff mode:

    by using a signal where IOCFGx.GPIOx_CFG setting is 0x30 or higher (for example one of the WOR_EVENT0) will give you a clear indication that sniff mode is running.

    BR

    Siri

  • Good information, Siri:

        We actually use the radio in sniff mode all the time.  The interrupt routine looks at the Carrier_Sense_Valid pulse which seems to be present every sniff cycle.  The irq keeps count of these pulses over .2 sec intervals.  If the count drops below 5 in .2 sec, the software assumes the receiver is locked and then it is re-initialized.

    It actually works well  so far.  I'm using GPIO3 to read CS and GPIO2 to read CS_Valid so I'm a little short of GPIO bits to look at EWOR events.

        Do you think this will work?

    Thanks, John 

  • Hi John

    I did some more testing, and your suggestion seems fine. However, it should be fully possible to write the applications so that the system never hangs, but I guess a "backup" solution to fix problems that the code does not take care of can't hurt :-)

    BR

    Siri

  • Thanks, Siri:

        Some units now hang then reset whenever communicated with via RS232.  I'm wondering if I should enhance the watchdog with

    an added software watchdog as well??

    John

  • If there are problems with your MCU code, I am not comfortable giving you advice as I do not even know what MCU you are using and what you are doing in the code.

    It is always good to add watchdog, and different kinds of error handling, but if the code is in such a state that you often gets into error situations that could only be "fixed" by resetting the device, I would recommend finding the root cause of what is causing the errors instead :-)

    BR

    Siri

  • Thanks, Siri

    John