CC1120 infinite packet

Please see example code in http://www.ti.com/litv/zip/swrc253a

Hi TER,

As you suggested, I read the example code. Although I'm not on the same target (PIC) I implemented the same code with ISR etc .. I've achieved to transmit the first 128 bytes but when I write the second packet (128 bytes), the CC1120 doesn't set an interrupt at the end of the transmission. So, I guess that the transmission doesn't start...

The state of the CC1120 is IDLE when I write the second time.

I don't know what I can test now...

Re,

I fixed it by fluishing the Tx FIFO at each transmission. Is it a normal behavior ?

Hi

It is not normal behavior if you need to flush the TXFIFO after each transmission. This means that there are still bytes left in the TXFIFO after transmission. In this case you either write more data to the FIFO than you send or you do not send the entire packet.

Do you have a logic analyzer plot of the fifo threshold ISR and your SPI traffic?

Hi Martin,

In fact the module turns into TX underflow after each transmission. In the TI example, in the FIFO Threshold ISR, you write to the Tx FIFO 122 bytes (AVAILABLE_BYTES_IN_TX_FIFO) despite there are only 121 (128 - 7) bytes free space. Why there is no Tx overflow ? (line 243 cc112x_infinite_packet_length_mode_tx.c)

Also, is the SYCN_RXTX is de-asserted after each transmission or after the last byte sent ?

Regards, Vincent

Hi Vincent

If you get TX underflow you probably do not refill the TXFIFO fast enough.

The TXFIFO_THR signal will assert when the TXFIFO is filled above or equal to the threshold. For a FIFO_THR of 120 the TXFIFO_THR will assert when there are (127 - FIFO_THR = 127 - 120 =7) seven bytes or more in the TXFIFO. When the TXFIFO_THR de-asserts, this means that thre is less than 7 bytes left in the TXFIFO. In other words maximum 6 bytes left in the TXFIFO. Then you can refill the TXFIFO with up to 128 - 6 = 122 bytes.

The PKT_SYNC_RXTX signal asserts when the sync word has been sent, and de-asserts when the last byte has been sent or the TXFIFO underflows/overflows.

Are you using the example code "as is" or have you changed any parameters?

Hi Martin,

Thanks a lot for your answer. As you said, I don't fill the FIFO fast enough. I'm not using the example "as is" cause I don't have enough interrupt entry on my MCU but it is a very good guide.

Also, when I configure the CC1120 in variable packet, I write the length byte then the payload but the module always turns in Tx underflow :s But in the Rx side, I receive a correct packet, CRC ok etc ...

Hi Vincent

Could you post a code snippet of your TX side along with a plot of your SPI transmission when you fill and refill the TXFIFO?

Hi Martin,

This is my code (target : PIC32)

do
                    {
                        //  Wait the FIFO THR interrupt to refill the FIFO
                        while( TxFIFO_THR == 0 );

                        if(byteleft > 128) // How many byte remaining
                        {
                            // Write 128 bytes
                            lprintf("Write 100 bytes \r\n"); // to avoid fifo overflow
                            SPI1_Write_To_Register( STANDARD_FIFO_ACCESS, BURST_ACCESS, STANDARD_ACCESS_FIFO_cmd, ptr_msg, 100 );
                            byteleft -= 100; // byte remaining after write
                            ptr_msg += 100; // point onto the next bytes
                        }
                        else
                        {
                            // fixed packet
                            lprintf("Set fixed packet\r\n");
                            data = 0;
                            SPI1_Write_To_Register(NORMAL_ADDRESS, SINGLE_ACCESS, PKT_CFG0_addr, &data, 1);

                            SPI1_Set_Reset_SS(DELAY_CC1120_SET_RESET);

                            data = byteleft;
                            SPI1_Write_To_Register(NORMAL_ADDRESS, SINGLE_ACCESS, PKT_LEN_addr, &data, 1);

                            // Write the remaining bytes
                            lprintf("Write the remaining bytes : %i\r\n", data);
                            SPI1_Write_To_Register( STANDARD_FIFO_ACCESS, BURST_ACCESS, STANDARD_ACCESS_FIFO_cmd, ptr_msg, byteleft );
                            byteleft = 0;
                        }
                        TxFIFO_THR = 0;
                    }while( EndOfPacket == 0 );

My ISR :

void __ISR(_CHANGE_NOTICE_VECTOR, ipl7) ChangeNotice_Handler(void)
{
    if (IFS1bits.CNIF)
    {
        value = mPORTBRead();

        if( ( value & 0x02 ) == 0 ) // GPIO0 = falling edge
        {
            TxFIFO_THR = 1;
        }
        if( ( value & 0x01 ) == 0 ) // GPIO2 = falling edge
        {
            EndOfPacket = 1;
        }
        IFS1bits.CNIF = 0;
    }
}

GPIO0 = 0x02

GPIO2 = 0x06

I see just on falling edge on the GPIO on the oscilloscope. However I see the first rising edge (first fill) and the second but after that, the falling edge never appears.

How many bytes is the packet you are trying to send? Do you need to fill the FIFO several times?

The packet is 500 bytes length. The firts purpose of this try is to measure the consumption of the CC1120 durgin long Tx and Rx. We may need to send packet over 128 butes in the final applicaion.

Regards, Vincent

TER,

where in TI's deep box of knowledge do one find such SW-examples? MEans, pls. guide me to an overview of examples as I know it from e.g. ANxxxx

Hi GGA

There is no complete overview of all available SW examples. To find SW examples associated to a specific product you should go to the product page. Here all related SW and application notes will be available.

For this example, you can go to the CC1120 product page (http://www.ti.com/product/cc1120) and you will find the SW example under the "Software" section on the page.

Vincent

If you have a 500 byte packet you need more than two refill to the TXFIFO. If the TXFIFO_THR signal never falls again after the second refill, it sounds strange to me that you are able to receive a full packet with correct CRC.

Without any plots of the GPIO signals during transmission it is very hard to know what the issue might be.

Thanks Martin. I don't receive any packet cause for the moment I'm just trying to send a infinite packet. I'll try to review my code today and I'll post if I'm not able to progess.

Regards, Vincent

Hi everybody,

Today the code that sends infinite packet works greatly. Now I'm on the receiver side and I follow your example code and I've a question about it :

Is it possible to activate the infinite packet reception during the reception of the packet  or is the module has to set this configuration before the reception time ?

Regards, Vincent

Hi Vincent

The radio has to be set to infinite packet length before you go int RX. It is not possible to change the length configuration during active mode( RX)

Hi,

Thanks for your reply.

I noticed a strange behavior : when I set the output power too high, the infinite packet transmission fails. Have you ever noticed this behavior ?

Actually, it appears when the receiver module is powered on...

Hi Vincent.

What do you mean by transmission fails? Are you not able to send or receive or do you receive packets with errors? A very strong signal to the receiver can make it go into saturation and produce bit errors. What output power and distance between the devices are you using when this fails?

Hi,

Well it appeared when I sent a packet but it seems fixed. Maybe due to a wrong manipulation.