• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 2 answers
  • Subscribers 17 subscribers
  • Views 521 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.

Original question:

TRF7970A: Problems with reading ISO14443a tag UID with TRF7970A

TRF7963A: TRF763A NFC tag read issue

Tajinder Randhawa
Prodigy 180 points
Part Number: TRF7963A


Hi I've a similar problem listed in last response from Demian in the thread: 

I'm using sloc297. There are two interrupts received one for RX and one for TX in the short duration between them, By the time, IRQ interrupt is generated, the IRQ status comes as 0xC0 indicating both TX and RX complete. I then set the TX complete flag and read the FiFO, get (0x44,00) as ATQA of the presented tag. After this the anti collision commands are run, IRQ Status is 0x0 after the IRQ is fired. 

  • 0
    TI__Guru*** 135355 points

    Hello Tajinder,

    I presume you have ported SLOC297 to another MCU?

    It sounds like you are not servicing the IRQ promptly.

    See Section 4.6 of our FAQ that covers this exact case to explain the issue and solution: http://www.ti.com/lit/pdf/sloa246

  • 0 in reply to Ralph Jacobi
    Prodigy 180 points

    Hi Ralph,

    correct, I've ported SLOC297 to NRF51. The issue I have is that GPIOTE IRQ interrupt priority can't be set higher than SPI IRQ priority otherwise SPI bus hangs during the IRQ status read after the interrupt is serviced. Making SPI priority higher than SPI seems to then delay servicing of TX complete and I receive 0xC0. TRF7963A also has HW issue where the clock priority has to be changed every time you read after a SPI write. This also adds to delay I suppose as I've to switch between Two SPI instances to implement this.

    I'm able to read ATQA correctly after I receive 0xC0. Is there any way to then read the UID after this state?

    Thanks,

    Tajinder

  • 0 in reply to Tajinder Randhawa
    TI__Guru*** 135355 points

    Hello Tajinder,

    You would need to send the next command to try and get the UID but probably need to adjust how the code works to not treat that as an error case, which would be complicated if you aren't familiar with embedded development.

    I would recommend finding a better host MCU though, you will inevitably get to a point where data corruption occurs because you didn't handle the TX complete before the RX came in.

    Or look for a more blackbox NFC chip.

    The TRF79xx are transceivers that demand the host MCU to promptly process IRQ's and data, they are powerful and flexible, but not always fit for applications with a lot of limitations. Just something to keep in mind.