CC1200 FIFO Questions

Hi Mike

Why are you sending 0x00 after the FIFO address? A standars FIFO access is only 1 byte long (see Table 3 in the data sheet). The 0x00 will be the length byte so this is why you are only sending one byte.

BR

Siri

Ah, good catch. I was experimenting with the direct access command and forgot to get rid of the address byte when I switched to the standard FIFO access.

Unfortunately, I am still getting a FIFO error after sending the first packet while using the standard FIFO access command.

Here is what I am seeing:

Before loading the first packet into TX FIFO :

TX_FIRST = 0
TX_LAST = 0
NUM_TX_BYTES = 0

After loading the first packet into TX FIFO :

TX_FIRST = 0
TX_LAST = 80
NUM_TX_BYTES = 80

After transmitting the first packet:

TX_FIRST = 80
TX_LAST = 80
NUM_TX_BYTES = 0

All of the above looks correct to me.

However, when I then attempt to send the second packet, here is what I see:
Before loading the first packet into TX FIFO :

TX_FIRST = 80
TX_LAST = 80
NUM_TX_BYTES = 0

But as soon as I begin sending the packet to the FIFO, I get an overrun indication on the SPI status byte.
Can you seen something I am doing wrong here?

Hi Mike

I did a test from SmartRF Studio and it worked as expected.

1^st packet written:

TXFIRST = 0

TXLAST = 50

NUM_TXBYTES = 50

1^st packet sent:

TXFIRST = 50

TXLAST = 50

NUM_TXBYTES = 0

2^nd packet written:

TXFIRST =50

TXLAST = 100

NUM_TXBYTES = 50

2^nd packet sent:

TXFIRST = 100

TXLAST = 100

NUM_TXBYTES = 0

 

What do you mean by getting an overrun on the status byte? Is it a TXFIFO_UNDERFLOW you mean?

What are the register settings you are using when testing?

If you for example are setting TXOFF_MODE = TX the first packet will be sent OK if you are stobing STX from IDLE but if the radio stays in TX after the packet is sent and you are filling the TXFIFO at a higher speed than the radio is sending data your TXFIFO will underflow.

BR

Siri

I have TXOFF_MODE = IDLE. I strobe STX for each packet and then wait ~3ms before sending the next packet. Each packet is ~700us, so the FIFO should easily be empty before I attempt to load another packet into the FIFO. The only way I can successfully transmit consecutive packets is to flush the TX FIFO before each packet is loaded into the TX FIFO.

Here is a snapshot of the status of TX_START, TX_END, AND NUM_TXBYTES after loading the FIFO, then after STX. Notice that now the TX_START does not change and NUM_TXBYTES remains at 80 (0x50). However, the packets ARE being transmitted and I can see them on the spectrum analyzer.

Also notice that the SPI status byte begins showing 0x50 when reading TX_END and NUM_TXBYTES at the end of this transaction.

What could I be doing that keeps the TX_START pointer from incrementing?

Per  your request, below are my register settings:

// Deviation = 399.169922
// Address config = No address check
// Bit rate = 1000
// Packet bit length = 0
// Carrier frequency = 915.000000
// Manchester enable = false
// Packet length mode = Not supported
// Symbol rate = 500
// RX filter BW = 1666.666667
// Packet length = 255
// Whitening = false
// Device address = 0
// Modulation format = 4-GFSK

static const registerSetting_t preferredSettings[]=
{
{CC1200_IOCFG2, 0x08},
{CC1200_IOCFG0, 0x00},
{CC1200_SYNC_CFG1, 0xA8},
{CC1200_DEVIATION_M, 0x47},
{CC1200_MODCFG_DEV_E, 0x2F},
{CC1200_DCFILT_CFG, 0x1E},
{CC1200_PREAMBLE_CFG1, 0x00},
{CC1200_PREAMBLE_CFG0, 0x8A},
{CC1200_IQIC, 0x00},
{CC1200_CHAN_BW, 0x01},
{CC1200_MDMCFG0, 0x05},
{CC1200_SYMBOL_RATE2, 0xC9},
{CC1200_SYMBOL_RATE1, 0x99},
{CC1200_SYMBOL_RATE0, 0x99},
{CC1200_AGC_REF, 0x2F},
{CC1200_AGC_CS_THR, 0x01},
{CC1200_AGC_CFG2, 0x60},
{CC1200_AGC_CFG1, 0x12},
{CC1200_AGC_CFG0, 0x84},
{CC1200_FIFO_CFG, 0x47}, //FIFO Threshold
{CC1200_FS_CFG, 0x12},
{CC1200_PKT_CFG2, 0x02},
{CC1200_PKT_CFG1, 0x00},
{CC1200_PKT_CFG0, 0x20},
{CC1200_PKT_LEN, 0xFF},
{CC1200_FREQOFF_CFG, 0x22},
{CC1200_MDMCFG2, 0x00},
{CC1200_FREQ2, 0x5B},
{CC1200_FREQ1, 0x80},
{CC1200_IF_ADC1, 0xEE},
{CC1200_IF_ADC0, 0x10},
{CC1200_FS_DIG1, 0x04},
{CC1200_FS_DIG0, 0xA3},
{CC1200_FS_CAL1, 0x40},
{CC1200_FS_CAL0, 0x0E},
{CC1200_FS_DIVTWO, 0x03},
{CC1200_FS_DSM0, 0x33},
{CC1200_FS_DVC0, 0x17},
{CC1200_FS_PFD, 0x00},
{CC1200_FS_PRE, 0x6E},
{CC1200_FS_REG_DIV_CML, 0x1C},
{CC1200_FS_SPARE, 0xAC},
{CC1200_FS_VCO0, 0xB5},
{CC1200_IFAMP, 0x0D},
{CC1200_XOSC5, 0x0E},
{CC1200_XOSC1, 0x03},
};

Sorry, there is a slight error in the SPI transaction above. Reading the TX_START, and NUM_TXBYTES immediately after issuing an STX command will not give the chip enough time to send the packet. So these values are not correct.

However, after moving these commands to the beginning of the next transaction shows that 

TX_START = 1; 

TX_END = 50h;

NUM_TXBYTES = 4F;

which says only one byte was sent from the FIFO.

But when I look at the spectrum, I can clearly see that the full packet is being transmitted. Since I flush the FIFO before each transaction, I am able to continuously send packets. But I would like to find out why the FIFO pointers are not behaving properly.

Any suggestions of how to debug this would be appreciated.