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.

TRF7970A: FIFO overrun

Part Number: TRF7970A
Other Parts Discussed in Thread: RF430CL331H

Hi all,

I'm having an occasional issue where the TRF79070A FIFO overruns.  I'm hoping you can tell me why.  

The SPI trace (Saleae) between TRF7970A and STM32L4 is available here

here is a screenshot:

At 3.652+s we empty the FIFO for 98 bytes but the subsequent read of the FIFO status register says there is a buffer overrun.  The FIFO is 128 bytes so it's not clear to me why there is an overrun.

Another observation is that the NFC traffic seems pretty steady but then at 3.592+s it looks like it slows down a bit.  I'm not sure why this happens and I'm wondering if it's causing the buffer overrun.

Any insights are greatly appreciated!

Regards,

Robert Abad

  • Hello Robert,

    That is an errata item Device#B07 which explains this: www.ti.com/.../sloz011b.pdf

    Our recommendation is to mask the overflow bit and disregard it as it doesn't get set correctly in all cases.
  • Hi Ralph,

    What cases does it not get set correctly?? How do you distinguish between getting set correctly and incorrectly?

    Regards,
    Robert Abad

  • Hello Robert,

    We never uncovered a set logic to it, and all our firmware examples disregard the bit entirely. This can be done safely by simply always being able to service the FIFO watermark interrupt in a timely manner to read out FIFO data before it overfills. Doing this, we are able to meet all NFC forum specs that test data transfers and have transferred 45kB of data through the TRF7970A from the RF430CL331H.
  • The NFC stack already masks out the error bit.  So in the data I provided, was the FIFO overrun? If not, then that means the data in the FIFO was the data received from the RF430 in our NFC tag, right?

    What about the slowdown NFC transactions I mentioned in my original post? Any issues there?

  • Hello Robert,

    That file is massive so you need to give me some guidance on where exactly to look if you want me to comment about a specific section.

    As long as you received the amount of data expected, no overrun occurred. So if you read 200 bytes, and received 200 bytes, then you are fine. These checks should already be handled in the firmware as well, to ensure packets were fully transmitted or received before exiting cleanly.

    As far as the slow down is concerned, it looks like the communication just had some lag. Probably from the tag side, if it needed time to buffer data before replying. Can't say 100% sure because no IRQ line is on to indicate if the reader didn't promptly handle an IRQ. But in any case, I don't see any issues as the data read in was not anything larger than the FIFO size (less than 100 bytes) each time so nothing would have been lost because of the delay even if it was from the reader side.
  • Hello Robert,

    After further reviewing the logic file, I don’t see anything incorrect with the TRF7970A’s behavior. Yes the overflow bit was set, but the FIFO only had 98 bytes in it when it was being read out from the first IRQ, and then an RX Complete interrupt is issued with only 26 bytes left in the FIFO which are read out, ending in 0x90 0x00 which is the expected last bytes for a Read Binary. Note that 98+26 bytes also is only 124 total bytes which is less than the 127 byte FIFO so there is no way it could even have filled based on the data received.
  • Hi Ralph,

    Allow me to take a step back and give a bigger picture. ..

    We're doing an NFC transfer where the data payload is 300 bytes of:

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    repeatedly until 300 bytes are sent.

    Occasionally, there is a hiccup where the data received is:

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08            0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00                      0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09

    NOTE:  I just put the spacing in here for readability.

    When this error occurs, it coincides exactly where the FIFO overrun bit is getting set.  The byte highlighted in green is the end of the 98 byte FIFO dump.  The FIFO overrun but is set on the next FIFO STATUS REGISTER read.  Folowed by another FIFO read of 24 bytes (highlighted in red).  We expect this transaction to be over 300 bytes so it looks like some data is lost.  Further more, the FIFO read at that 24 bytes was expected to start with 0x09 (to continue the sequence) as compared to the 0x07 that was actually received.  The end of that 24 byte read is (0x90 0x00) is the end of a read binary response.  So it looks like a lot of data is lost in between.

    You mentioned that you can't see the status of the IRQ line.  Will it help if I include that in the Saleae file?

    You mentioned in a previous post that the slowdown (just before this error occurs) may be tag related.  Can you please elaborate on that?

    Regards,

    Robert

  • Hello Robert,

    Thanks for sharing the additional details. I can understand clearly why there is concern regarding the FIFO overflow bit based on the behavior you are describing, and my subsequent digging led me down a heck of a rabbit hole the past few hours. I will summarize all my observations and findings here.

    First off for a transaction of over 300 bytes, that would need to be done across multiple commands unless the NFC stack was modified to have a buffer bigger than 256 bytes. I think though in this case that data attempted being read is 249 bytes. A minor point, but I thought it best to clarify that upfront so we are on the same page.

    Secondly, the timing you mentioned where it slows down, that would just be due the amount of data transferring. I didn't see any other areas in the file sent where a comparable amount of data was exchanged. So the 'slow down' is because of the overhead of waiting for over-the-air data to be transmitted. Want to clear that up as well.

    Okay, now for the error itself. First off, when I was looking at this from a pure hardware standpoint as well as a low level driver standpoint, and reviewing what the TRF7970A was communicating from a FIFO length vs data read out standpoint, the transaction appeared to be occurring correctly. However, as we both can agree now that I understand the data dropping off issue, clearly some data didn't make it across. Furthermore, in the event data was lost over the air or not processed by the TRF7970A, then there would be a CRC error of some manner, but that didn't occur either, so either A) the data didn't get sent, or B) data was lost but not correctly reported.

    For point B, that leaves us with the odd part of the transmission on the TRF7970A side - the overflow bit, which has an errata item. Now reading through the errata and comparing it to the exact captures raises another curiosity which is that the errata states the overflow bit may be set when the FIFO is receiving more than 127 bytes but from the calculations I made, it doesn't seem that would be the case based on what is reported from the FIFO Status outputs. Compounding this curiosity is that looking into the errata item details from internal data, the behavior had been shown in Peer-to-Peer mode, but not NFC-B where the TRF7970A is the transceiver. The issue was more from the TRF7970A receiving data from another transceiver.

    From what it looks like, we have not come across a circumstance that matches up with this exact behavior.

    I would say to handle this, there are one of two things which can be done.

    Method #1:
    Have the software validate that the amount of data requested is received, and if not, re-try the transaction. Part of me feels this should already be happening, but I haven't reviewed the parts of the stack that would handle that in a while. It could also be I'm thinking of P2P and that the ISO7816 layer for Reader/Writer didn't have that check included.

    Method #2:
    Revise the TRF79xx driver to:
    A) Only mask off the FIFO overflow for P2P modes
    B) Add in error handling that when the FIFO overflow is triggered that it reports a Protocol Error to the stack.

    Both methods would result in the same end result though: A retry of the command. Therefore I would suggest method #1 so the TRF79xx driver does not need to be modified because that is more complex and would open up the possibility of causing other unwanted issues.

    However the downside of not implementing method #2 is that would be the one method to try and isolate if the issue truly is device related on the TRF7970A side, or if the tag did not send enough data. If method #2 resolved the issue fully, then it was TRF7970A related, but if the error occurs again without the overflow bit being set, then it was triggered by the tag side (and could also explain why we never saw such behavior before, because the tag would be the cause of the unusual behavior which trickled down to the transceiver).

    From a production level standpoint, method #1 really is the safer bet, but it might be worthwhile from a test and debug standpoint to implement method #2 and try and determine which device was the root cause of the behavior.

    Let me know of any questions you have regarding these findings.
  • First, let me say thanks for going thru that data file. I realize it was large and not a trivial task!!!

    Yes, we did modify the NFC stack. The off-the-shelf implementation only handled NDEF short records. We modified it so that it would handle NDEF long records as well. We have chosen a maximum size of 1024 for the NDEF long record. We believe this is working properly with the exception of when we see this issue that we are currently discussing.

    We were hoping that doing a dump of the SPI traffic between TRF7970A and STM32L4 would help us isolate if the problem was with the reader or with the tag.

    Your last post mentioned a CRC check. Does the NFC stack do a CRC check of the data it receives from the tag? If so, can you point to where that is in the stack?

  • Hello Robert,

    The CRC check is handled inside of the TRF7970A hardware. It checks the CRC for data received. If an error in transmission occurs then the CRC check will fail and the IRQ status will indicate this.