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.

CC1101-Q1: Problem with chip behavior 2 issues believed to be related

Part Number: CC1101-Q1
Other Parts Discussed in Thread: TEST2, CC1101

Hello:

I am unable to get the RX FIFO to work properly and not able to figure out what setting is causing the problem.  Data that is read back is random garbage.

Also with the GDO2 pin configured as 0x06 to go high when a sync word is received which it does do - it however does NOT go low at the end of the message even though the length is set.

I believe these issues are related but can't figure out why / what is causing it.

I am able to read config registers and all other items over SPI - just not the RXFIFO so it is not an SPI configuration issue (Mode, timing are all correct.)

because of this I am forced to use the Asynchronous data output and software decode the FSK signal with the microcontroller which I should not have to do.

Please advise on what could cause this IC behavior.

Regards,

Rob Tywlak

BGM Engineering services

  • Hi Rob,

    It looks like you have encountered the RXFIFO_UNDERFLOW advisory, present in our errata: https://www.ti.com/lit/er/swrz020e/swrz020e.pdf?ts=1677578847640

    What is your length filtering configured to?

    Regards,

    Arthur

  • Arthur:

    That is not what I am experiencing because I am using a timer in the micro that is a little longer than the message to place the chip in IDLE and FLUSH the RXFIFO then go back to RX Mode...  The message length is 34 bytes and that is set in the length register.  The RX FIFO never overflows as far as I can tell.

    Also I am doing a software decode of the FSK Manchester message because the FIFO does not contain valid data when it should - just reads back garbage.

    I am using GDO0 set to 0x0D for asynchronous data out and the microcontroller works off of that raw FSK Demodulated Signal.

    This poses a question - does the FIFO start filling only when a SYNC WORD Match has occurred or will it fill up on Noise too?

    SYNC Word detection is working just not the end of the message so GDO2 set for 0x06 NEVER GOES LOW until my timer kicks the chip into IDLE and flushes the RXFIFO buffer.  This was the only way I could get the chip to work.  The SYNC WORD match starts the timer.

    So its something else...

    Regards,

    Rob

  • please share your register settings so that we can look into this.

    Siri

  • Siri:

    I have tried many different options and none of them make the GDO2 pin output go low at the end of the message or make the RXFIFO readable.

    Remember I am using the Micro to decode the message since the RXFIFO does not work properly which is why GDO0 is set to 0x0D.

    These are the current register settings:

    0x06, // IOCFG2 GDO2 Output Sync matched 06
    0x0E, // IOCFG1 RSSI above threshold
    0x0D, // IOCFG0 GDO0 Output Pin FSK data out 
    0x47, // FIFOTHR 
    0xCA, // SYNC1 
    0xE1, // SYNC0 
    0x22, // PKLEN 
    0x84, // PKTCTRL1 
    0x00, // PKTCTRL0 
    0x00, // ADDR
    0x00, // CHANNR 
    0x08, // FSCTRL1 
    0x00, // FSCTRL0 
    0x10, // FREQ2 
    0x12, // FREQ1 
    0x34, // FREQ0 
    0x9C, // MDMCFG4
    0x17, // MDMCFG3 
    0x19, // MDMCFG2 
    0x22, // MDMCFG1 
    0xE4, // MDMCFG0 
    0x47, // DEVIATN 
    0x07, // MCSM2 
    0x30, // MCSM1 
    0x18, // MCSM0 
    0x00, // FOCCFG 
    0x00, // BSCFG 
    0x03, // AGCCTRL2 
    0x00, // AGCCTRL1 
    0x22, // AGCCTRL0 
    0x87, // WOREVT1 
    0x6B, // WOREVT0 
    0xFB, // WORCTRL 
    0x56, // FREND1 
    0x10, // FREND0 
    0xE9, // FSCAL3 
    0x2A, // FSCAL2 
    0x00, // FSCAL1 
    0x1F, // FSCAL0 
    0x41, // RCCTRL1
    0x00, // RCCTRL0
    0x59, // FSTEST
    0x7F, // PTEST
    0x3F, // AGCTEST
    0x81, // TEST2
    0x35, // TEST1
    0x09, // TEST0

    Regards,

    Rob Tywlak

  • The radio will only put data in the FIFO after a sync is found, and when using fixed packet length mode, it will only put PKTLEN bytes in the FIFO (+ appended status bytes).

    I have looked through your settings, and I am not sure where all of them comes from. For testing purposes I have used the settings provided from SmartRF Studio for the packet format and RF parameters you are using. I have marked the settings that differs from your settings to mine

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    // Address Config = No address check
    // Base Frequency = 417.848755
    // CRC Autoflush = false
    // CRC Enable = false
    // Carrier Frequency = 417.848755
    // Channel Number = 0
    // Channel Spacing = 192.016602
    // Data Format = Normal mode
    // Data Rate = 110.687
    // Deviation = 47.607422
    // Device Address = 0
    // Manchester Enable = true
    // Modulated = true
    // Modulation Format = GFSK
    // PA Ramping = false
    // Packet Length = 34
    // Packet Length Mode = Fixed packet length mode. Length configured in PKTLEN register
    // Preamble Count = 4
    // RX Filter BW = 162.500000
    // Sync Word Qualifier Mode = 15/16 sync word bits detected
    // TX Power = 0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    RX implementation below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    void main(void) {
    // initialize MCU and peripherals
    initMCU();
    // Write radio registers
    registerConfig();
    // Enter runRX, never coming back
    runRX();
    }
    static void runRX(void) {
    uint8 rxBuffer[PKTLEN + 2] = {0}; // 34 data bytes + 2 status bytes
    uint8 rxBytes;
    uint8 marcstate;
    // Connect ISR function to GPIO2
    ioPinIntRegister(IO_PIN_PORT_1, GPIO2, &radioRxISR);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    For test purposes, I transmitted a 34 byte long packet from SmartRF Studio:

    The packets were received correctly and the GPIO2 signal behaved as it should:

    The data put in the FIFO will be the Manchester decoded representation of whatever is received on GDO0, so if you are only getting garbage in the FIFO, there is only garbage on the GDO0 line as well.

    There is either something wrong with your HW causing bad RF performance, or there might for example be something wrong with your SPI communication (not according to spec), so that you are not running with the config you try to run with.

    You need to try to figure out what this problem is, rather than trying to create a workaround for an error (GDO2 not being de-asserted) that should not happen..

    Are you certain that you have configured your receiver correctly with respect to how your transmitter is configured/the packet sent by the transmitter?

    Siri

  • Siri:

    I have verified my SPI settings are correct - MODE 0, 2 MHz and have tried everything from 1 MHz to 4 MHz with no difference.  I can Read back all configuration registers as well as the status byte and RSSI registers without issue - just not the RXFIFO.  Its not SPI settings...

    Your statement about the GDO0 being garbage also is not correct - that is how I am decoding the message... and doing so cleanly with the micro.

    The SYNC word match detection is working just fine so I must have the Modem configuration correct otherwise that part would not work.

    The settings came from RF studio and then I tweaked some of them to suit my application which is 115,2K symbol rate Manchester Encoded 34 byte packet.

    I am also using an identical board as a transmitter to test with - only the software load is different.  It has the same Micro and CC1101 on it.

    Asking for help here because I have literally tried everything and why I had to resort to software decoding in the micro with the asynchronous data output and using the sync word match as a trigger to start reading in data bits.  I prefer to use the RXFIFO and falling edge on GDO2 but that does not work here.

    The few setting differences you mention would have nothing to do with the GDO2 pin behavior - I believe it is a timing problem or command word problem but can't figure out what specifically that is.

    Try again.

    Regards,

    Rob Tywlak

  • Siri:

    Tried all of your settings and it made no difference.  Changed all of them to match.  Still the same behavior.

    Also its not likely hardware as I can get messages down to -100 dBm which is 10 dB above ambient noise... this is very near  datasheet performance.

    Try again because that is not it.

    Regards,

    Rob Tywlak

  • Any update on this issue?

    I would like to know what could be causing this behavior.

    Regards,

    Rob Tywlak

  • Unfortunately I do not know how to proceed here.

    You claim that your HW is OK, that the settings is OK and that your SPI communication is OK, but still it does not work.

    For me to be able to help you further, I will need a way to reproduce the issue on my end, meaning that you will need to port this to our development platform so that I can have it fail here on my desk and then debug it.

    By design, the FIFO is only filled when it finds a valid sync word.

    If you cannot re-create the problem on our dev. kit, at least you need to provide me with complete logic analyzer plots that shows everything from configuring the radio, entering RX, and then reading out the FIFO (all 4 SPI lines + GDO lines are needed).

    Siri

  • Siri:

    I believe the issue is a timing problem or a missing SPI command - As I stated before I can read back the configuration registers and RSSI values so my SPI is working just fine.

    One specification that is missing in the datasheet is how long does a FLUSH RX BUFFER take?  So how long of a delay should I insert before issuing the RX command?

    My initialization sequence is as follows:

    1) Issue a RESET command on SPI and wait 10 mS - tried from 1mS to 100 mS here with no difference

    2)  Burst write to all configuration registers and wait 1 mS - tried various delays here with no difference

    3)  Place chip in IDLE and wait 100uS - tried various delays here with no difference

    4)  Flush RX_FIFO command and wait 1 mS - have tried up to 100 mS here with no difference

    5)  Place chip in RX mode

    When Receiving packets GDO2 is set to go high when a sync word matches and that rising edge triggers my timer interrupt.  That part works. So with sync words being detected my receiver must be configured correctly otherwise this would fail and no sync word match would occur.

    The timer is set to 1 mS longer than the message length of 6.2 mS and then the IDLE command is sent, FLUSH_RX_FIFO is sent with 1 mS delay, then RX command is sent.  GDO2 never goes low at the end of the message and if I read the RX_FIFO it has garbage data in it.... this is forcing me to do software / hardware decode using the Asynchronous DATA output on GDO0 set to 0x0D which works just fine so if there was a hardware issue I would not be receiving down below -100 dBm RSSI levels reliably.  

    If I don't issue the IDLE and FLUSH_RX_FIFO then only a single message can be received as the FIFO overflows and forces IDLE operation.

    My question remains what is missing in my commands or what timing am I violating to cause this to occur?

    I do not have an evaluation board to compare against here.

    Regards,

    Rob Tywlak

  • There is no need for ANY delays between SPI commands. If you issue an SRX strobe right after the SFRX, the RX strobe will be queued internally until the flushing is done. 

    Again, please provide me with logic analyzer plot of your SPI communication and the GDO signals if you want us to dig into this.

    Siri

  • Siri:

    Scope plots are attached showing the issue.  GDO1 set to RXFIFO = 32 bytes.

    SYNC word MATCH

    SPI

    Regards,

    Rob Tywlak

  • Hi Rob

    I tested again, and are still not able to see any issues.

    Above I am sending a 34 byte long packet, and I have FIFO threshold set to 32

    SYNC_RECEIVED/PACKET_RECEIVED is asserted for 4.92 ms, which corresponds to 34 bytes Manchester encoded at 110.687 kBaud (55.3435 kbps):

    (34*8)*(1/55343.5) =  4.915 ms

    GDO1 is asserted after 32 bytes.

    Have you tried several different boards, or just one?

    Are you making sure that CPIP_RDYn always is asserted before doing SPI communication?

    Have you made sure that rise time, hold time etc. are according to spec on the SPI bus?

    Again, I am not sure how to proceed here since I am not able to reproduce any of the issues you are seeing.

    I have supported customers using the CC1101 since the chip was released, and I have never seen this issue before.

    If you are always sending the same packet from your transmitter, is the data your read from the FIFO always the same?

    If you do not strobe IDLE, will the GDO pin never be asserted, or does it de-assert when the FIFO overflows at 64 bytes?

    Have you read back the PKTLEN register to verify that it is the correct value?

    Siri

  • One additional question. You say that you use a data rate of 115.2 kBaud but your settings indicates 110.687 kBaud

    What crystal frequency are you using?

    Siri

  • Siri:

    Using 27.0000 MHz 10 ppm crystal.  Baud rate is correct at 115200 symbol rate with Manchester encoding = 57.6K data rate.

    Yes I am waiting for SO to go LOW before sending any SPI commands - first of which is a chip RESET.

    I can only conclude the few IC's I got from our production facility must not have been stored in a dry enough environment and these are damaged because they are MSL Level 3 parts and I hot air soldered them to these boards...

    So I am going to get some new ones in a dry pack and try again.

    Regards,

    Rob Tywlak