• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 1663 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1120 and variable packet length mode

Nicola
Intellectual 345 points
Other Parts Discussed in Thread: CC1120

Hello,

When CC1120 is configured for variable packet length mode, the CC1120 receiver reads packet length from the first byte after the sync word.

Is there a way to read the internal register holding this length?

In my driver I read received bytes from the RX FIFO when RX is in progress (i have to handle messages longer than 128 bytes);
I think it should be worth considering the case that something goes wrong and I loose the synchronization with the receiver state,
so it should be useful to me to know if the length of the message I have pulled out from FIFO is equal to the length supposed by the receiver.
CRC checking should be enough, but unfortunately the CRC check information is appended to the message, so if I loose synchronization
I loose also the position of the CRC check bit. And I don't think that reading CRC check state from a GPIO pin (configured with PKT_CRC_OK function)
works well for me, if I am pulling out bytes from the RX FIFO when RX is in progress, right?

Thank you

Nicola

 

  • 0
    TI__Guru* 85731 points

    Hi Nicola

    Not sure I understand what you want to achieve. The length the radio uses as its length byte is indeed the first byte received after sync and this is the first byte put in the RX FIFO. This means that if you want to know which byte the radio uses as its length byte, you can simply read this byte from the FIFO. If this byte reads 200, you know that the radio will receive 200 bytes (after the length byte) and put these bytes in the RXFIFO (as long as your SW reads the FIFO while in RX to make room for the complete packet).

    Even if your radio link is being corrupted (let's say after 100 bytes received), the radio will still receive 100 bytes more (as long as there is room in the RXFIFO). The CRC calculated after all 201 bytes has been received will tell you if the packet is corrupted or not.

    BR

    Siri

     

  • 0 in reply to Siri
    Intellectual 345 points

    Hi Siri,

    I was thinking of a situation in which I loose, for some reason, the information about the number of received bytes of a message. 

    For example: I poll the CC1120 and find there are some bytes on the RX FIFO. I can poll also a GPIO line configured for PKT_SYNC_RXTX detect,
    and find that a "SYNC" has been received (line high). Now I have to assume that the first byte in the FIFO is the length of the message.
    I was thinking about how happens if the first data in the FIFO is not the first byte of the message, e.g. because a problem in the SPI line when I read the last byte
    of the previous message made me thinking that I've read the byte, but in fact it was not pulled from the FIFO.
    If I check the CRC by myself, no problem. But if I want to use the hardware CRC checking capability of the CC1120, I have to assume that one bit of the
    [length + 4]th byte after what I think is the first byte contains the CRC check result, giving me a good chance to keep a wrong message as valid, and also the next...
    until I have the RX FIFO empty with the "PKT_SYNC_RXTX" GPIO line low, a situation that I can consider as "no messages in reception" (if I'm not wrong).

    I don't know if this situation should be considered so rare that I can forget about it, but thinking "just in case" I was looking for a method to detect that I am not "synchronized"
    with the radio.

    Thanks

    Nicola

  • 0 in reply to Nicola
    TI__Guru* 85731 points

    Hi Nicola

    You cannot write code that is supposed to encounter for problems with the SPI traffic etc. The SPI bus must be configured according to spec. and you r SW must be written in such a way that you always know how many bytes you have written/read etc.

    If you do not have full control over what you have read from the RXFIFO and you interpret for example byte number two of the packet as the length byte, you will then check CRC in the wrong byte and the packet is considered “wrong” (even if the radio has received good data and it is your SW that is wrong).

    The easiest is to implement a protocol where your complete packet has room in the FIFO. You will then simply strobe SRX, wait for PKT_SYNC_RXTX being de-asserted, read NUM_RXBYTES to find out how many bytes are in the RXFIFO and read all bytes.

    If you need packets longer than the FIFO you can do something like this.

    Use PKT_SYNC_RXTX  together with RXFIFO_THR (assume that the threshold is set to 50)

    Strobe SRX and wait for either falling edge interrupt on PKT_SYNC_RXTX  or rising edge interrupt on RXFIFO_THR.

    Assume the first packet you receive has length byte 30.

    You will then get a falling edge interrupt on PKT_SYNC_RXTX  telling you that the complete packet is received. If you read NUM_RXBYTES it will show 33 (length byte + 30 bytes + 2 status bytes (if append status is enabled)). You can now read all 33 bytes.

    The next packet you receive has a length byte of 75.

    You will first receive a FIFO interrupt. Since the threshold is programmed to 50 you know that you can read 50 bytes from the RX FIFO.

    The next interrupt you get will be the PKT_SYNC_RXTX  interrupt. You can now read NUM_RXBYTES, which will be 28,and you will read 28 bytes.
    You have now read a total of 78 bytes from the packet (length byte + 75 bytes + 2 status bytes (if append status is enabled)).

    If your packet is longer than the FIFO this approach will still work (but you will get several FIFO interrupt before you get the PKT_SYNC_RXTX   interrupt and can read NUM_RXBYTES and the remaining of the packet).

    If you send the following packet: 200, 1, 2, 3, 4, ….., 198, 199, 200 (2 CRC bytes are appended after the packet by the radio) and there is a error in the length byte so that the radio interpret it as 201, the radio will receive the following:

    201, 1, 2, 3, 4……, 198, 199, 200, CRC and than the second CRC byte + 1 byte of random data will be interpreted as the CRC. This will lead to a CRC error even if your payload is received OK.

    This is just the way radio communication works. Since the receives does not know what data is should receive, an error in the length field is just as bad as an error in the packet or an error in the CRC bytes L

    I hope this makes it a bit clearer when you start implementing your protocol.

    BR

    Siri

  • 0 in reply to Siri
    Intellectual 345 points

    Hi Siri,

    Ok, I got the point. My receive code is similar, although I poll the radio with a timer-driven ISR.

    Maybe the chance to get a corrupted message with CRC OK is probably greater to get a sync problem with the FIFOs...

    Thank you very much

    Nicola