Why cc1200 rx fifo can not been cleaned occasionally？

I wonder if anyone else has ever met with the same case, the command stobe SFRX could not clean the rx fifo of cc1200 successfully , sometimes and somewhere. "sometimes" means not always, and "somewhere" means, I executed the SFRX command at 6 different places of my source code project and just found this error occur at two of them. Let me show more details.

I used infinite packet length to send and receive data. The rx fifo is cleaned when unexpected abort during receiving, when packet receiving finished, when cc1200 initialised, when unexpected abort during transmitting... The error occurred just when unexpected abort during receiving. "unexpected abort" might be cases such as some unexpected data was received or rx/tx fifo error was detected.

In the whole source code, I clean the rx fifo with three sentences listed below: set cc1200 to idle state, send command SFRX, check if cc1200 is in idle state.

CC1200P__cmd_strobe(CMD_SIDLE);
CC1200P__cmd_strobe(CMD_SFRX);
while ((CC1200P__reg_read_robust(REG_MARCSTATE) & 0x1f) !=0x01) ;

I found the rx fifo not cleaned as the value of cc1200 register NUM_RXBYTES , read out exactly after the three sentences above, does not equal to zero. Sometimes I got 0x0B, 0x0C or other values.

while(CC1200P__reg_read_robust(REG_NUM_RXBYTES);

I'm sure function CC1200P__reg_read_robust() always works ok.

The SPI signals(SI and CS) I captured when commands SIDLE and SFRX are sent to cc1200 in order is as below.

Anyone has ideas about this? I'd appreciate it very much !

Hi Maxing, 

thanks for asking. Unfortunately, looks nobody here can reply you. As your English is pretty good, could you please post your question to our WorldWide forum?

https://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156

Thanks. 

BR. Albin

Hi Albin,

Thanks for your advice, actully I've already done that with this link http://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156/t/536527.

Although I got no more reply from both , I found the root cause last week after two months' debugging and would like to share it.

It was all about the SPI signal timing. As the datasheet required, the time Tns, negative edge on SCLK to CSn high, should be greater than 200ns. In bad case(the error could be replicated), this time I got was between 350ns and 450ns. In good case(some nop operations were added and the error never occurred), this time was extended to about 700ns. So I'm afaid the 200ns is not always the case, especially in some state like infinite length receiving process .