I have a weird problem... When my RF signal gets weak I get bit errors on the SPI bus. Specifically my packet has CRC check which passes but the data I get back over the SPI is not correct. If I increase my RF SNR (change attenuation) the SPI bus errors go away. I have also dropped the SPI speed to 5Mhz from 10Mhz and have the same result indicating it is not an SPI speed issue.
The failures are usually one bit errors, for example getting 0b1011 instead of 0b1010 or 0x1110 instead of 0x1010. Which almost appears as excessive capacitance on the MISO line, but other times the error is 0b00001001 instead of 0b00000001. Also the errors go away if the RF signal is increased. So it appears as though the problem might be with the chip having extra processing time with low signals which some how affect the packet data put on the SPI bus? The chip processes the CRC which indicates the packet is correct, so it has to be something between the packet CRC and SPI output.
Again I see this problem when doing 2GFSK at 500kbps and sending 1036 bytes in a packet with 80dB attenuation between the TX and RX, when I drop to 60dB the problem goes away. I also see the problem with 4GFSK 400ksymb/s (800kbps).
Here is the data first hex value is what I got from the Si4468 and the last is the correct value that was sent.
In the firmware I check in the interrupt handler for CRC error and zero my packet data. Also as I understand the chip will not set the PACKET_RX unless the CRC matches. Hence the only way I can get these errors is between the SI4468 and the host processor (ie SPI bus).
failure 29 0x19 0x1D
failure 61 0x39 0x3D
failure 170 0xAE 0xAA
failure 171 0xBB 0xAB
failure 174 0xEE 0xAE
failure 248 0xE8 0xF8
failure 256 0x01 0x00
failure 257 0x05 0x01
failure 265 0x19 0x09
failure 283 0x1A 0x1B
failure 285 0x09 0x1D
failure 347 0x5A 0x5B
failure 366 0x6A 0x6E
What kind of hardware do you have? Is it a Silicon Labs eval board or custom hardware? Can you check the SPI lines using an oscilloscope? Do you use an example code or you created it?
I have checked SPI lines and even dropped the clock rate in half with same results.
I have noticed that this problem appears to go away when I use 2GFSK instead of 4GFSK. Again my guess is that internal to the Si4468 it is taking too much processing time when the SNR gets low and this is causing it to shift out bad data on the SPI some how.