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.

Understanding receiver ACKs and buffer for CC254x in Proprietary mode

Other Parts Discussed in Thread: CC2543

I'm working with the CC2543 and am completely bewildered about the automatic ACK message returned upon a successfully received message.

The User's Guide (page 241. section 23.8.3) states that there are TWO buffers associated with each of the eight RF RAM pages that serve as FIFOs for the automatic ACK.  When the receiver matches an "address", it sends one of the two buffers.  The buffer that is chosen is PRF.PRF_ADDR_ENTRYn.SEQSTAT.NEXTACK, which is a single bit indicating either acknowledge buffer 0 or 1, and n is 0-7 for the eight RF RAM pages.  What I can't figure out is how that bit is set, or how it is to be used.

In section 23.9.2.3.2 (page 249) the manuals states that PRF_ADDR_ENTRYn.SEQSTAT.NEXTACK is inverted each time a acknowledge payload is sent.  That implies it automatically "ping-pongs" between the two buffers, and THAT implies I need to have identical information in each buffer.

There are bits of information spread seemingly randomly about the manual, discussing a "sequence number".  It appears that it can somehow be used to set the NEXTACK but I can't figure it out at all.  Likewise, there is something about sequence numbers being sent in the incoming message, but it equally opaque.

What I WANT TO DO is control which ACK buffer is sent back in response to a value in the transmitted messaged.

So, questions:

1.  What the double buffering intended to be controlled, or was it intended to have the same information in both buffers and then just have them Ping-Pong?  THIS IS A BIG QUESTION. 

2.  How do I control the NEXTACK bit?  Am I suppose to control it?  I can set it manually but the users guide implies that something else controls it.

  • Hello Carl,

    1.

    The idea here is that in the case where your previous acknowledgement sent from device A to device B was lost (corrupted or not received by B) then B could re-transmit the previous message containing the same SEQ number in the payload and then A would reply with the same acknowledgement packet again. When device A receives a new packet with a new SEQ number then it will invert the NEXTACK bit and clear the length field in the used ack-payload buffer. 

    2.

    Based on the case above, let the radio control the NEXTACK bit. This is done automatically by using auto-mode. 

  • Sorry, but this doesn't help.  What we desperately need is a flow-chart or sequence diagram.  OK, I'm going to walk through the scenario above.

    1.  The originator of the message transaction (device A in your answer) sends a message with SEQ number.  (How that is set I'll ask later.)  The receiver (device B) sends an ACK from one of the two buffers.  According to the manual, the NEXTACK bit determines which buffer.  QUESTION 1:  How is NEXTACK set?  Does it have something to do with the incoming message's SEQ number?  The manual indicates (page 249) that the bit is simply inverted after the previous TX/ACK sequence.  But your answer above implies that the receiver somehow determines if the incoming message is a retransmit or a new message and that affects the NEXTACK bit.

    QUESTION 2:  How does the receiver determine if this is a retransmit?

    From what you are saying, the device inverts the NEXTACK bit.  Thus, the ACK messages will automatically "ping pong" between the two buffers.  That, in turn, implies that the two ACK message should be identical, since the transmitter can't pick which ACK will be sent.

    I REALLY wish is didn't have to keep asking all these questions, but the manual for this device is simply one of the worst I've ever had the displeasure of using.  In 285 pages, there are only a couple of figures (and the one on page 222 is wrong!) and there is not a single flowchart or sequence diagram to explain the order of steps.  In a few cases, the author describes the logical flow in a solid paragraph of text!!  He (or she) didn't even bother to write it as pseudo-code or put bullets or indents.  Does no one at TI have VISIO or any other documentation tools for explaining process?

    I have a national award from EDN magazine hanging on my office wall for a series of articles I wrote under contract for TI on DRAMs and DRAM controllers.  I know what I'm talking about when it comes to writing manuals, and the CC254x manual is god-awful.  It is as if someone took an automatic transmission apart, random threw all the pieces on a table and then proceeded to describe each nut and bolt separately without ever discussing how they all fit together or what it does.

  • Hello Carl,

    No problem. I agree, the user guide has a lot of potential for improvement. I will bring this to the round table and maybe we can add some improvements in the near future.

    BTW: did you mean that figure "Figure 23-1. Mapping of Radio Memory to MCU XDATA Memory Space" was wrong? It is correct, but it can be a little hard to read. It basically says that page 0 to 5 are all mapped to the same XDATA address from 0x6000 to 0x607F and that page 6 and 7 are mapped to each of their own XDATA address spaces on top of this.

    1)

    Yes you are correct. The NEXTACK is toggled after the reception of a new packet that contains a SEQ number that is different from the previous received SEQ number that is stored in PRF_ADDR_ENTRYn.SEQSTAT.SEQ. So if you receive a re-transmission (Read the procedure in 23.9.2.3.2 Auto Mode) the same ACK payload you sent the last time will be sent again and the NEXTACK bit will not be changed.

    This does not mean that the ACK payload will pin-pong between each received packet. It will only ping pong if every received packet is a new packet and not a re-transmission.

    2)

    The receiver compares the SEQ number from the received payload against the value stored in PRF_ADDR_ENTRYn.SEQSTAT.SEQ. If the sequence numbers are equal and PRF_ADDR_ENTRYn.SEQSTAT.VALID is 1, the two last received CRC bytes are compared against the two bytes PRF_ADDR_ENTRYn.LASTCRC. If they are equal, the packet is determined to be a re-transmission which can be ignored. The ACK message will still be transmitted in reply, but because you in this case already have read the received payload earlier you can ignore the new packet payloar. It soed not imply that the radio ignores to send an ACK in reply. It will always send ACK on received packets if it is enabled.

    Did this help?

    I can try to make a simple flowchart if some part of this was unclear.

  • The error in Figure 23-1 I mentioned is that it shows the Radio XREG running from 0x6180 to 0x61F7.  I'm pretty sure that is wrong.  The upper boundary is 0x61FF, no?

  • I think you are correct, for the radio register.