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