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.

CC1110 CRC failure

Other Parts Discussed in Thread: CC1101, CC1100

Good day,

 

I am having a problem on a CC1110 in that it reports a CRC failure but I can see that the data is correct. I am sending 5 bytes, Length + 4, with CRC and Data Whitening enabled at 1200 baud. I use the DMA to capture the data while the CPU is sleeping and process the data once the IRQ_DONE interrupt wakes the CPU. Append status is active.

Can anybody explain why the CRC is failing when I can see the data is correct?

PS. I clear the buffer before starting the reception so I know that the data is the last received data.

Thanks,

Charles

  • Hi Charles,

    I had the exact same problem.  Same chip and even data rate. 

    I solved it by appending the 2 byte RSSI data to all transmitted packets.  (PKTCTRL1 = 0x04)

    My packet length is 3 bytes and I am using fixed length packets  PKTCTRL1 = 0x04 and PKTLEN=3)

    For my 3 byte packets, the receive DMA structure should be set up so that the length is 3+2 and VLEN =0   Use DMA irq for receiving so set the DMA IRQ to 1 in the 8th byte of the structure.

    For the transmit side I use the RF interrupt.  The length is 3 and VLEN=0.  Don't set the DMA enable in the Tx structure.

    For testing the CRC you can sample the MSB of the 2nd appended byte or what I do it to check that the MSB of the PKTSTATUS SFR is set.

    I know there are ways to get this working without appending the extra data, but that data could be useful.

    Bill

     

  • Hi,

    yes, Bill is right: You have to setup the receiver with two bytes more than the payload actually has when using the appended bytes (what is recommended).The setup for the transmitter is just the payload length.

    regards

    spachner

    xLDen>de GoogleC
    Charles
  • Hi,

     

    I have set up the DMA with VLEN = 4, n+3 bytes because I am using variable length messages so can't use the fixed length option.

    I have tried using the RF interrupt and the DMA interrupt.

    I receive the data but the CRC bit is zero 70% of the time. Seems more of a problem on messages with 6 bytes as on the 5 byte messages.

    In another project I am using the CC1100/CC1101 and don't have this problem with the CRC.

    Bill can you explain your logic for sending 2 extra bytes?

     

    Charles

  • Hi Charles,

    I am not sending 2 extra bytes.  The chip is.  It has a feature where it appends some link quality information which is contained in the 2 bytes that they append to the packet.  See paragrpah 13.8 of the datasheet.  This feature is enabled when you set PKTCTRL1.APPEND_STATUS.

    Sending packet status or not sending it effects which interrupt you need to use (RF vs DMA) to determine that a packet has arrived (or so I've been told).

    Bill

     

  • Hi Bill,

     

    Sorry miss understanding. In your first post you mentioned that you solved it by appending the 2 byte RSSI data to all TX packets.

    DN107 explains the use of the interrupt to use for the different situations, pg 4 Interrupt Mask (IRQMASK).

    When the CRC is enabled the chip appends and sends the CRC and extracts the CRC automaticaly on the RX side. The 2 extra bytes on the RX side are for the RSSI and LQI/CRC.

    Charles

  • Hi,

     

    I have found that although I stated that packets of variable length were getting through intermittently, after some investigation packet lengths of 6 bytes, length byte + 5 data bytes, the CRC always fails and packet lengths of 5 bytes are intermittent.

    Cheers,

    Charles

  • Hi,

     

    Appologies to all for wasting your time.

    I found the problem, I had a sleep timeout setup so while the transmission was busy the CPU would sleep just incase the TX hungup. And although I was setting the timer for longer than the transmission I had forgotten about the fact that I had made the sync word 32 bits insted of the 16 bits I was using previously, so the sleep timer was expiring before the transmission compleded and setting the RF back to IDLE while the CRC was transmitting.

     

    Charles