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.

TRF7964A: Read Single Block issue (corrupt last byte)

Part Number: TRF7964A

Hi,

we just hit the exact same problem as the author of the related discussion (See here). Although with a slightly different device.

Some TRF7964A on some of our PCBs occasionally transmit an erroneous value for the last byte of a block in an ISO15693 Read Single Block command. The original thread does not seem to be resolved unfortunately.

I ticked all the boxes that the TI engineer brought up at that time, but to no avail. I ended up explicitly writing all TRF configuration registers (with POR value if applicable) as part of our initialization routine. Even those that only the TRF7970 models expose. That did not change anything unfortunately.

I can confirm that setting weird values (e.g. 0x01) for the RX Wait Time Register improves the situation to some degree, but it still happens from time to time. I realize this is reckless behaviour, just thought I'd mention it.

Curious if 5 years later this rings some bell with you NFC people at TI or if you have any other suggestions as to what we might try.

Cheers

Björn

  • Might this be related to TRF7960: Last Byte of FIFO has wrong value ? Unfotunately unresolved as well.

  • So I've been digging a bit deeper and I've noticed the following:

    The sample code from SLOC297 issues a FIFO reset direct command immediately after Irq_tx is asserted:

    Our own code follows suit.

    The example given in the data sheet on the other hand (Inventory Command, SPI with SS, p. 37ff) does not seem to do this.

    So I gave it a try and ditched the FIFO reset at that point and lo and behold all my troubles are gone. It's been running for quite a while now and there are no more broken bytes and no regressions as far as I can tell.

    Can anyone explain this? Which is the way to go? Can / should this particular FIFO reset be omitted?

  • SLOA246B p10, chapter 4.6 is very explicit about a mandatory FIFO reset after Irq_tx so that settles that I guess? Still wondering why this is omitted in the data sheet example mentioned above.

    Anyway, I put the FIFO reset back in. I thought it possible that we're not servicing the TX IRQ quickly enough and I tried carving a couple of CPU cycles out of our handler code. We're now down to about 20 us from the IRQ line being asserted to reading the status register and about another 20 us from IRQ line reset to the FIFO reset command. This does noticeably improve the situation but the occasional corrupt last byte keeps sneaking in from time to time.

    I could not find any information on timing constraints for interrupt service, maybe someone could elaborate?

    Everything seems to be entirely fine without the post-TX FIFO reset though.

  • Here's another one with what looks like the same problem: TRF7962A: The UID number changes

  • Hello Customer, thank you for your question and interest in our products.

    The forum support of this product has been reduced to first reference our existing documentation and collateral. TI does not have plans to stop production or place the device into a “Not Recommended for New Design” status, we genuinely feel most questions on these devices can be answered by reviewing existing collateral and previous questions asked. Please feel free to continue to use this device as you see fit for your applications. For support, please take a look to the “Similar Topics” section at the lower right of the thread page. In addition, please consult the existing collateral in the “Technical Documentation” section of the TRF7964A product web page along with the Frequently Asked Question document. Alternatively, you can use the search engine of your choice to look for related E2E threads. With each of these resources we believe it will help with your question.

  • It seems that if we apply a Delay of at least 260 us from TX IRQ line reset to FIFO reset the problem disappears.

  • Hello Bjoern,

    thanks for your feedback.

    Then it seems I can close this thread.

    Thanks and best regards,

    Andreas.