CC1101-Q1: SO/GDO1 Pin high, device probably not entering PowerDown, high current measured, Not able to transmit

Hi Siri, not sure if you've read my reply below the query was marked as resovled,  but we can't find any issues with the software that are obvious other than some of your remarks that i kindly ask you to perhaps clarify some more why flush fifo commands musnt' be called unless there is error with fifo. also is there a possibility that there is a latched RSSI value that is above threshold from an overrun buffer that is preventing the new Tx Messages to be transmitted with the TX-IF-CCA setting if there was a RX fifo overflow that we are not handling properly?

Since I cannot get details on your code or the complete SPI plots, I can only answer very general, and it is hard to tell you what the problem is.

When it comes to CCA, yes, the radio needs to be in RX to use this feature.

TX is entered based on the channel is being clear or not, but for the radio to know if the channel is clear, it needs to listen to the channel (be in RX).

When it comes to flushing the FIFO, this alters the FIFO pointers and should not be done in for example RX or TX state, as the pointers are being updated in these states if packets are sent/received. You should therefore NEVER flush the FIFO unless you are in an error state (flushing the FIFO is the way to get out of the error state). It is also safe to flush the FIFOs if you know that you are in IDLE state (error in my previous post where I wrote RX instead of IDLE)

If you end up in an overflow state while being in RX to check the channel before going into TX, you will not able to enter TX.

The overflow state must be handled properly first (by flushing the FIFO) and then you must enter RX again.

Siri

Thanks for that Siri, greatly appreciated, We've deployed some diagnostics firmware to catch the states. I'll keep you updated. The one difference we've spotted is that the GDO1 pin was high in the failed units. 

I've managed to insert myself onto the SPI lines from the micro by writing some custom firmware without resetting the RF chip.

While i am going on one returned sample only, The RF chip appears to have all default values (i.e not our initialised/programmed values in it with one exception:)

The settings for the GDOx pins are as follows:

Any ideas what would cause a reset and have those IOCFGx settings? and have the rest default.

If it was full power reset or re-initialisation it would have the datasheet settings not 0x02, 0x00 and 0x00 

I've then reprogrammed the MCU which re-initialises the RF chip and things work again. i.e there is not permanent damage to the RF circuitry.

Any ideas?

With that setting the GDO1 pin (SO) would be associated with RX overflow  which would explain why it is asserted high following the CS release.

The problem is that nowhere in our code do have that value as a possible configuration for this pin.

Regards,

I also queried the PKTSTATUS is either: 0x80 or  0x08  (i may not have typed that correctly in my excel sheet), the  marc_state is 0x01

Regarding the reset, I know that for the CC1101 (not the CC11x1-Q1) there is a table in the data sheet (Power-On Reset Requirements), and if these requirements are not overheld, you do not know the state of the registers when powering up, and a manual reset is required. I will reach out to someone knowing the Q1 device better than me to find out why the same requirements are not in the Q! data sheet.

Siri

I'm now reading this section, would a similar wait time be required when waking the device from sleep:

"When CS is pulled low, the MCU must wait until CC11x1-Q1 SO pin goes low before starting to transfer the header byte. This indicates that the crystal is running. Unless the chip was in the SLEEP or XOFF states, the SO pin goes low immediately after taking CS low.. "

So is it possible that during the waking up process, attempting to write to the chip on SPI before the crystal has stabilized can reset the chip or put it into some unknown state?

From our code i can see that we are not calling a reset anywhere other than at startup.

Once configured and running the application will execute the commands discussed above to put the CC1101 to sleep  and then 1 second later we wake it up

by:

set_RF_SCLK();
clr_RF_MOSI();
set_RF_CS();
nop(); nop();
clr_RF_CS();
delay_uSec(45);
set_RF_CS();
delay_uSec(100);
int wait_delay = 0;
while(wait_delay++ < 500)
{
if(RF_MISO == 0) break;
}

The MCU clock is 8MHz and instructions like increments and branch compare are  1 or 2 cycle instructions. so the above wait_delay will be anywhere between 250us to 500us 

To be honest looking at it now, i'm not sure why the above was done and is so complicated.

Shouldn't waking up the RF chip simply be:

set_RF_CS();

while(RF_MISO)

{

nop();

}

Hello again Siri. Is there anything on this RF chip that would reset the chip if the receive signal was too strong from a powerful emitter close by? 

Hi Norm,

The Receiver will just be in saturation and don't be able to demodulate anything.

Thanks Christin, just checking if there is some path for inbuilt protection of some sort? Several weeks of testing in house and we can't replicate the problem. Mean time to failure 3 days in field.  Would the above wakeup sequence that may initiate a manual reset contribute to our issue?