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.

[CC112x] RX FIFO access using standard FIFO access

Other Parts Discussed in Thread: CC1120

Team,

Please let me ask about CC112x RX FIFO access using standard FIFO access. As far as I read Users Guide(Page 17, Figure 8), each length byte will be omitted.

How many frame CC1120 can store this length byte information? In the other word, Is CC1120 possible to read following maximum scenario?

Case1 - 1, D0 * 128   ->  Length byte information will be 128bytes

Case2 - 2, D0, D1 * 64   ->  Length byte information will be 64bytes

Or upto two packets are allowed?

Appreciate if I can know  if there is any limitation.

Best Regards,

Enok

  • Copied answer from another direction since respondent could not post this with some reason.

     

    ------------------------------------------------------------------------------------------------

    Hi Enok

    I am not sure I understand your question so I will try to explain how the FIFO works.

    I an application where you use variable packet length and you want to receive the whole packet before reading the RXFIFO, the max length byte you can send is 127.

    In the RX FIFO you will than have: 127, Data1, Data2, …, Data127.

    The RX FIFO is now full and you cannot receive any more packets before reading out the packet that is already there. In this case, append status must be disabled as there are no room for the status bytes

    Assume you start to read the FIFO and have read the following: 127, Data1, Data2, …, Data50.

    You have now read 51 bytes of the 128 bytes that you received, meaning that there will now be room for 51 new bytes in the FIFO. If you strobe SRX again you can for example receive a packet with length byte 50, without having the FIFO to overflow.

    If you have an empty FIFO and you enter RX mode you for example receive the following 4 packet before reading the FIFO:

    31, Data1, Data2, .., Data31, 31, Data1, Data2, .., Data31, 5, Data1, Data2, .., Data5, 57, Data1, Data2, …, Data57

    To summaries: In variable packet length mode you must always have a length byte as the first byte after sync. This byte should tell how many bytes there are in the following payload (excluding CRC/status bytes.) Max length byte is 127 when you want to receive the whole packet before reading the FIFO, and 255, if you want to read the FIFO during reception. In an application where you do not always empty the FIFO before a new packet is received it is the application that must make sure that the FIFO is emptied fast enough to avoid overflow.

    ---------------------------------------------------------------------------------------------

  • Hi Siri,

    Thanks for your clarification. I understood the variable length always requires length byte. 

    My original question is come from Direct FIFO Access. I have seen following description on Users Guide, and it looks the length byte are omitted. Therefore I understood the length information is stored to another memory. I know the question is unrealistic but that is why I'm wondering how does it work when the maximum number of packet.

      


    Which scenarios this execution will be issued? Or is there any misunderstanding of mine?

    Best Regards,

    Enok

  • Still have a problem with Siri's replying so posted instead of Siri.

    /////

    There is no problem even if the FIFO pointers gets close to 127 (end of FIFO). As long as NUM_RXBYTES is less than the FIFO size, there is "room" in the FIFO. The FIFO pointers simply wrap around to zero again. To better understand how the FIFO pointers work I suggest that you use SmartRF Studio and the "RF Device Command" window and monitor there how the FIFO pointers changes (remember to press the refresh button before reading the registers). An alternative is to write your own code and monitor the pointers for the scenarios you have questions about.

    /////

     

    Appreciated your answer.

    Best Regards,

    Enok