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 RX FIFO Pointer Issue

Other Parts Discussed in Thread: CC1200

I have encountered a strange issue with the CC1200 RX FIFO, where it appears that the RX FIFO count is jumping to 128 during the reception of a corrupted packet.

The transceiver is configured at "500ksps, 4-GFSK, max throughput, ETSI Standard (434MHz)" with data whitening enabled (settings pulled from SmartRF Studio 7).

Additionally, I am using the following configuration:

1 - Fixed packet length mode (Length = 54)

2 - Filter on CRC

3 - Enter RX mode after a packet completes.

4 - GPIO0 is set to toggle on the PKT_CRC_OK signal.

I am saturating the link from a second CC1200 transceiver with 54 byte packets. Each time a good CRC is received on the RX side, I have an interrupt read 54 bytes from the RXFIFO.

I was able to re-produce the issue with two back to back packets (54 bytes each) as follows:

1 - Packet 1 finishes, the PKT_CRC_OK GPIO is toggled, and the packet is received correctly.

2 - Packet 2 is transmitted immediately after packet 1, and is being received while packet 1 is being read out of the FIFO.

3 - No PKT_CRC_OK GPIO is triggered for packet 2

4 - NUM_RXBYTES now reads 0x80, and the transceiver is still in RX mode.

CRC filtering should not have allowed the more than 54 bytes to enter the FIFO without being validated (PKT_CRC_OK would have been toggled) or removed, so having 128 bytes is a “should not happen” scenario. I did not orphan valid packets in the FIFO, which I verified by reading out the FIFO data.

Reading the 128 bytes from the FIFO, I get the following (description of the data to follow):

74 38 38 38 38 78 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 9 3d 0 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 c c7 0 b5 33 43 12 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38

To break this down, the first 54 bytes is the corrupted packet 2, the last 54 bytes is packet 1 (which has already been received), and the data in between is from an older packet transaction.

Corrupted packet 2:

74 38 38 38 38 78 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 9 3d 0

Correctly formed packet 1:

b5 33 43 12 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38 38

Intermediate data from old transaction:

36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 36 c c7 0

None of the previous data is being re-transmitted, so the only way for this to be possible is if the FIFO pointer was set without data reception occurring, because nothing was copied over the existing data in the FIFO after the original 54 bytes (packet 2).  It is almost like the CRC Filtering set the FIFO end pointer back to far, causing an "emtpy" FIFO to become a "full" FIFO.

I am not writing to any registers in my architecture, so there is no chance that I am errantly setting the FIFO points manually. Additionally, everything works perfectly when there is no data corruption on the link.

 

Has anybody experienced anything similar to this?

 

Does anybody have any thoughts as to anything I may be doing wrong to cause this?

 

