TRF7960A: How to use TRF7960A

Hello Joseba,

"Do you Know how can I initialize the TRF without using the recomended code or without the need to implement a code, using the TRf in default mode, only uising the direct commands for read tag with the protocol ISO15693?"

That is impossible. The TRF7960A is a transceiver that requires the MCU to drive all communication. There is no 'read tag' direct command. You must configure the device, send packets to it, handle TX interrupt, handle RX interrupt if received, and then read out tag data from the FIFO. There is no way to circumvent these steps. If you want a device which you can just say 'read ISO15693 tag' then TI cannot help you as we do not make black box solutions for that. For our devices, the MCU must run a software stack and handle the burden of communication with the device including promptly servicing interrupts. This is why we provide firmware examples for customers to leverage.

"After this, when the reader reads a tag, an interrupt is generated. After this I should read the UID of the tag, how can I do this?"

If you service the TX complete interrupt in a timely manner (ideally immediately on reception), then when you get a second interrupt, if you read the register out it should be 0x40 or 0x60. A 0x40 means RX is complete, a 0x60 means that RX is in progress and the FIFO is almost full and must be read out immediately. At this point, you will read out the FIFO Status Register (0x1C) and see how many bytes are in the FIFO (see Page 61 of the TRF7960A datasheet for details) and then read out that many bytes from the FIFO using a Read Continuous direct command.

Also see Pages 34-37 of the TRF7960A datasheet which shows a step by step process of reading out an ISO15693 UID including the SPI captures, which you can use as a reference to compare to your own system if you can get a Logic State Analyzer or Oscilloscope to take captures of the same signals.

Hello Ralph,

Looking the code SLOC251:

__interrupt void
Trf796xPortB(void)                            // interrupt handler
{
    u08_t irq_status[4];
    
    irq_flag = 0x02;

    STOP_COUNTER;                            // stop timer mode
    
    do
    {
        IRQ_CLR;                            // PORT2 interrupt flag clear
        
        Trf796xReadIrqStatus(irq_status);

        // IRQ status register has to be read

        if(*irq_status == 0xA0)                // TX active and only 3 bytes left in FIFO
        {
            break;
        }

        Trf796xISR(&irq_status[0]);
    } while((IRQ_PORT & IRQ_PIN) == IRQ_PIN);
    //__low_power_mode_off_on_exit();
}

when an interrupt is detected, the IRQ status is read. If irq_status=0x80, the function Trf796xISR(&irq_status[0]) should manage this information. Looking for this function:

void
Trf796xISR(u08_t *irq_status)
{    
#ifdef ENABLE14443A
    u08_t    len;    
#endif

#if DBG
    UartPutByte(*irq_status);
#endif
    if(*irq_status == 0xA0)            // BIT5 and BIT7
    {                                // TX active and only 3 bytes left in FIFO
        i_reg = 0x00;
#if DBG
        UartPutChar('.');            // FIFO filling is done in the transmit function
#endif
    }

    else if(*irq_status == BIT7) //0x80
    {                                // TX complete
        i_reg = 0x00;
        Trf796xReset();                // reset the FIFO after TX 
#if DBG
        UartPutChar('T');
#endif
    }

:

}

is indicated that TX COMPLETE and the next step is the reset of the FIFO. In my opinion, the FIFO shouldn´t be deleted, because if the FIFO is empty, the reader can not answer with a 0x40 or 0x60, no?

By  the other hand, the example shown in pages 34-37 is a bit complex, I´m going to explain what I understand. After the inventory command of the figure 6-20,  in figure 6-21, an IRQ is detected and IRQ status register indicates an 0x80 (TX COMPLETED), then, the FIFO is reset. After Reset,  if a tag is in the field, another IRQ is expected. This IRQ should answer with a 0x60 or 0x40.

One of the drawbacks I see is the reset after the reading of IRQ status, with direct command 0x0F, generates the above mentioned problem. Another question is that starting from the reader works correctly, since it responds with 0x80 after a first interruption. It should be able to detect the response. Is it possible that the field is deactivated and has to be activated manually with a direct command (ENABLE RECEIVER 0x17)? In this case when should I run this command? In the initialization of the device or after the RESET that we made before the first interruption? I have used this command after the RESET and still unread cards, which I recommend?

Thanks

One of the drawbacks I see is the reset after the reading of IRQ status, with direct command 0x0F, generates the above mentioned problem. Another question is that starting from the reader works correctly, since it responds with 0x80 after a first interruption. It should be able to detect the response. Is it possible that the field is deactivated and has to be activated manually with a direct command (ENABLE RECEIVER 0x17)?

• No, the RESET command is only a reset of the FIFO, not the whole device. The RF field will remain on unless you change the settings of Register 0x00, if you execute a SOFT INIT command (0x03) which will clear register settings.

In this case when should I run this command? In the initialization of the device or after the RESET that we made before the first interruption?

• The ENABLE RECEIVER command is only used for anticollision when needing to transmit the ISO15693 slot marker, or in rare cases for advanced NFC operations to follow with NFC Forum compliance testing (far beyond your use case)

 I have used this command after the RESET and still unread cards, which I recommend?

• That may negative affect your attempt results.

I can't tell you what is going on wrong until I get some sort of SPI captures which data decoded and timing between the transmission. Without that, it is very difficult to help. If you got a Saleae and provided logic captures from it, I'd be able to find your issue quickly and help you fix it. But I'm working blind here right now so it's impossible to pinpoint what in the process is going wrong. All I can say is our code does work when implemented correctly, the project you are referencing is what is loaded into all our TRF7960AEVM's and reads all ISO15693 tags. Some step or steps of that process aren't working correctly on your MCU but without seeing SPI captures there isn't much else I can say.