This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1121: Transmitter stops to work

Part Number: CC1121

Hi team,

My customer faced with very rare issue with CC1121 when TX part of chip stops to work. The customer can't reproduce issue in lab, but already have tens of reports from their customers. Some customers never faced with the issue, but some of them heve it once for several days.

From logs the customer see that after packet transmission CC1121 does not notify MCU about a transmission complete by IRQ pin.

The customer sure that from MCU side the processing of external IRQ  pin interrupt is 100% correct because the same IRQ code in RX mode is executed normally.

After transmit waiting timeout if IRQ was not recieved the customer reads info from CC1121

Sometimes in FIFO bytes count we have 0, but sometimes same byte count like in last TX packet.

In status byre readed by SNOP cmd sometimes we have values that not listed in documentation.

When the chip in this state sometimes we have unexpected interrupts and in MARC_STATUS1 we have values 3(eWOR sync lost), 14, and 15 - last 2 values is also not listed in documentation.

When the customer resets CC1121 with nRESET pin, nothing happens, only power down-poser up cycle helps. But unfortunately the customer can't control power of CC1121 separately.

We try to add delays as mentioned there, but without any success. The problem still reproduced.  

  • There are only 3 things I know of that can make the TX fail:

    1) You have enabled some kind of CCA, and the radio do not enter TX due to a BUSY channel
    2) The SPI communication is not according to spec. to the radio do not “understand” the STX strobe
    3) The radio is in an error state (TX FIFO ERROR) and this error state is not handled correctly. This can happen if you for example strobe STX before you start to fill the FIFO, and then a higher prioritized task interrupts the FIFO writing, so that the TX FIFO underflows.

    I do not think that you should read MARC_STATUS1, as this registers is meant to be used together with the MCU_WAKEUP interrupt. You should instead read MARCSTATE, and all FIFO pointers, to determine the state of the device when it fails.

    I have talked to the designers of the device, and there should be no difference in doing a manual reset by pulling nRESET low compare to turning power OFF and then ON. If turning power OFF and ON also includes powering off and on the MCU, this might indicate that the problem is on the MCU side and not on the radio side.

    BR
    Siri
  • closed due to lack of feedback