CC1200: Trouble reading standard packet or encrypted packet

If the interrupts occur as expected, I would assume that data is received in the FIFO.

From your register settings I cannot see that you are using any CRC filtering, meaning that if a packet first is being placed in the FIFO, it should remain there until the FIFO is read or you flushed the FIFO.

Have you monitored you SPI when you are reading NUM_RXBYTES? Remember that this register is in extended register space.

I have not been able to verify your settings because there are a lot going on there with RF registers changes from default, WOR settings, RX Termination Based on PQT etc.

Have you tried to just use default settings from SmartRF Studio (select wanted frequency and data rate in SmartRF Studio), and then verified that you can receive packets with these settings? (Do not use WOR etc. just simple RX and TX)

Once you have verified that this work, you can change the RF parameters one by one to see that the changes does not break anything, and then you can start enabling the special features.

Doing it this way, it will be easier to figure our what exactly causes the problems you are seeing.

Thanks, Siri:

    I’m using GPIO0 for the radio interrupts but the examples use Gpio2. Would you mind to look at my interrupts, please.

//Gpio0 is wired into p1.2 and P7.1.  P1.2 catches gpio0’s rising edge and P7.1 //catches the falling edge.

#pragma vector=PORT1_VECTOR

__interrupt void radioRxISR(void)  //irqs for GPIO0 rising edge Rx interrupt

 {

    if( (P1IFG & BIT2)==BIT2)       //P1.2 irq

    {

        if((uFixedMode == RxMode) && (RxCald) && ( !RecIrqRunning))  //RxMode=2.  make sure rx has been cal'd and rx isn't already running!

        {

           RecIrqRunning =1; //set rec packet semaphore. rising edge, sync sent. 

           RunRx();              //start receiving

        }

        P1IFG &= ~BIT2;         //clear interrupt flag for P1.2 (GPIO0)

 }

//Gpio0 is also connected to P7.1 which catches its negative falling edge:

#pragma vector=PORT7_VECTOR      //falling edge irq on P7.1 to catch GPIO0 going low

__interrupt void radioTxISR(void)  //irqs for GPIO0 and GPIO2 MISO, MOSI, SCLK port1

{

        P7IFG &= ~BIT1;         //clear interrupt flag for P7.1 (connected to GPIO0)

        if (uFixedMode == TxMode)              //TxMode =1

        {

            packetSemaphore = TISR_ACTION_REQUIRED; //set transmit semaphore (falling edge, packet sent)

        }

}

    // Radio interrupts are set up as follows:

    // Connect ISR function to GPIO0 P1.2:

    P1SEL0 &= ~BIT2;          //select GPIO for P1.2

    P1SEL1 &= ~BIT2;

    P1DIR &= ~BIT2;          //set dir to input

    //P1REN |= (BIT2) ;       //pullup

    P1IES &= ~BIT2;          //Rising edge 0->1 gives sync rec'd irq (receive)

    P1IFG &= ~BIT2;          //clear interrupt flag for P1.2

    P1IE |= (BIT2) ;        //ie enable flag

    P1IFG =0;               //clear all irq flags for P1

    // connect ISR function to GPIO0 P7.1:

    P7SEL0 &= ~BIT1;        //select GPIO for P7.1

    P7SEL1 &= ~BIT1;

    P7DIR &= ~BIT1;         //set dir to input

    P7IES |= BIT1;          //falling edge

    P7IFG =0;               //clear all interrupt flags for P7

    P7IE |= BIT1;           //ie tx irq enable flag

John

I cannot review your MCU implementation for the interrupt. First of all, I do not even know what MCU you are using, and second, if you are using an MCU from TI you will need to ask this question in the proper forum (If you are using an MSP, you need to ask in the MSP forum), as I am only familiar with the RF devices supported by this forum

In addition to monitor the SPI and do all the testing I advised you to do in the last post, there are some simple teste you can do to check you interrupt.

The first thing you need to verify is that you enter the ISR when you get a falling edge on GPIO0 (packet received).

If you do not do that, there is something wrong with how you have set up the interrupt and/or the pin connected to GPIO0.

If you are not using length filtering, address filtering, or autoflushing of the FIFO on CRC error,

reading CC120X_NUM_RXBYTES in the ISR should show you that there are data in the RX FIFO.

Siri

I've done these basic tests but will try to do them better.   Using an MSP430FR5994.  The behavior is that it seems to always receive the rising edge irq of gpio0.  I can receive the whole packet every time by then giving time to receive all the bytes.  But the bytes aren't ready when the falling edge of gpio0 arrives.

If IOCFG0 = 0x06, the complete packet is present in the RX FIFO when GPIO0 is de-asserted.

There is not added anything to the FIFO after that. If you read NUM_RXRBYTES after that it will either be 0 (if you use some kind of filtering and the packet has been filtered away) or it will tell you how many bytes have been received in the packet (including length byte and optional status bytes).

I do not understand why your code have an interrupt at a rising edge of this signal? Why do you want to know when a sync word has been sent and/or received

Siri

Thanks, Siri:

     The rising edge of the gpio0 is used to tell the transmitter it is time to send the packet.  But I found that it can also be used to receive after waiting to receive all the packets.  This works every time but when falling edge gpio is used, there is no data available in my system.

John

I am sorry but I am not sure what you mean. You should not wait for a rising interrupt on the transmitter before you start writing to the TXFIFO. You should write to the TX FIFO and then Strobe STX, and the only signal you need to care about after that is a falling edge on GPIO0, telling you that the packet has been sent, your TX FIFO is empty and the radio is back in IDLE state (if you test with recommended settings from STudio, as I suggested).

On the RX side, the only thing you should do  is wait for falling edge on GPIO0, Check that there are bytes in the FIFO (it will be unless you are using filtering), and then read those bytes.

For me to help you further you need to do the tests I have asked you to and then provide me the results:

Use recommended settings from SmartRF Studio

Make sure IOCFG0 = 0x06

Init the MCU and radio and strobe SRX

Transmit a packet (you can use SmartRF Studio for simplicity)

Verify that you are getting an interrupt in your code on falling edge of GPIO0

Provide me with SPI plots of when you read the NUM_RXBYTES regsiter after the interrupt has occured

Siri

Thanks, Siri:

    I've been sick but will do this as soon as possible.

John