CC1120 TX FIFO ERROR

I've just measured the negative pulse width of TXFIFO_THR and it's about 13.32us. So that should be how long it takes for me to fill the TX FIFO with 122 bytes. 

Hi

Do you know if the TXFIFO_ERROR is a TXFIFO_OVERFLOW or a TXFIFO_UNDERFLOW error? This will indicate if you fill the FIFO to slow or to fast.

If not this can be checked by monitoring signal 0x27 on GPIO2 or 0x05 on any of the GPIO''s.

What data rate and modulation are you using?

Have you done any changes at all to the example? Since the swrc253 example works and your code does not there must be a difference and understanding the changes you have done would be useful in trying to help solving this.

A useful debug hint is to have a known sequence as your payload and then debug the RX side to see what data you actually receive. Since your TX underflows you will most likely miss the end of the packet on the RX side and knowing what bytes you are missing will give you an indication as to where it fails.

It might be that your interrupt handling takes longer than in the example code so that even if you are running your SPI at 8 MHz you start too late re-filling the FIFO and hence it underflow. What you can do is to change the FIFO threshold so that you get the interrupt earlier. Remember that when doing this you will need to adjust the number of bytes you are re-filling the FIFO with.

BR

Siri

Thank you both for your replies.

I've done as you suggested and found out that both overflow and underflow is happening! Oddly enough if I lower the THR I get the FIFO ERROR much more often.

I've made almost no changes to both ISRs. Here's my code:

#define FIFO_SIZE 128
#define TX_FIFO_THRESHOLD 120
#define AVAILABLE_BYTES_IN_TX_FIFO (TX_FIFO_THRESHOLD + 2)
#define BYTES_IN_TX_FIFO (FIFO_SIZE - AVAILABLE_BYTES_IN_TX_FIFO)

void txFifoISR(void) {
uint8 writeByte;

if (writeRemainingDataFlag) { // Less than 120 bytes to write to the TX FIFO
cc112xSpiWriteTxFifo(TXinfo.pByteIndex, (uint8)TXinfo.bytesLeft); // Write remaining bytes to the TX FIFO

// Disable interrupt on GPIO0
GPIOIntDisable(GPIO_PORTB_BASE, GPIO_PIN_0);

}
else { // Fill up the TX FIFO
cc112xSpiWriteTxFifo(TXinfo.pByteIndex, AVAILABLE_BYTES_IN_TX_FIFO);

// Change to fixed packet length mode when there is less than 256 bytes
// left to transmit
if ((TXinfo.bytesLeft < (MAX_FIXED_LENGTH - BYTES_IN_TX_FIFO)) && (TXinfo.format == INFINITE)) {
writeByte = FIXED_PACKET_LENGTH_MODE; cc112xSpiWriteReg(CC112X_PKT_CFG0, &writeByte, 1);
TXinfo.format = FIXED;
}

// Update the variables keeping track of how many more bytes should be
// written to the TX FIFO and where in txBuffer data should be taken from
TXinfo.pByteIndex += AVAILABLE_BYTES_IN_TX_FIFO;
TXinfo.bytesLeft -= AVAILABLE_BYTES_IN_TX_FIFO;

if (!(--iterations))
writeRemainingDataFlag = TRUE;
}

// Clear isr flag
GPIOIntClear(GPIO_PORTB_BASE, GPIO_PIN_0);
}

void packetSentISR(void) {

TXinfo.complete = TRUE;

// Clear the interrupt flag
GPIOIntClear(GPIO_PORTD_BASE, GPIO_PIN_0);

if (phys_settings.tx_CB_registered) { //it's not registered at this time, so it won't be called
phys_settings.transmitCallback();
}
}

The 13.32us was the low time of the GPIO0 which is TXFIFO_THR, that seems to be fast enough so I don't see what could cause this.

I'm sorry, I was wrong in my last statement. Only overflow is happening (I've been looking at the wrong signal) which makes much more sense considering the behavior when I lower the FIFO THR.

Hi

Sounds like you found the root cause. Good luck continuing forward!