cc1101 RXBYTES always zero

Hi

You have enabled CRC auto flush (PKTCTRL1 = 0x0C). This will flush the RXFIFO if you have a bit fault in the packet. Try to disable the CRC auto flush and see if you can read from the FIFO then.

Hi Martin,

   i change PKTCTRL=0x04, to disable CRC auto flush, but i can't read FIFO and RXBYTES is still zero... this is my code:

 // wait for packet received interrupt 
    if(packetSemaphore == ISR_ACTION_REQUIRED)
    {
        cc1101SpiReadReg(CC1101_RXBYTES,&rxBytesVerify,1);
       
              
                
        do
        {
          rxBytes = rxBytesVerify;
          cc1101SpiReadReg(CC1101_RXBYTES,&rxBytesVerify,1);
                  }
        while(rxBytes != rxBytesVerify);
        
        cc1101SpiReadRxFifo(rxBuffer,(rxBytes));
        
        // check CRC ok (CRC_OK: bit7 in second status byte)
        if(rxBuffer[rxBytes-1] & 0x80)
        {
          // toggle led
           halLedToggle(LED1);
          // update packet counter
          packetCounter++;
        }
      
      // reset packet semaphore
     packetSemaphore = ISR_IDLE;
     
          
      // set radio back in RX
      trxSpiCmdStrobe(CC1101_SRX);
      
      
    }

I await any suggestion....

Best regards,

How have you set up the interrupt? Are you interrupting on rising or falling edge of the GDO0 signal?

Hi Martin,

   thanks for your soon response. I have set up the interrupt... in the code that i showed, always enter when i transmitt.

In my code,"packetSemaphore = ISR_ACTION_REQUIRED", when GDO0 interruption occurred. But in code line 15, rxBytes is always zero, so i dont read anything in rxbuffer...  i forced to read some bytes but read trash... that i don't know is why interrupt GDO0 when transmitt but the rxbuffer its empty.

if I read RSSI register, i see a correct value (-40 dbm aprox).

Best regards,

Sorry but my latest post might have been a bit vague. Let my be more precise. It's not clear form the post how you set up the ISR. Be sure that your MCU is set up to trigger on the falling edge of the GDO signal, and verify with a scope or logic analyzer that the GDO signal on the receiver side acts like excepted. I.E. the signal asserts when a sync word is received, stays high through the entire payload and goes low at the end of the packet. I can be helpful to monitor the same signal on the transmitter to verify that the GDO signal is the same on both the transmitter and receiver. 

I have exactly same problem with you. and cannot find out the reason.

1 out of 2 of my device have this problem

Hi Martin,

    attached  GDO0 signal from my logic analyzer (only works at 4mhz and small buffer).

    however, i'm sure that GDO0 interrupt uC because i'm used the SmartRF04 EB program modified in this post:

http://e2e.ti.com/support/low_power_rf/f/155/t/301463.aspx

 P2SEL &= ~0x40; // P2SEL bit 6 (GDO0) set to one as default. Set to zero (I/O)
  // connect ISR function to GPIO0, interrupt on falling edge
  trxIsrConnect(GPIO_0, FALLING_EDGE, &radioRxTxISR);
  
  // enable interrupt from GPIO_0
  trxEnableInt(GPIO_0);

I understand that CC1101 read de sync words, because if i change the sync word in configuratión, GDO0 don't interrupt uC and i think that there are a reason that dont write fifo_rx, but i don't know why...

Finally, i can show you these signal with a new logic analyzer that i purchased:

Now you can see that GDO signal goes on an I read TXBYTES and obtain ZERO than result of this operation...

Hi

I noticed from you SPI list that the returned status byte indicates that the radio is still in RX. This usually indicates that the radio has discarded the packet due to filtering, either address, packet length or CRC fault.

The register settings you posted in the start of the post is a bit ambiguous. For instance; you have set an address for the device but are not using address filtering. You had also enabled the CRC_AUTOFLUSH without having CRC enabled (I know you have changed this later on).

My recommendation is to do a test with default register settings exported from SmartRF Studio without any changes. Then send a standard packet that is within the FIFO limit, for example:

0x05 0x01 0x02 0x03 0x04 0x05

look at the GDO signal and check that the signals stays high throughout the entire payload and verify that the radio has gone to IDLE after reception. Then read RXBYTES and the RXFIFO content.