Thanks

  • I have not been able to reproduce what you are seeing. Do you have some code that will run on our TrxEB boards that will show this error? Then I can try to reproduce it here and try to figure out what is going on.
    If you do not have code that will run on our kit, please share your register settings and pseudo code for what you are doing when seeing this issue.
    BR
    Siri
  • I did attempt to re-produce this using my exact register configuration on one of the TrxEB boards. I was able to see the Transceiver chip lock up when sending data at a high rate (which could be indicative of the Rx FIFO overflow this issues is causing), but was unable to verify whether the lockup was caused by the same problem I am seeing (due to limited access to the registers in real time). Additionally, I don't know what smarts are built into the TreXB for dealing with FIFO overflows, ect.

    None the less, I was able to re-produce the issue using one of your transceiver boards on the Rx side (CC120xEM 420-470MHz, Rev 1.1) when connected to our hardware (rules out issues with our tranciever board design). It may be critical that packet data is sent back to back, without any delay in between. The TreXB board may be injecting some delay between packets (Tx side), making the issues impossible to trigger with that hardware (just a theory). The code that I have driving the Tx side is keeping the Tx FIFO full at all times, with the chip programed to enter Tx mode after packet completion. In short, I am blasting data as fast as the transceiver chip can push it out on the Tx side.

    Additional update:

    I set up a second GPIO to trigger when the Rx FIFO exceeded 120 bytes (never should in my architecture). When the event occurs, this GPIO is toggled at the end of the packet (likely during the CRC check). It never went off in the middle of a packet, but was always synced with the end of the packet, exactly when the PKT_CRC_OK GPIO would have went off (were the packet not corrupted). Perhaps a pointer is being set incorrectly when a byte is received while the packet filtering is removing the corrupted packet from the FIFO (just a theory).

    Architecture:

    I am always sending 54 byte fixed length packets, and receiving with CRC filtering enabled. GPIO0 triggers a PKT_CRC_OK interrupt when a good packet is received, and an ISR on our hardware reads 54 bytes from the FIFO (56 if I have the status bytes enabled). The SPI interface is set to 5,000,000 bps to ensure that the FIFO data can be read out quick enough.

    Note: You will see GIO2 set up to toggle on RX Overflows, this is a work around I put together to bring the chip back up when the issue occurs (pseudo code for this is not included here).

    Pseudo Code for the Rx ISR:

    CC1200_RX_ISR()

    {

    Wait for previous DMA transfer to complete, if still active

    Set Chip Select Line to end last transaction

     

    Clear Chip Select Line to start the next transaction

    Start FIFO Read Multiple via SPI (Data:0x80|0x40|0x3F)

    Start a 54 Byte read from the SPI interface using a DMA transfer

    return;

    };

    Note: To maximize efficiency, I set the chip select line high to end the previous FIFO read at the start of the ISR.  Only the ISR touches the SPI interface, so this shouldn't cause any issues, as far as I can tell.

    On the Rx side, all register values are default except for the following table (set & verified at startup):

    CC1200_REG_INITCC1200_Rx_Initialization_Table[CC1200_INIT_TABLE_SIZE]=

    {

    {0x0001,0x44},

    {0x0003,0x53},

    {0x0008,0xA8},

    {0x000A,0x47},

    {0x000B,0x2F},

    {0x000C,0x1E},

    {0x000E,0x8A},

    {0x000F,0x00},

    {0x0010,0x01},

    {0x0011,0x42},

    {0x0012,0x05},

    {0x0013,0xC9},

    {0x0014,0x99},

    {0x0015,0x99},

    {0x0016,0x2F},

    {0x0017,0xF8},

    {0x001A,0x60},

    {0x001B,0x12},

    {0x001C,0x84},

    {0x001D,0x80},

    {0x0020,0x14},

    {0x0026,0x00},

    {0x0027,0x42},

    {0x0028,0x00},

    {0x0029,0x3F},

    {0x002A,0x00},

    {0x002E,0x36},

    {0x2F01,0x23},

    {0x2F05,0x00},

    {0x2F0C,0x56},

    {0x2F0D,0xCC},

    {0x2F0E,0xCC},

    {0x2F10,0xEE},

    {0x2F11,0x10},

    {0x2F12,0x07},

    {0x2F13,0xA0},

    {0x2F16,0x40},

    {0x2F17,0x0E},

    {0x2F19,0x03},

    {0x2F1B,0x33},

    {0x2F1D,0x17},

    {0x2F1F,0x00},

    {0x2F20,0x6E},

    {0x2F21,0x1C},

    {0x2F22,0xAC},

    {0x2F27,0xB5},

    {0x2F2F,0x0D},

    {0x2F32,0x0E},

    {0x2F36,0x03}

    };

    On the Tx side, all register values are default except for the following table (set & verified at startup):

    CC1200_REG_INIT CC1200_Tx_Initialization_Table[CC1200_INIT_TABLE_SIZE] =

    {

    {0x0001,0x06}

    {0x0003,0x46}

    {0x0008,0xA8}

    {0x000A,0x47}

    {0x000B,0x2F}

    {0x000C,0x1E}

    {0x000E,0x8A}

    {0x000F,0x00}

    {0x0010,0x01}

    {0x0011,0x42}

    {0x0012,0x05}

    {0x0013,0xC9}

    {0x0014,0x99}

    {0x0015,0x99}

    {0x0016,0x2F}

    {0x0017,0xF8}

    {0x001A,0x60}

    {0x001B,0x12}

    {0x001C,0x84}

    {0x001D,0x80}

    {0x0020,0x14}

    {0x0026,0x00}

    {0x0027,0x42}

    {0x0028,0x00}

    {0x0029,0x0F}

    {0x002A,0x00}

    {0x002B,0x42}

    {0x002E,0x36}

    {0x2F01,0x23}

    {0x2F05,0x00}

    {0x2F0C,0x56}

    {0x2F0D,0xCC}

    {0x2F0E,0xCC}

    {0x2F10,0xEE}

    {0x2F11,0x10}

    {0x2F12,0x04}

    {0x2F13,0xA3}

    {0x2F16,0x40}

    {0x2F17,0x0E}

    {0x2F19,0x03}

    {0x2F1B,0x33}

    {0x2F1C,0xF7}

    {0x2F1D,0x0F}

    {0x2F1F,0x00}

    {0x2F20,0x6E}

    {0x2F21,0x1C}

    {0x2F22,0xAC}

    {0x2F27,0xB5}

    {0x2F2F,0x0D}

    {0x2F32,0x0E}

    {0x2F36,0x03}

    };

     

    Hopefully some of this information will help.

     

    Thanks