CC1120 on TRxEB Board, Fill RX Fifo with 0x81

Me Ce

Other Parts Discussed in Thread: CC1120

Hi,

I work on TrxEB evaluation board.

I have been trying to write a code (on sample code) that sends and receives different size of packets on CC1120. So I made a demo that starts sending X bytes, where X starts with 512 and counts down to 1 by 1 every time I push a button.

At the receiver part, packet receiving for most of the sizes are working without a hitch.

But again on receive part, around packet size 498 (sometimes 497, sometimes 496, but always around these numbers), MSP430 does not receive packet receive interrupt, but receives rx fifo above threshold interrupt even though there is no bytes left to receive.

I read MARC Status 1 register, it shows 0x80, which says

"RX finished successfully (a packet is in the RX FIFO ready to be read)"

I read RX Fifo to see whats in the buffer (not my packet) but it is filled with 0x81.

I'm confused about what I'm doing wrong, since most of the time my code works great.

Has anybody see this problem before ? Or any ideas ?

Thanks,

over 11 years ago

0 Siri over 11 years ago

TI__Guru* 86241 points

I did some testing with the infinite packet length example available on the web and got similar problems, but on the TX side.

The problem there seems to be related to the bytesLeft variable wrapping around.

I will continue to debug this issue on Monday and when I am back in the office and have a logic analyzer available.

Siri

0 Me Ce over 11 years ago in reply to Siri

Prodigy 70 points

Thank you, waiting for your analyze.

0 Siri over 11 years ago in reply to Me Ce

TI__Guru* 86241 points

In the infinitePacketLength example on the web I had to make the following changed on the TX side:

Remove

// Update variables

writeRemainingDataFlag = FALSE;

bytesLeft = packetLength + 2;

pBufferIndex = txBuffer + FIFO_SIZE;

iterations = (bytesLeft / AVAILABLE_BYTES_IN_TX_FIFO) - 1;

fixedPacketLength = bytesLeft % (MAX_VARIABLE_LENGTH + 1);

and include the following after writing the first 128 bytes to the TX FIFO:

// Fill up the TX FIFO

cc112xSpiWriteTxFifo(txBuffer, FIFO_SIZE);

bytesLeft -= FIFO_SIZE;

iterations = (bytesLeft / AVAILABLE_BYTES_IN_TX_FIFO);

On the RX side, add a check to the rxFifoAboveThresholdISR to see if a packet is received or not :

static void rxFifoAboveThresholdISR(void) {

uint8 writeByte;

if (!packetReceived) {

// Change to fixed packet length mode when there is less than 256

// bytes left to receive

if (((bytesLeft - BYTES_IN_RX_FIFO) < (MAX_VARIABLE_LENGTH + 1)) && (pktFormat == INFINITE)) {

writeByte = FIXED_PACKET_LENGTH_MODE;

cc112xSpiWriteReg(CC112X_PKT_CFG0, &writeByte, 1);

pktFormat = FIXED;

}

// Read BYTS_IN_RX_FIFO bytes from the RX FIFO and update the variables

// keeping track of how many more bytes need to be read and where in

// rxBuffer they should be storeds

cc112xSpiReadRxFifo(pBufferIndex, BYTES_IN_RX_FIFO);

bytesLeft -= BYTES_IN_RX_FIFO;

pBufferIndex += BYTES_IN_RX_FIFO;

// Clear ISR flag

ioPinIntClear(IO_PIN_PORT_1, GPIO0);

}

Siri

0 Me Ce over 11 years ago in reply to Siri

Prodigy 70 points

Hi Siri,

Thank you for your answer, but this is not a solution, this is a workaround. Both transmitter and receiver of the infinity demo has a logic problem. I changed both receiver and transmitter code to make it work. This answer only limits the interrupt handler, but does not provide why the interrupt handler is called without any reason.

Still answer is an answer and works fine as well.

0 Siri over 11 years ago in reply to Me Ce

TI__Guru* 86241 points

this is a solution and not a work-around as the CC1120 begaves as expected.

The interrupt handler is not called without a reason. When the received packet length is close to a multiple of the RXFIFO threshold (in this case 122) the packet received interrupt will assert but so will the FIFO interrupt. If the MCU executes the packet received interrupt first and empties the FIFO and then handles the FIFO interrupt afterwards it will try to read 122 bytes from an empty FIFO (something that should not be done. It is fully possible to re-write you code in another way if you want that, but there are no signals asserted from the CC1120 that are not supposed to be asserted.

Siri

0 Me Ce over 11 years ago in reply to Siri

Prodigy 70 points

This makes sense now, thank you. I thought rx fifo above threshold always called before rx packet received interrupt handler.

Sub-1 GHz

Sub-1 GHz forum

CC1120 on TRxEB Board, Fill RX Fifo with 0x81